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

From: Chris Palmer <[email-masked]>
Date: Fri, 7 Dec 2012 13:31:54 -0800

On Thu, Nov 8, 2012 at 2:01 PM, websec issue tracker
<[email-masked]> 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?

---

From: Yoav Nir <[email-masked]>
Date: Fri, 7 Dec 2012 22:17:02 +0000

> 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

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 7 Dec 2012 21:58:06 -0800

On Fri, December 7, 2012 2:17 pm, Yoav Nir wrote:
>  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.

---

From: Chris Palmer <[email-masked]>
Date: Mon, 10 Dec 2012 11:19:04 -0800

> 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, a…

In addition to Ryan's comments, I'll add that I think we should talk
more in the draft about how we follow the hostname matching rules of
HSTS. The only reference to it in our I-D is in section 2.3.2:

"""   Otherwise, if the substring does not congruently match a Known Pinned
   Host's domain name, per the matching procedure specified in Section
   8.2 of [RFC6797], then the UA MUST note this host as a Known Pinned
   Host, caching the Pinned Host's domain name and noting along with it
   the expiry time of this information, as effectively stipulated per..."""

So I think we'll add a discussion of how this affects Pin Validation
(section 2.6) as well.

---

From: Chris Palmer <[email-masked]>
Date: Mon, 10 Dec 2012 11:20:50 -0800

> the only acceptable path.

Quick clarification: Pin(B) would also be acceptable.