Re: [HASMAT] VeriSign feedback/comments on STS -06

[=JeffH <Jeff.Hodges at KingsMountain.com>]

Alex,

thanks for your feedback, much appreciated.


accepted feedback below is implemented in -02 rev of..

  http://tools.ietf.org/html/draft-hodges-strict-transport-sec

..which is not yet submitted, but will be later tonight or this weekend.

Some items below we may wish to have more extensive discussion on in specific 
threads on the list.

thanks!

=JeffH



> 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