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

[Joseph Bonneau <[e-mail]>]

On Tue, Aug 26, 2014 at 6:10 PM, Chris Palmer <[e-mail]> wrote:

> On Tue, Aug 26, 2014 at 2:42 PM, Tom Ritter <[e-mail]> wrote:
> > This is especially true if includeSubdomains is enabled. It'd be
> > common for that directive to apply to hosts that the -RO header would
> > not be included on. In PKP-RO, it would not be applied to them; in PKP
> > it would.
>
> OK, so, what do you want?
>
> Is it even possible for me to write text you would accept?


The answer may be "no" here which would suggest dropping PKP-RO completely
as an alternative way forward. Taking a step back, this thread features two
sides arguing that this feature is (largely) useless for what the other
side wants it for (testing vs. security).

As pointed out, the current version is not nearly sufficient for testing a
site's PKP-readiness due to subdomains and (potentially) load-balancing a
domain onto servers with different keys (some of which may not be in the
pin set and not set PKP-RO and be missed by setting the header on other
servers). Testing with -RO is surely better than no testing at all, but it
seems most domains would need to do more extensive testing manually by
crawling/viewing network traffic/etc. at which point they'd gain the
benefit of -RO testing anyways.

Maybe there is some benefit for quick tests to see what certs UAs are
actually receiving, which it was pointed out Facebook used Flash to achieve
(I know of at least two other academic research efforts that have used the
same approach). But if this is the goal, PKP-RO is pretty limited compared
to adding something to JS or WebCrypto which would just ping back with the
exact cert chain received. This use case seems best addressed elsewhere
rather than bolted onto this spec.

Hence, given the concern that this spec is already bloated, I would
advocate we seriously consider dropping -RO mode completely.