Subject: [kitten] Roman Danyliw's Discuss on draft-ietf-kitten-tls-channel-bindings-for-tls13-14: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 28 Feb 2022 13:43:53 -0800

Roman Danyliw 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/about/groups/iesg/statements/handling-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:
----------------------------------------------------------------------

** On the issue of what behavior is MTI, Section 5.2 of Section RFC5801 and
Section of RFC5802 say:

(a)   'tls-unique' is the default channel binding type for any application
   that doesn't specify one.

(b)   Servers MUST implement the "tls-unique" [RFC5929] channel binding
   type, if they implement any channel binding.

Section 3 of this document says:

(c) As "tls-unique" is not defined for TLS 1.3 (and greater), this
   document updates [RFC5801], [RFC5802], and [RFC7677] to use "tls-
   exporter" as the default channel binding over TLS 1.3 (and greater).
   Note that this document does not change the default channel binding
   for SCRAM mechanisms over TLS 1.2 [RFC5246], which is still "tls-
   unique".

No problem with the guidance in (c).  Without specific citations being made,
I’m inferring that (c) is intended to “update”/clarify (a) in a TLS 1.3 context.

To the issue of MTI, (c) is silent on the guidance in (b).  Since “tls-unique”
is not defined for TLS 1.3, how would an implementer comply in the case of a
server that is TLS 1.3 only?  Should this document make a statement to the
effect of “tls-exporter” is MTI for any servers implementing TLS 1.3?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document to ensure TLS 1.3 support in SCRAM and GSS-API.

Per how this document is updating other documents:

** The “updates” header doesn’t note RFC8446 but the abstract and Section 1
suggest that this document does update it.  Per Martin Duke’s DISCUSS point
(which I support), please clarify.

** Per Section 3
  … this
   document updates [RFC5801], [RFC5802], and [RFC7677] to use "tls-
   exporter" as the default channel binding over TLS 1.3 (and greater).

In what way is RFC7677 being updated?  If RFC5802 is already updated to
required tls-exporter for TLS 1.3 what additional guidance is needed for
RFC7677?

---

From: "Sam Whited" <[email-masked]>
Date: Mon, 28 Feb 2022 17:39:08 -0500

On Mon, Feb 28, 2022, at 16:43, Roman Danyliw via Datatracker wrote:
> (a)   'tls-unique' is the default channel binding type for any
>       application that doesn't specify one.
>
> (b)   Servers MUST implement the "tls-unique" [RFC5929] channel
>       binding type, if they implement any channel binding.
>
>     exporter" as the default channel binding over TLS 1.3 (and
>     greater). Note that this document does not change the default
>     channel binding for SCRAM mechanisms over TLS 1.2 [RFC5246], which
>     is still "tls-unique".
>
> No problem with the guidance in (c).  Without specific citations being
> made, I’m inferring that (c) is intended to “update”/clarify (a) in a
> TLS 1.3 context.
>
> To the issue of MTI, (c) is silent on the guidance in (b).  Since “tls-
> unique” is not defined for TLS 1.3, how would an implementer comply in
> the case of a server that is TLS 1.3 only?  Should this document make
> a statement to the effect of “tls-exporter” is MTI for any servers
> implementing TLS 1.3?

I'm not sure that I understand the question; as you said, this updates
the use from "tls-unique" to "tls-exporter", but only when using TLS
1.3. So in a TLS 1.3-only context you would use "tls-exporter" just as
you would use it when TLS 1.3 was being used even if TLS 1.2 is
also supported.

> Thanks for this document to ensure TLS 1.3 support in SCRAM and

Thank you for the review!

> ** The “updates” header doesn’t note RFC8446 but the abstract and
> Section 1 suggest that this document does update it.  Per Martin
> Duke’s DISCUSS point (which I support), please clarify.

I have fixed this in my next draft; this was accidentally removed when
applying suggested changes that were sent to me by another reviewer.

> ** Per Section 3  … this   document updates [RFC5801], [RFC5802], and
> [RFC7677] to use "tls-   exporter" as the default channel binding over
> TLS 1.3 (and greater).
>
> In what way is RFC7677 being updated?  If RFC5802 is already updated
> to required tls-exporter for TLS 1.3 what additional guidance is
> needed for RFC7677?

RFC7677 doesn't need to be updated in the sense that it just says to
do whatever RFC5802 says, but not mentioning it would be confusing, I
suspect. I suppose I can change the text to read something along the
lines of "RFC5802, and by extension RFC7677, are updated", but I
don't think it's strictly necessary. I think it's clear what the
changes are either way, but I'm happy to reword this if you think it
would be clearer.

—Sam

-- 
Sam Whited

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Feb 2022 15:04:19 -0800

Hi Sam,

> you would use it when TLS 1.3 was being used even if TLS 1.2 is

I think Roman's concern is that the current text in this draft provides a
clear statement that modifies the (a) portions of RFCs 5801/5802, but
doesn't provide a clear statement that this draft also updates the (b)
portions of 5801/5802.  So we would presumably add another sentence like
"additionally, this document updates ... to make 'tls-exporter' the
mandatory to implement channel binding [if TLS 1.3 is implemented]".  More
wordsmithing is likely needed than my off-the-cuff phrasing here, and
ideally would be able to reuse the "MUST implement" phrasing from the other
documents.

> applying suggested changes that were sent to me by another reviewer.

With all due respect, I must object.

My willingness to advance this document for IESG consideration was
predicated on this document *not* having an "Updates:" relationship with
RFC 8446, based on my assessment of IETF consensus.  I understand that you
feel strongly that the "Updates:" relationship should be present, but we
can only add that relationship with IETF consensus, and I do not believe
that such consensus is present.  There is an appeals process (§6.5 of RFC
2026) that applies if you think my assessment of IETF consensus is flawed,
and I'd be happy to hear about any factors that I may have missed in making
that assessment.

> changes are either way, but I'm happy to reword this if you think it

For Roman's benefit, the "updates: 7677" was added in response to an
earlier reviewer's comments:
https://mailarchive.ietf.org/arch/msg/kitten/DvDUpK3FvxNX09zuRwOJvAsKXig/
is a link to the middle of that thread.  The rewording you propose here
looks good to me, for what it's worth.

Thanks,

Ben

---

From: "Sam Whited" <[email-masked]>
Date: Mon, 28 Feb 2022 19:06:35 -0500

On Mon, Feb 28, 2022, at 18:04, Benjamin Kaduk wrote:
> I think Roman's concern is that the current text in this draft
> provides a clear statement that modifies the (a) portions of RFCs
> 5801/5802, but doesn't provide a clear statement that this draft also
> updates the (b) portions of 5801/5802.  So we would presumably add
> another sentence like "additionally, this document updates ... to make
> 'tls-exporter' the mandatory to implement channel binding [if TLS 1.3
> is implemented]".  More wordsmithing is likely needed than my off-the-
> cuff phrasing here, and ideally would be able to reuse the "MUST
> implement" phrasing from the other documents.

Thank you, I'll work on drafting an update.

> predicated on this document *not* having an "Updates:" relationship
> with RFC 8446, based on my assessment of IETF consensus.  I understand
> that you feel strongly that the "Updates:" relationship should be
> present, but we can only add that relationship with IETF consensus,
> and I do not believe that such consensus is present.  There is an
> appeals process (§6.5 of RFC 2026) that applies if you think my
> assessment of IETF consensus is flawed, and I'd be happy to hear about
> any factors that I may have missed in making that assessment.

I do not believe their was consensus either way; one or two people
voiced an opinion that it should not update it, and I don't think anyone
else joined the discussion. The usefulness of this document is extremely
diminished if new implementations of TLS 1.3 can't find it and I
absolutely believe the text updates the sentence saying that no channel
bindings are defined.

> is a link to the middle of that thread.  The rewording you propose
> here looks good to me, for what it's worth.

Thanks, I'll rework this.

—Sam

-- 
Sam Whited