Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10

From: Chris Palmer <[email-masked]>
Date: Fri, 4 Apr 2014 15:14:48 -0700

On Sat, Feb 22, 2014 at 10:49 AM, Daniel Kahn Gillmor
<[email-masked]> 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.

>  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.

Any thoughts on how to write that into the spec?

Or, is treating such pins as identical too crazy?

> 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.

>  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?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Apr 2014 00:35:57 -0400

>> pin) is the right thing to do.

can this be stated explicitly in the draft then?  I think this guidance
would be useful for the inevitable corner cases.

> == 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"?

> 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.

> 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

---

From: Chris Palmer <[email-masked]>
Date: Mon, 28 Apr 2014 16:04:50 -0700

> 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.

> 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. :)