Re: [TLS] Additional warnings on 0-RTT data

[Martin Thomson <[e-mail]>]

On 24 November 2016 at 15:11, Colm MacCárthaigh <[e-mail]> wrote:
> Do you disagree that the three specific example security issues provided are
> realistic, representative and impactful? If so, what would persuade you to
> change your mind?

These are simply variants on "if someone hits you with a stick, they
might hurt you", all flow fairly logically from the premise, namely
that replay is possible (i.e., someone can hit you with a stick).

The third is interesting, but it's also the most far-fetched of the
lot (a server might read some bytes, which it later won't read,
exposing a timing attack).  But that's also corollary material; albeit
less obvious.  Like I said, I've no objection to expanding a little
bit on what is possible: all non-idempotent activity, which might be
logging, load, and some things that are potentially observable on
subsequent requests, like IO/CPU cache state that might be affected by
a request.

>> I'm of the belief that end-to-end
>> replay is a property we should be building in to protocols, not just
>> something a transport layer does for you.  On the web, that's what
>> happens, and it contributes greatly to overall reliability.
>
> The proposal here I think promotes that view; if anything, it nudges
> protocols/applications to actually support end-to-end replay.

You are encouraging the TLS stack to do this, if not the immediate
thing that drives it (in our case, that would be the HTTP stack).  If
the point is to make a statement about the importance of the
end-to-end principle with respect to application reliability, the TLS
spec isn't where I'd go for that.

> The problems of 0-RTT are disproportionately under-estimated. I've provided
> what I think are three concrete and realistic security issues. If we
> disagree on those, let's draw that out, because my motivation is to mitigate
> those new issues that are introduced by TLS1.3.
>
>> What I object to here is the externalizing that this represents.  Now if I
>> have the audacity to
>> deploy 0-RTT, I have to tolerate some amount of extra trash traffic
>> from legitimate clients?
>
>
> I think there is a far worse externalization if we don't do this. Consider
> the operations who choose not (or don't know) to add good replay protection.
> They will iterate more quickly and more cheaply than the diligent providers
> who are cautious to add the effective measures, which are expensive and
> difficult to get right.

OK let's ask a different question: who is going to do this?

It's a non-trivial thing you ask for.  This involves a new connection
setup just to send a few packets, and probably a timer so that you can
wait long enough for the server to explode.  Do you expect to replay
before the real attempt?  Because that's even less likely to happen.

Connections aren't cheap, bandwidth as well.  And the time requirement
for building such a feature would be better spent elsewhere, not to
mention the ongoing maintenance.

I don't see browsers doing anything like what you request; nor do I
see tools/libs like curl or wget doing it either.  If I'm wrong and
they do, they believe in predictability so won't add line noise
without an application asking for it.

If few enough people do this, what makes you think that such a tiny
amount of replay would make any difference?  Unless you replay with
high probability, then the odd error will be dismissed as a transient.
This is especially true because most of these sorts of exploitable
errors will happen adjacent to some sort of network glitch (the
requests at the start of most connections - on the web at least - are
pretty lame).

Then you all you have done is increased the global rate of "have you
turned it off and on again?", which is - after all - yet another
opportunity for replay.