Subject: [kitten] Martin Duke's Discuss on draft-ietf-kitten-tls-channel-bindings-for-tls13-14: (with DISCUSS)

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 23 Feb 2022 11:41:36 -0800

Martin Duke has entered the following ballot position for
draft-ietf-kitten-tls-channel-bindings-for-tls13-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A simple thing: the document header should state that it updates RFC 8446.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 23 Feb 2022 11:43:17 -0800

> https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/

No, it should not.

This topic was discussed with the TLS WG and there was strong feedback that
the use of the "Updates:" header was inappropriate.

See the thread at
https://mailarchive.ietf.org/arch/msg/tls/vH74JoSGYpJv7Tcem60L3RtNa9U/

-Ben

---

From: Martin Duke <[email-masked]>
Date: Wed, 23 Feb 2022 11:49:13 -0800

Very well, DISCUSS updated.

On Wed, Feb 23, 2022 at 11:43 AM Benjamin Kaduk <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/blog/handling-iesg-ballot-positions/

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 23 Feb 2022 15:26:00 -0500

I do not believe there was consensus one way or another on this.

The strong feedback was by one or two members of the TLS working group
and I do not believe it was correct or represented consensus. Unless
those people that complained *do* represent consensus among that working
group and intend to block publication of this document based on it (and
if they do, I wish they had said so earlier during the discussion and
not let the matter drop), I would like it to move forward with the
"updates" line in place if at all possible.

—Sam

On Wed, Feb 23, 2022, at 14:43, Benjamin Kaduk wrote:
>> Martin Duke has entered the following ballot position for draft-ietf-kitten-tls-channel-bindings-for-tls13-
>> 14: Discuss
>>
>> email addresses included in the To and CC lines. (Feel free to cut
>> this introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more
>> information about how to handle DISCUSS and COMMENT positions.
>>
>>
> This topic was discussed with the TLS WG and there was strong feedback
> that the use of the "Updates:" header was inappropriate.
>
> See the thread at

-- 
Sam Whited

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 23 Feb 2022 12:59:26 -0800

Hi Sam,

I think that the proximate topic here is that Martin is noticing a mismatch
between the in-document header (the "Updates:" header) and the prose of the
document.  That's my fault; I sent you suggestions that removed the header
but forgot to touch the prose at all, and if I had done so, I don't think
Martin would have raised the topic (Martin, please correct me if I'm
wrong).

On the question of whether or not "updates" is correct, I think that
https://mailarchive.ietf.org/arch/msg/tls/YZQWmP_8BDkacfy3O-qcy8EV2N0/
(from a TLS WG co-chair) is a good summary -- the current "normal" for TLS
is to not use the header for this sort of thing.

It also notes that the question of what text (if any) to put in the ongoing
8446bis effort is more important, long-term, than whether to use the
"updates" header here.  That is, RFC 8446 itself will probably only be
current for a couple years and then the successor will be current, so any
"updates" relationship would become stale at that point.

-Ben

P.S. Sean also mentioned draft-ietf-ace-coap-est in the linked message, and
there are changes in flight for that document to refer to
draft-ietf-kitten-tls-channel-bindings-for-tls13

---

From: Martin Duke <[email-masked]>
Date: Wed, 23 Feb 2022 13:08:42 -0800

Yep , I have no opinion on whether it should be updated, but the header and
the text should match.

That said, if there is no consensus that seems like a bigger issue.

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 23 Feb 2022 16:40:56 -0500

I see, I missed that the suggested changes had removed this, or possibly
forgot to bring it up before applying them. If the text no longer
matches the header I agree they should match, but I still feel strongly
that this should in fact update TLS 1.3, which makes it sound as if
there are no channel bindings for TLS 1.3 (except now there are, so that
sounds like an update to me and something that's important to make
discoverable).

—Sam

On Wed, Feb 23, 2022, at 16:08, Martin Duke wrote:
> Yep , I have no opinion on whether it should be updated, but the
> header and the text should match.
>
>> I think that the proximate topic here is that Martin is noticing a
>> mismatch between the in-document header (the "Updates:" header) and
>> the prose of the document.  That's my fault; I sent you suggestions
>> that removed the header but forgot to touch the prose at all, and if
>> I had done so, I don't think Martin would have raised the topic
>> (Martin, please correct me if I'm wrong).
>>
>> (from a TLS WG co-chair) is a good summary -- the current "normal"
>> for TLS is to not use the header for this sort of thing.
>>
>> It also notes that the question of what text (if any) to put in the
>> ongoing 8446bis effort is more important, long-term, than whether to
>> use the "updates" header here.  That is, RFC 8446 itself will
>> probably only be current for a couple years and then the successor
>> will be current, so any "updates" relationship would become stale at
>> that point.
>>
>> -Ben
>>
>> P.S. Sean also mentioned draft-ietf-ace-coap-est in the linked
>>      message, and there are changes in flight for that document to
>>      refer to draft-ietf-kitten-tls-channel-bindings-for-tls13
>>
>> > The strong feedback was by one or two members of the TLS working
>> > group and I do not believe it was correct or represented consensus.
>> > Unless those people that complained *do* represent consensus among
>> > that working group and intend to block publication of this document
>> > based on it (and if they do, I wish they had said so earlier during
>> > the discussion and not let the matter drop), I would like it to
>> > move forward with the "updates" line in place if at all possible.
>> >
>> > —Sam
>> >
>> > >> When responding, please keep the subject line intact and reply
>> > >> to all email addresses included in the To and CC lines. (Feel
>> > >> free to cut this introductory paragraph, however.)
>> > >>
>> > >>
>> > >> Please refer to
>> > >> https://www.ietf.org/blog/handling-iesg-ballot-positions/ for
>> > >> more information about how to handle DISCUSS and COMMENT
>> > >> positions.
>> > >>
>> > >>
>> > > This topic was discussed with the TLS WG and there was strong
>> > > feedback that the use of the "Updates:" header was inappropriate.
>> > >
>> > > See the thread at

-- 
Sam Whited

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 Feb 2022 18:48:18 -0800

I had planned to highlight that change a bit more prominently in my thread
with you, but I guess I got distracted or something.  I'm sorry to have it
come as a surprise in this thread.

My stance here is roughly:

- the TLS WG is pretty authoritative on what RFCs should Update: the RFCs
  that it produced

- the TLS WG recent practice for (not) using Updates: would fall towards
  "not" in this scenario

- with the publication of TLS 1.3, the TLS WG has established a practice of
  having rigorous formal analysis of the security properties of its output
  where cryptography is involved, even going so far as to explicitly build
  in time to the document lifecycle for such analysis to take place prior
  to IETF last call.  Other security-area WGs have adopted similar
  practice, though it is not universal (and cannot be universal given the
  resources available in the different WGs).  The exporter-based channel
  binding this document defines is not analyzed in such a way, and
  realistically cannot be so analyzed, for the very reasons now documented
  in the security considerations.  That analysis does exist for the
  exporter construct in general, under certain assumptions, but that
  analysis covers only the output of the TLS exporter, not its use as an
  input for the channel binding schemes that consume it.  So, the bar in
  practice of the TLS WG for the amount of analysis a cryptographically
  relevant protocol (extension) received has not been met here (though the
  bar of the KITTEN WG has been met), and so I wouldn't expect the TLS WG
  to conclude that this scheme is ready to be rolled in to be "part of TLS
  1.3" at this time, which is what an "Updates: 8446" status would signal
  to many people.  (The precise meaning of the tag is, unfortunately, quite
  under-specified and a topic on which many emails have been spent in the
  IETF.)

Accordingly, I don't think there's enough reasoning and consensus to
support having this document Update: RFC 8446.

I do, however, think that this is a great opportunity to think about what
draft-ietf-tls-rfc8446bis should say about channel bindings.  While it
remains true that "the channel bindings described in [RFC5929] are not
defined for TLS 1.3", there are analogous (arguably, better) channel
bindings that are defined, and it would be a shame if 8446bis didn't say
anything about them.

-Ben