Re: [TLS] TLS 1.2 hash agility

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

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.

If the client sends its list, and the server doesn't respond with the
extension, the client must assume that the server only supports the
algorithms mentioned above.  A client that requires better algorithms
than MD5 and SHA-1, can abort the session if it doesn't receive the
extension in the ServerHello, or if the list doesn't contain an
acceptable algorithm.

You can remove the HashType list from the CertificateRequest message
since it is handled by the server's SupportedSignatureAlgorithms
extension.  The client also chooses a certificate signed with a listed
algorithm.

If the Signature becomes (as Pasi suggested):

    struct {
        SignatureAlgorithm signature_algorithm;
        opaque signature_value<0..2^16-1>;
    } Signature;

we'd also need to add a null signature algorithm:

    enum {
        null(0),            rsa_with_md5(1),
        rsa_with_sha1(2),   rsa_with_sha256(3),
        rsa_with_sha384(4), rsa_with_sha512(5),
        dsa_with_sha1(6),
        (65535)
    } SignatureAlgorithm;

for use with anonymous exchanges.

Mike

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