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/>.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
