Re: [kitten] AD review of draft-ietf-kitten-tls-channel-bindings-for-tls13-08

[Alexey Melnikov <[e-mail]>]

Hi Ben,

On 01/10/2021 05:53, Benjamin Kaduk wrote:

> Hi all,
>
> Nothing particularly earth-shattering here, but enough that we should
> put out a revised I-D before I initiate the IETF last-call.
>
> Though there's not currently a formal requirement (since the precise
> meaning and usage of the "updates" tag is not well defined), it's been
> the practice of recent IESGs to ask that documents provide a clear
> statement of the nature of any updates being made.  While we currently
> do this for the updates of RFCs 5801 and 5802, we're pretty silent about
> how we update RFCs 5929 and 8446.  I have a proposal for 8446 below
> (wrapped into another suggestion), and we can probably put a note
> somewhere that we update 5929 to provide a channel-binding for TLS that
> is compatible with TLS 1.3.
>
> Section 1
>
>     The "unique" channel binding types defined in [RFC5929] were found to
>     be vulnerable to the "triple handshake vulnerability"
>     [TRIPLE-HANDSHAKE] without the extended master secret extension
>     defined in [RFC7627].  Because of this they were not defined for TLS
>     1.3 (see [RFC8446] section C.5).  [...]
>
> I don't think this conveys quite the right reasoning for why the channel
> bindings were not updated in RFC 8446 directly.  In particular, TLS 1.3
> intrinsically uses the extended master secret mechanism of "hash the
> entire handshake transcript" and in that regard is not susceptible to
> triple-handshake type attacks.
>
> Peeking through the archives, it seems that
> https://mailarchive.ietf.org/arch/msg/tls/2XbkUZhdxwFXhLVTdE2C-UZGaO0/
> may have been the most recent discussion of tls-unique in the context of
> draft-ietf-tls-tls13 .  The note referenced in that email thread seems
> to be:
>
> % [Raw public keys or skipping certificate chain checking]
> % used alone is vulnerable to man-in-the-middle
> % attacks and therefore unsafe for general use.  However, it is also
> % possible to bind such connections to an external authentication
> % mechanism via out-of-band validation of the server's public key,
> % trust on first use, or channel bindings [RFC5929].  [[NOTE: TLS 1.3
> % needs a new channel binding definition that has not yet been
> % defined.]] If no such mechanism is used, then the connection has no
> % protection against active man-in-the-middle attack; applications MUST
> % NOT use TLS in such a way absent explicit configuration or a specific
> % application profile.
>
> So I would propose the following replacement text:
>
>     The "unique" channel binding types defined in [RFC5929] were found to
>     be vulnerable to the "triple handshake vulnerability"
>     [TRIPLE-HANDSHAKE] without the extended master secret extension
>     defined in [RFC7627].  While TLS 1.3 uses a complete transcript hash
>     akin to the extended master secret procedures, the safety of channel
>     bindings with TLS 1.3 was not analyzed as part of the core protocol
>     work, and so the specification of channel bindings for TLS 1.3 was
>     deferred.  [RFC8446] section C.5 notes the lack of a channel bindings
>     definition for TLS 1.3; as this document defines such channel
>     bindings, it accordingly updates [RFC8446] to note that the gap has
>     been filled.
>
> (Note that I also modified the final sentence to be able to explicitly
> note in what way we see this document as updating RFC 8446.)
I like your proposal.
> Section 3
>
>     Channel bindings do not leak secret information about the channel and
>     are considered public.  [...]
>
> In light of the way that
> https://datatracker.ietf.org/doc/html/rfc5929#section-10.2 frames its
> discussion of channel-bindings disclosure (and to some extent
> https://datatracker.ietf.org/doc/html/rfc5056#section-8 as well), I
> think that we might want to scope the statement to just "the channel
> bindings type defined in this document" and to frame the subsequent
> discussion as being that "disclosure of the channel binding data does
> not affect the security of the TLS channel.  To say that they are
> "considered public" might imply an intention to disclose, when it seems
> that the important point is only that disclosure or non-disclosure is
> irrelevant.  With those changes included, this might look something
> like:
>
>    The channel binding type defined in this document is constructed so
>    that disclosure of the channel binding data does not leak secret
>    information about the TLS channel and does not affect the security of
>    the TLS channel.  [...]
I like this too.
> Section 3.1
>
>     While it is possible to use this channel binding mechanism with TLS
>     versions below 1.3, extra precaution must be taken to ensure that the
>     chosen cipher suites always result in unique master secrets.  For
>     more information see the Security Considerations section of
>     [RFC5705].
>
> Should we reiterate here that the extended master secret mechanism of
> RFC 7627 is one way to ensure uniqueness of master secrets?
>
>     When TLS renegotiation is enabled the "tls-exporter" channel binding
>     type is not defined and implementations MUST NOT support it.
>
> We may want to be specific that this mandate is scoped to renegotiation
> being enabled at (e.g.) connection scope (vs implementation-wide).
Right.
> Section 4.1
>
>     Subject:  Registration of channel binding tls-exporter
>
> It's interesting that this is part of the template given in RFC 5056 but
> not part of the registry itself...arguably a bug in 5056, but probably
> not worth doing anything about now.

Agreed.

Best Regards,

Alexey