Subject: [websec] Key pinning for DSA keys with inherited domain params

From: "Manger, James H" <[email-masked]>
Date: Sun, 11 Dec 2011 01:30:34 +1100

A DSA public key consists of an integer y, plus domain parameters p, q, and g. The domain parameters may be included in a SubjectPublicKeyInfo value for the key in a certificate, but they may also be omitted if the CA that issued the certificate uses the same domain parameters for its key. [See RFC 3279 Algorithms and Identifiers for PKIX, section 2.3.2; http://tools.ietf.org/html/rfc3279#section-2.3.2]

This seems like a problem for key pinning as specified in draft-ietf-websec-key-pinning-01, where a pin is the hash of a SubjectPublicKeyInfo value. My guess is that it is insecure for a pin to only cover y, but not p, q, and g.

Without going back to the maths of DSA, I suspect an attacker can find another set of domain parameters and private key that have the same public key (y) as a victim. This attacker key can have the same pin as the victim's.

I think the same issue applies to ECDSA and ECDH keys, and potentially other public key algorithms as well.

Possible solutions:

1. Say the pinning mechanism MUST NOT be used when a SubjectPublicKeyInfo value does not completely specify the public key, such as when holding a DSA key without its domain parameters. This would be acceptable if no one uses the inherit-parameters-from-the-CA option. I have no idea whether or not that is true.

2. Define a special rule for each known algorithm that can inherit parameters (such as DSA): the domain parameters MUST be added (from the CA cert, for instance) before calculating the pin. That is a bit of a burden for all implementations.

--James Manger

---

From: Adam Langley <[email-masked]>
Date: Mon, 12 Dec 2011 10:03:04 -0500

> 1. Say the pinning mechanism MUST NOT be used when a SubjectPublicKeyInfo value does not completely specify the public key, such as when holding a DSA key without its domain parameters. This would…

I believe that you're correct that this is a problem and I suggest
your solution (1): a public key pin cannot be formed if the SPKI is
incomplete when taken in isolation.

Cheers

AGL

---

From: Chris Palmer <[email-masked]>
Date: Mon, 12 Dec 2011 16:37:52 -0800

Also, FWIW, from the EFF SSL Observatory:

mysql> select distinct `Subject Public Key Info:Public Key Algorithm`
from valid_certs;
+----------------------------------------------+
| Subject Public Key Info:Public Key Algorithm |
+----------------------------------------------+
|  rsaEncryption                               |
|  dsaEncryption                               |
+----------------------------------------------+
2 rows in set (4.09 sec)

mysql> select count(*) from valid_certs where `Subject Public Key
Info:Public Key Algorithm` like '%dsa%';
+----------+
| count(*) |
+----------+
|       25 |
+----------+
1 row in set (3.26 sec)

---

From: Chris Palmer <[email-masked]>
Date: Mon, 12 Dec 2011 16:55:30 -0800

Of these, the handful that I spot-checked are all either down,
expired, or have been replaced with certificates for RSA keys.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Dec 2011 08:11:39 +0200

True. I don't expect DSA to ever become viable enough to worry about.  I think if you ran the same select for ECDSA, you would come up with zero, but there is some expectation of that changing in the long run. 

By now all the major browsers except Opera support ECDSA, so we might be seeing some of those when websites feel it's safe to abandon the IE6-on-Windows-XP and old Macs.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Dec 2011 07:56:29 -0500

DSA is unlikely to be widespread enough to cause problems.

But I cannot be confident that the same problem is not going to appear with
ECC parameters. (sorry for the double negative).

I don't like a solution for pinning that depends on the CA delivering the
'right' sort of cert. I would prefer to add in a second hash over the
parameter values or specify them explicitly in the pin or to have the hash
be over what the values would be if completely specified in the Key Info.

On Tue, Dec 13, 2011 at 1:11 AM, Yoav Nir <[email-masked]> wrote:

> True. I don't expect DSA to ever become viable enough to worry about.  I
> think if you ran the same select for ECDSA, you would come up with zero,
> but there is some expectation of that changing in the long run.
>
> By now all the major browsers except Opera support ECDSA, so we might be
> seeing some of those when websites feel it's safe to abandon the
> IE6-on-Windows-XP and old Macs.
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

-- 
Website: http://hallambaker.com/

---

From: Adam Langley <[email-masked]>
Date: Tue, 13 Dec 2011 10:20:23 -0500

> be over what the values would be if completely specified in the Key Info.

In the case of ECDSA, it'll be very rare for the parameters to be
omitted since they can be compactly represented by a named curve. In
fact, I've not seen code in SSL libraries that'll go hunting for EC
parameters in a CA key - I strongly suspect that support for this is
minimal at best.

Therefore I'm happy to simply exclude the possibility in the spec and
save the complexity.

Cheers

AGL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Dec 2011 08:22:18 -0500

Actually, the inheritance mechanism should probably be prohibited
altogether.

As things stand it allows a CA to poison a cert issued by another CA!

Let us imagine CA X issues a cert for Alice, the chain is X -> XI -> A. Now
imagine that CA Y issues a cross cert for XI, we now have a chain Y-> XI ->
A

The parameters for the key now depend on the path! Yuk!

I don't know if there is a practical attack possible , this just occurred
to me. But even if there is no attack there is potential for error.

[The sort of attack I am thinking of is a kleptography like attack when
country A sells sabotaged crypto equipment to country B. Country B may
verify that only certs issued through the sub CA XI they control are used
but this gives a way to defeat that control.]