[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS
From: |
Wouter Verhelst |
Subject: |
Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS |
Date: |
Sat, 9 Apr 2016 12:33:18 +0200 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Sat, Apr 09, 2016 at 11:04:09AM +0100, Alex Bligh wrote:
[...]
> > [...]
> >> +The server MUST NOT send `NBD_REP_ERR_TLS_REQD` in reply to
> >> +any command if TLS has already been neogitated. The server
> >
> > negotiated
>
> I'd make sure you're looking at the latest version as Eagle Eyed Eric
> pointed out a whole pile of these.
Yeah, I noticed :-)
> > [...]
> >> +The client MAY send `NBD_OPT_STARTTLS` at any time to initiate
> >> +a TLS session, except that the client MUST NOT send
> >> +`NBD_OPT_STARTTLS` if TLS has alreay been initiated. If the
> >> +cllient receives `NBD_REP_ACK` in response, it
> >> +MUST immediately upgrade the connection to TLS. If it receives
> >> +`NBD_ERR_REP_UNSUP` in response or any other error, it indicates
> >> +that the server cannot or will not upgrade the connection to
> >> +TLS and therefore MUST either continue the connection without
> >> +TLS, or discconnect.
> >
> > That, or NBD_REP_ERR_POLICY.
>
> Yeah I can make that an alternative.
POLICY is the correct message; UNSUP is the alternative ;-)
(as in "for backwards compatibility, a client should also be prepared...")
[...]
> > (actually, "any error". If STARTTLS errors, the server effectively does
> > not support TLS)
>
> Well NBD_REP_ERR_INVALID means "The option sent by the client is known by
> this server, but was determined by the server to be syntactically invalid."
> which means the client has done something wrong. Given we've defined the
> legal responses to NBD_OPT_STARTTLS I'd rather keep that one.
Fair enough. Also, INVALID is the correct error message when the client sent
NBD_OPT_STARTTLS while inside a TLS connection, too, so that would've been a
contradiction ;-)
> > [...]
> >> - `NBD_OPT_STARTTLS` (5)
> >>
> >> - The client wishes to initiate TLS. If the server replies with
> >> - `NBD_REP_ACK`, then the client should immediately initiate a TLS
> >> - handshake and continue the negotiation in the encrypted channel. If
> >> - the server is unwilling to perform TLS, it should reply with
> >> - `NBD_REP_ERR_POLICY`. For backwards compatibility, a client should
> >> - also be prepared to handle `NBD_REP_ERR_UNSUP`. If the client sent
> >> - along any data with the request, the server should send back
> >> - `NBD_REP_ERR_INVALID`. The client MUST NOT send this option if
> >> - it has already negotiated TLS; if the server receives
> >> - `NBD_OPT_STARTTLS` when TLS has already been negotiated, the server
> >> - MUST send back `NBD_REP_ERR_INVALID`.
> >> -
> >> - This functionality has not yet been implemented by the reference
> >> - implementation, but was implemented by qemu so has been moved out of
> >> - the "experimental" section.
> >> + The client wishes to initiate TLS.
> >> +
> >> + The server MUST either reply with `NBD_REP_ACK` after which
> >> + point the connection is upgraded to TLS, or reply with
> >> + `NBD_REP_ERR_UNSUP`.
> >
> > (or POLICY)
>
> OK
--
< 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
- Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS, (continued)
Re: [Qemu-devel] [PATCH] Improve documentation for TLS, Eric Blake, 2016/04/07
Re: [Qemu-devel] [PATCH] Improve documentation for TLS, Eric Blake, 2016/04/07
Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS, Wouter Verhelst, 2016/04/09