On Wed, Sep 2, 2015 at 3:00 AM, Bill Cox <waywardg...@google.com> wrote:
> On Tue, Sep 1, 2015 at 2:50 PM, Emilia Käsper <emi...@openssl.org> wrote: > >> It's not quite clear to me why you'd have to resend parameters on >> resumption. After all, they are definitive for the session. Best if the >> draft explicitly specifies resumption behaviour. >> > > I agree the draft should be enhanced to address resumption. I'll ping the > ietf list. > > >> It's also not clear to me that the serialized TLS session is the place to >> store the parameters. Shouldn't they rather be stored at the application >> level, alongside with the eventual token? >> > > I think everyone is opposed to storing state from the Token Binding > extension in the TLS session state. I agree it could be saved higher in > the application stack in the client, but what if the resumption is with a > server that does not support Token Binding for some reason? In that case > the server ignores the extension and the client knows to disable Token > Binding because it did not receive the extension from the server. This is > how I implemented it locally, but I think this behavior should be clarified > in the spec. > Ah right. Yes, the spec should spell that out. > > >> But setting that aside, the interaction with extended master secret makes >> using custom extensions for this purpose tricky anyway. Custom extensions >> don't really support interaction with other extensions; there's no >> guarantee that you'll end up processing them in the right order. >> >> (But I've only skimmed the docs so it's possible I got it all wrong.) >> > > In this case I am lucky. EMS is baked-in with native support, and all > native extensions are parsed before all custom extensions. However, I > realize this is not gaurenteed behavior. I should add a test for it... > As far as I can see, the OpenSSL client processes extensions in the order they come in. But nothing is guaranteed. > > I do think this is a good candidate for custom extensions. > > Thanks, > Bill > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > >
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
