Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

[Ilari Liusvaara <[e-mail]>]

On Tue, Apr 18, 2017 at 10:18:03PM +0000, Nick Sullivan wrote:
> On Sat, Apr 15, 2017 at 6:42 AM Ilari Liusvaara <[e-mail]>
> wrote:
> >
> > How do certificate type extensions (#9, #19 and #20) work with exported
> > authenticators?
> >
> > Where other extensions are either meaningless or are edditional info,
> > certificate types actually change the format of the first certificate,
> > which the library needs to understand in order to extract the SPKI for
> > validating the following CertificateVerify.
> >
> 
> I think it would be fair to only support server-generated exported
> authenticators with the certificate_type negotiated by the TLS handshake.
> If the client sent a list of server_certificate_types in its client hello,
> then only authenticators of that type can be used (with the chosen type
> included an extension to the certificate message). Similarly, if the
> server's EE message contains a single client_certificate_type, that would
> be the only type supported by client-generated exported authenticators. I
> can add text to this effect (
> https://github.com/grittygrease/tls-exported-authenticator/issues/12).

There are two bad problems with this:

- The certificate types in TLS 1.3 are a bad hack just for bare minimum
  support for RPK. Using the thing for client post-handshake auth is
  completely unworkable. And adding new certificate types is pretty
  much only workable in special applications[1].

- Relying on TLS capability negotiation is fundamentally problematic.
  There capabilties may not match. And things get downright unworkable
  when things like signature algorithms are considered.


[1] The recent ITS stuff might be one of these applications. Basically,
you can only handle one certificate per type, any more and one gets
issues. And one certificate per type impiles that one does not need
post-handshake authentication.


-Ilari