On Wednesday, 31 August 2016 11:23:11 CEST Eric Rescorla wrote: > On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario <hka...@redhat.com> wrote: > > Current draft has the following text in it: > > If any of these checks fail, the server MUST NOT respond > > with the extension and must discard all the remaining first > > flight data (thus falling back to 1-RTT). If the client attempts > > a 0-RTT handshake but the server rejects it, it will generally > > not have the 0-RTT record protection keys and must instead > > trial decrypt each record with the 1-RTT handshake keys > > until it finds one that decrypts properly, and then pick up > > the handshake from that point. > > > > My understanding of that, in case client does 0-RTT but server rejects it > > (because the PSK is too old or its time is different enough) is that the > > server needs to keep on reading arbitrarily large amounts of data it has > > no > > idea what to do with > > > > Why is there no limit on the amount of data that can be encrypted using > > PSK keys (0-RTT)? > > I don't think this would usefully improve things.
there's also second angle: I'm afraid that requiring the server to keep the connection open for essentially arbitrary amount of time while it consumes garbage data is not unlike the Apache slowloris attack. -- 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
