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

[Hannes Tschofenig <[e-mail]>]

Hi Colm,

thanks for your review.

I disagree with your assessment in a few places.

First, talk about tickets and point out that distributing the session
key for encrypting the ticket content (Session Ticket Encryption Keys
(STEKs)) is a challenge and raises security concerns. You point to
Akamai CDN and their huge number of hosts.

The TLS 1.3 ticket concept combines three types of tickets approaches
standardized for earlier versions of TLS, namely session resumption
(which caches keys on both sides), and RFC 5077, which allows you to use
self-contained tokens aka tickets in the style of Kerberos tickets.
Finally, you could use RFC 5077 with references to tickets but you loose
the stateless nature (since you have to write keys, and other necessary
parameters in a database).

Which approach is best depends on your infrastructure.

When you use TLS in your environment you need to make a few decisions
about the algorithms you want to support, key lengths, etc. You also
have to determine what ticket concept you want. Maybe the right decision
for a deployment that has to synchronize STEKs across so many hosts
isn't a great idea.

Second, you talk about 0-RTT and replay attacks. In a 0-RTT exchange you
cannot rely on the nonce exchange for replay protection (as it was done
in earlier TLS versions). Instead, you have to rely on other replay
protection mechanisms, and taking the application semantic into account
is obvious approach. Clearly 0-RTT is not applicable to all environments
and hence the spec contains a warning: "Protocols MUST NOT use 0-RTT
data without a profile that defines its use."

What I could, however, imagine is to add either in the TLS handshake or
at the application layer something like a timestamp or a sequence number
so that the server-side can check for replays. This is what has been
done with other security protocols in the past. Is the TLS layer the
right place or the application layer? Hard to say.

Minor issues:

You also suggest that 0-RTT supports PFS. The definition of PFS
unfortunately is not super helpful here when there are so many keys in
play. The PFS definition talks about the loss of the long-term key. What
you care about is the potential loss of the STEKs, which is not a
long-term key.

You write: "Any client that attempts to use a ticket multiple times will
also likely leak the obfuscated_ticket_age value, which is intended to
be secret." The obfuscated_ticket_age is not secret - it is sent in the
clear. What is supposed to be kept confidential is the ticket age. I
have been wondering myself what the privacy value of the
obfuscated_ticket_age, and the ticket age is and I am still not
convinced that it provides much benefit.

Ciao
Hannes

PS: You talk about OATH in this paragraph:

"
To avoid simple spoofing risks, many such systems perform throttling
post-authentication. For example the request may be signed
cryptographically (see the AWS SIGv4 signing protocol or the OATH
signing process), that signature is verified prior to throttling. This
post-authentication property is one reason why such protocols are
designed to be extremely fast to verify, which often means as much
cryptography as possible must be pre-computed, making random nonces
infeasible in many cases.
"

What you actually mean is OAuth (OATH is a different effort also related
to earlier IETF work on one-time-passwords). Your reference points to an
old OAuth specification that has been replaced by OAuth 2.0, which does
not use the same application layer signing anymore.

On 05/02/2017 04:44 PM, Colm MacCárthaigh 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
> <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
>