Re: [TLS] TLS 1.2 hash agility

[Eric Rescorla <[e-mail]>]

At Sat, 15 Sep 2007 11:56:39 -0700,
Mike wrote:
> I have an idea.  Change the Cert Hash Types extension to the Supported
> Signature Algorithms extension, and allow the server to respond with
> its supported algorithms (only if the client sends its list, of course).
> 
>      struct {
>          SignatureAlgorithm supported_algorithms<2..2^16-2>;
>      } SupportedSignatureAlgorithms;
>
> If the client doesn't send the extension, the server would assume the
> client supports rsa_with_sha1, rsa_with_md5 (?), and dsa_with_sha1
> (and the appropriate ecdsa algorithms if an ECDSA cipher suite is
> negotiated).  Since the server can't send its list if the client
> doesn't, the client must assume that the server only supports the same
> list of algorithms.

I don't see how this solves the major problem, which is that you
are advertising your public key algorithm support in two places.

- In the case of the ServerKeyExchange, the client signals his
support in this extension *and* in the cipher suite.

- In the case of the CertificateVerify, the server signals his
  support in the CertificateRequest and in this extension.

Taking the ServerKeyExchange as the paradigmatic example, ISTM that
we either need to rework the entire negotiation scheme, e.g.,
to create new cipher suites which specify also the digest used
for signature, or just live with this duplication. The former
seems superior.

So, I propose we simply replace the HashTypes type with a signature
algorithms type that specifies both hash algorithm and signature
algorithm. As you suggest:

     struct {
         SignatureAlgorithm supported_algorithms<2..2^16-2>;
     } SupportedSignatureAlgorithms;

This would go wherever HashTypes goes now.

However, the interpretation rules need to be extremely clear,
as below.


CERTIFICATEREQUEST
For signatures by the client (i.e., CertificateVerify and Certificate),
the following rules apply:

    struct {
        ClientCertificateType certificate_types<1..2^8-1>;
        SignatureAlgorithm signature_types<1..2^16-1>;
        DistinguishedName certificate_authorities<0..2^16-1>;
    } CertificateRequest;
 
- Any certificate offered by the client must be signed with an
  algorithm described in signature_types.
- The certificate must contain a public key with an
  algorithm specified in certificate_types.
- The CertificateVerify must be signed with a signature algorithm
  in signature_types.

Consider the following examples:

(1) 
certificate_types = rsa_sign
signature_types   = rsa_sha1, rsa_sha256

In this case:

- The client's certificate must be signed with rsa_sha1 or rsa_sha256
- The client must sign with either rsa_sha1 or rsa_sha256


(2) 
certificate_types = rsa_sign
signature_types   = rsa_sha1, rsa_sha256, dsa_sha1

In this case:

- The client's certificate must be signed with rsa_sha1 or rsa_sha256, or 
  dsa_sha1
- The client must sign with rsa_sha1 or rsa_sha256, but NOT DSA



(3) 
certificate_types = rsa_sign, dsa_sign
signature_types   = rsa_sha1, rsa_sha256

In this case:

- The client's certificate must be signed with rsa_sha1 or rsa_sha256
- The client must sign with either rsa_sha1 or rsa_sha256

Note that even though the server advertised dsa, it didn't advertise
any hashes so it's not actually usable.



SIGNATUREALGORITHMS
As you suggest, the client would offer a SignatureAlgorithms
extension. The rules would be similar:

- Any certificate offered by the server must be signed with an
  algorithm described in signature_types.
- The certificate key must contain a public key which has
  an algorithm that matches the cipher suite, either for
  signing (in the case of cipher suites which have it)
  or encryption (in the case of cipher suites which don't).
- The ServerKeyExchange must be signed with an algorithm that
  matches signature_types.

Examples:
(1) 
cipher suite      = TLS_RSA_WITH_AES_128_CBC_SHA
signature_types   = rsa_sha1, rsa_sha256

In this case:

- The server's certificate must be signed with rsa_sha1 or rsa_sha256
- The server's certificate must contain an RSA key.


(2) 
cipher suite      = TLS_RSA_DHE_WITH_AES_128_CBC_SHA
signature_types   = rsa_sha1, rsa_sha256


- The server's certificate must be signed with rsa_sha1 or rsa_sha256
- The server's certificate must contain an RSA key.
- The ServerKeyExchange MUST be signed with rsa_sha1 or rsa_sha256

-Ekr


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls