On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario <hka...@redhat.com> wrote:
> 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. > It's not required to. It can close the connection at any time. -Ekr -- > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
