[openssl-dev] Minor bug in custom TLS extensions

[Bill Cox]

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.


> 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...

I do think this is a good candidate for custom extensions.

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150901/091ce829/attachment-0001.html>