[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] doc/proto.md: TLS question



Wouter,

On 6 Apr 2016, at 22:04, Alex Bligh <alex@...872...> wrote:

>>>>> I think this should thus be deleted.
>>>> 
>>>> No, it must stay.
>>>> 
>>>> There's currently no way to detect whether a particular export supports
>>>> TLS. If the client wants to connect to an export that the server only
>>>> exports through TLS, then the server must drop the connection upon
>>>> NBD_OPT_EXPORT_NAME. This is part of why we need INFO/GO.
>>>> 
>>>> INFO/GO modifies TLS_REQD in that it makes it legal for TLS_REQD to be
>>>> sent as an error reply *for those two requests* if a particular export
>>>> requires TLS but another one does not. Once the INFO extension is no
>>>> longer experimental, the above-quoted language will indeed need to be
>>>> changed, but for now a server can only send it in the "I don't do no
>>>> steenking cleartext" case, and then that language is correct.
>>> 
>>> Mmmm... I think it could be 'improved' then :-)
>> 
>> That isn't something I'm opposed to :-)
> 
> OK I'll have a go. Something there also mentions NBD_PEEK_EXPORT
> I think so I'll fix that too.

I've just sent through a patch which (I hope) clarifies
greatly the documentation.

I think part of the difference is what one means by 'optional'
in the sense of a NBD server. Originally (before NBD_OPT_INFO)
I think optional was meant to mean 'either TLS or not, whatever
export you choose', whereas NBD_OPT_INFO definitely permits
'selective' tls, i.e. some exports are tls-only, and some are
either. In fact I think selective TLS (as well as optional
TLS) should be permitted without NBD_OPT_INFO, and whilst
it's ugly as sin without NBD_OPT_INFO, actually TLS as a whole
is pretty ugly without NBD_OPT_INFO.

I've tried to set these out in my document. If you think selective
TLS should not be permitted without NBD_OPT_INFO support, we
just need to change a few 'SHOULD's to 'MUST's.

I've added Daniel & qemu-devel added as CC to the patch (but not
this message) as I think qemu is the only user, apart from
my gonbdserver (with which it interoperates successfully), so
perhaps best move the conversation to that.

-- 
Alex Bligh







Reply to: