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 (I _do_ see how NBD_OPT_LIST could be a security leak on an unencrypted connection, but that's different) - so maybe we need to revisit the wording on when it is fair game for a server to reply with ERR_TLS_REQD. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature