On Sat 2014-02-22 13:49:10 -0500, Daniel Kahn Gillmor wrote: > 0) if a site operator decides to use more than one hash algorithms in > the future, do we require that they issue the same set of pins under > each algorithm? So if i'm pinning keys X and Y and Z, and i'm using > both pin-sha2-256 and pin-sha3-256, must i issue 6 pins? I think it's > reasonable to say yes here, even if we don't have any other digests > defined yet. Why would you want to pin different keys with different > hash algorithms? > > 1) If a UA knows about two hashing algorithms, then the language in 2.6 > is potentially problematic for visiting a site that provides pins using > both hashing algorithms. In particular, checking the set intersection > of all pins suggests that an attacker need only defeat the weakest hash. > I suggest that when multiple hash algorithms are known to the UA, and > it has pins for a given site under more than one hash algorithm, then it > must look for the set intersection *per hash algorithm used by the site* > and only proceed if all hash algorithms show a set intersection. > > This should raise the attacker's bar to the strongest of the set of > hashes used, rather than the weakest.
I haven't heard any followup on these questions about how we envision
hash agility to work in practice, and they don't seem to be addressed in
-11.
To address (0), i recommend adding the following text after the third
paragraph of section 2.4:
When more than one cryptographic hash algorithm is offered for
pinning, the same set of keys MUST be pinned with each algorithm.
For example, if three keys are pinned with two different
cryptographic hash algorithms, the header will contain six pins.
To address (1), i recommend changing section 2.6 from:
The UA will then check that the set of these SPKI Fingerprints
intersects the set of SPKI Fingerprints in that Pinned Host's Pinning
Metadata. If there is set intersection, the UA continues with the
connection as normal.
to:
For each cryptographic hash algorithm offered by the server and
supported by the UA, the UA will check that the set of SPKI
Fingerprints over that algorithm intersects the set of SPKI
Fingerprints over that algorithm in that Pinned Host's Pinning
Metadata. If there is set intersection for all hash algorithms, the
UA continues with the connection as normal.
This raises one more question, which is: what should a UA do if it sees
pins only of algorithms it doesn't recognize. In some imaginable future
SHA256 is broken and deprecated, and servers only offer pins with some
future hash algorithm. Code written today might still be running in
that future, and we need to be clear what it should do if pins are
present, but none of them are any supported algorithm.
I think section 2.5 implies that in that case (these algorithms are
considered an "unrecognized header directive"), the UA MUST NOT note the
host as a pinned host, which i think is the right thing.
I don't know if this needs extra clarification, but if it does, we might
change:
For forward compatibility, the UA MUST ignore any unrecognized
Public-Key-Pins header directives, while still processing those
directives it does recognize.
to:
For forward compatibility, the UA MUST ignore any unrecognized
Public-Key-Pins header directives (including any pins made over
unknown or unsupported hash algorithms), while still processing
those directives it does recognize.
Regards,
--dkg
pgpNcXZ1uJvYs.pgp
Description: PGP signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
