[TLS] TLS 1.2 and hash agility for signatures

[<[e-mail]>]

There's one area in TLS 1.2 that still doesn't give me a warm 
fuzzy feeling that "yes, this is the way it should be done", and 
that's the algorithm agility for signatures (in certificates and
ClientKeyExchange/ServerKeyExchange messages).

I'd like to get some more discussion about this, and fresh
ideas on what's the best way to implement it in TLS 1.2.

Some issues that don't yet seem right:


1) Asymmetry: The server sends its list of supported hashes in the
CertificateRequest message, together with list of trusted CAs (DNs)
and ClientCertificateTypes. The client sends the list of supported
hashes in cert_hash_types extension, list of trusted CAs (DNs or
hashes) in trusted_ca_keys extension, and there's no equivalent of
ClientCertificateType.  In addition, we have the "cert_type" extension
for non-X.509 certs (draft-ietf-tls-openpgp-keys).

To make things worse, ClientCertificateTypes field seems quite
redundant, since at this point we already know the ciphersuite, and
that limits our choice (it doesn't make sense to request dss_sign
certificate if you've already negotiated RSA ciphersuite). Or if it's
not redundant, then we need more text in the spec explaining why not.

Perhaps we can't avoid this asymmetry completely, but is there any way
to make this a bit nicer? Perhaps remove the ClientCertificateTypes
field in TLS 1.2, and use cert_hash_types extension also from server
to client?


2) Wrong concept: instead of telling what hash algorithms we support
we'd really like to tell what kinds of signatures we can verify.
E.g. for RSA, we have at least three different schemes (PKCS#1 v1.5,
PSS and ANSI X9.32), all of which can be used with different hashes.
And we also have DSS and ECDSA.

For TLS level signatures (ServerKeyExchange/CertificateVerify), some
part of this is already determined by the ciphersuite's key exchange
algorithm (e.g. RSA here means PKCS#1 v1.5; if someone wants to use
RSA PSS we'd define new ciphersuites). But for certificates, the
situation is not the same; we could have certificate containing RSA
public key signed with DSS, or something.

Should we have signature_schemes extension instead of cert_hash_types?
(with values like rsa_pkcs15_sha256, dss_sha1, ecdsa_sha512, etc.)  
Or separate lists for certificate signatures and signatures in TLS?



3) Tying algorithm in ServerKeyExchange/CertificateVerify and
certificate. The current spec says that for RSA, signatures in TLS
(ServerKeyExchange and CertificateVerify) use the same hash as was
used by the CA in the certificate.

The idea itself is not wrong: if you're worried about using SHA-1,
then it's much more important to use something better in certificates
(usually long-lived) than in ServerKeyExchange/CertificateVerify
(which include fresh nonces, and are verified only once immediately
following signature generation -- so offline attacks don't count).

However... what if the cert isn't signed with RSA? Or it's signed with
RSA PSS? And is it OK to require the peer to parse its own certificate
(something not previously required)? Perhaps we should decouple these?


4) RSA-specific text. It looks like much of the text (and whole
cert_hash_types) is really specific to RSA ciphersuites, since the
spec fixes SHA-1 for DSS, and RFC4492 specifies that for ECDSA, the
hash is always SHA-1 unless otherwise specified by yet-unspecified
extension in the certificate.

It may not be possible to avoid RSA-specific text, but then it should
be easy to see what parts are specific to RSA and what are not. And we
should probably plan for hash agility in DSS as well?


Comments? I think we'd want something reasonably simple in the spec,
but on the other hand, it should be technically coherent as well.
I'm planning to sketch something before Prague, but any kinds
of ideas (or alternative ways of looking at the problem) would
be welcome...

Best regards,
Pasi

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