Subject: [TLS] Remove 0-RTT client auth

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Feb 2016 11:31:04 -0800

I'm sitting here in TRON listening to Karthik describe all the various
ways in which client authentication in 0-RTT is bad.  I'm particularly
sympathetic to the perpetual impersonation attack that arises when the
client's ephemeral key is compromised.

We originally thought that we might want to do this for
WebRTC/real-time.  As it so happens, we have an alternative design
that doesn't need this, so...

I propose that we remove client authentication from 0-RTT.

This should simplify the protocol considerably.

https://github.com/tlswg/tls13-spec/issues/420

[1] Compromising the server's long term key has the same impact, but
that's interesting for other, worse reasons.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Feb 2016 11:37:06 -0800

+1

On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Cedric Fournet <[email-masked]>
Date: Sun, 21 Feb 2016 19:41:56 +0000

Agreed. For what it is worth, 0-RTT with PSK would still provide implicit client authentication.

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 21 February 2016 19:37
To: Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Remove 0-RTT client auth

+1

On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

[1] Compromising the server's long term key has the same impact, but
that's interesting for other, worse reasons.
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7cb8afe35a6c8a4dd7e41308d33af67de7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=JiINW%2fUouLWcJn0b%2fGjg7mVZH%2fGQxI1QvOhA42YdywE%3d>

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Feb 2016 11:43:28 -0800

> Agreed. For what it is worth, 0-RTT with PSK would still provide implicit

s/would/could

That implies many of the hazards that we were talking about here, so
none of this makes 0-RTT any less of a hazard.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Feb 2016 11:43:21 -0800

Correct.

-Ekr

On Sun, Feb 21, 2016 at 11:41 AM, Cedric Fournet <[email-masked]>
wrote:

> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* 21 February 2016 19:37
> *To:* Martin Thomson <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] Remove 0-RTT client auth
>
>
>
> +1
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7cb8afe35a6c8a4dd7e41308d33af67de7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=JiINW%2fUouLWcJn0b%2fGjg7mVZH%2fGQxI1QvOhA42YdywE%3d>
>
>
>

---

From: Adam Langley <[email-masked]>
Date: Sun, 21 Feb 2016 12:01:32 -0800

> This should simplify the protocol considerably.

The token-binding(*) folks care about authenticating 0-RTT requests,
although they are currently working at the application-layer[1] and so
would be recreating 0-RTT client authentication on top of TLS. (They
would thus have all the same issues, but we already knew that.)

If there was still a channel-binding value available at 0-RTT time,
they should be happy.

(* To recap, token-binding wants to eliminate the bearer-token nature
of cookies in order to avoid several issues. For example,
Heartbleed-like leaks of cookie data, origin confusion attacks[2]
etc.)

Cheers

AGL

[1] https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04
[2] http://antoine.delignat-lavaud.fr/doc/www15.pdf

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Feb 2016 12:05:03 -0800

> would thus have all the same issues, but we already knew that.)

You can't run an exporter until the handshake is complete, so how were
you imagining that this would work?

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Feb 2016 12:06:17 -0800

> you imagining that this would work?

I think we're going to have to invent a 0-RTT exporter (yes, I understand
that this
requires care).

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Feb 2016 12:08:48 -0800

> I think we're going to have to invent a 0-RTT exporter (yes, I understand

We might disagree about that "have to".  I'd be happier if the 0-RTT
data couldn't rely on the existence of an exporter.  If that means
that token-binding needs to work out a bespoke solution, I think that
I'd prefer that.

---

From: Andrei Popov <[email-masked]>
Date: Sun, 21 Feb 2016 23:58:51 +0000

I am strongly in favor of removing client auth from 0-RTT.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Sunday, February 21, 2016 11:37 AM
To: Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Remove 0-RTT client auth

+1

https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cb8afe35a6c8a4dd7e41308d33af67de7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bLPondg934Q9uP279%2b4Rq5Lnm3eRiqHR1%2fhE7K5z0Yg%3d>

---

From: Russ Housley <[email-masked]>
Date: Sun, 21 Feb 2016 19:02:10 -0500

+1 
 
On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson <[email-masked]> wrote:

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 22 Feb 2016 07:46:09 +0200

> client's ephemeral key is compromised.

It also seems like a footgun to me (yes, I realize one isn't
supposed to transport "non-safe"[1] data on it, but...).

> that doesn't need this, so...

Got mailarchive or draft link?

Some sort of "sign ClientHello" scheme? Or just taking the 1RTT for
the authentcation?

> This should simplify the protocol considerably.

Yes, there are all sorts of obscure corner-cases with 0-RTT auth
that don't happen with 0-RTT data, and seemingly some existing
extensions if implemented bring even more (and the current spec
doesn't even begin to explain those extension issues).

[1] "idempotent" isn't enough: e.g. HTTP considers unconditional DELETE
to be idempotent, but effects of making such thing replayable with
authentication might not be desirable...

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Feb 2016 23:18:48 -0800

> Got mailarchive or draft link?

No, this was a realization that we could just stuff the ClientHello
into the signaling (the SDP offer to be precise) and continue the
handshake later.  There were all sorts of ideas floating around about
using offline configs, but those are all just more complex.