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

[Alex Bligh]

On 9 Apr 2016, at 11:11, Wouter Verhelst <address@hidden> wrote:
> Since you say zero here, how is it different from OPTIONALTLS?
> 
> If "not at all", just drop optional.

As per previous message, because SELECTIVETLS requires INFO,
but OPTIONALTLS doesn't.

> I'm not *that* well versed in the details of TLS, but isn't it better to
> specify which side should go first?

I believe it's a design feature that you need not. Essentially both
parties start in a 'no handshake has taken place' state, and on the
first read or write from either end, one party starts the handshake
(and there is a provision in case they collide). Alternatively
either end can explicitly request the handshake.

There is actually an implementation advantage to the server doing it
(having just written it) which is that the server can then capture
any error (invalid credentials or whatever) and report it with whatever
logging it does for the STARTTLS option; otherwise invalid certificate
responses come with the next option it receives.

> [...]
>> +If the server receives any other option, including `NBD_OPT_INFO`
>> +and unsupported options, it MUST reply with `NBD_REP_ERR_TLS_REQD`
>> +if TLS has not been initiated; `NBD_OPT_INFO` is included as in this
>> +mode, all exports are TLS-only. If the server receives a request to
>> +enter transmission mode via `NBD_OPT_EXPORT_NAME` when TLS has not
>> +been initiated, then as this request cannot error, it MUST
>> +disconnect the connection. If the server receives a request to
> 
> s/disconnect/terminate/ reads slightly better.

OK

> [...]
>> +The client MUST NOT issue `NBD_OPT_STARTTLS` unless the server
>> +set flag NBD_FLAG_FIXED_NEWSTYLE and the client replied
>> +with NBD_FLAG_C_FIXED_NEWSTYLE in the fixed newstyle
>> +negotiation.
> 
> Why not "unless fixed newstyle negotiation is in effect"? No need to
> repeat that definition.

Can do; I just wanted to be explicit that both server and client
must support it.

> 
> [...]
>> +### Security considerations
>> +
>> +#### TLS versions
>> +
>> +NBD implementations supporting TLS MUST support TLS version 1.2,
>> +SHOULD support any later versions, and MAY support older versions.
> 
> I would prefer "SHOULD NOT allow TLS versions older than 1.2" here.
> There are some serious flaws in older TLS versions; currently these are
> still supported by most web browsers for backwards compatibility
> reasons, but that does not apply for us.

I'd be all for that. Or certainly "SHOULD NOT support LS versions older
than 1.2 by default" (gonbdserver allows you to configure minimum and
maximum TLS versions).

-- 
Alex Bligh