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

[Colm MacCárthaigh <[e-mail]>]

On Wed, May 3, 2017 at 2:15 AM, Hannes Tschofenig <[e-mail]
> wrote:
>
> 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.
>

I used Akamai as a reference as they are probably the worlds largest
deployment of TLS, measured by hosts. But to be clear; Akamai has always
done great work on securing keys and I know it's something they take very
seriously.


> Which approach is best depends on your infrastructure.
>

Here I want to be more opinionated than that. I think that forward secrecy
is important and is more secure, and should always be provided. Its absence
is a security issue, so it's appropriate to highly in a security review.
It's possible in all cases, as shown, and the trade-off is unnecessary from
first principles.

The fundamental problem with STEKs is that there is no forward secrecy, and
in the case of TLS1.3, no FS for critical data. It's an unfortunate
alignment, as it really undoes a lot of the collective good work to deploy
PFS in practice.

Deploying the PFS cipher suites took nudging providers along; and was not
without cost. I think the same thing may happen with STEKs in the
not-too-distant future. People seem to care about getting forward secrecy.
Smart customers with particularly sensitive workloads will insist.

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.
>

This is easy to say; the TLS layer is the right place. It is not practical
for applications to defend themselves, especially from timing attacks.

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.
>

As the crypto-shortcuts paper showed, in some cases servers had STEKs in
place for the duration of the experiment (months) and perhaps years.


> 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.
>

Sorry, you're right, it's the ticket_age_add which should remain secret. My
understanding is that as NewSesstionTickets messages occur post-handshake,
that they are encrypted under the session keys, and that value is secret.



>
> 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.
>

Thanks for letting me know!


>
> 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
> >
>
>


-- 
Colm