[openssl-dev] Minor bug in custom TLS extensions
Emilia Käsper
emilia at openssl.org
Wed Sep 2 10:01:20 UTC 2015
On Wed, Sep 2, 2015 at 3:00 AM, Bill Cox <waywardgeek at google.com> wrote:
> On Tue, Sep 1, 2015 at 2:50 PM, Emilia Käsper <emilia at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150902/855a1101/attachment.html>
More information about the openssl-dev
mailing list