Re: [websec] draft-ietf-websec-key-pinning

[Ryan Sleevi <[e-mail]>]

Right, so, I do agree with Joe that I do think we've reached conclusions on
the suitability for security and the suitability for testing, and I do want
to see what can be done to editorially resolve this.

Without having fully drafted the text, it seems like one possible solution
is to describe HOW a site operator might use this to test deployment of
pins, knowing that it may not be a perfect solution for all use cases, it
would at least help to clarify both the strengths and limitations.

The example I'm thinking of is as follows:

-- Begin
Site operator deploys PKP-RO on their domain
- In order for this to be useful, the assumption here (and which I think
had always been implicit, but it may help to call this out, in several
places if necessary) is that PKP-RO does not require that the current
connection MATCH the pins in order to send a report (otherwise, you'd never
get a negative report, because you'd never evaluate PKP-RO in the negative
case)
- They gather data from their users, which may include information about
possible certificate chain paths that they were not aware of (assuming a
publicly trusted CA with UAs with different trust stores, etc)

After gathering data, they deploy PKP, which makes the RO now a hard fail.
They may still use report-uri with their PKP header, along with shorter
timeframes, to ensure no critical errors were missed

Now it comes time to gather in the sub-domains, the site operator works
through their (known) subdomains with PKP-RO, doing the same steps as they
did for the parent domain, setting PKP on these subdomains.

Believing they have gathered all their subdomains into a unified policy,
they then work to set PKP on the 'main' domain with includeSubDomains +
reportURI set.
They likely do this in small bursts, temporarily decreasing the max-age of
the 'main' domain when setting the includeSubDomains (e.g. perhaps 1 day or
even 4-12h), examining reportURI for failures, and then turning on their
sans-includeSubDomains policy with the longer max-age

Finally, believing to have gathered sufficient data, they turn on
includeSubDomains (with report-URI), and have the whole system protected

-- Fin

As Eric noted in HSTS, this may include having the subdomains either set
their own policies (for redundancy/safety, but at the tradeoff of
potentially conflicting pin policies, as already noted), or having the
subdomains source a resource from the parent domain (which causes them to
fetch/detect the includeSubDomains from the parent domain)


The assumption here, and I realize is perhaps unfair for some use cases, is
that you know the sub-domains you wish to protect. Hopefully a competant
domain administrator was responsible and this information can be
discovered. The short-lived PKP+includeSubDomains+reportUri provides an
added means of testing, but is admittedly 'more' heavy-handed than simply
PKP-RO with persistence.

PKP-RO with persistence is, I think, dangerous. In the naieve form, it
allows a MITM to setup a DOS bomb against a legitimate server, by setting a
PKP-RO to report errors. Unlike a PKP policy (which is detectable by the
user, by virtue of fail-closed), whose fail-closed nature may indicate to
the user that somebody set them up a bomb, a PKP-RO is conceptually and
practically silent to the user, which may cause the user to flood the
legitimate server with reports once they're away from the MITM. Now, we
could tweak how persistence works for that case, but I think as we do, we
get further and further into a complexity that may require significant
edits/reviews. We can do that, but I gather the spirit, both of the editors
and, from the responses, those involved in this discussion, that it's not
necessarily something felt too strongly about.

The question is, does the above scenario sound reasonable enough to
include, perhaps in an "operational advice" or some form of appendix, that
provides guidance on how the existing primitives can be used, but also
highlights the limitations of the current primitives so as not to cause
confusion?


On Wed, Aug 27, 2014 at 5:26 AM, Tom Ritter <[e-mail]> wrote:

> On 27 August 2014 05:46, Yoav Nir <[e-mail]> wrote:
> > At this stage, we can make editorial changes, but we cannot make
> significant
> > changes on our own. We can withdraw the request to publish, and take it
> back
> > to the working group, but I think that would be inadvisable.
> >
> > I think we should proceed, making only editorial changes, and changes
> > resulting from discussion with IESG members.
>
> If adding a note in 4.2 about includeSubdomains and PKP-RO (for
> testing) counts as editorial, I think that is worthwhile.
> Otherwise/regardless I also don't want to withdraw.
>
> -tom
>