[openssl-dev] Minor bug in custom TLS extensions

[Emilia Käsper]

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>