Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Kyle Nekritz <[e-mail]>]

I think that idempotency is a relatively straightforward idea, it seems reasonable to trust that the application layer will only send 0-RTT data that is idempotent in terms of server-side state. I also don't think it's that much different than the current state of TLS. Providing strict replay protection over an unreliable network link requires that requests are never retried in the case of network failure - which is not practical in most applications. If the application doesn't already have some way to provide idempotency to requests that change state, it's likely already in a bad place (see http://blog.valverde.me/2015/12/07/bad-life-advice/).

However, to safely use 0-RTT (in the current draft), the 0-RTT data needs a stricter property than idempotency, it needs to be completely replay-safe. Unlike TLS now, where the opportunity for replay is linear in relation to the number of times a client is willing to retry a request, an attacker can replay a request an unlimited number of times.

There's two capabilities a passive eavesdropper gains from this that concern me the most:
    1) Changes to the response's length and timing can be observed over time
    2) The response's timing can be statistically analyzed (since the request can be replayed an unlimited number of times)
Mitigating these at the application layer seems much harder, if not impossible, to get right.

Adding a client time indicator (as I suggested in the other thread) makes this harder, but it certainly doesn't solve either problem. A server-side client nonce cache does solve these problems, which I think may be required to use 0-RTT safely. That said, I echo Bill's comments about the need for 0-RTT in TLS 1.3. Speed is very important.

Kyle

From: TLS [mailto:[e-mail]] On Behalf Of Bill Cox
Sent: Sunday, March 13, 2016 6:23 PM
To: Scott Schmit <[e-mail]>
Cc: [e-mail]
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit <[e-mail]<mailto:[e-mail]>> wrote:

So why are we adding a protocol optimization known from the start to be
insecure (or less secure than you'd expect from using a PFS cipher
suite)?

If you require PFS with resolution on the order of seconds to minutes rather than hours to days, you probably do not want to use tickets either.  The ticket decryption key rotation schedule limits PFS.  0-RTT resumes do not make this worse.

What percentage of servers that have a perceived need for 0-RTT will be
able to securely use and benefit from this feature as their
infrastructure is actually implemented?

Well, Google already sees a significant fraction.  Going back to 1-RTT would be a significant downgrade.

If almost everyone should turn it off, why are we including it?

Almost every small site on the Internet should turn it off, but the large sites that want to enable it could make up a large fraction of all traffic.

Most server admins won't be reading the TLSv1.3 spec.  They're going to
see "shiny feature added specifically in this version that makes it
faster!" with *maybe* a warning that there are risks, which they'll
dismiss because "if it was so insecure, they wouldn't have included it
in the protocol in the first place."  Unless 0-RTT can be fixed, it
looks like an attractive nuisance.

I agree.  Instead of dropping 0-RTT, I think we should make it easy for admins to learn about what is involved in using 0-RTT in ways we believe are secure.  The two modes I am aware of that are potentially as secure as TLS 1.2 session resumption are:

- Do 0-RTT session resumption using a session cache, using the ticket as the session ID.  This should have the same security as TLS 1.2 resume, right?
- At the HTTP app layer, make all requests that change state transaction based with unique transaction numbers, so replay attacks fail to change server state.  Done successfully, this should be more secure than TLS 1.2 resumption, shouldn't it?

Are we aware of other secure ways to do 0-RTT?

Bill