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

Hi Andrei,

The text states:

    A basic property of Token Binding is that malware can't export the
    token and successfully use it from another machine,
    as long as it cannot also export the TB key.

This sentence is incorrect for two reasons:

    1° The major problem is not related to a malware, but to a specific
    piece of software voluntary installed and used by one client.

    2° There is no need to export the TB key, since one client can
    perform all the needed computations for the benefit of another client.

For example, simply protecting the TB key in a secure element (e.g. 
smart card or a HSM) is insufficient.

A basic property of the current Token Binding mechanism is that a 
specific piece of software voluntarily installed by a client can export
the token and perform all the needed computations so that the token can 
successfully be used from another machine.

As soon as someone will develop that piece of software and make it 
publicly available, everybody will be able to use it and
all the current Token Binding mechanisms will collapse.

Denis

> Hi Nick,
>
>> Second replay of a TokenBinding message on a new connection (where the exporter is the same). This involves client malware, which can just as easily do private key operations to generate new TokenBinding messages to use on new connections. In TBPROTO, this is also possible, but it can only be done for active connections. With 0-RTT, the attacker can do this for connections that will be created up to 7 days in the future.
> A basic property of Token Binding is that malware can't export the token and successfully use it from another machine, as long as it cannot also export the TB key. This is a useful property, because it means that once the client malware is removed, the attack is immediately stopped. This property is not present when Token Binding is used in combination with 0-RTT, because it may be possible for the malware to export the TLS 1.3 resumption secret.
>
>> If a server's threat model does not include client malware, i.e. the server is only using Token Binding to protect against attacks like XSS (e.g. to protect cookies without the HttpOnly flag set, or OAuth tokens), then enabling both TB and 0-RTT is perfectly reasonable.
>> Depending on the server's policies, even if client malware is in its threat model it still could find the 7 day window acceptable.
> Yes, I can easily imagine servers with such policies:).
> If the WG decides to allow the use of TB in combination with 0-RTT, then we should at least provide a way for the client to negotiate replayable/0-RTT TB option separately. This would allow a client to opt out of "replayable TB", while avoiding reauthentication on every connection. A server that receives a TLS 1.3 ClientHello advertising "proper TB" (and not "replayable TB") would either not negotiate Token Binding, or reject 0-RTT resumption with this client (and instead do a full handshake).
>
> A different client would be able to offer both "proper TB" and "replayable TB". Such a client would use the 0-RTT exporter throughout all 0-RTT connections, simplifying the rules... Would this work for you, Nick?
>
> Cheers,
>
> Andrei
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable