Subject: [kitten] Call for adoption on draft-whited-tls-channel-bindings-for-tls13

From: Robbie Harwood <[email-masked]>
Date: Thu, 04 Jun 2020 12:57:22 -0400

On behalf of Sam Whited, I'm issuing a call for adoption of
https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/

We've discussed this with the TLS working group, and consensus is that
this work should take place in kitten (with consultation from TLS
folks).

Besides Sam, I've seen interest expressed by Alexey,  Anyone else
interested in this, or have objections?

Thanks,
--Robbie

---

From: Simo Sorce <[email-masked]>
Date: Thu, 04 Jun 2020 14:37:35 -0400

> interested in this, or have objections?

Over time I've heard comments that the current tls-unique bindings are
not working out as initially expected. It would be nice to know if we
also plan to address those issues in this draft (or whether this draft
already avoid those).

Note that in practice, in the wild, I see that most implementations I
am exposed to are opting for tls-server-end-point, so it would be
important to know that this new bindings of type unique for TLS 1.3
will be usable and there are consumers wanting to use them.

Not pushing back just asking to address these questions in due course.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Jun 2020 13:42:04 -0500

> interested in this, or have objections?

I support making this a KITTEN WG work item.

To be sure, channel binding has not worked out to be as useful as we'd
hoped.  Problems arise having to do with reverse proxies, support in
ECMASCript APIs, support in TLS stacks, etc.  Token binding (basically,
channel binding of half round trip bearer tokens) also seemed promising
but has failed to become widely deployed for similar reasons.  But as a
general matter, we should make sure that we have solid channel bindings
for TLS 1.3.

Nico
--

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 04 Jun 2020 14:43:45 -0400

> also plan to address those issues in this draft (or whether this draft

To my knowledge there are two problems here: 1) it's not long enough,
and 2) without the master secret fix it's not actually unique enough.
This spec should fix both of those. If there are any other problems with
tls-unique that I'm not aware of, we should definitely fix them and this
is why the TLS WG would need to be involved most likely.

> will be usable and there are consumers wanting to use them.

I wouldn't mind having an end-point binding mechanism too, and could see
us adding that to this document eventually; to start though I wanted to
get the most dead simple thing in the hands of the IETF.

> Not pushing back just asking to address these questions in due course.

Indeed; I've added them to my list of TODOs, issues, and open
questions. Thanks!

—Sam

-- 
Sam Whited

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 5 Jun 2020 12:27:33 +0100

> interested in this, or have objections?

I am still interested :-).

I think the document needs to change, but it is a good starting point 
for the WG discussions.