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

[Ilari Liusvaara <[e-mail]>]

On Tue, May 16, 2017 at 05:39:55PM -0700, Eric Rescorla wrote:
> On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla <[e-mail]> wrote:
> 
> > As promised:
> > https://github.com/tlswg/tls13-spec/pull/1005
> >
> > Note: I may have to do a little post-landing cleanup, but I wanted to get
> > people's senses of the text ASAP.
> >
> 
> Thanks for everyone's comments. I've updated the text to address many of
> them and
> made comments in Github where I decided not to do so. Can those who have
> read
> the previous version please take a look?

To me, that reads as gross understatement about the dangers involved in
0-RTT:

- The side channel attacks with millions or billions of replays are hard
  to protect against. This is if the side channels are in TLS library.
  If not, protecting against that sort of side channels becomes
  virtually impossible.
- Furthermore, with that kind of replay volume, protecting against DoS
  attacks is virtually impossible.
- Even if once-per-server or once-per-cluster replay detection limits
  the number of replays to few hundred to few thoursand at maximum,
  where the low-level crypto side channels are much less of a threat,
  cache attacks can be used to break security (in fact, not sending a
  mad burst of data to any one server is useful for carrying out these).
- 0-RTT Exporters are severly broken unless servers do strict anti-
  replay.

(I left unordered replay out, because I don't see how that is
actually created by 0-RTT, as opposed to just being made easier).

There are no inherent problems in 0-RTT that I know of that would
prevent sending even non-idempotent things like HTTP POSTs over it
(however, failure rates are increased if you do). However, as
currently described, I would not think 0-RTT is safe for anything
except very boring things like protocol banners. I also do not
consider it safe enough to implement in anything that actually
considers security.


Also, on 0-RTT enable/disable: I would imagine that some browsers at
first might have an option to disable 0-RTT. However, I expect that
over time it will get removed (like what happened with the session
ticket support in Firefox), so when serious problem is discovered, there
is no option to disable the vulernable feature at all (like happened
with tickets in TLS 1.0-1.2) or the disable is far too wide (e.g.
disabling whole TLS 1.3 in order to disable 0-RTT).



Also, the kind of thing going on here seems exactly how I would imagine
the past very bad decisions from TLS WG, that were known to be insecure
at the time of specification and where then successfully attacked later,
played out. However, I have not read those discussions from the ML
archives.



-Ilari