Re: [kitten] Status update on draft-ietf-kitten-tls-channel-bindings-for-tls13-15

[tom petch <[e-mail]>]

On 28/04/2022 17:23, Benjamin Kaduk wrote:
> Hi Tom,
>
> On Thu, Apr 28, 2022 at 05:11:30PM +0100, tom petch wrote:
>> On 26/04/2022 17:35, Alexey Melnikov wrote:
>>> On 25/04/2022 16:34, Paul Wouters wrote:
>>>> i am confused how an Updates: call is depending on consensus. either
>>>> it updates something said in that document or it doesn't.
>>>>
>>>> in theory this cannot be a subjective call?
>>>
>>> The shortish version of the argument is as follows:
>>>
>>> 1) The desire to include "Updates: RFC 8446" header in
>>> draft-ietf-kitten-tls-channel-bindings-for-tls13-15 is to make the new
>>> TLS 1.3 channel binding "tls-exporter" be discoverable by SASL/GSSAPI
>>> implementors.
>>>
>>> 2) "Updates" header is typically used to make implementors of the
>>> updated RFC be aware of important fixes (in particular changes in
>>> behavior) or mandatory extensions. In the past it was sometimes used by
>>> optional extensions, but this practice is not generally supported now.
>>>
>>> 3) TLS WG now uses higher bar for other documents to include "Updates:
>>> RFC 8446". Optional extensions (such as
>>> draft-ietf-kitten-tls-channel-bindings-for-tls13-15) don't meet this bar.
>>>
>>> 4) draft-ietf-kitten-tls-channel-bindings-for-tls13-15 doesn't define a
>>> mandatory-to-implement extension for TLS 1.3 implementations. Because of
>>> 2) and 3) it must not include "Updates: RFC 8446". Additionally,
>>> implementors can discover this extension through a) IANA registry of
>>> channel bindings or b) through Updates: 5801 (SCRAM) or Updates: 5929
>>> (Channel Bindings for TLS). RFC 5801 is the most likely reason why
>>> people would implement any TLS channel binding in the first place.
>>
>> Alexey
>>
>> My initial reaction was that you were spot on but re-reading the I-D and
>> RFC, the problem is that RFC8446 says that there are no channel bindings
>> which is rather off-putting.  If it had said 'at this time' 'for future
>> study' or some such then I would not see a problem.  It is the somewhat
>> dogmatic 'are not defined for TLS1.3' that I think will mislead people
>> and warrants an update.
>
> Could you please clarify where you see RFC 8446 saying "there are no
> channel bindings"?  I thought it said that the previously defined channel
> binding types are not defined, but actually encouraged future work to
> explore the use of TLS-Exporter values as channel bindings (which this I-D
> does).  (I cound five instances of the phrase "channel binding" or "channel
> bindings" in RFC 8446, easiest to search for "binding" which has ten
> occurences, and have reviewed all five.)


Ben

I am looking at C.5 'the channel bindings described in RFC5929 are not 
defined for TLS 1.3'.

That comes across to me as negative, no hint that they can be in future. 
  TLS1.3 makes a number of things impossible, compared to TLS1.2, as 
anyone who has followed the TLS list will know so for me, that statement 
has undertones of 'and they cannot or will not be because we do not 
think that they should be'.  Those words are not there, of course, but 
that has been the message on the TLS WG list about a number of valuable 
features of TLS1.2 so anyone who has tracked the development of what is 
now TLS1.3, ab initio, may well read such a meaning into them.

I was plesantly surprised when a channel bindings for TLS1.3 I-D 
appeared but not surprised that the work has not been carried out on the 
TLS WG list, the logical home for it IMHO.

Tom Petch



>
>> Perhaps an Erratum for RFC8446 would do the trick.
>
> I don't think so, as I do not see a statement in RFC 8446 that was an error
> at the time of publication.
>
> Thanks,
>
> Ben
> .
>