On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla <e...@rtfm.com> wrote: > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote: >> > On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario <hka...@redhat.com> wrote: >> > > >> > > 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. >> >> Should there be recommendation for clients to cut transfer and send >> Finished if the client receives EncryptedExtensions without >> early_data extension? >> > > I thought that was implicit, but i'd take a PR that did that. >
(s/EncryptedExtensions/ServerHello/, but whatever.) At this point the client must do much more than cut transfer anyway. It probably should be phrased as starting over and retrying or so. Everything sent has been rejected and all you thought you knew about the connection may have changed, like ALPN. At sufficiently high layers, you should probably just pretend you got a fresh connection and are repeating the request (or whatever) from scratch. In the general case, you may even need to bounce to a new connection. Consider if our session was established with h2, we try to 0-RTT-resume it, send 20 replayable HTTP requests across it... and only then to hear from server, "Nope, no 0-RTT for you, try again. Oh, by the way, we're talking http/1.1 now." At least 19 of those 20 requests must get fresh connections anyway. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
