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:[email protected]] On Behalf Of Bill Cox
Sent: Sunday, March 13, 2016 6:23 PM
To: Scott Schmit <[email protected]>
Cc: [email protected]
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit
<[email protected]<mailto:[email protected]>> 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
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
