Subject: [websec] #60: Well Known URIs vs Response Headers

From: "websec issue tracker" <[email-masked]>
Date: Mon, 29 Jul 2013 20:38:26 -0000

#60: Well Known URIs vs Response Headers

 This is about a suggestion to replace the HPKP header with an RFC 5785
 well-known URI.  This would allow lower bandwidth, as this resource would
 be read at most once per connection, rather than with each request.

 However, the same is true for HSTS, CSP, and any other policy-conveying
 header.

 The consensus in the room was to not change this for HPKP. If all policies
 get moved to w-k URIs, HPKP should move as well, but it should not lead
 the way.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-websec-key-
  [email-masked]    |  [email-masked]
     Type:  enhancement  |     Status:  new
 Priority:  major        |  Milestone:
Component:  key-pinning  |    Version:
 Severity:  In WG Last   |   Keywords:  HPKP RFC5785
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/60>
websec <http://tools.ietf.org/websec/>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 29 Jul 2013 20:44:18 +0000

Hi

This is the last in this series of post-LC issues. The consensus in the room was almost unanimous, with only Mark pointing out that in his opinion, if we don't do it now, it will never be any different.

So, if you feel this (rather major) change is needed, please speak up, or else your silence will be interpreted as assent to the status quo.

Tobias and Yoav

On Jul 29, 2013, at 10:38 PM, websec issue tracker <[email-masked]> wrote:

> websec <http://tools.ietf.org/wg/websec/>

---

From: Larry Masinter <[email-masked]>
Date: Tue, 30 Jul 2013 01:50:48 -0700

This seems like a good idea. Do people think it isn't a good idea, or just "not now"?
If it's a good idea but not now, then when?

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Jul 2013 10:14:00 +0000

I guess the time would be when everybody ([1]) gets together and decides to create a big, unified policy format that goes in a resource and can convey all policy.

It's far better to do this consistently among all the policies that are conveyed from the server to the client.

Yoav

[1] should include people responsible for both things that were standardized in W3C and in IETF, so I guess that would require (shudder!) collaboration with the WebAppSec.

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 30 Jul 2013 12:17:33 -0700

>  be read at most once per connection, rather than with each request.

To me this seems related to a couple other issues:
 - can a client pin CAs by name, or will the client have to list
potentially dozens of hashes in the header?
 - is the header sent on every response from the pinned host, or is it
only returned infrequently or to a client who asks for it?

If CAs can be pinned by name, or if response headers are only returned
to a client who asks for them, then large headers don't matter much.

But the current draft seems inefficient / inelegant, since an HPKP
header may contain dozens of hashes.  The header must be sent on
*every* response from a pinned site (draft-08, section 2.2.1), so the
client must process the header on every response.

>  However, the same is true for HSTS, CSP, and any other policy-conveying

It's not exactly the same - HSTS does not interpret an absent response
header as max-age=0, so the headers doesn't need to be sent on every
response.  HSTS headers are also smaller.

Trevor

---

From: Joseph Bonneau <[email-masked]>
Date: Tue, 30 Jul 2013 17:40:17 -0400

> response.  HSTS headers are also smaller.

This is a big issue I wouldn't overlook. In my experience looking at web
crawls and trying to determine which sites are consistently setting HSTS,
almost nobody consistently sets the header for every path and subdomain
within a domain. For HSTS, this is okay as pointed out, but for HPKP I
expect this will lead to a lot of accidentally clearing of pins. So we
should think about what makes life easiest for server admins deploying HPKP
in addition to efficiency.

This could be argued either way-if servers aren't disciplined enough to
always set the header, they may not be disciplined enough to always satisfy
their own pins and they'll hang themselves that way. Serving everything
satisfying a set of pins is strictly harder than serving everything over
HSTS, and that's an issue. On the other hand servers will be more motivated
to fix anything they serve not satisfying pins, since clients will lose
access and complain, whereas accidentally clearing client pins by not
setting the header is a siient failure.

Personally I'd advocate strongly for a well-known URI. This is a tragedy of
the commons-if every working group uses a header since this is a little
less work, we end up with lots of headers being set and it being much
harder for everybody to manage than a well-known URI specifying all TLS
policy would be, as well as far less extensible.

As an example, it would be useful during the rollout of Certificate
Transparency if sites can specify that they are a "CT required" domain
before this policy could be turned on by default for every domain in the
world. Should this be another new header "Strict-Certificate-Transparency"?
An extra directive for HSTS? Having a simple JSON file at a well-known URI
to add a new field to makes much more sense.

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 31 Jul 2013 20:18:06 +0200

<no hats>

> client must process the header on every response.

actually the client does not have to process the hash for every
response. A simple compare with the previous cached hash(es) is
sufficient. So less processing effort.

Best regards, Tobias

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 31 Jul 2013 11:53:39 -0700

> sufficient. So less processing effort.

For *every* HTTPS response from a pinned site the client would have to
load its cached entry, parse the header, compare all parsed hashes
with all stored hashes, and update the cache / writethrough to disk
(because the "most recently observed" time changes on every HTTP
response, and the spec mandates tracking that).

Not a big deal in the scheme of things, maybe, but in my limited
browser devel experience they are extremely performance sensitive.

All this strikes me as inelegant.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Wed, 31 Jul 2013 20:33:45 +0000

Hi all

This issue turned out to be more contentious that I had expected. We've had two people in support of the change, in addition to one response that seems to indicate support for such a change, and Mark's remarks at the meeting, which were also kind-of, sort-of in support of such a change.

This does not look to me like consensus to keep the status quo. Do others feel differently?  If so, please speak up soon.

And for those who would like to use a .well-known resource, can you suggest a format for the key pinning resource?

Yoav

---

From: Joseph Bonneau <[email-masked]>
Date: Wed, 31 Jul 2013 17:01:22 -0400

> This issue turned out to be more contentious that I had expected. We've
> had two people in support of the change, in addition to one response that
> seems to indicate support for such a change, and Mark's remarks at the
> meeting, which were also kind-of, sort-of in support of such a change.
>

I'm in support of a change, I hope I'm counted as such.

> And for those who would like to use a .well-known resource, can you
> suggest a format for the key pinning resource?

I think the simplest option is to use a CSP-style format, with multiple
lines of "directive-name : value," such that Strict-Transport-Security and
Public-Key-Pins headers could be pasted directly on such lines with no
other changes to the spec. Future security policies could be defined/added
as needed such as "Strict-Certificate-Transparency : max-age=N"

An alternative would be a JSON or XML file which might be a little more
extensible and easier to parse, but would require more re-writing of this
and other specs.

Joe

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 31 Jul 2013 16:50:53 -0700

> I'm in support of a change, I hope I'm counted as such.

Me too.

>> suggest a format for the key pinning resource?

I'd vote for JSON, I think it's easier & safer than custom parsers based on BNF.

I looked over the websec slides, and I think there's one misconception
about this:
"""
W-K URI introduces a blocking load in the path
for loading pages/resources, increased pageload latency.
""

I don't see why this would be a blocking load.  I would expect it to
be done in the background, so have no latency impact.

Trevor

---

From: Chris Palmer <[email-masked]>
Date: Wed, 31 Jul 2013 17:53:47 -0700

> be done in the background, so have no latency impact.

So are we supposed to send cookies (for example) to the server before
finishing the W-K URI load?

If I completely rewrite HPKP to be a W-K URI I-D encompassing all of
HSTS, HPKP, and CSP (and what else?), does that actually have a chance
of flying? Or would it be a waste of everyone's time? Keep in mind
that including more people, including the authors of RFCs who think
their work is done, will make for a very slow and expensive process.

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 31 Jul 2013 20:22:30 -0700

> finishing the W-K URI load?

Sure.  That's how HPKP currently works: cookies are sent before the
server has a chance to deliver an HPKP header.  I don't think this
needs to be different?

> of flying?

Hmm, I wouldn't encompass all those things.  I'd just create a
"security_policy.json" with HPKP data in it.  But allow it to be
extended in the future.

If other people want to write their own specs to add data into it,
that's great - it's a convenient single place for browsers and web
crawlers to find security policy for a site.  But we don't need to do
all that immediately...

Trevor

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 01 Aug 2013 00:12:46 -0400

On 07/31/2013 11:22 PM, Trevor Perrin wrote:
> crawlers to find security policy for a site.

I'm finding myself more and more convinced  by the well-known URI
suggestion as well, despite the PITA that overhauling the spec is likely
to be.

Headers usually say something about a given HTTP request; the headers
we're discussing here say something about the site as a whole.

In addition to the extra overhead of re-evaluating the header on each
request, there is a potential security hole for sites which permit users
to control some subtree of the URL space.

For example, if the administrators of https://example.net/ allow the
user foo to publish arbitrary content below https://example.net/~foo/,
and that user emits an HPKP header, they could potentially override the
backup pins offered by the site administrator, or set an HSTS header
with includeSubDomains that would cause other unrelated requests to fail
closed, potentially for weeks or months depending on the max-age.
Control of a specific well-known URI seems more likely to be restricted
to the administrator.

With a well-known URI, there are probably still caching issues to stake
out; how often should a browser update its security policy for a given
site in the absence of standard HTTP caching headers from the server?
Or is it a MUST that the well-known URI needs to publish caching headers?

	--dkg

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 01 Aug 2013 08:22:43 +0200

> their work is done, will make for a very slow and expensive process.

<no hats>
I would not expect the draft to be extended to HSTS and CSP or other
things.
Only consider the approach for HPKP at this time.

Btw. a few thoughts:
personally I am not so comfortable with the resource part yet and would
still prefer the header, but like to do some more research before I make
any arguments.

And there might actually be another approach:
Finish HPKP as is with header and start a generic draft on moving
"everything" (extendable) to a resource location. Btw. we should also
start a discussion with W3C webappsec to learn what they think about it,
as CSP is done there.

Cheers, Tobias

---

From: Yoav Nir <[email-masked]>
Date: Thu, 1 Aug 2013 06:46:08 +0000

> I'd vote for JSON, I think it's easier & safer than custom parsers based on BNF.

And for maximum IETF buzzword-compliance, JSON encoded with CBOR ( http://tools.ietf.org/html/draft-bormann-cbor-04 )

> be done in the background, so have no latency impact.

Yes, we did mention it at the meeting. HPKP only impacts the next connection, so we might as well load it last in HTTP/1 and load it with low priority in HTTP/2.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 1 Aug 2013 06:53:58 +0000

> their work is done, will make for a very slow and expensive process.

I agree with Tobias. Assuming this is the consensus, we should do /.well-known/PublicKeyPinning

If someone ever wants to encompass all of the policy things (CSP, HSTS, and HPKP) in one big /.well-known/ServerPolicy that's another effort that could start here or at W3C, and is not in our charter. But anyway, that's maybe in the future.

Adding a well-known URI to the server is fairly easy. Since you (Chris) work for Google, you're in a better position than us to tell the group whether it would be acceptable for a browser such as Chrome to go and fetch the well-known URI. IMO it's not much different than fetching favicon, but I guess would know better.

Yoav