Re: [Nbd] [PATCHv3] Improve documentation for TLS
- To: Wouter Verhelst <w@...112...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, "Daniel P. Berrange" <berrange@...696...>, "qemu-devel@...530..." <qemu-devel@...530...>
- Subject: Re: [Nbd] [PATCHv3] Improve documentation for TLS
- From: Alex Bligh <alex@...872...>
- Date: Sat, 9 Apr 2016 12:55:28 +0100
- Message-id: <C9155C63-9883-4C61-B5C8-2D8CE0BABC71@...872...>
- In-reply-to: <20160409113811.GT19023@...3...>
- References: <1460053967-65141-1-git-send-email-alex@...872...> <20160409101117.GI19023@...3...> <9AD6CFB3-011D-42FF-8652-5BCBF085BE57@...872...> <20160409103828.GO19023@...3...> <7E2CCD80-B06D-4F69-87C2-49F703545E00@...872...> <20160409113811.GT19023@...3...>
Wouter,
On 9 Apr 2016, at 12:38, Wouter Verhelst <w@...112...> wrote:
> On Sat, Apr 09, 2016 at 12:21:03PM +0100, Alex Bligh wrote:
>> An alternative route would be to delete OPTIONALTLS, and make some of
>> the MUST requirements in SELECTIVETLS say "MUST xyz unless there are
>> no TLS-only exports". However, this makes it rather harder to read,
>> so I described that case as a separate mode.
>
> I understand now.
>
> However, although I disagree with Daniel on the idea of having a server
> which can (in the same process) support both TLS-enabled and
> non-TLS-enabled exports, I do agree with him that what you call
> OPTIONALTLS is a bad idea, and that it should be discouraged.
>
> Mentioning that option explicitly is counter to that goal, and I would
> therefore prefer that you not add it.
>
> Also, while we try to negotiate the protocol in such a way that things
> remain compatible between implementations who implement a disjoint set
> of features from the protocol, I think the long-term goal should be that
> STARTTLS and INFO are supported by all implementations (or at least,
> that INFO is). In that context, explicitly explaining (in much detail)
> what happens when a client doesn't support INFO but does support
> STARTTLS seems contraproductive.
>
> So I'd just drop optional.
OK. I will kill it in v6.
In practice it means 'if you want to export some things with
TLS and some without then you need to implement INFO'.
This would be a *good* thing if INFO is brought into the main
standard (i.e. taken beyond experimental). Eric's just sent
patches for Qemu to qemu-devel. I need to check the implementation
on my server is still compliant, but it's basically done. So
I may argue for INFO to be put into the body of the standard.
>>>> I'd be all for that. Or certainly "SHOULD NOT support LS versions older
>>>> than 1.2 by default"
>>>
>>> Or that. The point is that doing TLS < 1.2 is stupid, especially for a
>>> new protocol, so I think we should make it explicit that clients should
>>> not try that save in exceptional circumstances.
>>
>> +1. Do you want to ping me when you have had a chance to review v5 and
>> I will collate all of these in to a v6?
>
> I have, but did not have any further comments.
Great. v6 coming up.
--
Alex Bligh
Reply to: