Re: [websec] #56: Specify includeSubdomains directive for HPKP

["Ryan Sleevi" <[e-mail]>]

On Fri, December 7, 2012 2:17 pm, Yoav Nir wrote:
>
>  On Dec 7, 2012, at 11:31 PM, Chris Palmer <[e-mail]> wrote:
>
> > On Thu, Nov 8, 2012 at 2:01 PM, websec issue tracker
> > <[e-mail]> wrote:
> >
> >> #56: Specify includeSubdomains directive for HPKP
> >>
> >> Ticket URL: <http://tools.ietf.org/wg/websec/trac/ticket/56#comment:1>
> >
> > Do people agree that draft -04 resolves this issue?
>
>  Sort of. I see that includeSubdomains is included, but I couldn't find the
>  discussion about resolving conflicts between a superdomain (such as
>  google.com) that has the includeSubdomain directive, and a subdomain (such
>  as www.google.com) that has a different key in its PKP directive. This
>  question is asked in the ticket.
>
>  I'm also not sure how that could ever work.  Suppose I go to google.com,
>  and get the pin with the includeSubdomain directive.
>
>  Next, I go to www.google.com, and the pin doesn't match the TLS handshake.
>  Wouldn't the UA immediately terminate the connection, with no opportunity
>  to ever receive any HTTP header? How will the more specific pin ever get
>  set?
>
>  Yoav

So, let's say the workflow is:
You first visit "google.com" (or, through whatever U-A specific means
exist, you have a pre-loaded pin for "google.com").
It has a PKP directive that asserts Pin(A) and Pin(B), along with
includeSubDomains.
The validated cert chain contains Pin(A), so the PKP is accepted, and
google.com (and all of its subdomains through all levels) are set to
Pin(A) and Pin(B)

You now visit www.google.com

IF www.google.com is not valid for Pin(A), fail the connection. That is
the only acceptable path.

IF www.google.com IS valid for Pin(A), it MAY assert a different pin.
Since, as noted above, it MUST be valid for Pin(A), the only possible
pinning that www.google.com would be to Pin to a more narrow scope of
authority than A.

For example, assume that Pin(A) refers to a root cert/trust anchor.
www.google.com may wish to Pin(C), which is a specific subordinate CA
certificate beneath A - such as an OV CA, rather than a DV CA.

Further, www.google.com may wish to assert includeSubdomains as well, and
all domains beneath www.google.com should pin to Pin(C) instead.

This equally applies to the Enterprise PKI scenario, where you may have a
DNS hierarchy that reflects an organizational layout -
divisiona.mycorp.example and divisionb.mycorp.example. mycorp.example may
chain to the MyCorp trust anchor, but divisiona and divisionb may assert
pins to their respective Division A CA (which is cross-certified by the
MyCorp root) and Division B CA (which is cross-certified by the MyCorp
root). In this case, Division A CA will NOT be able to issue certificates
for any name under divisionb.mycorp.example

This latter case is a bit contrived, I admit - name constraints function
much better for the enterprise PKI case - but hopefully it demonstrates
how you can, at each level, further scope the trust anchors to the minimal
acceptable set.

You may have an example.com PKP that asserts trust for 4 different,
distinct root CAs, but that subdomains individually limit to specific root
CAs (or specific intermediates - such as EV, DV, OV, or however the root
CA is configured)


Finally, it may simply be the case that an entity like "example.com" wants
to assert a single pinning directive for ALL their subdomains - that is,
they do not care about restricting trust as much as simply being able to
have a single unified policy - and includeSubDomains (obtained dynamically
through the header or through a-priori crawling, much like HSTS has been
done) is one way to do that.


However, it sounds like all of this needs more clarification, so if the
description above matches peoples expectations, I'll work to draft text to
concisely explain these rules in the spec.