On 04/04/2014 06:14 PM, Chris Palmer wrote: > On Sat, Feb 22, 2014 at 10:49 AM, Daniel Kahn Gillmor > <[email protected]> wrote: > >> 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. > > I think I agree.
can this be stated explicitly in the draft then? I think this guidance
would be useful for the inevitable corner cases.
>> 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.
>
> No, I'd like to say that sha256(foo.getSPKI()) == sha3(foo.getSPKI())
> == sha4(foo.getSPKI()), and for UAs to treat them as identical.
i'm afraid i'm not sure what you're using == to mean here, or "UAs to
treat them as identical".
Given a key that produces three different digests, if the digests are
not broken, then sure a match on any one is as good as a match on any other.
But if implementations of this spec are expected to survive an algorithm
agility shift (even if we want it to be all-sha256 for now) then we need
to specify what happens when some of the known digests match and others
don't.
consider a world where we've made sha3 available in this spec, and
someone figures out a preimage attack against sha-256.
now, that attacker can create a match on the sha256 pin but can't create
a match on the sha3 pin.
if we treat the sha256 pin as identical to the sha3 pin, that we've just
reduced the strength of the pin to the weakest algorithm. or am i
misunderstanding what you mean by "identical"?
>> Why would you want to pin different keys with different
>> hash algorithms?
>
> People are weird. :) But yeah, I am kind of hoping that SHA-256
> remains the only hash algorithm for HPKP for as long as that is safe,
> and that it is safe for a long time.
i also hope for this scenario, and am fine with sha256 as the only
algorithm for this spec. But that's no reason to avoid specifying what
to do in the case where multiple digests are present, though.
>> 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.
>
> Does treating H(foo) for all specified H mitigate or exacerbate your concern?
sorry, i'm unclear what you mean here too. how exactly do you want to
treat H(foo)?
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
