Re: [TLS] Security review of TLS1.3 0-RTT

[Kyle Nekritz <[e-mail]>]

Yep, I think your PR is in the right direction.

> I have been basically assuming that you can't really do TLS without a real-time clock, but maybe that's wrong?

Well, it’s possible, although I do not know if anyone actually does (and of course certificate validation would be a little challenging). Maybe someone from the embedded crowd can enlighten us.

> "For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value."

Ah, I had missed that. I think the MUST might be a little strong there, even without direct involvement of the server in issuing the external PSK the ticket age can still be useful, for example using a similar method we use with Zero Protocol (Time-bound 0-RTT data section of https://code.facebook.com/posts/608854979307125/building-zero-protocol-for-fast-secure-mobile-connections/ ).

From: Eric Rescorla [mailto:[e-mail]]
Sent: Thursday, May 4, 2017 5:37 PM
To: Kyle Nekritz <[e-mail]>
Cc: Colm MacCárthaigh <[e-mail]>; [e-mail]
Subject: Re: [TLS] Security review of TLS1.3 0-RTT



On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <[e-mail]<mailto:[e-mail]>> wrote:
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining both session-cache and strike register styles and the merits of each.

First, a point of clarification, I think two issues have been conflated in this long thread:
1) Servers rejecting replayed 0-RTT data (using a single use session cache/strike register/replay cache/some other method)

There are definitely cases (i.e. application profiles) where this should be done. I think a general case HTTPS server is one. But I don’t think this is strictly necessary across the board (for every application using 0-RTT at all). DNS was brought up earlier in this thread as an example of a protocol that is likely quite workable without extra measures to prevent replay.

We already state “Protocols MUST NOT use 0-RTT data without a profile that defines its use.”. We could also describe methods that may be used to provide further replay protection. But I don’t think it’s appropriate to make a blanket requirement that *all* application protocols should require it.

I also consider it quite misleading to say TLS 1.3 is insecure without such a recommendation. Uses of TLS can be insecure, that does not mean the protocol itself is. It’s insecure to use TLS without properly authenticating the server. Some users of TLS do not do this correctly. I’d actually argue that it is easier to mess this up than it is to mess up a 0-RTT deployment (and it can result in worse consequences). That doesn’t mean we should require a particular method of authentication, for all uses of TLS.

I think this is basically right. In the PR I just posted, I spent most of my time describing the
mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
I think there's a bunch of room to wordsmith the requirement. Perhaps we say:

- You can't do 0-RTT without an application profile
- Absent the application profile saying otherwise you SHOULD/MUST do one of these mitigations?


2) Preventing clients from sending 0-RTT data multiple times (on separate connections) using the same PSK (for forward secrecy reasons)

I think this should be allowed. Otherwise, clients will not be able to retry 0-RTT requests that fail due to an unknown network error prior to receiving a NST (if they are out of cached PSKs). I’d expect the need for these retries to be larger with 0-RTT data, particularly when 0-RTT data is sent without even a transport roundtrip (in the case of TFO or QUIC). Servers are definitely not required to accept multiple 0-RTT connections using the same PSK, but I don’t think clients should be banned from attempting.

I agree, and the PR I provided doesn't attempt to do so.


> 4. I would add to this that we recommend that proxy/CDN implementations signal which data is 0-RTT and which is 1-RTT to the back-end (this was in Colm's original message).

I’m not sure that the TLS 1.3 spec is the right place to make recommendations for this. I can see several reasonable approaches here, for example:
- Adding some kind of application level annotation (for example an HTTP header)
- Robustly preventing replay on the 0-RTT hop
- Sending proxied early data with a different TLS ContentType, etc.
I don’t see a need to specifically endorse any particular method here.

I think Colm has also agreed we shouldn't do this and it's not in my PR.



There was also a point brought up about the use of ticket_age without 0-RTT. I’m not aware of any use for ticket_age other than 0-RTT replay protection. I believe that ticket_age is sent with all PSKs mostly out of convenience/consistency. I don’t really have an objection to the current method, but I also wouldn’t be opposed to moving the ticket age to the early data extension, so that it is only sent along with 0-RTT data.

I would be OK with this as well. It does seem slightly more elegant.



It also seems a little under-specified what implementations unable to compute a reasonable ticket age should send (for example in the case of a device without a real time clock,

Right. I have been basically assuming that you can't really do TLS without a real-time clock, but maybe that's wrong?


or with an external PSK).

This actually is well-specified (though maybe wrong)
"For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value."
https://tlswg.github.io/tls13-spec/#pre-shared-key-extension<https://urldefense.proofpoint.com/v2/url?u=https-3A__tlswg.github.io_tls13-2Dspec_-23pre-2Dshared-2Dkey-2Dextension&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=00D34eqyobqYsnH-0x2sQdC8Xn1GCqHQBFPqPeXE0gg&s=pachGLJQErJG8nAK5OKJ4L3Da70bIO1BQlytdiuuaNs&e=>

-Ekr

From: TLS [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Eric Rescorla
Sent: Wednesday, May 3, 2017 11:13 PM
To: Colm MacCárthaigh <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

[Deliberately responding to the OP rather than to anyone in particular]

Hi folks,

I'm seeing a lot of back and forth about general philosophy and the
wisdom of 0-RTT but I think it would be useful if we focused on what
changes, if any, we need to make to the draft.

I made some proposals yesterday
(https://www.ietf.org/mail-archive/web/tls/current/msg23088.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23088.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0&s=XgHbUwT6upAsOin4T6P8ePs8i0ZFsnD-_BNvueeq83E&e=>).

Specifically:
1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
both session-cache and strike register styles and the merits of each.

2. Document 0-RTT greasing in draft-ietf-tls-grease

3. Adopt PR#448 (or some variant) so that session-id style implementations
provide PFS.

4. I would add to this that we recommend that proxy/CDN implementations
signal which data is 0-RTT and which is 1-RTT to the back-end (this was in
Colm's original message).

Based on Colm's response, I think these largely hits the points he made
in his original message.

There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
What would be most helpful to me as Editor would be if people could review
these PRs and/or suggest other specific changes that we should make
to the document.

Thanks,
-Ekr




On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh <[e-mail]<mailto:[e-mail]>> wrote:
On Sunday at the TLS:DIV workshop I presented a summary of findings of a security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. Thanks to feedback in the room I've now tightened up the findings from the review and posted them as an issue on the draft GitHub repo:

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

I'll summarize the summary: Naturally the focus was on forward secrecy and replay. On forward secrecy the main finding was that it's not necessary to trade off Forward Secrecy and 0-RTT. A single-use session cache can provide it, and with the modification that ekr has created in https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for both pre-auth and post-auth tickets, and it allows clients to build up pools of meaningfully distinct tickets.

There's also an observation there that it should really be that clients "MUST" use tickets only once. Any re-use likely discloses the obfuscated ticket age, which is intended to be secret. Right now it's a "SHOULD".

On replay, the main finding is that what's in the draft is not workably secure, and the review includes 5 different attacks against 0-RTT data to illustrate that. Attacks 1 and 2 show that the kind of replay permitted by the draft is very different from the kind of replay permitted by dkg's existing downgrade-and-retry attack. I also go over why it very very difficult to many applications to achieve that idempotency, and why one idempotency pattern actually relies on non-replayable messages.

Attack 3 shows that idempotency is not sufficient, applications must also be free of measurable side-effects, which is not practical.  Attack 4 shows that 0-RTT breaks a common security mechanism: spoofing-resistant throttles. Attack 5 shows that 0-RTT replay-ability enables an additional form of traffic analysis.

The recommendation in the review is that implementations "MUST" prevent replays of 0-RTT section, with some additional discussion about why the existing advice is unlikely to be followed, and why consistent interoperability matters here.

Unfortunately, I wasn't aware until Friday that this review would be coming so late in the TLD1.3 draft process, and my apologies for that. I am now planning to attend the future WG in-person meetings and look forward to seeing many of you there.

--
Colm

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0&s=6GIocGzW6wPK4EAlqDLIirNvsuQj7gWhYG_OzROR2qY&e=>