Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?

[Eric Rescorla <[e-mail]>]

I'm not quite sure I understand the reasoning here, so let me try to walk
through it.

The HTTP stack tells the TLS stack to initiate a connection and starts
streaming
requests down to the TLS stack. At this point, it can only use the 0-RTT
exporter,
so it has to do that. At some point in this process, the client receives
the 1-RTT
Finished and can then switch to the 1-RTT exporter, but the serves has no
way
of knowing at which point that is.

In the current rule, the client MUST switch when it sees app data from the
server,
so if the server receives a HTTP request from the client that is
semantically
dependent on some HTTP response from the server, then it knows that the
client should have switched at this point. However, ISTM that SFIN must
have appeared prior to the any such application layer message, so requiring
the client to switch on SFIN would make the switch happen slightly earlier
and give the server the same guarantees. What's the argument for not
requiring
that instead, given that it's tied to the state of the TLS stack rather
than the
HTTP stack.

-Ekr


On Fri, Mar 10, 2017 at 12:11 PM, Nick Harper <[e-mail]> wrote:

> I'd like to update the I-D to address the concern of which exporter to
> use when. I know that this update will not address the recent concern
> around proof of possession of the TB key in 0-RTT, and we can discuss
> that concern at IETF 98 in Chicago. Below is an outline of how I plan
> to handle changing exporters. Does it sound reasonable to update the
> I-D now, even with the open concern around proof of possession?
>
> Outline for changing exporters:
> In early data, the client uses the early exporter.
> Upon receiving an application-layer response from the server, the
> client switches to the regular exporter. (The client may have some
> requests that were sent after the TLS handshake completed but still
> using the early exporter.)
> The above switch allows a server to on a per-request basis decide that
> the signature of the early exporter was not sufficient and have the
> client re-send the request with the regular exporter. In http, this
> can be done by the server responding with a 307 redirecting to the
> same resource (optionally with an additional query param indicating
> that said redirect happened).
>
> In the TokenBinding struct for any Token Binding whose signature is of
> the early exporter, the client includes an Extension with
> ExtensionType early_exporter(TBD) and 0-length extension_data to
> indicate that the server should verify the signature using the early
> exporter instead of the normal exporter.
>
> On Wed, Mar 1, 2017 at 5:36 PM, Nick Harper <[e-mail]> wrote:
> >> -----Original Message-----
> >> From: Martin Thomson [mailto:[e-mail]]
> >> Sent: Wednesday, March 1, 2017 4:53 PM
> >> To: Nick Harper <[e-mail]>
> >> Cc: Andrei Popov <[e-mail]>; IETF Tokbind WG <
> [e-mail]>
> >> Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?
> >>
> >> Would it help to include a clear signal about which keys are intended
> to be exported and used?
> >
> > Yes, I plan to include some sort of signal so that the server doesn't
> > have to do trial verification. This could be defining a new set of key
> > types that when used in a TokenBinding struct indicate the signature
> > is over the early exporter, or it could be an indicator extension in
> > the TokenBinding struct (or maybe something else). The former has the
> > benefit that it is covered by the signature (unless the signature
> > format changes).
> >
> >
> > On Wed, Mar 1, 2017 at 4:54 PM, Andrei Popov <[e-mail]>
> wrote:
> >> This solution introduces a lot of complexity, but does not address the
> fundamental problem, which is that the client can't prove possession of the
> TB key in 0-RTT. So, if I have a site that requires strong protection of
> tokens with TB, I would disable 0-RTT application data, or at least reject
> requests that arrive in 0-RTT and require bound tokens to be authorized.
> >
> > The signature over the early exporter proves that the client had
> > possession of the TB key sometime after the server issued the
> > NewSessionTicket used for starting the 0-RTT connection. Whether this
> > is good enough depends on the threat model of the server. Obviously a
> > server that is paranoid can choose to reject 0-RTT data if Token
> > Binding is also negotiated on the connection, and I'm fine with that.
> > However, a server may decide that it is not concerned with client
> > malware stealing a NewSessionTicket (and corresponding data to replay
> > a 0-RTT TokenBindingMessage), and find this proof of possession good
> > enough.
> >
> > 0-RTT data has different security properties than 0.5-RTT or
> > post-handshake application data in TLS 1.3, so it's reasonable for a
> > TokenBindingMessage sent in 0-RTT application data to have different
> > security properties.
>
> _______________________________________________
> Unbearable mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/unbearable
>