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

[Sam Whited <[e-mail]>]

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.


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


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