RE: VeriSign feedback/comments on STS -06

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 18:03:43 UTC