Re: [TLS] Summary of discussion regarding spontaneuous authentication

[Joseph Salowey <[e-mail]>]

On Mon, Oct 27, 2014 at 3:07 PM, Eric Rescorla <[e-mail]> wrote:

> 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]
>
>
[Joe]  While I'm not a huge fan of the certificate authorities list, I'm
not sure that punting this to the application layer is the right thing to
do.  Some uses of TLS do not have a way to signal this in a higher layer.
For example, there are some EAP-TLS clients that will choose what
certificate to use based on this information from the server.   It may be
possible to extend EAP-TLS to send a client identity hint or similar
information in the first message from the server, but there really isn't
space in EAP-TLS for non-tls data.   An alternate approach would be the
client makes a guess as to which cert to use and if it isn't right then the
server sends a message encoded in TLS that tells the client what to do.
I'm not overly excited about wither of these approaches since they will
require changes to the applications.




> 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.
>
>
[Joe]  I'm not convinced about pushing the PKI part to the application yet,
but I like the rest of the concept.


> -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
>>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>