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

[Hubert Kario <[e-mail]>]

On Monday 14 March 2016 12:12:51 Geoffrey Keating wrote:
> Colm MacCárthaigh <[e-mail]> writes:
> > On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar <[e-mail]> 
wrote:
> > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite
> > > replayability. As mentioned in the other thread we have ways to
> > > reduce the impact of infinite replayable data for TLS, making it
> > > reasonably replay safe.
> > 
> > That too is a mis-understanding. The deeper problem is that a third
> > party can do the replay, and that forward secrecy is gone for what
> > likely is sensitive data. Neither is the case with ordinary
> > retries.
> 
> Just to expand on this:
> 
> HTTP GET is idempotent and so replayable, correct?  That is, if you
> send two GET requests in a row, you should get the same results, no
> changes should be caused on the server side, and the attacker learns
> nothing new, even if the attacker could not have issued the original
> GET.

Only in theory, in practice you can do most of the same things in GET's 
as you can in POSTs.

in other words, basically web frameworks can be made to modify server 
state upon receiving GET request

and even just the fact that the server thinks it has processed so many 
requests can be damaging (think timestamping service in which you pay 
per request)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic