Subject: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto

From: Jim Roskind <[email-masked]>
Date: Fri, 8 Apr 2016 13:50:34 -0700

The combination of DHE and TLS 1.3 session resumption via session tickets,
can destroy the forward secrecy property that DHE was intended to provide.
With the proposed removal of DHE-based 0-RTT from TLS 1.3, session
resumption is the mechanism by which 0-RTT connections are established.
When adopted into QUIC, this will then be a reduction in security as
compared with the current QUIC Crypto protocol, which rapidly steps all
connections up to having forward secrecy immediately after a 0-RTT
connection.

The 0-RTT connection is extremely desirable for use in QUIC, because of the
impact on connection latency, a known critical issues in all HTTP(S)
content acquisition.  Currently, at least 75% of all QUIC connections use
0-RTT, and then enjoy forward secrecy for the bulk of their communications.
I would like TLS 1.3 to provide similar forward-secrecy guarantees after a
0-RTT connection.

If a symmetric-session-ticket-decryption-key was compromised by a server,
as a result of a break-in, or a subpoena, then all traffic that depended on
the session resumption tickets would be at risk.  Moreover, a third party
attacker that possessed such a key, or planned to acquire a copy, could
"encourage" traffic to use session resumption by disrupting any connection.

A common use case involves having a large number of servers that must all
be equally able to resume a connection. As a result, encrypted session
tickets, protected by a server's symmetric secret key, are generally the
preferred mechanism for resumption.

Thanks for you consideration,

Jim Roskind

---

From: Bill Cox <[email-masked]>
Date: Fri, 8 Apr 2016 14:13:47 -0700

> connections up to having forward secrecy immediately after a 0-RTT

I think I can accurately answer this: just use ephemeral keys during your
resumption handshake.  Then only the first flight 0-RTT packets lack PFS,
just like with DHE 0-RTT.

> The 0-RTT connection is extremely desirable for use in QUIC, because of
> the impact on connection latency, a known critical issues in all HTTP(S)

If you are only getting 75%, there is room for improvement :)  I also would
like as much PFS as we can afford.  Running the server with a session cache
enables PSK 0-RTT to have true PFS for all application data, even first
flight 0-RTT data, but of course the session cache is expensive in several
ways.  Doing an ephemeral key exchange might be preferable in many cases,
even with the loss of first-flight PFS.

Just reiterating a point I think is important: the client needs to know
whether the server has replay protection in this case.  It may decide to
use 1-RTT to have full PFS for all application data and real proofs of
possession for client certs, or it might decide to send 0-RTT data in any
case.  However, we should advise clients not to send client certs and POST
requests over PSK 0-RTT resumes during the first flight, IMO.  I'd like to
see tickets enhanced to enable the server to tell the client whether replay
protection is in place on the server.

Bill

---

From: Bill Cox <[email-masked]>
Date: Fri, 8 Apr 2016 14:17:25 -0700

On Fri, Apr 8, 2016 at 2:13 PM, Bill Cox <[email-masked]> wrote:

> However, we should advise clients not to send client certs and POST

Just clarifying: I meant client certs should not be sent over PSK 0-RTT
resumption when the server has no replay protection.  With replay
protection, I'd probably recommend it.  As the spec stands today, there is
not quite enough information in the 1-RTT initial server reply for the
client to figure out how to behave.

Bill

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 Apr 2016 18:31:56 -0300

On Fri, Apr 8, 2016 at 6:13 PM, Bill Cox <[email-masked]> wrote:

>> The combination of DHE and TLS 1.3 session resumption via session
>> tickets, can destroy the forward secrecy property that DHE was intended to
>> provide.  With the proposed removal of DHE-based 0-RTT from TLS 1.3,
>> session resumption is the mechanism by which 0-RTT connections are
>> established. When adopted into QUIC, this will then be a reduction in
>> security as compared with the current QUIC Crypto protocol, which rapidly
>> steps all connections up to having forward secrecy immediately after a
>> 0-RTT connection.
>>
>

Quite so. TLS 1.3 supports two PSK-resumption modes:

1. Pure PSK, which has somewhat better security properties than in TLS 1.2
2. PSK-ECDHE, which has similar security properties to those of QUIC, i.e.,
no-PFS for the first flight and PFS for subsequent flights

I think it would be good to encourage people to use mode #2, but there are
obvious
reasons why performance-sensitive implementations might opt for mode #1.

-Ekr

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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 8 Apr 2016 14:38:39 -0700

> "encourage" traffic to use session resumption by disrupting any connection.

Why isn't your concern just as valid for the 0RTT itself though? If it's a
URL it's entirely possible for it to be privacy sensitive, or to have some
kind of bearer token in it. Or the 0RTT might have POST-like data, like
maybe your credit card number.

-- 
Colm

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 8 Apr 2016 14:42:40 -0700

On Fri, Apr 8, 2016 at 2:31 PM, Eric Rescorla <[email-masked]> wrote:
>
> ... TLS 1.3 supports two PSK-resumption modes:
>

I don't know why one wants to choose PSK-ECDHE resumption over ECDHE
full handshake. Does PSK-ECDHE resumption have any advantage over
ECDHE full handshake?

Wan-Teh Chang

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 Apr 2016 18:53:31 -0300

> full handshake. Does PSK-ECDHE resumption have any advantage over

Yes [0]

1. It has a significantly lower performance cost (especially if you have an
RSA cert)
2. If you have done client authentication, then you can carry the state
over between
handshakes.
3. As it seems likely we are going to remove the (EC)DHE 0-RTT mode, this
is how you
do 0-RTT.

-Ekr

[0] For the sake of this discussion, I'm talking about resumption PSK when
the server
is authenticating with a cert. Obviously if you are using PSK-based
authentication there
are reasons why you would want to do this.