On Thursday, 1 September 2016 05:48:02 CEST Eric Rescorla wrote: > 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.
Then how about making it explicit by including following paragraph:
To protect against denial of service attacks, servers MAY close the
connection at any point when processing records with
trial decryption, but SHOULD process at least four records before doing
so. This is so that server can find the second Finished message in case
client sent just one record of Application Data.
--
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
