Subject: [TLS] 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: "Sam Whited" <[email-masked]>
Date: Thu, 11 Mar 2021 07:38:46 -0500

Re-iterating that CBs may be public seems sane. I'll add some text.
along the lines of:

> Channel bindings do not leak secret information about the channel and
> are considered public. Implementations MUST NOT use the channel
> binding to protect secret information.

With regard to context strings, I don't think it gets us any benefit. If
two protocols get the same channel binding and something changes (eg.
the protocol is resumed over a new TLS session), both channel bindings
break either way. We'd also want to create some sort of registry for
these strings, most likely which adds a lot of overhead for no benefit
that I can see. Maybe there's some benefit to having separate channel
bindings per protocol and per channel and not just per channel that I
can't see though.

—Sam

On Wed, Mar 10, 2021, at 18:57, Jonathan Hoyland 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. 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
> 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.

---

From: Jonathan Hoyland <[email-masked]>
Date: Thu, 11 Mar 2021 16:59:58 +0000

For the text, I would change the last clause to "Implementations MUST NOT
rely on the secrecy of the channel binding for their own security."
(Although that is actually slightly stronger than RFC 5056, which only
requires this for integrity protection of the underlying channel, i.e. TLS.)

W.r.t. context strings, the issue I'm thinking about is two protocols that
both use this channel binding for a single session and somehow step on each
other's toes.
For example it's not hard to imagine one protocol building some kind of
MAC-based auth protocol on this, and finding it's broken when deployed with
another protocol that can be used as an oracle.
I'm not sure this is an issue in practice, so much as, when thinking about
a security analysis, a very common assumption is that only the protocol
under analysis will generate messages of the given format.
If the channel bindings aren't separated by context strings then any formal
analysis would have to consider all protocols at the same time, which makes
the analysis (literally) exponentially more complex for each new protocol.

Also, in case it matters, there are authentication changes in TLS that do
not change the state / move the state machine, for example Exported
Authenticators.

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