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

[Benjamin Kaduk <[e-mail]>]

Hi Sam,

On Mon, Feb 28, 2022 at 05:39:08PM -0500, Sam Whited wrote:
> 
> 
> 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.
> >
> > 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?
> 
> 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.

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.

> 
> > Thanks for this document to ensure TLS 1.3 support in SCRAM and
> > GSS-API.
> 
> 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.

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.

> 
> > ** 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.

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