Subject: [TLS] Call for consensus: Removing 0-RTT client auth

From: Sean Turner <[email-masked]>
Date: Tue, 29 Mar 2016 08:59:24 -0400

All,

To make sure we’ve got a clear way forward coming out of our BA sessions, we need to make sure there’s consensus on a couple of outstanding issues.  So...

It seems that there is a clear consensus not to support 0-RTT client authentication in TLS 1.3 at this time.  If you think 0-RTT client authentication needs to be supported please indicate so now and provide your rationale.

J&S

---

From: Bill Cox <[email-masked]>
Date: Tue, 29 Mar 2016 09:19:18 -0700

+1

Again, I am not speaking for Google.  However, in this case, I am confident
we are right about this for just about every application.

Bill

On Tue, Mar 29, 2016 at 5:59 AM, Sean Turner <[email-masked]> wrote:

> All,
>
> To make sure we’ve got a clear way forward coming out of our BA sessions,
> we need to make sure there’s consensus on a couple of outstanding issues.
> So...
>
> It seems that there is a clear consensus not to support 0-RTT client
> authentication in TLS 1.3 at this time.  If you think 0-RTT client
> authentication needs to be supported please indicate so now and provide
> your rationale.
>
> J&S
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 14:17:17 +0200

Hi Sean,

we at ARM would find it somewhat unfortunate to remove the client
authentication feature from the 0-RTT exchange since this is one of the
features that could speed up the exchange quite significantly and would
make a big difference compared to TLS 1.2.

For the IoT use cases we need client authentication; I understand that
the situation may be somewhat different in the Web space.

So, I am not happy with the proposed change!

Ciao
Hannes

On 03/29/2016 02:59 PM, Sean Turner wrote:
> All,
> 
> To make sure we’ve got a clear way forward coming out of our BA
> sessions, we need to make sure there’s consensus on a couple of
> outstanding issues.  So...
> 
> authentication needs to be supported please indicate so now and
> provide your rationale.
> 
> J&S _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Bill Cox <[email-masked]>
Date: Thu, 31 Mar 2016 10:02:41 -0700

> make a big difference compared to TLS 1.2.

Client certs can still be used with PSK 0-RTT, but only on the initial
1-RTT handshake.  it is up to the client to ensure that the security of the
resumption master secret (RMS) is solid enough to warrant doing 0-RTT
session resumption without re-verification of the client cert.  The
simplest way to explain how the server should work in this case is to just
say you need to emulate a session cache.

This is both more secure and faster than the current spec, where client
certs are sent during a 0-RTT resume.  The root security problem is that
the client cannot prove it possesses the private key in a 0-RTT handshake.

So, it is going to be a bit more work, but it will be fast and should be
secure.

Bill

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Mar 2016 12:08:08 -0500

On 03/31/2016 12:02 PM, Bill Cox wrote:
> On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Sean,
>
> 1-RTT handshake.  it is up to the client to ensure that the security
> of the resumption master secret (RMS) is solid enough to warrant doing
> 0-RTT session resumption without re-verification of the client cert. 

That seems to rule out most corporate uses of client certs [for 0-RTT
client authentication], since I doubt anyone will be interested in
trusting that the client does so properly.

-Ben

> The simplest way to explain how the server should work in this case is
> to just say you need to emulate a session cache.
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2016 10:13:59 -0700

On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <[email-masked]> wrote:

> <[email-masked]>[email-masked]> wrote:
>
>> Hi Sean,
>>
> session resumption without re-verification of the client cert.
>
>
> client authentication], since I doubt anyone will be interested in trusting
> that the client does so properly.
>

Do those servers generally carry over client auth through resumption?

-Ekr

>
> -Ben
>
> The simplest way to explain how the server should work in this case is to
> just say you need to emulate a session cache.
>
>
>

---

From: Bill Cox <[email-masked]>
Date: Thu, 31 Mar 2016 10:17:53 -0700

> that the client does so properly.

You would think so, but in TLS 1.2, the client only proves possession of
the certificate key on the initial connection, and not again on resumption,
so corporations are already trusting the client to maintain the security of
their resumption tickets and cache.  This seem like a significant security
issue that is not well known.

Bill

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Mar 2016 12:17:55 -0500

On 03/31/2016 12:13 PM, Eric Rescorla wrote:
>
>
> On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>     Client certs can still be used with PSK 0-RTT, but only on the
>>     initial 1-RTT handshake.  it is up to the client to ensure that
>>     the security of the resumption master secret (RMS) is solid
>>     enough to warrant doing 0-RTT session resumption without
>>     re-verification of the client cert. 
>
>     That seems to rule out most corporate uses of client certs [for
>     0-RTT client authentication], since I doubt anyone will be
>     interested in trusting that the client does so properly.
>
>

I don't know, offhand.  I just wanted to point out that for one sizeable
use case for client certs in general (not considering 0RTT), this
proposed scheme does not seem useful.  It may still be useful in other
use cases, of course.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2016 10:21:25 -0700

On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk <[email-masked]> wrote:

> On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk < <[email-masked]>
> [email-masked]> wrote:
>
> use case for client certs in general (not considering 0RTT), this proposed
> scheme does not seem useful.  It may still be useful in other use cases, of
> course.
>

I'm really not following you here.

My point is that for TLS 1.2 there are two categories of servers that do
client auth:

- Those which carry over client auth through resumption
- Those which do not

The former should be equally happy (modulo all the concerns about replay,
etc.) to carry over
client auth through 0-RTT resumption. The latter will presumably not be but
can do 1-RTT.
The question then becomes how large the two populations are.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Mar 2016 13:45:58 -0500

On 03/31/2016 12:21 PM, Eric Rescorla wrote:
>
>
> On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk <[email-masked]
>>     On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>             Hi Sean,
>>>
>>>         Client certs can still be used with PSK 0-RTT, but only on
>>>         the initial 1-RTT handshake.  it is up to the client to
>>>         ensure that the security of the resumption master secret
>>>         (RMS) is solid enough to warrant doing 0-RTT session
>>>         resumption without re-verification of the client cert. 
>>
>>         That seems to rule out most corporate uses of client certs
>>         [for 0-RTT client authentication], since I doubt anyone will
>>         be interested in trusting that the client does so properly.
>>
>>
>     I don't know, offhand.  I just wanted to point out that for one
>     sizeable use case for client certs in general (not considering
>     0RTT), this proposed scheme does not seem useful.  It may still be
>     useful in other use cases, of course.
>
>

Sorry.  I did not really make a very clear point.

> My point is that for TLS 1.2 there are two categories of servers that
> do client auth:
>
> The former should be equally happy (modulo all the concerns about
> replay, etc.) to carry over
> client auth through 0-RTT resumption. The latter will presumably not
> be but can do 1-RTT.

I guess I was thinking about the latter, and trying to note (but not
actually doing so) that they would have to do 1-RTT.

I think this subthread has outlived its useful existence...

-Ben