On Tue, Apr 8, 2014 at 9:35 PM, 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. Well, it's hard to draft text that reads well. There are a lot of hypotheticals: * A new version of this spec has been published that specifies BetterHash. * Separately, SHA256 becomes deemed unsafe. * Some site operators would rather be un-pinned than to pin with a hash function that is vulnerable to a preimage attack of complexity (pretend with me) 2**80. * Some UA that is fancy enough to support HPKP, but not fancy enough to also support BetterHash, exists in the wild for long enough that site operators actually face that weird choice. Honestly, I'd rather deal with this question in the future version of the spec that actually specifies the use of a second hash function. I am not real excited :) to specify how the UA should behave if a situation arises that the spec currently doesn't even allow for. >>> 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"? No, that is what I mean. It is true that there will be a window of vulnerability — we can't just say, "Starting next Tuesday, you're not pinned unless you're using SHA-3." There has to be a period of deprecation before we get rid of a thing completely. Hopefully, when somebody publishes a research paper showing an improved attack on SHA-256 — say, preimage at a cost of 2**128 (yikes!) — we should immediately begin the deprecation process in anticipation of the attack improving to 2**80 soon. Conscientious site operators will observe the new spec, and update their headers, and will be ready for the time a year later when we say "...UAs MUST NOT honor SHA-256...". Honestly, that is good enough for me. Of all the problems with web PKI, the hypothetical future weakness of SHA-256 in a feature that already greatly reduces the potential for mis-issuance just doesn't rate. We're talking about, after years of unprecedentedly awesome research by brilliant cryptanalysts, an attacker who can (a) get a mis-issued certificate; (b) can do the 2**80 work to get their cert to match the good pin; and (c) even after all that can only attack (d) sites using that key that didn't start pinning with SHA-3 yet. I owe you a beer (or your flavorite beverage) anyway, and if that ever happens, I'll get you a second one. :) _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
