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

[Sam Whited <[e-mail]>]

This all looks good; I've updated the draft and incorporated your
language as well as the tweaks you suggested. Thank you for your review.

—Sam

On Fri, Oct 1, 2021, at 00: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.)
>
> 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

-- 
Sam Whited