[Unbearable] Removing explicit public key crypto from Token Binding

[Nick Sullivan <[e-mail]>]

Please pardon the timing of this review, I know it's not fun receiving
critiques and large suggestions so late in the process but I think there
are serious issues with the Token Binding Protocol draft that should be
discussed.

The introduction of public key crypto at the application layer seems like a
major downside to the current Token Binding Protocol draft. We went through
a similar design in the Secondary Certificate Authentication in HTTP/2
draft, and learned a bunch of lessons that could be applied to Token
Binding. From these lessons, I have some suggestions that could result in a
much shorter draft that is less complex and will result in a lower
maintenance burden going forward. Long story short: I think the explicit
public key crypto pieces should be removed from this draft.

First, let me spell out some of the downsides of introducing public key
crypto to the application layer:
a) Public key crypto is hard to do right.
Historically, applications have done a bad job at handling public key
cryptography. You don't have to look far past the recent curve point
validation issues in JWS libraries to see this. Exposing "low-level" APIs
like digital signature validation to applications is best avoided if you
want a secure application. For example, things like asking an HTTP server
to properly seed the randomness in an ECDSA signature expands the scope of
what developers at this layer are used to dealing with.
b) Maintenance burden.
Every new signature algorithm to be used here needs to be added to the new
IANA registry. Every time this happens, this document needs to be updated.
Which working group is responsible for updating drafts to add new
algorithms or remove compromised ones once TOKBIND is over and we're
discussing post-quantum signatures? This document is already behind the
curve by supporting P-256 instead of the CFRG-chosen signature algorithms
ed25519 and ed448.
c) It's done better elsewhere.
Correctly defining how to do public key crypto in a draft like this seems
duplicative of other work. Defining the tricky part of actually binding a
public key into TLS should be done with the support of those who have
experience with doing this wrong and learning from their mistakes, like the
TLS working group itself.
d) Layering.
This draft in particular is bound the semantics of several TLS extensions.
Not only does the application need to know the result of the token binding
extension, it needs to know whether or not the extended master secret has
been used. Depending on the correct calculation of a master secret is an
esoteric point that applications may forget to enforce.

Channel-ID is problematic because it introduces additional complexity at
the TLS layer and introduces privacy issues. Token Binding improves this by
putting the messages  at the application layer, but at the cost of also
bringing the public key cryptography into the application. Is there a
middle ground? I suggest there is.


Here's a proposal: rather than defining the signature algorithm and the
binding to the exporter at the application layer, leverage the TLS library
itself to do the binding. This can be done with Exported Authenticators (
https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-01)
The basic idea is that the application provides a private key and
certificate to the TLS library and the TLS library returns a binding of
that certificate to the connection called an "exported authenticator". This
opaque binding can be transported by the application from one party to
another. The receiving party can pass the exported authenticator into the
TLS library, which returns the certificate if it's valid and bound to the
current connection.

Under the hood, the exported authenticator looks like the triplet of TLS
messages {Certificate, CertificateVerify and Finished} with an exporter as
the handshake context. It maps very closely to what Token Binding is doing
now, but eliminates the need for public key crypto in the application.
Instead, the application layer just needs to pass around opaque blobs that
can be decoded by the TLS library into certificates.

To be more concrete about how this could work for the Token Binding
protocol, a self-signed certificate could be used in place of the
TokenBindingPublicKey and the exported authenticator could be used in place
of the TokenBinding. The tokenbinding_type and extensions could be embedded
in the certificate as X.509 extensions. Or application-defined TLS
extensions. I don't know the exact right mapping, but it doesn't seem
difficult to define.

My proposed change would bring the following benefits:
- signature algorithms support would evolve with TLS libraries rather than
with application libraries and updates to this document
- the "token binding key parameters" registry would no longer be needed
- several pages would be eliminated from this draft
- no public key crypto functions added to applications that don't currently
use public key crypto

Nick

P.S.
This proposal also has the interesting benefit of allowing token binding to
be symmetrical. Both clients and servers could created token bindings.
Currently the same exporter is used for both so there's a possibility of
putting server token binding in the place of client token bindings.