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

[Sam Whited <[e-mail]>]

It seems that I was wrong about there being no consensus since it does
seem like everyone is speaking in favor of making this change and no one
but me is in support of leaving it as is. I still strongly feel that the
WG is incorrect and that leaving it off is a bad idea, but in the
interest of cooperation I will make the change.

—Sam

On Mon, May 2, 2022, at 15:37, Paul Wouters wrote:
> On Tue, Apr 26, 2022 at 6:35 PM Alexey Melnikov
> <[e-mail]> 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.
>>
>> Best Regards,
>>
>> Alexey
>>
>
> Thanks for the update. Based on this, plus Ben Kaduk's investigation
> into the consensus, plus my own reading that I believe that there is
> no need for an Update: clause. I set my ballot to DISCUSS to resolve
> this issue before the document can proceed.
>
> As suggested, an Errata can be filed for 8446 to leave a pointer that
> the statement is no longer correct.
>
> Sam, as the author of a WG document, you should be making the change
> requested by the WG. If you really are not planning to make this
> change, the WG chair can either add another author to make the change
> or we can make the changes in AUTH48. But obviously, the easiest is if
> you would just proceed with this as per WG request.
>
> Thank you,
>
> Paul
>
>
>
>
>
>>
>> > Sent from my iPhone
>> >> On Apr 25, 2022, at 16:11, Alexey
>> >> Melnikov<[e-mail]>
>> wrote:
>> >>
>> >> Quick status update on this.
>> >>
>> >> draft-ietf-kitten-tls-channel-bindings-for-tls13-15 includes
>> >> "Updates:
>> RFC 8446".
>> >>
>> >> After reviewing various mailing list discussions, I confirm that
>> inclusion of this header in the draft doesn't represent IETF
>> consensus. So the header needs to be taken out. Sam, I know that this
>> is not what you personally prefer, but are you willing to make the
>> change?
>> >>
>> >> The document also needs to have a "Yes" ballot from one of current
>> >> IESG
>> members. So I separately asked Paul Wouters (our new Sec AD) to do
>> the document review.
>> >>
>> >> Best Regards,
>> >>
>> >> Alexey, as a KITTEN chair
>> >>
>> >>
>>

-- 
Sam Whited