Re: [TLS] Summary of discussion regarding spontaneuous authentication

[Eric Rescorla <[e-mail]>]

One way to handle this would be to separate out the things that indicate
cryptographic capabilities from those that indicate proposed identity.

Specifically, CertificateRequest currently contains:

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;


But as is noted in 5246, there is redundancy here:

   The interaction of the certificate_types and
   supported_signature_algorithms fields is somewhat complicated.
   certificate_types has been present in TLS since SSLv3, but was
   somewhat underspecified.  Much of its functionality is superseded by
   supported_signature_algorithms.  The following rules apply:


And since we have removed the non-signing modes in 1.3, arguably we *just*
need signature_algorithms to specify the cryptographic parameters. Further,
I would argue that the certificate_authorities field is an practice a mess
and doesn't belong at the TLS layer (note that we don't have an analog to
it for the client to tell the server which CAs it supports). [0]

I would argue that the natural thing to do is to keep the cryptographic
pieces
in TLS but move them into the extensions (to match what the client sends).
Specifically, in TLS 1.3 do:

1. Modify https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 to let the
server send the SignatureAlgorithms extension in the ServerHello.

2. Allow the server to send the Supported Elliptic Curves extension
https://tools.ietf.org/html/rfc4492#section-5.1.1 in the ServerHello.


This would have a number of advantages:

1. A more symmetric design since you would use the same extensions in
both directions.

2. A more expressive (and yet simpler) cryptographic negotiation design
since we could indicate both algorithms and groups.

3. Push off the clumsy PKI-based part into the application while leaving the
TLS-relevant crypto part in TLS.

4. It's consistent with both server-solicited and unsolicited authentication
because the client knows what kinds of certificate it is allowed to deliver.

If we make this change, we could still leave CertificateRequest in place,
but
it could be empty, just indicating that the server wants some kind of client
auth and let the client decide. We might also allow the client to say that
he is going to provide it and let the server say OK, to match MT's CANT
draft. The point is that this would leave us with an orthogonal design that
detached capabilities from requests.

-Ekr









On Wed, Oct 22, 2014 at 8:59 AM, Salz, Rich <[e-mail]> wrote:

> > I tend to think that we need a more general mechanism for indicating
> > support for certificate types and signature algorithms.  Maybe we could
> > unconditionally include those in the early handshake instead.
>
> Yes.  In two years when MSFT and Google start deprecating SHA-2 for
> Keccak, it'd be nice to know which cert chain to send.  Or when I don't
> know whether to send an RSA or ECDSA certificate next year.
>
> --
> Principal Security Engineer, Akamai Technologies
> IM: [e-mail] Twitter: RichSalz
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>