On 5 Apr 2016, at 16:47, Eric Blake <eblake@...696...> wrote:
> 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.
Mmmm... right, but if the client is requesting NBD_CMD_SELECT before
TLS then a third party can snoop on that anyway (whatever the
server replies). IE the client should not do that.
If the client is itself the attack vector, as you say the server
can respond NBD_REP_ERR_TLS_REQD to anything that is either unknown
or receives TLS. I think 'MUST NOT' is a bit strong. The server
might not care who knows what disks it has. It also reveals that
at least one disk is available under TLS.
But as far as I can see nothing turns on whether the server
REMEMBERS the choice since before the TLS negotiation.
What I presumed was the reason was that the client could try
selecting disk 'foo' prior to the TLS, but a man-in-the-middle
could (whilst cleverly hijacking the TCP session) change this
to a select of disk 'bar' (which might be his own and laden
with malware). The client would then negotiate TLS, and issue
a NBD_OPT_GO on the 'wrong' disk. This is stretching credibility
a little but the easy solution is either if clients have
already selected a disk prior to negotiation, they SHOULD
reselect it afterwards, or alternatively (cough) that they
should specify their disk name in NBD_OPT_GO (with my
proposal).
> 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.
That would be my take.
> 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.
That's a bit of a stretch, yes. But that would be a way out.
> 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).
Yeah.
>> 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.
OK I will get on with that.
--
Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail