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. All using slow path (thinking exception handling in > particular). > > Is my understanding correct? > It's not clear to me that it's particularly slow. You get a MAC failure and rejecting the packet is slightly faster than processing it. 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. -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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
