[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] [Qemu-devel] [PATCH v2 3/3] doc: Propose Structured Read extension



On Wed, Mar 30, 2016 at 11:12:29PM -0600, Eric Blake wrote:
> On 03/30/2016 01:51 PM, Wouter Verhelst wrote:
> >>
> >> I'm a bit reluctant to put ordering requirements on option haggling
> >> (that option A must be turned on before option B),
> > 
> > Yes, me too.
> > 
> >> but then again, the
> >> SELECT extension requires NBD_OPT_SELECT to be haggled prior to
> >> NBD_OPT_GO, so there's precedent.
> > 
> > Yeah, but then, that's only because GO is meant to transition from
> > negotiation to transmission, so it needs to be after *any* other
> > negotiation; anything else would defeat its purpose.
> > 
> 
> We have another ordering dependency: NBD_OPT_STARTTLS must be haggled
> BEFORE any other option (except NBD_OPT_SELECT), because we document
> that the server SHOULD send NBD_REP_ERR_TLS_REQD in reply to any other
> non-encrypted option, at least when there are no exports that do not
> require encryption.  Technically, I don't see how haggling structured
> replies before encryption is a data leak

It's not as much about eavesdropping as it is about KISS. If all the
server's exports *require* TLS, the client *will* need to negotiate TLS
at some point before going to transmission (no way around that). Since
some options may leak data, it is best that TLS is negotiated at some
time before negotiating those options.

Yes, we could categorize each and every option and say whether TLS_REQD
makes sense for that one, but that's a lot of work for little to no
benefit.

Currently the situation is:

- server doesn't support TLS: no TLS_REQD
- server supports TLS but doesn't require it: no TLS_REQD
- server supports TLS and requires it: TLS_REQD on everything except
  STARTTLS
- SELECT extension adds the possibility of "no TLS_REQD on anything,
  except on SELECT for an export that individually requires TLS"

This is simple and easy to understand. If we start modifying that to
"TLS_REQD on this list of commands, but not on those, except if a, but
do so if B" etc, then it becomes rather convoluted rather soon for
little benefit

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Attachment: signature.asc
Description: PGP signature


Reply to: