Subject: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

From: Chris Palmer <[email-masked]>
Date: Tue, 16 Oct 2012 11:49:02 -0700

Hi all,

This is just a quick interim version to respond to Tom Ritter's bugs
that he filed in the issue tracker. We still have some issues to
resolve around pin activation (à la TACK), max-age, and whether and
how to perform pin validation when X.509 chains chain up to private
trust anchors.

http://trac.tools.ietf.org/wg/websec/trac/ticket/52
http://trac.tools.ietf.org/wg/websec/trac/ticket/53

Any other issues anyone wants to raise? Thanks.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Oct 16, 2012 at 11:35 AM
Subject: New Version Notification for draft-ietf-websec-key-pinning-03.txt
To: [email-masked]
Cc: [email-masked]

A new version of I-D, draft-ietf-websec-key-pinning-03.txt
has been successfully submitted by Chris Palmer and posted to the
IETF repository.

Filename:        draft-ietf-websec-key-pinning
Revision:        03
Title:           Public Key Pinning Extension for HTTP
Creation date:   2012-10-16
WG ID:           websec
Number of pages: 17
URL:
http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-03.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning
Htmlized:        http://tools.ietf.org/html/draft-ietf-websec-key-pinning-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-03

Abstract:
   This memo describes an extension to the HTTP protocol allowing web
   host operators to instruct user agents (UAs) to remember ("pin") the
   hosts' cryptographic identities for a given period of time.  During
   that time, UAs will require that the host present a certificate chain
   including at least one Subject Public Key Info structure whose
   fingerprint matches one or more of the pinned fingerprints for that
   host.  By effectively reducing the scope of authorities who can
   authenticate the domain during the lifetime of the pin, pinning may
   reduce the incidence of man-in-the-middle attacks due to compromised
   Certification Authorities and other authentication errors and
   attacks.

The IETF Secretariat

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Oct 2012 22:16:38 +0200

Hi Chris.

Good to see this. Do you intend to publish another revision by the draft submission cutoff date next Monday?

Or would you like us to discuss these issues to resolve at the meeting in Atlanta?

Thanks

Yoav

On Oct 16, 2012, at 8:49 PM, Chris Palmer wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
> IƧ��[�(^rC�{S�֥I�.�+r�^��

---

From: Tom Ritter <[email-masked]>
Date: Wed, 17 Oct 2012 10:23:24 -0400

Some musings after reading again:

Section 2.3 "Noting Pins":

I wonder if it is worth moving "The UAs MUST ignore Public-Key-Pins
response header fields received on HTTP (non-HTTPS) connections."
outside the criteria to be unambiguous that a client should not
"discard any previously set Pinning Metadata" if it receives the
header over HTTP.  Or if it's reasonable enough to assume no one would
get confused.

Similarly, I wonder if there was some situation that could result in
an attacker-induced 'errored' TLS connection that still sent the
header, resulting in the data being discarded...

Section 2.4: "Validating Pinned Connections":

   For the purposes of Pin Validation, the UA MUST ignore
   certificates who SPKI cannot be taken in isolation and superfluous
   certificates in the chain that do not form part of the validating
   chain.

I know I just modified this, but the second phrase just hit me.
Because path construction is non-standard, could a client wind up in a
situation where the site pinned to CA_Alice, with the intended path
CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was
trusted, the ultimate validating chain was simply CA_Bob ->
Intermediate -> Leaf?  I'm not sure what the right way to counteract
that would be...

2.5: "Pin Validity Times"

I find the "current + current - initial" / "(b) the amount of time the
pin has been noted" item confusing, and am not sure what it means from
reading only the draft.  If I'm not the only one, it might be worth
clarifying.

2.6.  "Interactions With Preloaded Pin Lists"

If closing private browsing mode or clearing saved data also clears
preloaded pins (and I think it should), this would cause a revert to
the preloaded pins, which may break sites.  A workaround may be to
disable a preloaded pin if a new pin is seen, and keep that disabled
even after the saved data wipe/private browsing mode close.  To
prevent using this as a backdoor into tracking, the preloaded pins
should be sanity checked for "Is this organization likely to abuse the
feature."

Again, excited about this - thanks for the work.

-tom

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 17 Oct 2012 09:36:43 -0700

>  Intermediate -> Leaf?  I'm not sure what the right way to counteract

Yes. This is one of the troubling areas of the current draft, and that has
been particularly challenging when implementing within Chromium.

It's not clear whether your case was demonstrative of the
inter-organizational cross-signing relationships (a new CA getting
cross-certified by an existing, established CA) or whether it was an
intra-organizational relationship, such as a SHA-1 root cross-signing the
SHA-2 root, until such a time as the SHA-2 root is included in the trust
stores.

In the case of inter-organizational, where CA_Alice and CA_Bob are two
distinct entities, it's generally seen as unlikely that the "site" would
pin to CA_Alice, since their business relationship is almost certainly
with CA_Bob (by virtue of CA_Bob having certified Intermediate). So if the
site were to pin to CA_Bob, their issue would be mitigated.

However, for the intra-organizational scenario, where intermediates and
roots are changed or re-issued more commonly than site operators may
realized or be re-configuring, I agree that this is a very real problem.

The mitigation for this has been to make the pins an appropriate
cross-section of both root and intermediates - intermediates in the event
of new roots being issued, and roots in the event of the CA issuing new
intermediates (and serving them up via AIA, as the common case is)

This leaves the broader question of "How does the site operator know about
CA_Alice and CA_Bob to begin with". One possible solution for this is a
report-but-unenforced mode, where user agents could describe their
observed chains to the site. As unseemly as this is, it's very likely that
many site operators - even Very Large, High Value sites - may not have a
full understanding of the PKI that they're a participant in.

Another solution is to rely on policy changes in root stores, such as
Mozilla's recent proposed CA Certificate Store requirements change, which
would encourage (by requiring, with only one acceptable alternative) the
public disclosure of such CA hierarchies. As a result of such changes,
there would be knowledge of the relationship between CA_Alice and CA_Bob,
which under today's model, is actually quite hard for site operators to
discover.

Because pinning permits multiple entries, and is considered satisfied so
long as at least one SPKI appears in the client validated chain, the issue
here is largely not a technical challenge, but an operational one, and
that's why this issue is not critical, but remains very important.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 17 Oct 2012 13:04:06 -0400

On 10/17/12 12:36 PM, "Ryan Sleevi" <[email-masked]> wrote:

><large snip>

A tool that builds all possible paths that the site operator can run
without involving any users would be good too.  The site operator mainly
needs to know where its certificate chains against public stuff and could
check that independently.  This should come close to relegating the user
report tool to oddball instances.

>which under today's model, is actually quite hard for site operators to

Even with disclosure a builder tool that illustrates possible chains would
be useful.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 17 Oct 2012 10:52:52 -0700

>  report tool to oddball instances.

The problem in general with such tools (and I'm sure this will be a
talking point during the WPKOPS and CERTTRANS BOFs) is that it's actually
a rather hard problem to know exactly what certificates exist.

Beyond the issues such as "What user agents have what behaviour" and "what
intermediates are baked into what platforms," one of the more problematic
areas is related to the AIA chasing that is functionally and fundamentally
necessary to maintain parity and access to a depressingly vast majority of
sites.

When the site operator installs their cert, they may only install on their
HTTPS server (Site_Cert, Intermediate). This is because CA_Bob and the
site operator are assuming that CA_Bob can be omitted, since it's the root
of trust.

For clients that don't trust CA_Bob, Intermediate has an AIA to a URL that
contains CA_Bob, which is cross-certified by CA_Alice.

So the possible chains are:
Site_Cert (via TLS) -> Intermediate (via TLS) -> CA_Bob (obtained
out-of-band)
Site_Cert (via TLS) -> Intermediate (via TLS) -> CA_Bob (obtained via AIA)
-> CA_Alice (obtained out of band)

Now what if CA_Bob goes out of business/is acquired? Well, one common
trick is to update the URL of Intermediate to point to a new version,
signed by CA_Charles. When the path building for Intermediate (via TLS)
fails, user agents may "unwind" their depth search, and attempt the AIA
fetch from Site_Cert, leading to a new chain.

Site_Cert (via TLS) -> Intermediate (via AIA) -> CA_Charles (obtained
out-of-band)

Or CA_Bob may decide they want to sever ties with CA_Alice, and go with
CA_Charlene. They simply replace the AIA URL used to serve up the
cross-certified CA_Bob.

This is all well and good for "point in time" evaluation - but the added
crux on this is that the site operator may be noticing all these
shenanigans, and now explicitly configure their server to send a
particular chain they believe is accurate/optimal. Also, clients may be
caching intermediates as well.

So it's "Very Hard" to actually know what *all* possible paths are,
because the possible paths change over time, and some paths may no longer
be knowable by such a tool when the certificate is being evaluated,
because the old certificates served at URL X are now replaced with newer
ones.

You may think I'm just grasping at edge cases, but unfortunately every
situation I just described above has been done by major CAs, including
some that might be considered of the "Too big too fail" variety. So it's
definitely an issue, and that's some from of client reporting seems
necessary (with transparency + disclosure to make it easier to write such
tools in the future)

---

From: Carl Wallace <[email-masked]>
Date: Wed, 17 Oct 2012 14:07:48 -0400

>a rather hard problem to know exactly what certificates exist.

Why do you care what certificates exist vs. what certificates are
generally available (via AIAs and such)?  The certificates available from
most AIAs are constant for most people.  I'm not suggesting that a tool
would be a 100% solution, but it'd be a good first shot vs. collecting
data from some (manually run?) user tool after a problem is observed.

>necessary to maintain parity and access to a depressingly vast majority of

There would be some homework to collect the full set of trust anchors that
may be encountered.  This shouldn't be that hard to maintain if a
collective effort focused on it.  It'd make no difference if the set used
to harvest public keys was too large.

>caching intermediates as well.

What is a user report but a "point in time" evaluation?

>because the old certificates served at URL X are now replaced with newer

Monitoring is necessary to keep track of changes.  It sucks, but it's the
way it is.  

>necessary (with transparency + disclosure to make it easier to write such

I don't doubt any of this, but still think a crawler tool would be
sufficient in many (if not most) cases.  It'd probably be instructive to
run for the site operators in the worst case.  Note, I did not suggest
that a user report feature was not a good or necessary thing, only that a
builder tool for the site operator to run without bothering any users
would be nice to have in the toolbox too.  Thinking about it, they may
well be the same tool if the user reporting tool is aggressive enough.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 17 Oct 2012 11:33:34 -0700

On Wed, October 17, 2012 11:07 am, Carl Wallace wrote:
<snip>
>  well be the same tool if the user reporting tool is aggressive enough.

Ah, I misunderstood your point to be suggesting that a crawler would be
sufficient, and reporting would be unnecessary.

I'm a big fan of the crawler - both for purposes of pinning and for
purposes of generally understanding the nature of the web PKI. Public
datasets such as the EFF SSL Observatory data [1], along with private
datasets such as those that inform tools such as Qualys' SSL Labs [2] or
the Google's Certificate Catalog [3], would go a good deal to establish
what the known-possible certificate hierarchies are. I just thing there
will be a tail of oddities and legacy that are only picked up by
reporting.

[1] https://www.eff.org/observatory
[2] https://www.ssllabs.com/
[3]
http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html

---

From: Chris Palmer <[email-masked]>
Date: Thu, 18 Oct 2012 17:27:27 -0700

> Good to see this. Do you intend to publish another revision by the draft submission cutoff date next Monday?

It's quite possible, but I can't guarantee it right now.

> Or would you like us to discuss these issues to resolve at the meeting in Atlanta?

Ryan will be at Atlanta, and I won't be. I think it's easier for me if
we continue to discuss things here on the mailing list.

---

From: Chris Palmer <[email-masked]>
Date: Thu, 18 Oct 2012 18:15:34 -0700

> header over HTTP.  Or if it's reasonable enough to assume no one would

I think it's reasonable enough. However I did add this:

"""The UA MUST note the pins if and only if it received the
Public-Key-Pins response header field over an error-free TLS
connection. The UAs MUST ignore Public-Key-Pins response header fields
received on HTTP (non-HTTPS) connections and on HTTPS connections that
are not error-free."""

> header, resulting in the data being discarded...

Thoughts?

> Intermediate -> Leaf?  I'm not sure what the right way to counteract

Yes, Ryan raised this hilarious point to me a while back, and now I
see he has responded to your question here on the list.

So, it's a strong motivating factor for a report-only mode. I've
created an issue tracker entry and a discussion thread for that.

> reading only the draft.  If I'm not the only one, it might be worth

Yes, even after a lot of thought I am still undecided about this. I
see several possible approaches:

(a) simply have the validity time be the same as for HSTS;
(b) the same as HSTS but with a 30-day maximum;
(c) the current attempt to mirror TACK, except clarified and with examples; or
(d) something else.

Of these, I think I currently like (b) best. Thoughts?

> preloaded pins (and I think it should),

I think you mean "clears dynamic pins"? In Chromium's Incognito, any
accrued dynamic pins will be lost when you close your last Incognito
window. (If not, that is a bug and you can assign it to
[email-masked].) Also, in Chromium, when you clear browsing
history, chrome://chrome/settings/clearBrowserData, *and you select
"from the beginning of time"* (or presumably any time that predates
when your HSTS data is from), your HSTS metadata (e.g.
~/.config/chromium/Default/TransportSecurity) is indeed wiped clean.
That was true last time I checked, on 7 May 2012. Again, if you find
otherwise, assign me a bug.

> this would cause a revert to
> even after the saved data wipe/private browsing mode close.

Good point. I'll add a note to that effect and ship it in the next draft.

> To prevent using this as a backdoor into tracking,

I don't consider the implicit tracking cookie problem to be solvable.
I think EFF's Panopticlick conclusively shows that it cannot be
solved. Tracking with HSTS and HPKP metadata would be a notably noisy
and inefficient way to implicitly track people; much "better" methods
exist now and always will. See http://www.w3.org/TR/hr-time/ just as a
random example...

> the preloaded pins

I suppose we could press the Safe Browsing list into service for this
(and data and API for that are open), but it's a stretch. SB is about
malware and phishing, which is a different thing than implicit
tracking.

It could at best be a "UAs MAY choose to ignore HSTS and pinning
metadata for certain sites... a mechanism to do so is beyond the scope
of this I-D..." thing.

> Again, excited about this - thanks for the work.

Thank you for all your help!

---

From: Tobias Gondrom <[email-masked]>
Date: Fri, 19 Oct 2012 08:52:05 +0100

> we continue to discuss things here on the mailing list.

<hat="WG chair">
Hi Chris,
yes, please. Discussion on the mailing-list is the right place.
In addition, we will be looking forward to a presentation and discussion 
on the open issues from Ryan on your behalf during our websec meeting in 
Atlanta.
Best regards, Tobias

---

From: Tom Ritter <[email-masked]>
Date: Fri, 19 Oct 2012 10:29:31 -0400

>> header, resulting in the data being discarded...

Sorry, but I think that introduces more confusion.  Point 1 includes a
criteria and a "Do Something if not Criteria" but the following
paragraph after the Criteria also includes a "Do Something if not
Criteria".  I would suggest moving the "do something" out of the first
criteria.

I would suggest the following, which moves the 'do something' out of
criteria 1, clarifies that the discarding action only applies to
currently Pinned Hosts, and states explictly that when we say
"error-free TLS" this includes the validation in Section 2.4 if
applicable.

The UA MUST observe these conditions when noting a host:

   o  The UA MUST note the pins if and only if it received the
      Public-Key-Pins response header field over an error-free TLS
      connection. If the host is a Pinned Host, this includes the
      validation added in Section 2.4

   o  The UA MUST note the pins if and only if the TLS connection was
      authenticated with a certificate chain containing at least one of
      the SPKI structures indicated by at least one of the given
      fingerprints.  (See Section 2.4.)

   o  The UA MUST note the pins if and only if the given set of pins
      contains at least one pin that does NOT refer to an SPKI in the
      certificate chain.  (That is, the host must set a Backup Pin; see
      Section 3.1.)

   If the Public-Key-Pins response header field does not meet all three
   of these criteria, the UA MUST NOT note the host as a Pinned Host.
   A Public-Key-Pins response header field that meets all these critera is
   known as a Valid Pinning Header.

   The UAs MUST ignore Public-Key-Pins response header fields received on
   connections that do not meet the first criteria. If the UA recives
   a Public-Key-Pins header from a Pinned Host that meets the first
   criteria, but not the following two, the UA MUST discard any previously
   set Pinning Metadata for that host in its non-volatile store.
<<<<

> Of these, I think I currently like (b) best. Thoughts?

I think A.  I believe (without evidence) there are institutions that
would eventually like to use this that have customers that work with
them on a quarterly or annual basis.  Likewise, I believe (without
evidence) that a institution who was risk adverse would mitigate that
risk by pinning to several large CA roots, not by saying "Oh well our
customers can't access us for the next 30 days, but it's only 30 days
who cares - but 60, that would be unacceptable!"

I do like TACK's notion of 'growing' out pins but only in a "That
sounds like a feature we're anticipating people wanting" way.  If
people actually hold off on deploying this because of that and that
alone, it SHOULD be possible to add a new directive, ignored by older
browsers who don't implement it.

Public-Key-Pins: max-age=600; grow-to=86400;
pin-sha1="4n972HfV354KP560yw4uqe/baXc=";

The spec should probably note that directives not understood should be
ignored, and not invalidate the header, to allow for future expansion.
 Right?

> I think you mean "clears dynamic pins"?

Yes, dynamic pins.

> solved.
> ...

I was actually saying "Chrome shouldn't ship preloaded pins for
Marketing Firms, because if a MF sends Pins to a user in Incognito
Mode, then the user closes Incognito Mode - MF can learn that a user
is a repeat visitor even though they visited in Incognito Mode."  But
AFAICT that would be all the information a Marketing Firm would be
able to learn - binary visited or not.

BUT: Even if UAs did not ship pins for Marketing Firms, it wouldn't
matter because an attacker could use Cross Origin Img Loads with a
stolen certificate to learn the same amount of information (whether a
user visited in Incognito mode) about a valid, non-marketing site
(e.g. Abuse Counseling site).

> metadata for certain sites... a mechanism to do so is beyond the scope

I recant, I don't think this is necessary, because the above is not
solvable in the technical constraints and Incognito Mode clears pins.

-tom

---

From: Chris Palmer <[email-masked]>
Date: Fri, 19 Oct 2012 13:38:34 -0700

>    set Pinning Metadata for that host in its non-volatile store.

Thanks again, Tom. I've adopted this in my copy.

By the way, people can follow my copy here:
https://code.google.com/p/key-pinning-draft

> who cares - but 60, that would be unacceptable!"

Makes sense. Any other votes?

> browsers who don't implement it.

Makes sense.

> ignored, and not invalidate the header, to allow for future expansion.

Yes. In fact Chrome's implementation does do that. I thought I had
specified it in this I-D, but apparently not. I propose this
parapgrah:

<t>For forward compatibility, the UA MUST ignore any unrecognized
Public-Key-Pins header directives, while still processing those
directives
it does recognize. <target xref="header-syntax" /> specifies the two
directives max-age and pins, but future specifications and
implementations
might use additional directives.</t>

at the end of the Noting Pins section.