[Nbd] option haggling: reordering and TLS

[Wouter Verhelst <w@...112...>]

Something just occurred to me.

A client sends:
NBD_OPT_LIST
NBD_OPT_STARTTLS

without waiting for replies from the server. The server hasn't finished
replying to NBD_OPT_LIST yet (although it may have started) by the time
it sees NBD_OPT_STARTTLS.

One way to reply to this could be to send NBD_REP_ACK(NBD_OPT_STARTTLS)
before the NBD_REP_ACK(NBD_OPT_LIST). At that point, the client hasn't
seen the full reply to NBD_OPT_LIST (if it has seen anything at all).

How do we handle this?

- We can say that this is not allowed (an upgrade to TLS can only be
  performed once all outstanding requests have been handled)
- We can say that this is allowed, and that upgrading to TLS cancels all
  outstanding requests.
- We can say that this is allowed, and that upgrading to TLS does *not*
  cancel all outstanding requests.

The first is easiest to implement, but adds ordering requirements. The
second is harder to implement, but can allow the server to leak less
data. In both cases, a client will likely issue another NBD_OPT_LIST in
the TLS channel, so the first (certainly) as well as the second
(possibly) provides plaintext for an eavesdropper, which will allow the
latter to perform a known-plaintext attack.

The third does away with the known plaintext issue, but it does make it
much much harder for a client to keep track of things.

Thoughts?

-- 
< 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