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

[Benjamin Kaduk <[e-mail]>]

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

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

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

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.

Thanks,

Ben