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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 01 May 2014 10:17:21 -0400

On 04/28/2014 07:04 PM, Chris Palmer wrote:
> 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.

By that point, it's too late; there *will* be deployed key-pinning
clients that aren't updated from the initial deployment, if present
experience is any indication; if we don't suggest now what behavior we
expect in this case, then people who upgrade servers will face a range
of implementation choices in the clients that interact with them.

I think the changes to section 2.1 in draft -12 look like they cover
this.  Thanks for making them :)

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

yes, of course.

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

But in the meantime, clients which have already implemented SHA-3 (or
whatever) should be able to be protected against breaks in SHA-256, no?

It takes us a long long while to get around to deprecating things that
we know are broken.  If both peers in a negotiation *can* handle
stronger mechanisms, they shouldn't have to wait for an official
deprecation of the weaker mechanism in order to get the benefit of the
stronger mechanism.

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

No, my point is that if we don't make it clear that *all published
digests supported by the client must match*, then at least (c) isn't
necessary for the attacker.

I think this is not fixed in -12 yet.

I agree that we're talking about pretty intense hypotheticals here, but
i see no reason that we shouldn't specify the right thing in this draft
while we have the chance to provide this guidance.

> I owe you a beer (or your flavorite beverage) anyway, and if that ever
> happens, I'll get you a second one. :)

:)

	--dkg

PS orthographic nitpick: in -12, you've got "interpretting" where i
think you mean "interpreting"

PPS your link to [pin-break-codes] appears to be 404:
              Perrin, T., "Self-Asserted Key Pinning", September 2011,
              <http://trevp.net/SAKP/>.

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 May 2014 13:38:05 -0700

> whatever) should be able to be protected against breaks in SHA-256, no?

2**128 is so expensive, and would be such an incredible improvement
over the current cost of second-preimage attack (2**256) that frankly
I'm willing to take the risk to keep the I-D from getting any more
complicated. Second-preimage attack against SHA-256 is so much not our
biggest problem right now — many other things are much more likely to
go wrong.

> deprecation of the weaker mechanism in order to get the benefit of the

First, we have to get any peers at all using HPKP. And we've been
sluggish long enough (blame me first and foremost, of course).

> while we have the chance to provide this guidance.

I'm a Worse Is Better believer, rather than a Right Thingist;
especially when as far as anyone publicly knows, SHA-256 is very
strong against second-preimage. We already moved to get rid of SHA-1
as a concession to the Right Thing (and, code simplification).

> think you mean "interpreting"

Fixed, thanks.

>               <http://trevp.net/SAKP/>.

Oh yes, I believe Trevor mentioned this too. Got rid of it.

https://code.google.com/p/key-pinning-draft/source/detail?r=9c118381b2b6e49384f2ea22e13247ea1c992fb9