Re: [TLS] TLS 1.2 hash agility

[Mike <mike-list at pobox.com>]

Sorry for taking so long to respond to this....

> > 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).
>
> I don't see how this solves the major problem, which is that you
> are advertising your public key algorithm support in two places.

I look at the Supported Signature Algorithms extension as a hybrid
of the sender's list of capabilities (which algorithms his encryption
library supports), and the sender's list of algorithms he deems
acceptable from a security standpoint.  If you exchange this
information in the (proposed) extension, then you don't need to
send it again in other places.

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

The cipher suite doesn't have all the information about which
signature algorithm to use.

    TLS_RSA_WITH_RC4_128_MD5
    TLS_RSA_WITH_RC4_128_SHA
    TLS_RSA_WITH_3DES_EDE_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_AES_256_CBC_SHA

The above cipher suites specify that the public key in the
certificate must be an RSA key, but they don't say anything about
what algorithm is used to sign the certificate.

    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA

These specify that the DH parameters are signed with DSS, but they
don't say which hash to use.  Right now you can only use SHA-1, so
it implicitly limits you to that, but isn't this going to change
soon?

    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Similarly, these say to use RSA to sign the DH parameters, but don't
specify the hash algorithm, so you still need to specify that some-
where.

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

I would argue that all you need to do is remove the redundant list
from the CertificateRequest message.  Since the extension has
already indicated to the client which algorithms the server will
accept, there is no need to send the list again.

> 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.

It's my opinion that the current cipher suites will continue to
work fine.  As I said above, the current cipher suites are under-
specified, so adding the extension fills in the missing blanks.

> 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.

My point is that if you specify this information in ClientHello
and ServerHello, you never have to exchange it again, so you can
eliminate HashTypes altogether.  This will also benefit any future
addition to TLS that requires a signature, since there won't be
the need to exchange the list of supported signature algorithms
yet again.

> 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 would be signed with an algorithm listed in the
server's Supported Signature Algorithms extension.

> - The certificate must contain a public key with an
>   algorithm specified in certificate_types.

Yes, we still need certificate_types.

> - The CertificateVerify must be signed with a signature algorithm
>   in signature_types.

Again, the CertificateVerify would be signed with an algorithm
from the server's extension.

> 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.

I agree with all of that.

At the risk of being redundant, I assert that making this extension
symmetric and allowing the server to respond with its own list of
supported algorithms, is better than having the server send its
list every place where it is needed (now and in the future).  Send
it once in ServerHello, and use it where it's needed.

Mike

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls