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

[Eric Rescorla <[e-mail]>]

On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <[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

-Ekr


> *From:* TLS [mailto:[e-mail]] *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, May 3, 2017 11:13 PM
> *To:* Colm MacCárthaigh <[e-mail]>
> *Cc:* [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]>
> 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]
> 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=>
>
>
>