RE: [TLS] TLS 1.2 hash agility

[<[e-mail]>]

Eric,

Looks very good!

There's one corner case that probably needs explicit clarification 
in the spec: certificate request containg any of the fixed-DH client
certificate types (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, and
ecdsa_fixed_ecdh).

One option would be to simply replace these with "fixed_dh" and
"fixed_ecdh" -- but that would require updating RFC 4492 as well,
and maybe we don't want to go there.

So perhaps the simplest solution would be just to add another
rule for certificate request processing:

- In case of "*_fixed_dh" client certificate types, the 
  client certificate must be signed by an algorithm specified 
  in certificate_types. This restriction applies only to the
  end-entity certificate, not other certificates possibly
  included in the certificate chain.

Or we could just remove this redundancy, and instead say:

- For historical reasons, the names of some client certificate 
  types include the algorithm used to sign the certificate.
  For example, in earlier versions of TLS, rsa_fixed_dh meant a 
  certificate signed with RSA and containing a static DH key.

  In TLS 1.2, this functionality has been obsoleted by the
  signature_types field, and the certificate type no longer 
  restricts the algorithm used to sign the certificate.
  For example, if the server sends dss_fixed_dh certificate type
  and {dss_sha1, rsa_sha1} signature types, the client is allowed
  to reply with a certificate containing a static DH key, signed
  with RSA-SHA1.

(The latter alternative would bring us more flexibility,
and would enable combinations not currently possible: e.g.
fixed_dh key signed with ecdsa).

Best regards,
Pasi

> -----Original Message-----
> From: ext Eric Rescorla [mailto:[e-mail]] 
> Sent: 17 September, 2007 21:58
> To: Mike
> Cc: [e-mail]
> Subject: Re: [TLS] TLS 1.2 hash agility
> 
> 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
> 

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