On 02/21/2014 03:58 PM, Tobias Gondrom wrote: >> (a) ignore it, keeping the old pin, or (b) treat this as unpinning?
> in case of an unrecognised pin-shaX, scenario (a) would result in a
> potentially dangerous situation, that can brick the site, i.e. make it
> unavailable.
> If the new pin is ignored, i.e. not noted, that would mean the old pin
> would remain in place for the full period of time, even though maybe the
> new cert will be active soon and the old one no longer available.
> So I am afraid we probably need to entertain (b)?
I also think that (b) (unpinning) is the right answer here, considering
the semantics of the decision.
Consider it this way:
* the site operator gets to decide what pins they issue, and what hash
algorithms to use.
* the site operator presumably has a rough idea of how many of their
clients are using software that might not be able to handle new hash
algorithms
* the site operator also decides what security properties/strength they
require of a given hash algorithm.
If the site operator considers an older hash algorithm to be too weak to
rely on, and a client only knows that hash algorithm, then the site
operator asking that client to unpin (and perhaps acknowledge the lack
of pinning to the user via whatever UI provides information about the
pin) is the right thing to do.
If a site operator considers the older hash algorithm to be weak but
still acceptable as a pin for those that only know that hash algorithm,
then they should include a matching pin with the older hash algorithm as
well as their preferred hash algorithm.
This raises a couple of suggestions for me:
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.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
