On Thu, Sep 1, 2016 at 8:46 AM, David Benjamin <david...@chromium.org> wrote:
> 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? > ALPN is also in EE. My general principle was that only things that were required to decrypt the handshake messages should be in SH. Arguably, btw, this means that Server.signature_algorithms should be in EE, but I chickened out. -Ekr > > 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
