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

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

On Tue, May 2, 2017 at 8:17 PM, Eric Rescorla <[e-mail]> wrote:

> Colm,
>
> Thanks for your review. Interesting stuff.
>

Thanks too for taking the time to read it.


> Scrolling ahead to the recommendations, I see you have:
>
> * Require implementations to robustly prevent Ticket re-use for 0-RTT.
>
> This seems like a good idea. I think it's arguable that we got a bit
> nihilistic about this, and as you say, you can do a pretty good job of
> reducing replay within a given data center using some local
> anti-replay mechanism. I would tend to think that a strong SHOULD is
> what you want here, as a MUST is going to be a lot more like a 6919
> MUST (BUT WE KNOW YOU WON'T).
>

A provider choosing to allow replays to their own applications is on them,
they can own the stack top to bottom, take the risk, have a response team
handle attack events, etc ... That's a legitimate case for "SHOULD", there
are exceptions to everything.

But at the same time, what I think we should care most about is the
interoperability case. So for example, if a TLS library, a web server, or
an upstream CDN, can break the assumptions of a down-stream service or
application, that's where we'll see CVEs cropping up. In those cases, I
think the problem is the upstream component, breaking long-held and fair
assumptions. In those cases, it feels like a "MUST".

I'm not sure how to strike a balance, so chose the more secure option.


> I understand from your document and our previous conversation that you
> believe single-use tokens are easier to implement on the server side,
> but I'm not sure I really follow your argument. If you want to provide
> some short text on that that we can all agree on, then I think we
> could incorporate this as well.
>

It's probably not important to get into a single-use token cache in the
draft itself. That was just intended for implementors. One thing that makes
a single-use cache slightly easier to implement is that reads and writes to
keys need not be sequenced relative to any kind of checkpoint.

With a strike register, some kind of checkpoint process is needed. A simple
one is to start with a clean slate, accept only writes for a time period
equivalent to the replay window, and then go read-write. But that kind of
modality is, I think, required. With a single-use cache, it need only
sequence the reads and writes to individual keys. Though it must store much
much more state, so there are different trade-offs to consider.


> * Partial mitigation for Gilmor attacks: deliberately duplicate 0-RTT
>   data
>
> This seems like some sort of extra-grease, but I'm kinda skeptical
> that anyone is going to do it. Perhaps it would be useful to add it to
> draft-ietf-tls-grease?
>

Grease is a good place for it for sure.


> * Require TLS proxies to operate 0-RTT transitively
>
> I've read this several times but I have to admit I don't understand
> it. Do you think you could rephrase?
>

What's in the draft is that there should be an application profile and that
TLS implementations should provide applications with special functions to
tell apart the early and regular data. The problem is that doesn't work
with TLS proxies (like CDNs) ... because the proxies are re-combulating the
data as a single stream to the origin. So the origin can't tell which data
was replayable.

If 0-RTT replay is tolerated, I think that's a big gnarly problem leading
to CVEs. If we prevent replay by other means, like the strike register,
it's not so big a deal.

What I was suggesting was that such proxies always send an outgoing 0-RTT
section to the origin that exactly lines up with the 0-RTT section that
came in on the front end. It's quite hard to make that all work; the CDN
would have to accept 0-RTT only if the origin also does. But I can't see
another way that really works, especially for Layer 4 accelerators. Again,
if 0-RTT replay is forbidden, not nearly as big a deal.


> The following doesn't appear in your recommendations, but I think you
> also think we should:
>
> * Adopt something like PR#998 to make each PSK_id correspond to a
>   different PSK even when they are issued on the same connection.
>

Big +1 to this.


> For the reasons Viktor indicated, I tend to think this is inadvisable.
>

I've been thinking more about this. What if tickets are single-use when
used with 0-RTT, but otherwise allowed for multiple uses? If that's
acceptable, then could we drop the age from tickets purely used for
resumption. That way the age would only appear on tickets that are used
once.

I think that way we get everything.

* Remove ticket_age
>
> This doesn't seem like a good idea: if you are implementing a strike
> register, you want to use ticket_age to help distinguish "fresh" from
> "unknown state". I.e., the ticket_age + the ticket issue time allows
> you to determine approximately when a CH was sent, and any CH that
> is significantly older or newer than now is forced back into 1-RTT.
>

Yep, I was wrong about this, I get it now, and that makes sense.

-- 
Colm