Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

[Alex Bligh]

On 9 Apr 2016, at 10:36, Wouter Verhelst <address@hidden> wrote:

>> +These modes of operations are described in detail below.
>> +
>> +#### NOTLS mode
>> +
>> +If the server receives `NBD_OPT_STARTTLS` it MUST respond with
>> +`NBD_REP_ERR_UNSUPP`. The server MUST NOT respond to any
> 
> No. UNSUP (one P) is reserved for "this server doesn't support that"
> (i.e., backwards compatibility). Not configured for supporting TLS would
> be NBD_REP_ERR_POLICY.

'P' fixed in later draft.

Right, but a server which doesn't actually have TLS at all will
by definition be running in NOTLS mode, and thus will be replying
NBD_REP_ERR_UNSUP (because that's what you reply with if you
receive an option you don't understand). Allowing NBD_REP_ERR_POLICY
to be sent as as a reply too would be fine.

> 
>> +command with `NBD_REP_ERR_TLS_REQD`.
>> +
>> +#### OPTIONALTLS mode
>> +
>> +If the server receives `NBD_OPT_STARTTLS` it MUST reply with
>> +`NBD_REP_ACK`. After this reply has been sent, the server MUST
>> +be prepared for a TLS handshake, and all further data MUST
>> +be sent and received over TLS. There is no downgrade to a
>> +non-TLS connection.
>> +
>> +As per the TLS standard, the handshake MAY be initiated either
>> +by the server (having sent the `NBD_REP_ACK`) or by the client.
>> +If the handshake is unsuccessful (for instance the client's
>> +certificate does not match) the server MUST disconnect as
>> +by this stage it is too late to continue without TLS as the
>> +acknowledgement has been sent.
>> +
>> +The server MUST NOT respond to any command with `NBD_REP_ERR_TLS_REQD`,
>> +as TLS is optional.
> 
> I think this mode is effectively the same as what you call selective,
> modulo that no exports have any TLS requirements, so I wouldn't specify
> it as a separate mode of operation (save perhaps that you may want to
> discourage it)

See the section on 'degenerate cases' in the last version. I agree
OPTIONALTLS is not to be encouraged, however it's there so it's possible
for a server to provide optionality when it doesn't support INFO.
As INFO is merely experimental, I didn't want to make a 'MUST' dependency
on it and thus lose all ability to do optional TLS without INFO.

>> +The FORCEDTLS mode of operation has an implementation problem in
>> +that the client MAY legally simply send a `NBD_OPT_EXPORT_NAME`
>> +to enter transmission mode without previously sending any options.
>> +Therefore, if a server uses FORCEDTLS, it SHOULD implement the
>> +INFO extension.
> 
> Right. Clearly this can't be a must, because qemu already implements
> this and doesn't do INFO :-)

Yeah though Eric has (I think) submitted a patch to qemu to support
that.

> 
> [...]
>> +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.

> 
> [...]
>> +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.

> 
> [...]
>> +appropriate credentials for this server). If the client
>> +receives `NBD_REP_ERR_TLS_REQD` in response to
>> +`NBD_OPT_INFO` or `NBD_OPT_GO` this indicates that the
>> +export referred to within the option is either non-existent
>> +or requires TLS; the server MAY therefore choose to issue
> 
> client, not server

Again, EEE fixed this.
> 
>> +a `NBD_OPT_STARTTLS`, MAY disconnect the session (if
>> +for instance it does not support TLS or does not have
>> +appropriate credentials for this server), or MAY continue
>> +in another manner without tls, for instance by querying
>> +or using other exports.
>> +
>> +The client MAY discover the server operates in NOTLS mode by
>> +sending `NBD_OPT_STARTTLS`. If `NBD_REP_ERR_UNSUPP` is
>> +replied, it is guaranteed the server is not in this mode.
> 
> UNSUP or POLICY

OK

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

> 
> [...]
>> - `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
> 

-- 
Alex Bligh