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

[Yoav Nir]

That text works for me. 

On Mar 22, 2013, at 6:47 PM, websec issue tracker 
 wrote:

> #56: Specify includeSubdomains directive for HPKP
> 
> 
> Comment (by pal...@google.com):
> 
> I have added language to the working copy of the draft
> (https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-
> websec-key-pinning.xml) in the Security Considerations section.
> 
> -- 
> ---+
> Reporter:  pal...@google.com  |   Owner:  pal...@google.com
> Type:  defect |  Status:  assigned
> Priority:  major  |   Milestone:
> Component:  key-pinning| Version:
> Severity:  -  |  Resolution:
> Keywords:  includeSubdomains  |
> ---+
> 
> Ticket URL: 
> websec 
> 
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
> 
> Email secured by Check Point

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #57: Re-add an upper limit to max-age

[Yoav Nir]

On Mar 22, 2013, at 7:36 PM, Joseph Bonneau  wrote:

> On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin  wrote:
>> With a spec maximum (say 30 days), then you have a clear reference
>> point to plan around.
> 
> Agreed.
> 
> I have some stats I've been looking at from Google's web crawls about
> HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a
> max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1
> day, and a smattering of other choices (with a few large hosts like
> Twitter setting very long-lived max-age).

As Ekr said in the meeting, there is a big difference here between HSTS and 
HPKP. It doesn't matter if Paypal or some bank advertises HSTS for a million 
years. It's not likely that someone who has declared a policy for always using 
secure transport will suddenly switch to non-secure transport. They might stop 
advertising HSTS, but they're not likely to stop insisting on TLS use.

OTOH a particular public key might be replaced because of switching certificate 
vendors, because auditors don't like that key length any more, or because your 
certificate vendor has decided that ECC is the way to go. Pinning something 
that has an expiry date for an unlimited time could be a problem.

Something to consider is that if the max-age time is shorter than the time 
between accesses to the site, the security of this mechanism is lost. If either 
the draft or the UA sets an upper limit of 30 days, then HKPK won't work for 
pub.ietf.org. This is a site that I only use from one week before an IETF 
meeting to one week following it. In between there are a little over three 
months where I don't use the site at all. So it would make sense for the site 
operator to set a max-age of 4 months. That limit may be inappropriate for web 
mail or social media, but even those might be accessed from different UAs at 
different times. For example, I might use my home computer for a social media 
site while I'm at home, but use a smart phone or a laptop for the same site 
when I'm away from home. 

I understand Trevor's issue. Does it make a difference to a site operator 
whether the site is partially bricked by bad pins for 30 days or 365 days?

Yoav

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #57: Re-add an upper limit to max-age

[Joseph Bonneau]

On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin  wrote:
> With a spec maximum (say 30 days), then you have a clear reference
> point to plan around.

Agreed.

I have some stats I've been looking at from Google's web crawls about
HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a
max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1
day, and a smattering of other choices (with a few large hosts like
Twitter setting very long-lived max-age).

These are only a rough upper bound on the max-age values that would be
set for pins, but it seems a substantial number of hosts would request
longer than 30 days, while 1 year will support most likely use cases,
so we should probably land somewhere between those two points.

The follow-on question is, if UAs allow max-age of 1 year, will there
need to be a revocation method to deal with some of the cases that
Trevor highlighted?
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #57: Re-add an upper limit to max-age

[Trevor Perrin]

On Fri, Mar 22, 2013 at 2:39 PM, websec issue tracker
 wrote:
> #57: Re-add an upper limit to max-age
>
>
> Comment (by pal...@google.com):
>
>  Rather, it was decided that there should be implementation guidance for
>  setting an upper limit, including discussing the security considerations
>  /trade-offs of high vs. low maximum max-age values.

So this maximum is a "local policy" decided by the UA?

It might be good to also have a spec-mandated maximum.

There are cases where you (a domain owner) might have unknown pins or
bad pins.  For example:
 - you purchased a domain name from someone
 - the domain name was victimized by domain hijacking or domain squatting
 - you misconfigured pins for your domain

If there's no spec-mandated maximum, then there's no point in time at
which all old pins are guaranteed to have been expired, and you can
start referring people to this domain safely.

With a spec maximum (say 30 days), then you have a clear reference
point to plan around.


Trevor
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[websec issue tracker]

#56: Specify includeSubdomains directive for HPKP


Comment (by pal...@google.com):

 I have added language to the working copy of the draft
 (https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-
 websec-key-pinning.xml) in the Security Considerations section.

-- 
---+
 Reporter:  pal...@google.com  |   Owner:  pal...@google.com
 Type:  defect |  Status:  assigned
 Priority:  major  |   Milestone:
Component:  key-pinning| Version:
 Severity:  -  |  Resolution:
 Keywords:  includeSubdomains  |
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[websec issue tracker]

#56: Specify includeSubdomains directive for HPKP


Comment (by pal...@google.com):

 TODO: Discuss the problem that, given that we prefer (2), Pinned Host
 operators will have a problem if UAs by chance happen to visit Google.com
 first, and then second try to visit WWW.Google.com. Due to
 includeSubdomains, the pins A and B will take effect, and Pin Validation
 will fail, *before the UA has a chance to note the pin C for
 WWW.Google.com*. Host operators SHOULD take this problem into account when
 deploying Pinned Hosts.

-- 
---+
 Reporter:  pal...@google.com  |   Owner:  pal...@google.com
 Type:  defect |  Status:  assigned
 Priority:  major  |   Milestone:
Component:  key-pinning| Version:
 Severity:  -  |  Resolution:
 Keywords:  includeSubdomains  |
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #57: Re-add an upper limit to max-age

[websec issue tracker]

#57: Re-add an upper limit to max-age


Comment (by pal...@google.com):

 I have added language discussing the issue to the latest working copy of
 the draft at https://code.google.com/p/key-pinning-draft/source/browse
 /draft-ietf-websec-key-pinning.xml.

-- 
+
 Reporter:  pal...@google.com   |   Owner:  pal...@google.com
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:
Component:  key-pinning | Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:  |
+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #57: Re-add an upper limit to max-age

[websec issue tracker]

#57: Re-add an upper limit to max-age


Comment (by pal...@google.com):

 Rather, it was decided that there should be implementation guidance for
 setting an upper limit, including discussing the security considerations
 /trade-offs of high vs. low maximum max-age values.

-- 
+
 Reporter:  pal...@google.com   |   Owner:  pal...@google.com
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:
Component:  key-pinning | Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:  |
+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #57: Re-add an upper limit to max-age

[websec issue tracker]

#57: Re-add an upper limit to max-age

 At IETF 86, it was decided that there should be an upper limit to the max-
 age directive

-- 
+---
 Reporter:  pal...@google.com   |  Owner:  pal...@google.com
 Type:  defect  | Status:  new
 Priority:  major   |  Milestone:
Component:  key-pinning |Version:
 Severity:  Active WG Document  |   Keywords:
+---

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec