[websec] HSTS spec issues noted in tracker

[=JeffH]

As y'all likely noticed, I worked through hasmat@ and websec@ mailing list 
archives since approx Jul-2010 and documented issues with the HSTS spec that've 
been raised, but aren't as yet addressed in 
draft-ietf-websec-strict-transport-sec-01.


an overview report is available here..

  http://trac.tools.ietf.org/wg/websec/trac/report/1?asc=1&sort=ticket

(that URI in the future will gen a report for all tickets submitted against all 
WebSec WG specs, just fyi/fwiw)


If there's any issues with the HSTS spec you feel are salient and that I didn't 
capture, please raise it on the list and/or submit a ticket.


I don't know if I'll be able to get the spec updated before Monday's I-D 
cutoff, but I will get it updated before Quebec in any case.


thanks,

=JeffH

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #10: note that end-entity certs can be dristrib'd to http clients ?

[websec issue tracker]

#10: note that end-entity certs can be dristrib'd to http clients ?

 http://www.ietf.org/mail-archive/web/websec/current/msg00306.html


 Subject: Re: [websec] Decouple HSTS's two orthogonal effects?
 From: Adam Barth 
 Date: Tue, 29 Mar 2011 14:35:58 -0700
 To: Tom Ritter 
 Cc: websec@ietf.org

 

 > Also Section 9 recommends distributing root CA certs to users'
 > browsers, and does not mention the possibly of distributing the leaf
 > certs instead.  Less related, but I prefer to trust organizations leaf
 > certs individually than their root cert.

 I don't have a problem with also recommending leaf certs, but you
 should check with =JeffH.

 Adam

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #9: explicitly note revocation check failures as errors causing connection termination?

[websec issue tracker]

#9: explicitly note revocation check failures as errors causing connection
termination?

 http://www.ietf.org/mail-archive/web/websec/current/msg00306.html


 Subject: Re: [websec] Decouple HSTS's two orthogonal effects?
 From: Adam Barth 
 Date: Tue, 29 Mar 2011 14:35:58 -0700
 To: Tom Ritter 
 Cc: websec@ietf.org

 On Tue, Mar 29, 2011 at 2:29 PM, Tom Ritter  wrote:
 > On Tue, Mar 29, 2011 at 4:58 PM, Adam Barth  wrote:
 >> There's no coupling between HSTS and the particular algorithm a UA
 >> uses to verify certificates.  The UA is free to use whatever
 >> verification mechanism it desires.
 >
 > This is good, but perhaps some clarification to the draft would be in
 order:
 >
 > Section 2.2 states:
 >
 >   2.  The UA terminates, without user recourse, any secure transport
 >       connection attempts upon any and all secure transport errors or
 >       warnings, including those caused by a site presenting self-signed
 >       certificates

 If a self-signed certificate does not cause a secure transport error,
 then you're all set.  For example, it's fine for a self-signed
 certificate to be in the list of explicitly trusted certificates.  In
 that case, no secure transport error is generated.  Try it.  :)

 > Knowing that HSTS allows any validation method a posteriori allows you
 > interpret this correctly - that self-signed certs *may* be allowed
 > under HSTS, if the user has added them to their store.  But without
 > that, it may be interpretted incorrectly - that no self-signed certs
 > would be allowed.

 That's not what it says.

 > Furthermore, I'm not sure, but "any and all secure
 > transport errors or warnings" may be ambiguous.  I don't know if it's
 > an existing standard to enter a warning or error state in event of
 > (for example) a revocation check failure - although we do know that
 > most browsers do not present any warning or error.  There's more on
 > that in Adam Langley's thread.   If HSTS does not define whether or
 > not a revocation check failure is an error condition, I think it
 > should.

 Indeed.  A reference there would be helpful.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #7: clarify and add examples/justification wrt connection termination due to tls warnings/errors

[websec issue tracker]

#7: clarify and add examples/justification wrt connection termination due to
tls warnings/errors


Comment(by jeff.hodges@…):

 see also

 http://www.ietf.org/mail-archive/web/websec/current/msg00063.html

 Subject: Re: [websec] Some questions about HSTS
 From: Adam Barth 
 Date: Mon, 22 Nov 2010 22:06:24 -0800
 To: Yoav Nir 
 Cc: "websec@ietf.org" 

 (text/plain)
 On Mon, Nov 22, 2010 at 9:46 PM, Yoav Nir  wrote:
 > Taking both your answers together, suppose I have a web server with a
 corporate or self-signed certificate, which is OK, as I expect all my
 users to approve an exception (as it's called in Firefox). I turn on HSTS
 because I'm worried about them being duped by a fake server using HTTP. To
 me, HSTS reduces the attack surface by making them dupable only on the
 first ever connect. Then, as it turns out, a certain browser breaks the
 connection when connecting from outside the organization, because the CDP
 is not available. Fine, I turn off HSTS, but because the cache is
 untouched, the users will get intermittent connectivity problems for three
 more months.

 I don't recommend using HSTS with self-signed certificates.  In this
 scenario, I'd recommend the corporation install a root certificate in
 all machines owned by the corporation and then use that root
 certificate to issue whatever other certificates the corporation
 needs.

 > I agree with Marsh, that this is too much of scope creep. It makes sense
 for a big website like paypal, amazon or gmail to want strict enforcement
 on the client. But smaller websites don't have the IT department of such
 companies, and often let their certificates expire. In their case, having
 HSTS on would cause a lot of trouble on certificate expiry day.

 Folks are already in for a headache if they let their certificates
 expire.  They'll get big nasty warnings in either case.  The
 difference is only whether those warnings will let the user ignore
 them.

 If you don't think your organization is sufficiently competent to
 schedule a reminder to update its certificates, then I don't recommend
 using HSTS.

 > The use case that I am interested in is not a big commercial website,
 but rather an SSL-VPN portal. These have two relevant properties: They
 come pre-packaged, and they're SSL-only. It is up to the customer to get a
 certificate, or generate a self-signed one. I would have liked to have
 HSTS on by default for such a product, but if that means that customers
 with self-signed certificates or corporate certificates get long-lasting
 connectivity problems, I can't justify that.

 Indeed.  Please don't use HSTS with self-signed certificates.  HSTS is
 a feature for well-maintained web sites that have a need for strong
 security.  The reason we designed HSTS was to differentiate between
 sites that actually want strong security and sites that are using TLS
 but don't have strong security needs.  If you don't need strong
 security, you don't need HSTS (and the additional careful
 administration it requires).

 > Sure, I can have a configuration flag for whether or not we should have
 the header, but administrators tend to configure those wrong just as much
 as users tend to click through dangerous screens.

 I don't think user agents should offer such a configuration flag.

 > What do the current implementations (Chrome, Firefox) do?

 They do what the spec says.  TLS errors on HSTS hosts are treated as
 fatal errors, much like the host's DNS name not resolving.  There is
 no recourse except to reload the page.

 Adam



 ###

 http://www.ietf.org/mail-archive/web/websec/current/msg00304.html

 Subject: Re: [websec] Decouple HSTS's two orthogonal effects?
 From: Adam Barth 
 Date: Tue, 29 Mar 2011 13:58:08 -0700
 To: websec@ietf.org

 (text/plain)
 There's no coupling between HSTS and the particular algorithm a UA
 uses to verify certificates.  The UA is free to use whatever
 verification mechanism it desires.  You can remove whatever CAs you
 consider sloppy from the list of trusted certificate authorities and
 add in whatever other verification mechanism you like.

 For example, if/when certificate verification through DNSSEC becomes
 widespread, we won't need to change anything about the HSTS spec.  Of
 course, we'll need to change our implementations, but that's true
 regardless of what the HSTS spec says.

 Adam

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___

[websec] #8: clarify/explain behavior when STS header not returned by known HSTS Host

[websec issue tracker]

#8: clarify/explain behavior when STS header not returned by  known HSTS Host

 http://www.ietf.org/mail-archive/web/websec/current/msg00045.html

 Subject: Re: [websec] Some questions about HSTS
 From: "Steingruebl, Andy" 
 Date: Mon, 22 Nov 2010 09:57:21 -0700 (08:57 PST)
 To: Yoav Nir , "'websec@ietf.org'" 

 

 > My second question regards the UA behavior when policy changes. Suppose
 > a website has had the HSTS header for a while. The UA has a cache entry
 with
 > a TTL of several more weeks. Now the UA connects to the server (over
 > HTTPS) and does not get an HSTS header at all. What now?  If there was a
 > header and it was merely changed, the spec says to update the cache
 entry.
 > But if the header is missing altogether, does that mean that the UA
 should
 > delete the cache entry?

 I think we can make this clear, but until the client receives a new
 header, it does not tinker with the cache.  We do say the header should be
 present in all /most server responses, but the behavior should be that the
 value persists until set to something else.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #7: clarify and add examples/justification wrt connection termination due to tls warnings/errors

[websec issue tracker]

#7: clarify and add examples/justification wrt connection termination due to
tls warnings/errors

 http://www.ietf.org/mail-archive/web/websec/current/msg00045.html

 Subject: Re: [websec] Some questions about HSTS
 From: "Steingruebl, Andy" 
 Date: Mon, 22 Nov 2010 09:57:21 -0700 (08:57 PST)
 To: Yoav Nir , "'websec@ietf.org'" 

 > In sections 2.4.1.1, point #9 says:
 >9.  UAs need to prevent users from clicking-through security
 >warnings.  Halting connection attempts in the face of secure
 >transport exceptions is acceptable.
 > What exactly are these secure transport exceptions?  Expired
 certificates?
 > Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA?
 > Self-signed?

 Anything that would currently pop a browser warning for a user currently.
 Browsers differ slightly in how they handle OCSP, etc.  In any case where
 a browser has already made the policy decision it should show a
 certificate "error", it must now abort.

 > Also, I don't understand why this change is needed. HSTS is supposed to
 stop
 > a very specific attack vector - a user duped into using insecure HTTP
 over the
 > (presumably secure) HTTPS.
 >
 > As it is, HSTS cannot be used by servers with self-signed or corporate
 > certificates, for fear that user agents may not allow the user to
 browse.

 That is correct.  I personally believe, as do several of the contributors
 on this (and I hope I'm not speaking too much out of turn) that self-
 signed certificate warnings are just a punt, and an easy way for a user to
 make a bad security decision.  If  you want to support HTTPS, do it with a
 cert that your browser already trusts.  Anything else is just a recipe for
 a MiTM attack.  If a host advertises HSTS, it is specifically opting into
 this scheme, whereby all certificate warnings will cause abort, with no
 chance to "fool" the user into making the wrong decision.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #4: Clarify that HSTS policy applies to entire host (all ports)

[websec issue tracker]

#4: Clarify that HSTS policy applies to entire host (all ports)


Comment(by jeff.hodges@…):

 http://www.ietf.org/mail-archive/web/websec/current/msg00041.html

 Subject: [websec] HSTS -- what about ports?
 From: Daniel Veditz 
 Date: Sat, 20 Nov 2010 22:29:48 -0800
 To: websec@ietf.org

 The HSTS spec needs to be more clear about how to handle multiple
 servers running on different ports on the same host. I think, by
 referring to host name matching only, that the intent of the spec is
 that a server running on any port can set HSTS behavior for every
 other port on that host. If this is correct it might be clearer to
 rename "HSTS Server" to "HSTS Host" and to somewhere in the spec
 mention explicitly that the port is ignored when matching host names.

 An alternate behavior would be that a server running on port X only
 specifies the behavior for that port, with a special case for the
 default ports 80/443 because they go unspecified. This would make
 sense from a security POV only if cookies were port-specific (with
 again a special case for the unspecified default ports), but I don't
 believe any browser implements cookies in that way. Handling HSTS in
 a port-specific manner also complicates the meaning of
 includeSubDomains.

 ###

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #6: cite FireSheep as real-life threat HSTS addresses

[websec issue tracker]

#6: cite FireSheep as real-life threat HSTS addresses

 cite FireSheep as real-life threat HSTS addresses, in response to this
 query:

 http://www.ietf.org/mail-archive/web/hasmat/current/msg00074.html

 Subject: [HASMAT] HSTS Threat prevalence
 From: Devdatta Akhawe 
 Date: Fri, 6 Aug 2010 11:36:12 -0700
 To: IETF HASMAT list 

 Hi all

 The HSTS specification talks about possible attacks that could be
 prevented by the use of HSTS. Do we have any data that suggests these
 attacks are actually a concern / being used by attackers anywhere ? I
 couldn't find any citation to this effect in the specification.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  -  |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #5: Clarify need for IncludeSubDomains

[websec issue tracker]

#5: Clarify need for IncludeSubDomains

 Yes, this is an unfortunate consequence of the way cookies work.
 Suppose you wanted to protect the confidentiality of a Secure cookie
 (i.e., a cookie with the Secure flag set), which, actually, is the
 primary use case for the header.  Further suppose that this cookie is
 a domain cookie (e.g., set for the entire example.com domain).  Now,
 if the attacker causes the browser to request
 https://aiodsfnuiasnis.example.com/, then:

 1) We're unlikely to have the HSTS policy bit for
 aiodsfnuiasnis.example.com.
 2) The request for https://aiodsfnuiasnis.example.com will include the
 Secure cookie.

 If the attacker then substitutes his certificate, the user will be
 able to click through the certificate error, which lets the attacker
 obtain the cookie we're trying to protect.

 If we remove the "includeSubDomains" directive, that means sites can't
 use HSTS to protect domain cookies.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  -  |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #4: Clarify that HSTS policy applies to entire host (all ports)

[websec issue tracker]

#4: Clarify that HSTS policy applies to entire host (all ports)


Comment(by jeff.hodges@…):

 add reference to "Beware Finer-grained Origins"
 

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #4: Clarify that HSTS policy applies to entire host (all ports)

[websec issue tracker]

#4: Clarify that HSTS policy applies to entire host (all ports)

 Clarify and make more explicit that HSTS policy applies to entire host
 (all ports).

 Also include security rationale, e.g. Secure-flagged cookie eavesdropping,
 XSS vulns, etc.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  major  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #3: Better Effective Request URI definition

[websec issue tracker]

#3: Better Effective Request URI definition

 Present Effective Request URI (ERU) definition is not as good/elegant as
 that in HTTPbis.

 In case we do not wish to have dependency on HTTPbis spec advancement, due
 to normative reference for ERU definition, we can copy the httpbis
 definition by value.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  minor  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  -  |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #2: Effective Request URI definition dependency on HTTPbis spec ?

[websec issue tracker]

#2: Effective Request URI definition dependency on HTTPbis spec ?

 Should we have an explicit normative dependency on the HTTPbis spec
 (Internet-drafts, advancement to RFC timeframe uncertain) for the
 definition of Effective Request URI ?

 Note: there is another ticket in case the answer to this question is "no",
 stipulating that we need to copy the ERU text from the httpbis I-D.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  task   |  Status:  new   
 Priority:  minor  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #1: port mapping should be explicit about case where URI does not contain explicit port

[websec issue tracker]

#1: port mapping should be explicit about case where URI does not contain
explicit port

 S 7.2. URI Loading and Port Mapping -- should contain explicit language
 about case where URI does not contain explicit port.

-- 
---+
 Reporter:  jeff.hodges@…  |   Owner:  =JeffH
 Type:  defect |  Status:  new   
 Priority:  minor  |   Milestone:
Component:  strict-transport-sec   | Version:
 Severity:  Active WG Document |Keywords:
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

[David Ross]

> Given that there's a fair number of web apps (aka websites) emitting 
> "X-FRAME-OPTIONS" (see below), and given its wide support in web 
> browsers, I think its justifiable to do (a), then see about (b).

Works for me.

David Ross
dr...@microsoft.com


-Original Message-
From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of 
Peter Saint-Andre
Sent: Friday, July 08, 2011 2:57 PM
To: =JeffH
Cc: IETF WebSec WG
Subject: Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New 
draft draft-gondrom-frame-options-01)

On 7/8/11 3:41 PM, =JeffH wrote:
>>> seems to me, this confusion & potential issues are reasons to /not/ 
>>> specify the header name as "Frame-Options" (for now), given 
>>> "X-FRAME-OPTIONS" apparent wide use.
>>
>> Sounds OK to me though I'd just want to be careful to do whatever the 
>> standards process dictates here.  I have to imagine there's a
> precedent we'd
>> want to follow.
> 
> there isn't much "process" wrt which we choose.
> 
> In terms of precedent, AFAIK there's examples of both (a) 
> documenting/specifying current practice, and (b) 
> documenting/specifying how proponents would like various practices to evolve.
> 
> Given that there's a fair number of web apps (aka websites) emitting 
> "X-FRAME-OPTIONS" (see below), and given its wide support in web 
> browsers, I think its justifiable to do (a), then see about (b).
> 
> There's a recent I-D,
>  'Use of the "X-"
> Prefix in Application Protocols' (being discussed on 
> ), which argues against its use. But in this 
> case current practice long predates said "X-" deprecation effort.

Correct. This is a perfect example of how parameters leak out from the 
non-standard space into the standard space. Thus "X-" is unnecessary:
someone could've just called it "Frame-Options" to start with. But as you say, 
that train has left the station...

Peter

--
Peter Saint-Andre
https://stpeter.im/


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

[Peter Saint-Andre]

On 7/8/11 3:41 PM, =JeffH wrote:
>>> seems to me, this confusion & potential issues are reasons to /not/
>>> specify the header name as "Frame-Options" (for now), given
>>> "X-FRAME-OPTIONS" apparent wide use.
>>
>> Sounds OK to me though I'd just want to be careful to do whatever the
>> standards process dictates here.  I have to imagine there's a
> precedent we'd
>> want to follow.
> 
> there isn't much "process" wrt which we choose.
> 
> In terms of precedent, AFAIK there's examples of both (a)
> documenting/specifying current practice, and (b) documenting/specifying
> how proponents would like various practices to evolve.
> 
> Given that there's a fair number of web apps (aka websites) emitting
> "X-FRAME-OPTIONS" (see below), and given its wide support in web
> browsers, I think its justifiable to do (a), then see about (b).
> 
> There's a recent I-D,
>  'Use of the "X-"
> Prefix in Application Protocols' (being discussed on
> ), which argues against its use. But in this case
> current practice long predates said "X-" deprecation effort.

Correct. This is a perfect example of how parameters leak out from the
non-standard space into the standard space. Thus "X-" is unnecessary:
someone could've just called it "Frame-Options" to start with. But as
you say, that train has left the station...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

[=JeffH]

>> seems to me, this confusion & potential issues are reasons to /not/
>> specify the header name as "Frame-Options" (for now), given
>> "X-FRAME-OPTIONS" apparent wide use.
>
> Sounds OK to me though I'd just want to be careful to do whatever the
> standards process dictates here.  I have to imagine there's a precedent we'd
> want to follow.

there isn't much "process" wrt which we choose.

In terms of precedent, AFAIK there's examples of both (a) 
documenting/specifying current practice, and (b) documenting/specifying how 
proponents would like various practices to evolve.


Given that there's a fair number of web apps (aka websites) emitting 
"X-FRAME-OPTIONS" (see below), and given its wide support in web browsers, I 
think its justifiable to do (a), then see about (b).


There's a recent I-D,  'Use 
of the "X-" Prefix in Application Protocols' (being discussed on 
), which argues against its use. But in this case 
current practice long predates said "X-" deprecation effort.


thanks,

=JeffH
--

Here's www.shodanhq.com's counts of web apps emitting x-frame-options...

* United States 6,853
* Germany   1,190
* United Kingdom  861
* Japan   793
* Canada  736

Results 1 - 10 of about 16032 for x-frame-options  <-- total ?





___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

[David Ross]

>  seems to me, this confusion & potential issues are reasons to /not/ specify 
> the header name as "Frame-Options" (for now), given "X-FRAME-OPTIONS" 
> apparent wide use.

Sounds OK to me though I'd just want to be careful to do whatever the standards 
process dictates here.  I have to imagine there's a precedent we'd want to 
follow.

David Ross
dr...@microsoft.com


-Original Message-
From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of 
=JeffH
Sent: Friday, July 08, 2011 12:41 PM
To: IETF WebSec WG
Subject: Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New 
draft draft-gondrom-frame-options-01)

 > I agree it would be good to get the ALLOW-FROM in the draft consistent with  
 > > [2].

super.

 > The major difference does seem to be the fact that the RFC supports a  > 
 > list of origins for ALLOW-FROM, whereas [2] does not.

yep.


 >> Also, the header name is declared as "Frame-Options" rather than what's  >> 
 >> presently implemented and deployed: "X-FRAME-OPTIONS".
 >
 > Since the RFC will standardize it, I think it may be appropriate to drop the 
 >  > X- prefix.  But then also we should probably have the RFC draft 
 > explicitly  > specify the behavior if there are multiple conflicting 
 > X-FRAME-OPTIONS /  > FRAME-OPTIONS headers present in a given HTTP response. 
 >  (Eg: What happens  > if there is both an X-FRAME-OPTIONS and a 
 > FRAME-OPTIONS header, each with  > ALLOW-FROM directives pointing to 
 > different sites?)

seems to me, this confusion & potential issues are reasons to /not/ specify the 
header name as "Frame-Options" (for now), given "X-FRAME-OPTIONS" apparent wide 
use.

FWIW, we can make this "X-FRAME-OPTIONS" spec be on the Informational or 
Experimental track. Microsoft already has a modest passel of specs in the 
former group.

thanks,

=JeffH

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

[=JeffH]

> I agree it would be good to get the ALLOW-FROM in the draft consistent with
> [2].

super.

> The major difference does seem to be the fact that the RFC supports a
> list of origins for ALLOW-FROM, whereas [2] does not.

yep.


>> Also, the header name is declared as "Frame-Options" rather than what's
>> presently implemented and deployed: "X-FRAME-OPTIONS".
>
> Since the RFC will standardize it, I think it may be appropriate to drop the
> X- prefix.  But then also we should probably have the RFC draft explicitly
> specify the behavior if there are multiple conflicting X-FRAME-OPTIONS /
> FRAME-OPTIONS headers present in a given HTTP response.  (Eg: What happens
> if there is both an X-FRAME-OPTIONS and a FRAME-OPTIONS header, each with
> ALLOW-FROM directives pointing to different sites?)

seems to me, this confusion & potential issues are reasons to /not/ specify the 
header name as "Frame-Options" (for now), given "X-FRAME-OPTIONS" apparent wide 
use.


FWIW, we can make this "X-FRAME-OPTIONS" spec be on the Informational or 
Experimental track. Microsoft already has a modest passel of specs in the 
former group.


thanks,

=JeffH

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

[David Ross]

I agree it would be good to get the ALLOW-FROM in the draft consistent with 
[2].  The major difference does seem to be the fact that the RFC supports a 
list of origins for ALLOW-FROM, whereas [2] does not.

> Also, the header name is declared as "Frame-Options" rather than what's 
> presently implemented and deployed: "X-FRAME-OPTIONS".

Since the RFC will standardize it, I think it may be appropriate to drop the X- 
prefix.  But then also we should probably have the RFC draft explicitly specify 
the behavior if there are multiple conflicting X-FRAME-OPTIONS / FRAME-OPTIONS 
headers present in a given HTTP response.  (Eg: What happens if there is both 
an X-FRAME-OPTIONS and a FRAME-OPTIONS header, each with ALLOW-FROM directives 
pointing to different sites?) 

David Ross
dr...@microsoft.com


-Original Message-
From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of 
=JeffH
Sent: Thursday, July 07, 2011 9:39 PM
To: Tobias Gondrom
Cc: IETF WebSec WG
Subject: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft 
draft-gondrom-frame-options-01)


Hi Tobias -- thanks for working on this spec, it will be good to get this all 
more formally documented.

It appears that the -01 rev of draft-gondrom-frame-options takes into account 
the apparently present X-Frame-Options documentation here..


[2] Combating ClickJacking With X-Frame-Options
 EricLaw [MSFT]
 30 Mar 2010 2:42 PM



..which apparently supersedes the prior nominal documentation..


[1] IE8 Security Part VII: ClickJacking Defenses
 ieblog
 27 Jan 2009 9:40 PM



..and which draft-gondrom-frame-options-00 appears to have been based on.


As Dave Ross earlier today noted in..

   Re: [websec] FYI: New draft draft-gondrom-frame-options-01
   http://www.ietf.org/mail-archive/web/websec/current/msg00388.html

..the -01 spec rev differs from [2] in that it allows for declaring an origin 
list as a value for the ALLOW-FROM directive.

Also, the header name is declared as "Frame-Options" rather than what's 
presently implemented and deployed: "X-FRAME-OPTIONS".


Why don't we (WebSec) first simply document present X-FRAME-OPTIONS practice 
and get that more formally nailed down before we begin enhancing/altering it ?

After all, it's apparently implemented in most all major browsers, and (I hear) 
emitted by a fair number of web applications. Plus, there's always the question 
of how closely all those implementations today conform to the present de jure 
specification, especially the "new" ALLOW-FROM directive in [2].

This would be in the same spirit as the RFC6265 "HTTP State Management" (aka 
Cookies) effort where we (hopefully unambiguously) documented the present 
implemented and deployed cookie subprotocol.

thanks,

=JeffH








___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec