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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Robbie Harwood
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
On Thu, 2020-06-04 at 12:57 -0400, Robbie Harwood wrote:
> 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?

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




_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Robbie Harwood
On Thu, Jun 04, 2020 at 12:57:22PM -0400, Robbie Harwood wrote:
> 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?

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Sam Whited
In reply to this post by Simo Sorce-3


On Thu, Jun 4, 2020, at 14:37, Simo Sorce wrote:
> 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).

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.

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Alexey Melnikov
In reply to this post by Robbie Harwood
On 04/06/2020 17:57, Robbie Harwood wrote:

> 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?

I am still interested :-).

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten