Subject: [TLS] Exported Authenticators proposed updates

From: Nick Sullivan <[email-masked]>
Date: Tue, 13 Jun 2017 00:32:12 +0000

All,

I've collected a few changes that help clarify some ambiguities brought up
on the list and during implementation of the draft. These changes are laid
out as the following PRs in Github:

Restrict the Certificate type to standard X.509 certificates.
https://github.com/grittygrease/tls-exported-authenticator/pull/20

Relax requirement for the certificate_request_context to be unique, clarify
the benefits of doing so.
https://github.com/grittygrease/tls-exported-authenticator/pull/18

Be more explicit about how signature schemes are chosen and supported.
https://github.com/grittygrease/tls-exported-authenticator/pull/18

Modify handshake context to be asymmetrical with respect to client and
server.
https://github.com/grittygrease/tls-exported-authenticator/pull/15
<https://github.com/grittygrease/tls-exported-authenticator/pull/16>

Let me know if there are any objections. If there are no comments I'll
merge the changes and publish a new draft.

Nick

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Jun 2017 10:56:09 +0300

> https://github.com/grittygrease/tls-exported-authenticator/pull/20

Supporting certificates that are not X.509 actually brings major
complications in protocol like this. The TLS library must
recognize those types in order to properly extract the key
needed to verify the CertificateVerify. The type extension can't
just be skipped.

Also, for related reasons, when implementing client certificates
in TLS library I am working on, I only implemented X.509, despite the
library supporting authentication based on keys, and RPK being
supported for server authentication. The reason for this was the
pretty nasty interaction of certificate types with client
certificates.

> https://github.com/grittygrease/tls-exported-authenticator/pull/18

Might also note unpredictability. And then note what happens if
uniqueness (replays of the same certificate) or unpredictability
(pregenerating responses) fails. Neither seems catastrophic (unlike,
say repeating a nonce in AEAD).
 
After all, the certificate contexts in TLS 1.3 discuss
unpredictability.

> https://github.com/grittygrease/tls-exported-authenticator/pull/18

This seems to be only place where non-standard APIs are required from
the TLS library itself (I don't think most TLS APIs that do have
exporters and EMS indication have facility to obtain the list of
algorithms supported).

And the client side is supposed to have a call for obtaining the
supported algorithms anyway.

Why not always operate on TLS 1.3 semantics, regardless of transport
version? Main implications would be always using PSS with RSA and
not mixing ECDSA curves and hashes.

-Ilari

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 13 Jun 2017 18:12:02 +0000

Thanks for the comments. I've updated the PRs appropriately.

> After all, the certificate contexts in TLS 1.3 discuss

Good comment. I added some text to reflect this.

> exporters and EMS indication have facility to obtain the list of

For this API, the server needs to know which signature algorithms the
client supports and use that to make the correct choice of certificate. The
signature schemes will have to be available already for servers to do
dynamic certificate selection, so I don't see this as a big ask.

> not mixing ECDSA curves and hashes.

This would simplify the logic substantially. I don't see any problems with
eliminating PKCS#1 1.5 altogether. I have updated the PR.