Subject: [websec] Issue #57 - another try

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Jun 2013 21:51:37 +0000

Hi

Version -05 of the draft has some proposed text for issue #57.

   UAs SHOULD set an upper limit on the value of max-age, so that UAs
   that have noted erroneous pins (whether by accident or due to attack)
   have some chance of recovering over time.  If the server sets a max-
   age greater than the UA's upper limit, the UA SHOULD behave as if the
   server set the max-age to the UA's upper limit.  For example, if the
   UA caps max-age at 2592000 seconds (30 days), and a Pinned Host sets
   a max-age directive of 60 days in its Valid Pinning Header, the UA
   SHOULD behave as if the max-age were effectively 30 days.  (One way
   to achieve this behavior is for the UA to simply store a value of 30
   days instead of the 60 day value provided by the Pinned Host.)  For
   UA implementation guidance on how to select a maximum max-age, see
   Section 4.1.

I think by now we've heard all the arguments back and forth for and against limits on max-age. So the question to the group is, can you live with the above text? If so, then I think we can move on to last call.

With no hats, I can live with this text, although I have two issues with it:

 1. I think the 30 days recommended in section 4.1 is too low, as I can think of many cases where a user would connect to a site from a particular device less often than every 30 days.

 2. I think it's a bad idea to leave the max-max-age to the discretion of the UA. If an erroneous pin was set for a domain for, say, 10 years, the domain owner has no way of knowing how long the pin will be set on some devices, and will have to assume the longest of all the UA implementation he's ever heard of. IOW having one popular browser set the maximum to 30 days, while another sets it to 90 days means that as the domain owner, I have to assume that the pin is "out there" for 90 days. 

Yoav

---

From: Tom Ritter <[email-masked]>
Date: Tue, 11 Jun 2013 19:02:45 -0400

I can live with it, although I also have lots of quibbles: I think a
'MAY' would be more appropriate, and I also think 30 days is too low.

-tom

---

From: Chris Palmer <[email-masked]>
Date: Tue, 11 Jun 2013 16:05:42 -0700

> I think by now we've heard all the arguments back and forth for and against limits on max-age. So the question to the group is, can you live with the above text? If so, then I think we can move on…

I can live with it. :)

>  1. I think the 30 days recommended in section 4.1 is too low, as I can think of many cases where a user would connect to a site from a particular device less often than every 30 days.

Noted.

>  2. I think it's a bad idea to leave the max-max-age to the discretion of the UA. If an erroneous pin was set for a domain for, say, 10 years, the domain owner has no way of knowing how long the pi…

Yes. But, FWIW, section 6 (Usability Considerations) says:

   UAs MUST have a way for users to clear current pins for Pinned Hosts.
   UAs SHOULD have a way for users to query the current state of Pinned
   Hosts.

---

From: "Sheehe, Charles J. (GRC-DPC0)" <[email-masked]>
Date: Thu, 13 Jun 2013 06:56:00 -0500

Hi
I like the paragraph as written.

Chuck

RFC 2119
SHOULD  
 This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

MAY  
 This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, June 11, 2013 5:52 PM
To: IETF WebSec WG
Subject: [websec] Issue #57 - another try

Hi

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 18 Jun 2013 18:57:14 +0800

On 12/06/13 07:02, Tom Ritter wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

<no hats>

I would agree with Tom and the "MAY" and please use an example of more
then 30 days.

But to be clear, I can also live with the "SHOULD".

Best regards, Tobias

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Jun 2013 12:05:58 +0000

> 'MAY' would be more appropriate, and I also think 30 days is too low.

I've already stated my opinion about the 30 days, but Tom is right about the SHOULD.  Unlike MUST, a SHOULD requires an explanation of when it is OK to not do the thing. So it's not enough to say "UAs SHOULD set a limit". You should have "UAs SHOULD set a limit ... unless all trust anchors are managed within the same administrative domain"  (that's just an example - it's not supposed to make sense). 

So either make it a MAY (in both sections 3.2.3 and 4.1) or come up with a good "unless" clause (like "UAs should set an upper limit... unless erroneous or malicious pins are not a concern").

I'd go with the MAY.

Yoav