Re: VeriSign feedback/comments on STS -06

It's available here:

 http://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html

I found the link on the Wikipedia entry:

 http://en.wikipedia.org/wiki/Strict_Transport_Security#References

- Bil


Chandersekaran, Coimbatore Ctr SAF/XCTX wrote on 5/17/2010 11:03 AM: 
> Could someone send me a copy of STS - 06?  I seem to have misplaced it.   Thanks. 
> 
> Coimbatore S Chandersekaran
> Chief Engineer, Distributed Systems and IA,
> USAF CIO Office
> 703-588-6161
> coimbatore.chandersekaran.ctr@pentagon.af.mil 
> 
> -----Original Message-----
> From: public-web-security-request@w3.org [mailto:public-web-security-request@w3.org] On Behalf Of Deacon, Alex
> Sent: Friday, May 14, 2010 8:24 PM
> To: public-web-security@w3.org
> Subject: VeriSign feedback/comments on STS -06
> 
> Jeff and all,
>  
> I wanted to send along my feedback/comments on the STS draft (-06).
> VeriSign is supportive of this work and based on my review the draft is
> in pretty good shape already.   Great job!
> 
> 
> 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..."
> 
> * 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..." 
> 
> 2.1 Use Cases
> -------------
> * Nit - I would suggest we delete the first sentence of this section.
> i.e. "The overall applicable....."
> 
> 2.2 Strict Transport Security Policy Effects
> --------------------------------------------
> * 1st Paragraph: s/wielding/asserting
> 
> * 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...."
> 
> * bullet 2.: Replace "including those caused by a site wielding
> self-signed certificates." with "including those caused sites identified
> using self-signed certificates."
> 
> 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?  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.
> 
> 5.1 Syntax
> ----------
> * Several example Strict-Transport-Security header values would be
> useful here.  
> 
> 6.1 HTTP-over-Secure-Transport Request Type
> -------------------------------------------
> * s/Strict-Transport-Sec/Strict-Transport-Security
> 
> * 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.    
> 
> 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.  
> 
> 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?   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.
> 
> * 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.  
> 
> 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."
> 
> 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?
> 
> 
> 9 Server Implementation Advice
> ------------------------------
> * Second bullet: replace "site wielding that organization's
> certificate," with "site identifying itself using a self-signed
> certificate, then secure ...."
> 
> 
> 
>  
> 
> 
>  
>  
> 
> 
>

Received on Monday, 17 May 2010 19:11:58 UTC