On Monday 14 March 2016 12:12:51 Geoffrey Keating wrote: > Colm MacCárthaigh <c...@allcosts.net> writes: > > On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar <sub...@fb.com> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
