Re: [ietf-privacy] [websec] HPKP and privacy

Chris Palmer <palmer@google.com> Wed, 10 July 2013 20:36 UTC

MIME-Version: 1.0
In-Reply-To: <CAOe4Ui=j+SEF_JVtFLc63CJr5YaLep_K4M3BqqOiLY+2SPJE3A@mail.gmail.com>
References: <CAOe4UimnDeEU3BHwy5KrCOi=4KxLPRuuKZRHQv49s1_BNg44Ww@mail.gmail.com> <51C7F08F.2090205@gondrom.org> <CAOe4Ui=Teo77EG3r+gsfeAVsHoykOsG=2cV8xVkiw+3SNoUvrg@mail.gmail.com> <CA+cU71nEPm95MLPAcgDjFdzuR5eLT98+-WEsxpfSbH+dHq81UA@mail.gmail.com> <CAOuvq20A+KZv+O=Hp2jqZw8-j0oKzVVTJR=d7H=tkA9rADJzUg@mail.gmail.com> <CAOe4Ui=j+SEF_JVtFLc63CJr5YaLep_K4M3BqqOiLY+2SPJE3A@mail.gmail.com>
Date: Wed, 10 Jul 2013 13:36:14 -0700
Message-ID: <CAOuvq23Q6BGRKwq2z3r9Pr7PZRKs9OGnC7xRhUU_fcczSNx34g@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Joseph Bonneau <jbonneau@gmail.com>, ietf-privacy@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: IETF WebSec WG <websec@ietf.org>, Tom Ritter <tom@ritter.vg>
Subject: Re: [ietf-privacy] [websec] HPKP and privacy
Precedence: list

On Tue, Jul 9, 2013 at 3:54 PM, Joseph Bonneau <jbonneau@gmail.com> wrote:

>> Yes. Unfortunately, I don't see a way to have both HPKP and automatic
>> defense against this kind of super-cookie. The problem exists for
>> HSTS, too.
>
> I agree, but there are two things user agents SHOULD do at a minimum: (a)
> clear pins for domains whenever other domain-specific information is cleared
> for privacy reasons (delete history since time N, or private browsing mode)

We currently have decided NOT to do this for HSTS. You can see the
somewhat tortured history of the behavior in Chrome here:

https://code.google.com/p/chromium/issues/detail?id=104935

Chrome's Incognito mode is an easy way to get Chrome to not
persistently store any local state (thus defeating a wide range of
super-cookie techniques, including but not limited to ETag, HSTS,
HPKP, cache hit/miss timing). If you are concerned about privacy
side-effects from local state, use Incognito.

(Also, it behooves me to refer to the official Incognito
documentation: https://support.google.com/chrome/answer/95464?hl=en)

> (b) not store pins in cases where cookies will not be rejected for privacy
> reasons (such as third-party cookie blocking policies). I don't think these
> are obvious to implementers so I would like to seem them in the spec.

I'm not sure what you mean here. Did you mean to write, "not store
pins in cases where cookies WILL be rejected for privacy reasons"?

Note that the HSTS and HPKP super-cookie is primarily useful for
*recovering* a previously-set but then deleted cookie — it does not by
itself allow the server to *easily* correlate requests, only to
laboriously recover a thing (like a cookie) that does. So if the UA is
blocking (say) third-party cookies anyway, the HSTS/HPKP super-cookie
technique might not work too well for the third-party adversary. Or at
least not as well as other techniques that are already available.

I believe we are in the privacy margins here. Incognito mitigates the
concern; blocking third-party cookies somewhat mitigates the concern;
N-host HSTS/HPKP super-cookies are (probably? I think?) not the most
efficient of the many available super-cookie techniques; I assume
everyone likes the report-uri feature and that we don't want to get
rid of it; et c. As far as I know, the ETag/Last-Modified super-cookie
technique is unsolved
(http://www.nikcub.com/posts/persistant-and-unblockable-cookies-using-http-headers),
and much more straightforward for implicit-tracking adversaries to
use.

Re: [ietf-privacy] [websec] HPKP and privacy SM
Re: [ietf-privacy] [websec] HPKP and privacy Chris Palmer