Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Nikos Mavrogiannopoulos <[e-mail]>]

On Sun, 2016-03-13 at 13:38 +0100, Eric Rescorla wrote:
> > 
> > However, if I'm in the rough about the above, (which seems
> > to me to be the case now) then my job as AD when I get a
> > publication
> > request that includes 0rtt, will include figuring out if that's
> > safe or not. And I've no clue how I'll do that unless the WG
> > have already done some analysis of the many, many protocols
> > that use TLS. Note that I do not consider "use a different API"
> > to be a sufficient answer here (it is necessary, but not
> > sufficient). 
> It seem to me that there are several important mitigating factors
> here.
> 
> 1. Nothing requires applications to use this feature at all. First,
> servers
> need to advertise it and are free to (a) not offer clients the
> ability to send
> 0-RTT data and (b) refuse to accept it if clients send it. Moreover,
> everyone
> I know of who is considering building a 1.3 library intends to
> provide
> that data to the server via a separate API, so the server will have
> to work
> to get it.

It is important to see how protocols are perceived. For many people TLS
1.3 with 0rtt will be the same as TLS 1.3. The first publication of an
attack against TLS 1.3 with rtt, will be perceived as an attack against
TLS 1.3 protocol. Even if the published attack against TLS 1.3 with
0rtt was an expected one (i.e., replay of data), if the attack impact
is high, that may not be sufficient to stop the avalanche of bad
publicity. In turn that will lead several people losing confidence to
TLS 1.3 as a protocol, even TLS and the IETF process overall.
 
My suggestion, if you need 0rtt, publish it as a different document,
don't mix it with TLS 1.3. The security requirements from TLS are
vastly different from the security requirements of a 0rtt protocol.

regards,
Nikos