On 04/05/2016 09:24 AM, Alex Bligh wrote:
> Eric,
>
> (apologies for using the wrong email address for me, which may mean my text didn't
> get to the list - correct one inserted)
The list (should) accept posts from non-subscriber addresses (at any
rate, I had several posts show up before I subscribed with all the
flurry going on this week...), although it may have a moderation delay.
>> I'm a bit worried about the sequence of:
>>
>> NBD_OPT_SELECT (name): succeeds
>> NBD_OPT_STARTTLS
>> NBD_OPT_GO (no name)
>>
>> The first SELECT means that I want to visit 'name', and the server
>> succeeds because it is willing to offer the export without TLS. But
>> then I go ahead and negotiate TLS anyways, which wipes out the current
>> selection.
>
> I'm a bit confused as to why "negotiating TLS clears the selected export".
> This seems a needless complication, but I'm sure there is some security
> reason I've missed.
Plausible security reason, as follows:
Before TLS, the server can be queried about any export name, and MUST
return success for names that it is willing to export unencrypted, and
error with TLS_REQD on any export that it is unwilling to expose without
TLS - but merely exposing the name of devices that require TLS may be an
information leak (where you don't want the client to learn about such
names until after it has done TLS). So a server MAY report
NBD_REP_ERR_TLS_REQD even on names that don't exist, rather than
NBD_REP_ERR_UNKNOWN (and we should probably tweak the text to make this
clear). Then, after TLS, the server MUST NOT acknowledge any names that
it is not willing to actually export under encryption, regardless of
what it advertised before TLS..
I see this working in two different directions:
If the server replied with 'TLS_REQD' on a pre-TLS request for 'bar'
(out of policy for all names, whether or not they exist, to avoid
leaking information), and the client has now negotiated TLS, we want the
client to re-request 'bar' to learn whether it actually exists, and not
whether the server was just giving a default error.
Conversely (although a bit more of a stretch), there may be
configurations where a server is instructed to expose name 'foo' _only_
when unencrypted (maybe because 'foo' is not security-critical, and we
don't want to burn CPU time in encrypting the connection). If we
selected 'foo' prior to TLS (and got success) but starting TLS did not
clear out the selection, then attempting to NBD_OPT_GO with the last
successful SELECT ('foo') would fail, whereas we generally want
NBD_OPT_GO with last-selected name to succeed if NBD_OPT_SELECT
succeeded. Requiring the client to redo NBD_OPT_SELECT would properly
get NBD_REP_ERR_UNKNOWN after TLS if 'foo' can only be accessed without
encryption.
But in either scenario, it looks like your recommendation of
NBD_OPT_GO+name would be useful after TLS has completed to get either a
sane error about name not existing, or successful transition to
transmission, without needing a second NBD_OPT_SELECT that was used
prior to TLS. (That is, your proposal compresses things from
SELECT/STARTTLS/SELECT/GO down to SELECT/STARTTLS/GO+name).
> I'm more arguing that the current spec is experimental, and the
> point about experimental bits of the specs is we can make changes,
> particularly ones that only affect edge case.
Indeed, and the more I see your arguments about an optional name to
NBD_OPT_GO, the more it seems like a spec change should be okay.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature