Subject: [kitten] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02

From: Robbie Harwood <[email-masked]>
Date: Wed, 10 Mar 2021 14:25:15 -0500

Hello kitten and TLS,

Our document defining TLS 1.3 channel bindings is now in 2-week last
call (to end 2021-03-24).  That document can be viewed at:

https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/

If you read the document during this period, please submit a review in
reply (even if it's just that you think it's ready), especially if you
are more active in TLS than kitten.  This helps me judge consensus.

Thanks,
--Robbie

---

From: Watson Ladd <[email-masked]>
Date: Wed, 10 Mar 2021 11:29:48 -0800

> are more active in TLS than kitten.  This helps me judge consensus.

Looks ready to me.

>
> Thanks,
> --Robbie
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Astra mortemque praestare gradatim

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Mar 2021 13:36:31 -0600

+1

---

From: Jonathan Hoyland <[email-masked]>
Date: Wed, 10 Mar 2021 23:57:30 +0000

IIUC a channel binding (in this context) provides a unique "name" for a
channel.
In the case where two distinct protocols running over the top of TLS use
this definition, they will both get the same channel binding.
It might be useful to pull out in the security considerations one
consideration from RFC 5056 that might be forgotten.

```
 o The integrity of a secure channel MUST NOT be weakened should
      their channel bindings be revealed to an attacker.  That is, the
      construction of the channel bindings for any type of secure
      channel MUST NOT leak secret information about the channel. [...]
```

This means that a perfectly valid (even if currently undefined) use of a
channel binding might involve posting it to Twitter.
I don't follow kitten, but if there are multiple places that use this
binding then this might be a useful warning.
You cannot assume the channel binding of a channel is secret.

Alternatively using context strings allows for independent channel bindings
to be used by each over-the-top protocol, so perhaps requiring some unique
context string per usage type might be appropriate.

Perhaps these concerns are too out there, but just thought they warranted
at least a mention.

Regards,

Jonathan

---

From: Watson Ladd <[email-masked]>
Date: Thu, 11 Mar 2021 13:55:53 -0800

On Wed, Mar 10, 2021 at 3:57 PM Jonathan Hoyland
<[email-masked]> wrote:
>
> IIUC a channel binding (in this context) provides a unique "name" for a channel.
> In the case where two distinct protocols running over the top of TLS use this definition, they will both get the same channel binding.

This draft is using exporter instead since channel bindings died an
ignominious death at the hands of Karthikeyan Bhargavan and his
students. Because it uses exporters and registers a use in the
registry, the other exporter values will be distinct.

Exporters are stronger, so I think this is less relevant.

Sincerely,
Watson Ladd

---

From: Jonathan Hoyland <[email-masked]>
Date: Fri, 12 Mar 2021 11:47:42 +0000

Hi Watson,

Exporters are a form of channel binding (in the protocol theory sense, not
in the RFC 5056 sense).
Two protocols that use the defined binding on a single TLS connection will
derive the same Exporter.
This is clearly intended to be generic, the input string is
"EXPORTER-Channel-Binding" not something specific to a single protocol, so
presumably more than one thing will use it.

Ideally this wouldn't be defined and anything that would have used this
would just use the Exporter interface directly because, as you say, using
the Exporter interface with different context strings will yield different
values.
However, if this "Channel binding" exporter is defined as described, and is
used by more than one thing, as the name suggests, then it will have all
the same issues as those found by Karthik.

Yes, other things that use the Exporter interface will be unaffected, but
if two things use this binding then they could be vulnerable.

Regards,

Jonathan

---

From: Dave Cridland <[email-masked]>
Date: Fri, 12 Mar 2021 14:56:21 +0000

Hi Sam, Kittens,

Summary: Yeah, ready, I think, but a tiny bit of wordsmithing might benefit.

Main Issue:

Use with TLS 1.2 is not entirely clear. I think all the information is
there, but it's a little scattered, and I misread the "When TLS
renegotiation is enabled (pre TLS 1.3)" initially. While TLS 1.3 is
obviously desirable, there's enough TLS 1.2 out there that making this
clear would be a benefit.

So I would personally extract the last paragraph of §2 and the first from
§3 into a new section (§2.1, §3.1, or something else). A suggestion of
actual text for this new version (mostly a cut and paste). I'm not sure if
the "must" wants to be a MUST here, either:

Use with earlier TLS versions

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

   In addition, session renegotiation MUST NOT be enabled. When TLS
   renegotiation is enabled the "tls-exporter" channel binding type is not
   defined and implementations MUST NOT support it.

If you use this suggestion, you may wish to include a "Other security
considerations are discussed throughout this document" in Security
Considerations, and you may wish to do that anyway.

You may also want to drive home the point that people really ought to just
use 1.3.

Many thanks for writing this document and riding it through, I fully intend
to implement as and when the APIs surface.

Dave.

On Wed, 10 Mar 2021 at 19:26, Robbie Harwood <[email-masked]> wrote:

> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: "Sam Whited" <[email-masked]>
Date: Fri, 12 Mar 2021 10:11:55 -0500

Thank you, I've moved this into a new "Use with Legacy TLS" section
under the security considerations. I think that "must" should remain
lower case since it's on something a bit hand-wavy and doesn't mention
any real behavior or changes to make.

I'll wait a bit longer for more feedback then push an update with what
I've got so far. Thanks again!

—Sam

On Fri, Mar 12, 2021, at 09:56, Dave Cridland wrote:
> So I would personally extract the last paragraph of §2 and the first
> from §3 into a new section (§2.1, §3.1, or something else). A
> suggestion of actual text for this new version (mostly a cut and
> paste). I'm not sure if the "must" wants to be a MUST here, either:
>
>    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].
>
>    renegotiation is enabled the "tls-exporter" channel binding type is
>    not defined and implementations MUST NOT support it.
>
> You may also want to drive home the point that people really ought to
> just use 1.3.
>
> Many thanks for writing this document and riding it through, I fully
> intend to implement as and when the APIs surface.