Re: VeriSign feedback/comments on STS -06

There is actually an alternative proposal that conveys the STS bit
using DNSSec.  The primary advantage of that proposal is that it
removes the secure initialization assumption.  The primary
disadvantage, however, is that it requires DNSSec, which is not yet
widely available.

Adam


2010/5/17 Henrik Nordström <henrik@henriknordstrom.net>:
> Just joined the list in the middle of this discussion. Wasn't aware of
> this list until quite recently when I saw it annouced in http-wg.
>
> What I do not get is why this is addressed at the HTTP level. My first
> reaction is that this belongs at either the SSL or DNS layers, not HTTP.
>
> SSL by atting a suitable attribute to certificate.
>
> DNS by adding a DNS record stating the site policy, similar to as has
> been done for SMTP and other protocols for similar policy purposes. This
> way it's possible to prevent user agents from even trying to access the
> site using http, automatically swithing to https even if the user did
> not ask for it. Sure, DNS isn't at it best days with cache poisoning
> attacks, but that's improving considerably thanks to "new"
> recommendations and with DNSSec becoming common in the not too distant
> horizon it should relatively soon be very much on track again.
>
> Regards
> Henrik
>
> mån 2010-05-17 klockan 12:11 -0700 skrev Bil Corry:
>> 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 Tuesday, 18 May 2010 09:34:03 UTC