Re: [HASMAT] VeriSign feedback/comments on STS

[=JeffH <[e-mail]>]

I've submitted   draft-hodges-strict-transport-sec-02.  I believe I addressed 
all of the outstanding items remaining in my original reply to your comments 
(attached further below). Here's the change log from -02..


Appendix B.  Change Log

       Changes from -01 to -02:

       1.   updated abstract such that means for expressing HSTS Policy
            other than via HSTS header field is noted.

       2.   Changed spec title to "HTTP Strict Transport Security (HSTS)"
            from "Strict Transport Security".  Updated use of "STS"
            acronym throughout spec to HSTS (except for when specifically
            discussing syntax of Strict-Transport-Security HTTP Response
            Header field), updated "Terminology" appropriately.

       3.   Updated the discussion of "Passive Network Attackers" to be
            more precise and offered references.

       4.   Removed para on normative/non-normative from "Conformance
            Criteria" pending polishing said section to IETF RFC norms.

       5.   Added examples subsection to "Syntax" section.

       6.   Added OWS to maxAge production in Strict-Transport-Security
            ABNF.

       7.   Cleaned up explanation in the "Note:" in the "HTTP-over-
            Secure-Transport Request Type" section, folded 3d para into
            "Note:", added conformance clauses to the latter.

       8.   Added explanatory "Note:" and reference to "HTTP Request
            Type" section.  Added "XXX1" issue.

       9.   Added conformance clause to "URI Loading".

       10.  Moved "Notes for STS Server implementors:" from "UA
            Implementation advice " to "HSTS Policy expiration time
            considerations:" in "Server Implementation Advice", and also
            noted another option.

       11.  Added cautionary "Note:" to "Ability to delete UA's cached
            HSTS Policy on a per HSTS Server basis".

       12.  Added some informative references.

       13.  Various minor editorial fixes.




> -------- Original Message --------
> Subject: Re: VeriSign feedback/comments on STS -06
> Date: Fri, 09 Jul 2010 14:34:46 -0700
> From: =JeffH <[e-mail]>
> To: Deacon, Alex <[e-mail]>,  IETF HASMAT list <[e-mail]>

<snip/>


> 
> 
>> 1. Introduction
>> ---------------
>> * 3rd paragraph: Nit - Replace "Often, UAs provide for users to be able
>> to elect to continue..." with "Often, UAs enable users to elect to
>> continue..."
> 
> fixed.
> 
> 
>> * 4th paragraph: Nit - Replace "...to enable web sites and/or users to
>> be able to declare that such issues..." with "...to enable web sites
>> and/or users to declare that such issues..."
> 
> fixed.
> 
> 
> 
>> 2.1 Use Cases
>> -------------
>> * Nit - I would suggest we delete the first sentence of this section.
>> i.e. "The overall applicable....."
> 
> first sentence wordsmithed.
> 
> 
> 
>> 2.2 Strict Transport Security Policy Effects
>> --------------------------------------------
>> * 1st Paragraph: s/wielding/asserting
> 
> well, i think the connotations of wielding are appropriate :)
> 
> 
>> * Bullet 1.: I assume the intent is that *all* insecure connections
>> should be redirected, no?  If so I would state that.  i.e. "All insecure
>> ("http") connections...."
> 
> good catch, fixed.
> 
> 
>> * bullet 2.: Replace "including those caused by a site wielding
>> self-signed certificates." with "including those caused sites identified
>> using self-signed certificates."
> 
> replaced "wielding" with "presenting".
> 
> 
> 
>> 2.3.1.1 Passive Network Attackers
>> ---------------------------------
>> * 1st paragraph: Are we concerned about all 'wireless networks"?  Or is
>> the focus here on unsecured (i.e. non-WEP/WPA/etc) wifi networks?
> 
> well, ostensibly the focus is on unsecured wireless nets, but WEP and even the less-strong type of WPA are breakable, and there's tools to do so out there for the former (not sure about the latter)
> 
> although I see why you have this questions, we don't want (I think) to go into that level of detail in this spec.
> 
> I'll see what I can do.
> 
>> I'm
>> not an expert on cellular networks, but are they also a threat in this
>> regard?   In discussing this internally there was confusion on this
>> point until we focused on public hot-spots, be they in starbucks or a
>> hotel or a conference center.  It may drive home the point if we state
>> this scenario specifically.
> 
> ok, will fold this into the above.
> 
> 
> 
>> 5.1 Syntax
>> ----------
>> * Several example Strict-Transport-Security header values would be
>> useful here.
> 
> 
> done.
> 
> 
> 
>> 6.1 HTTP-over-Secure-Transport Request Type
>> -------------------------------------------
>> * s/Strict-Transport-Sec/Strict-Transport-Security
> 
> fixed.
> 
> 
>> * Its not clear why the first paragraph of this section states that STS
>> Sever *SHOULD* include a Strict-Transport-Security header but then in
>> the third paragraph it states the host *MUST* correctly return...at
>> least one valid STS header.  I would seem to me that if the intent is to
>> be conformant to this spec then servers MUST include the STS
>> header....no matter what caches and load-balancers may do.
> 
> We received a fair bit of feedback on earlier revs of the spec that these server-side processing rules ought to be "SHOULD"s -- we can re-open that discussion if folks wish to.
> 
> Wrt the "third paragraph" I presume you mean the para after the "Note:".
> 
> That 3d para is sorta broken in that establishing a given host as a STS Server may also be accomplished e.g. by client-side pre-loaded STS list (a la Chrome <http://dev.chromium.org/sts>). I've fixed that para to have MAYs and
> also to point to the "UA Implementation Advice" section.
> 
> 
> 
>> 6.2 HTTP Request Type
>> ----------------------
>> * 1st paragraph - Why is this requirement a SHOULD?  Assuming the term
>> "STS Server" means its conformant to this spec, then servers *MUST*
>> return a 301.
> 
> Again, we received feedback from colleagues that this was too stringent for
> servers for various reasons, e.g. those servers wishing to redirect only HSTS-capable UAs, but not legacy UAs.
> 
> 
> 
>> 7.1 STS Response header Field Processing
>> ----------------------------------------
>> * Upon receipt of new STS header values for a "Known STS Server" we
>> (well perhaps just me) should think about "downgrade/rollback" style
>> attacks.  For example can "bad things" happen by including or not
>> including (over time) the includeSubDomains field?
> 
> ah, we haven't really thought about "cycling" of the includeSubDomains directive. might be something to discuss in a dedicated thread.
> 
> 
>> Same goes for the
>> max-age values - i.e. is it OK on time t for the max-age to be 90 days,
>> and then at time t+5min for the server to specify the max age to 10
>> seconds.  Its late on a Friday evening, so perhaps there isn't an issue
>> here...but I thought I would mention it.
> 
> we decided in early STS discussions that since the UA only pays attention to STS headerfields conveyed over secure transport that we'd give the server admins the capability to "reset" the cached max-age value.
> 
> 
> 
>> * What does it mean to "ignore" the header (when received over insecure
>> transport or if there are syntax issues)?   I believe it means we do not
>> want the user to be notified with a error dialog but the UA could log a
>> warning to the audit trail.
> 
> ah, the latter is a good point that we can add to the UA impl advice.
> 
> 
> 
> 
>> 7.2 URI Loading
>> ---------------
>> * I don't see any normative words in this paragraph.   Looks like we
>> want to change the last sentence to "....then UA's MUST replace the URI
>> scheme with "https" before proceeding with the load."
> 
> hm. I thought section 7.2 was cross-referenced from elsewhere in the spec. will look into this.
> 
> 
>> 7.3 Errors in Secure Transport Establishment
>> --------------------------------------------
>> * This may be overstepping the bounds of this spec, but we should
>> discuss outlining some "best practices" from a UX point of view.  What
>> exactly does it mean to terminate the connection with no user recourse?
> 
> We could perhaps make some suggestions in section 10 UA Implementation Advice. I'm not sure what to add at this time though.
> 
> 
> 
> 
>> 9 Server Implementation Advice
>> ------------------------------
>> * Second bullet: replace "site wielding that organization's
>> certificate," with "site identifying itself using a self-signed
>> certificate, then secure ...."
> 
> done.
> 
> 
> ---
> end
>