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

From: "Dan Harkins" <[email-masked]>
Date: Sun, 3 Apr 2016 17:43:48 -0700 (PDT)

Hi Sean & Joe,

On Tue, March 29, 2016 5:59 am, 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...
>
> 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.

  I don't think it needs to be supported and would be happy if
it was removed. It's a dangerous and flawed feature. My concern
is that if (which I fear is pronounced "when") an exploit is found
it might be easy to remove in a browser update but there's gonna
be some large TLS concentrator vendor that'll have a helluva time
getting its deployed boxes patched and it'll be ugly.

  The rationale for this-- to get an ad to me just that much faster
(an ad, I note, that I sure hope my ad blocking software will prevent
me from seeing), and that the people who want to do this know what
they're doing so it'll all be fine (which is not reassuring in the
least)-- just does not justify the risk.

  regards,

  Dan.

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 4 Apr 2016 16:36:58 +0000

If DH 0-RTT client auth is removed, most apps will start using client auth with PSK 0-RTT handshakes which is the current state in TLS 1.2 (with tickets) as Bill previous mentioned. We've encountered implications of this when using TLS1.2 for internal authentication. The tradeoff here is that a server that shares a ticket key with another server can masquerade as any client to the other server. This is a performance / security tradeoff here, and we solve this using partitioning of ticket keys between untrustworthy servers. There are several other implications of session tickets that we already deal with for this security / performance tradeoff, and this is not the worst one. 

I don't think having some form of 0-RTT client auth is a bad thing since there are engineering implications of not providing client auth during 0-RTT. 
A server app is using TLS for cert authentication and doing it's own authorization, it might provide certain methods to be accessible without authorization, but others with authorization. In a lot of application protocols, the client would not know about this aproiri. Not having a form of client auth would obviate these from using 0-RTT completely which would be sad.

Since 0-RTT DH is still under discussion, maybe we should revisit 0-RTT DH client auth after that is decided?

Subodh Iyengar
________________________________________
From: TLS [[email-masked]] on behalf of Dan Harkins [[email-masked]]
Sent: Sunday, April 03, 2016 5:43 PM
To: Sean Turner
Cc: [email-masked]
Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth

  Hi Sean & Joe,

  regards,

  Dan.

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=0Wl8UysaIyWxp0Iw_9TKo4jE9Iwn7DnABCdnYWj_2Kk&s=2SuDKxG_YMEaEm1zqgKy4-aHt4NzUB9QVq8SzByaqp8&e=

---

From: Bill Cox <[email-masked]>
Date: Thu, 7 Apr 2016 08:32:45 -0700

I've been reviewing this issue because I want to help figure out how to do
token binding over TLS 1.3 PKS 0-RTT.  When the server emulates a session
cache, then the RMS is unique on every PSK 0-RTT resumption.  That means
the client handshake hash is also unique, and it therefore becomes an
attractive value for the purpose of signing.  If we allow client auth in
this mode, we gain some security.  In particular, without access to the
client cert private key, an attacker cannot resume a session, even if they
have the RMS.

Give this possible mode of operation, we may want to consider keeping
client auth as an option in 0-RTT PSK resumption.

Bill

---

From: Bill Cox <[email-masked]>
Date: Thu, 7 Apr 2016 08:52:11 -0700

> client auth as an option in 0-RTT PSK resumption.

This brings up another issue: the client does not currently know if the
server is running stateless or if it has some form of replay protection.
It was proposed on another thread to add this information to the new ticket
with a 1-byte type.  I think this is a good idea.

With replay protection, allowing client auth makes some sense.  The server
loses freshness, but not uniqueness of the signature, and uniqueness is the
more important of the two properties IMO.  Without replay protection, only
the initial 1-RTT signature actually proves possession of the private key,
so we should probably not allow client auth on PSK 0-RTT in that case and
instead advise the client to secure the RMS well, since it can be used to
resume authenticated sessions without the client private key.  Without
extending the ticket format to provide this information to the client, it
will not be possible to make this differentiation, and either we will have
to disallow all 0-RTT client auth for replay-resistant servers, or we will
have to require all servers supporting 0-RTT to provide a client signature,
even when running stateless.  Given that stateless 0-RTT client auth does
not prove possession of the private key, I would prefer not to allow it in
that mode.

Bill