Re: [TLS] Closing on 0-RTT

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

On Sun, Jun 11, 2017 at 8:18 AM, Eric Rescorla <[e-mail]> wrote:

> Here's what I propose to do:
>
> - Describe the attacks that Colm described.
>
> - Distinguish between replay and retransmission
>
> - Mandate (SHOULD-level) that servers do some sort of bounded
>   (at-most-N times) anti-replay mechanism and emphasize that
>   implementations that forbid replays entirely (only allowing
>   retransmission) are superior.
>
> - Describe the stateless mechanism as a recommended behavior but not
>   as a substitute for the other mechanisms. As Martin Thomson has
>   pointed out, it's a nice pre-filter for either of these other
>   mechanisms.
>
> - Clarify the behavior you need to get PFS.
>
> - Require (MUST) that clients only send and servers only accept "safe"
>   requests in 0-RTT, but allow implementations to determine what is
>   safe.
>
> Note: there's been a lot of debate about exactly where this stuff
> should go in the document and how it should be phrased.  I think these
> are editorial questions and so largely my discretion.
>

First of all, thanks for doing this, that all sounds great! The TLS spec is
obviously monumentally important to the internet, and years of hard work
aren't made easier by late-coming changes, that shouldn't be thankless.


> Here's what I do not intend to do.
>
> - Mandate (MUST-level) any anti-replay mechanism. I do not believe
>   there is any WG consensus for this.
>

The one case here where I'd really argue for a "MUST" is middle-boxes like
CDNs. The concern I have is if someone has an application that uses
throttling or is vulnerable to a resource-exhaustion problem and goes and
puts a CDN in front of it, it's not obvious that enabling TLS 1.3 could
open them to a new kind of DOS attack.

We've already seen CDNs enable TLS 1.3 with unintentionally broken 0-RTT
mitigations, so that's clear evidence that the existing guidance isn't
sufficient. I think it would help manage the interoperability risks if we
can point out to their customers that the configuration is unambiguously
broken. Or at least, it helps to flag it as a security issue, which makes
it more likely to get fixed. Absent this, the operators of "backend"
applications would have to live with risk that is created by the upstream
CDN providers for their own convenience. That seems like a really bad
interoperability set up.

I'd argue for at-most-once protection here, since that's the only way a
client can make deterministic decisions, and it's also easier to audit and
GREASE. But there doesn't seem to be consensus around that. At the moment,
I feel that's a bit like the lack of consensus the "Clean coal" industry
has on global warming though, because it seems to be an argument rooted in
operational convenience rather than actual security. This is not the
standard we apply in other cases; we wouldn't listen to those who say that
it's ok to keep RC4 or MD5 in the standard because the problems are small
and the operational performance benefit is worth it. My spidey-sense is
that these attacks will get better and more refined over time.

Nevertheless, /some/ guaranteed replay protection would be better than
none. particularly in this case. So if it's at-most-N, and N is small
enough to at least avoid many throttling cases, that's something worth
taking, even though it does leave open the easier cache-analysis attacks.

- Design a mechanism to allow the server to tell the client that it
>   either (a) enforces strong anti-replay or (b) deletes PSKs after
>   first use. Either of these seem like OK ideas, but they can be added
>   to NST as extensions at some future time, and I haven't seen a lot
>   of evidence that existing clients would consume these.
>

This can happen totally outside of the protocol too; as-in an operator can
advertise it as a feature. Likely most useful for the forward secrecy case.

-- 
Colm