On Thu, Sep 1, 2016 at 11:25 AM Eric Rescorla <e...@rtfm.com> wrote: > On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> On Thu, Sep 01, 2016 at 02:29:00PM +0000, David Benjamin wrote: >> > 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> >> > >> >> > >> 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.) >> >> According to the table it is EncryptedExtensions (but there have been >> errors in it before)... >> > > It goes in EE, because it should be encrypted. >
Hrm. Most of the text currently says ServerHello, except for the table which says EncryptedExtensions. ServerHello: https://tlswg.github.io/tls13-spec/#rfc.section.4.2.6 https://tlswg.github.io/tls13-spec/#rfc.section.2.3 EncryptedExtensions: https://tlswg.github.io/tls13-spec/#rfc.section.10 I'm a little wary of putting something that tells you the handshake "shape" in EncryptedExtensions. Accepting early_data comes with a host of constraints the client must enforce like ALPN not being allowed to change, etc. But I think all the current constraints are with EncryptedExtensions, so maybe it's fine? (The failure mode for getting this wrong is a risk of serious implementation complexity and bugs, similar to why client EncryptedExtensions was a problem. E.g. if ALPN were in SH but early_data in EE , there would be a window of time where we have a new ALPN but aren't sure if it's a 0-RTT reject or fatal error. It makes things a mess.) > > 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. >> >> So server is supposed to continue on 0-RTT fail, but not client? > > > There are plenty of scenarios where the client can continue. For instance, > if the server has forgotten the ticket but is otherwise unchanged. > Right, I mean it's a logical starting over. I imagine most cases one can keep affinity with the old transport socket just fine, but data does likely need to be reset. (Although in some cases you can't.) David > -Ekr > > >> >> -Ilari >> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
