Subject: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9

From: Tobias Gondrom <[email-masked]>
Date: Sun, 18 Mar 2012 22:31:27 +0000

Hello dear websec fellows,

after reading the feedback, tracker entries and the updates on the HSTS 
draft, the WG chairs and secretary have the impression that the draft is 
in good shape and we like to ask for WG Last Call for this document:
http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-06

As we are close to the IETF meeting in Paris, this last call will be 
extended to three weeks and close on April-9. Please make a last careful 
review of the draft and submit comments, questions and discuss items for 
this draft ASAP. You can submit them via email to the mailing-list or 
make entries for HSTS in the tracker. If you perceive any major issues, 
it might also make sense to raise them during our meeting in Paris on 
March-26.

Kind regards and thank you,

Tobias
chair of websec

Tobias Gondrom
email: [email-masked]
mobile: +447521003005

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Mar 2012 10:35:45 +0100

On 2012-03-18 23:31, Tobias Gondrom wrote:
> ...

I'd like to point out that I still think my concerns over the 
inconsistent use of quoted-string 
(<http://www.ietf.org/mail-archive/web/websec/current/msg01044.html>) 
are valid and not addressed; and I think they should be before you go to 
IETF LC.

Note that since we had a long discussion with Adam Barth about 
quoted-string, Chrome has started supporting it in Content-Disposition, 
and a similar fix for Content-Type is in preparation 
(<http://code.google.com/p/chromium/issues/detail?id=103361#c7>).

In <http://www.ietf.org/mail-archive/web/websec/current/msg01045.html> 
Jeff points out that Firefox doesn't support quoted-string in all 
parameters, but IMHO that's a bogus argument because it currently 
doesn't support q-s *at all*; so it will need to be fixed to conform to 
the current spec as well (see 
<https://bugzilla.mozilla.org/show_bug.cgi?id=718409>).

I believe this could be a useful discussion topic for Paris.

Best regards, Julian

---

From: Marsh Ray <[email-masked]>
Date: Mon, 19 Mar 2012 12:05:04 -0500

> are valid and not addressed; and I think they should be before you go to

As a developer at a company which makes a product that makes security 
decisions based on parsing HTTP headers I find Julian's concerns, well, 
concerning.

While we don't currently operate on this specific header, ambiguities in 
how an application server will interpret minor variations on header 
values often become opportunities for an attacker to bypass security 
measures. For example, a "web application firewall" (WAF) may be 
configured to forbid certain values of a customer-specified header. When 
new headers don't follow consistent syntactic rules, it takes away a bit 
of the developer's ability to simply things for his customer.

Again, I'm not claiming to be an expert on this particular header and 
clearly it's a difficult issue with arguments for doing it both ways. 
But I would ask that everyone try their best to find the least-bad 
alternative with an emphasis on consistency with the rest of HTTP.

- Marsh

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 19 Mar 2012 19:59:08 +0000

Julian,

thank you for the reminder. I agree that we have to discuss this during 
our WG LC (and before we go to IETF LC).
Definitely yes, to discuss this at our meeting in Paris.

Best regards, Tobias

On 19/03/12 09:35, Julian Reschke wrote:
> are valid and not addressed; and I think they should be before you go 
> to IETF LC.
>
> quoted-string, Chrome has started supporting it in 
> Content-Disposition, and a similar fix for Content-Type is in 
> preparation 
> doesn't support q-s *at all*; so it will need to be fixed to conform 
> to the current spec as well (see

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Mar 2012 19:50:18 +0000

On 18/03/2012 22:31, Tobias Gondrom wrote:
> after reading the feedback, tracker entries and the updates on the 
> HSTS draft, the WG chairs and secretary have the impression that the 
> draft is in good shape and we like to ask for WG Last Call for this 
> document:
> extended to three weeks and close on April-9. Please make a last 
> careful review of the draft and submit comments, questions and discuss 
> items for this draft ASAP. You can submit them via email to the 
> mailing-list or make entries for HSTS in the tracker. If you perceive 
> any major issues, it might also make sense to raise them during our 
> meeting in Paris on March-26.
I just would like to add that raising issues at a microphone in Paris 
doesn't replace sending them in email/opening a tracker ticket. And WG 
chairs would really appreciate reviews before March 26th.
> Kind regards and thank you,
Alexey,
WebSec co-chair.

---

From: SM <[email-masked]>
Date: Tue, 20 Mar 2012 08:29:25 -0700

Hi Julian,
At 02:35 19-03-2012, Julian Reschke wrote:
>  are valid and not addressed; and I think they should be before you 
>go to IETF LC.

Wasn't a similar issue raised in another WG recently?

Regards,
-sm

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Mar 2012 17:01:11 +0100

> Wasn't a similar issue raised in another WG recently?

Indeed; in the context of the auth parameters in the OAuth Bearer 
authentication scheme.

There's a slight difference though, the Bearer spec defined new 
parameters for an HTTP header field that already exists 
(WWW-Authenticate), while STS is a completely new header field.

In the first case, it's a bug (that got fixed), in this case it's "just" 
a bad idea. Note that HTTPbis P2 has advice with respect to this:

"Many header fields use a format including (case-insensitively) named 
parameters (for instance, Content-Type, defined in Section 6.8 of 
[Part3]). Allowing both unquoted (token) and quoted (quoted-string) 
syntax for the parameter value enables recipients to use existing parser 
components. When allowing both forms, the meaning of a parameter value 
ought to be independent of the syntax used for it (for an example, see 
the notes on parameter handling for media types in Section 2.3 of 
[Part3])." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.3.1.p.8>

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2012 18:21:57 -0700

Greetings again. I have read the draft again, and am quite happy that this is moving forwards. Having said that, I have a list of issues that I think need to be dealt with, and a few editorial issues.

--Paul Hoffman

Significant:

This document pretends that the TLSA protocol from the DANE WG will not exist. This is a tad odd, given that TLSA is likely to be published a few weeks before HSTS. In specific, bullet 2 of section 2.2 and all of section 10.2 are written as if self-signed certificates will always cause HTST-compliant browsers to fail, even if those certificates cause matching when used with TLSA.

Proposed replacements:

   2.  The UA terminates any secure transport connection attempts upon
       any and all secure transport errors or warnings, including those
       caused by a web application presenting a certificate that does
       chain to a trusted root or match a trusted certificate association
       from the TLSA protocol [I-D.draft-ietf-dane-protocol].

. . .

   If a web site/organization/enterprise is generating their own secure
   transport public-key certificates for web sites, and that
   organization's root certification authority (CA) certificate is not
   typically embedded by default in browser CA certificate stores, and
   if HSTS Policy is enabled on a site identifying itself using a self-
   signed certificate, and the certificate presented by the TLS server
   does not match a trusted certificate association from the TLSA
   protocol [I-D.draft-ietf-dane-protocol],
   then secure connections to that site will fail,
   per the HSTS design.  This is to protect against various active
   attacks, as discussed above.

   However, if said organization strongly wishes to employ self-signed
   certificates, and their own CA in concert with HSTS, they can do so
   by deploying their root CA certificate to their users' browsers.
   They can also, in addition or instead, distribute to their users'
   browsers the end-entity certificate(s) for specific hosts.  There are
   various ways in which this can be accomplished (details are out of
   scope for this specification).  Once their root CA certificate is
   installed in the browsers, they may employ HSTS Policy on their
   site(s).

   Alternately, that organization can deploy the TLSA protocol; all
   browsers that also use TLSA will then be able to trust the
   self-signed certificates if it announced through TLSA.

   Note:  Interactively distributing root CA certificates to users,
          e.g., via email, and having the users install them, is
          arguably training the users to be susceptible to a possible
          form of phishing attack, see Section 14.6 "Bogus Root CA
          Certificate Phish plus DNS Cache Poisoning Attack".

Moderate:

In section 8.1.2, I don't know what "ignoring separator characters" means, and suspect it will cause pain if left this way.

[I-D.ietf-tls-ssl-version3] is not a "work in progress". I'll take this up on the rfc-interest mailing list, and nothing needs to be done here.

RFC 2818 is listed as a normative reference, and yet it is Informational. This will need to be called out in the PROTO report. Alternately, it can be called an informative reference, since one does not need to understand it in order to implement this document.

I have alerted the idna-update mailing list of this WG LC. This might cause some helicoptered-in comments, but better now than during IETF LC.

Editorial:

"annunciate" (used a few times) is a fancy word for "announce". Maybe use the far more common word instead.

In section 3.1, "suboptimal downside" is unclear. Is there an optimal downside? I suggest replacing it with "negative".

The lead sentences in sections 11.2, 11.4, and 11.5 lack verbs; verbs are used in 11.1 and 11.3. This should be an easy fix.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Mar 2012 10:56:26 +0200

Hi

I have two significant comment, and several editorial.

The significant: 

I have said this before, and was rejected by the group, so I'll raise this one last time here. 
Section 8.3 makes it a MUST-level requirement that any failure of the underlying secure transport. Section 11.1 clarifies that there should be no user recourse for this. This makes the cost of implementing unreasonably high, and significantly discourages trial roll-outs. Adding an HSTS header to your web site takes about 2 lines of configuration file in Apache. But doing so makes small errors like letting the certificate lapse or using links with a different FQDN cause hard failures. Both these sections do now state specifically what constitutes a failure, so it might be that the intention was not to include expirations. I think this should be clarified, but mismatched names obviously apply.
I suggest that either we remove the no user recourse advice, or else add a "hardfail" directive. Roll out with "hardfail=no", and if people don't complain, change to "hardfail=yes"

Section 10.3 discusses the case where the server or some subdomain also hosts CRLs or OCSP and suggests some work-around to the "all TCP" port requirement. Fetching CRLs is a different context than rendering a web page. I think the suggestions should be removed and a sentence added that says that the STS policy does not apply to fetching of revocation information by the browser. I think this would be far easier to implement.

Editorial:

In the introduction 2nd paragraph it says "(although modulo other rules)". s/modulo/subject to/.

Also, replace "annunciate" with "announce" or "indicate".

Both the introduction and section 8.2 say the policy applies to "all TCP ports". Hosts have multiple TCP ports: for SSH as an example. I suggest we change to "all HTTP(S) ports"

In the title of section 8.5, I think we can do without the word "Interstitially".

Section 10.1 begins with "Server implementations and deploying web sites need to consider whether they are setting…". Searching for the alternative (because an implied "or not" doesn't work for this sentence) took me to the 4th paragraph of this section, and the top of page 21, which begins with "Or, whether they are setting". This won't make it past the RFC editor, but I think it should be rephrased earlier.

Section 14.1 discusses a UA behind an SSL proxy and implies that such a connection will cause warning screens (without HSTS) or hard failures. Such a deployment would be considered a wrong deployment of an SSL proxy. Administrators usually configure the UAs that are managed, and give detailed instructions to the owners of UAs that are not managed, so that the CA used by the proxy is trusted. There should be no warnings and no hard failures.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Mar 2012 07:36:44 -0700

On Mar 19, 2012, at 2:35 AM, Julian Reschke wrote:

> I'd like to point out that I still think my concerns over the inconsistent use of quoted-string (<http://www.ietf.org/mail-archive/web/websec/current/msg01044.html>) are valid and not addressed; and I think they should be before you go to IETF LC.
> 
> Note that since we had a long discussion with Adam Barth about quoted-string, Chrome has started supporting it in Content-Disposition, and a similar fix for Content-Type is in preparation (<http://code.google.com/p/chromium/issues/detail?id=103361#c7>).
> 
> In <http://www.ietf.org/mail-archive/web/websec/current/msg01045.html> Jeff points out that Firefox doesn't support quoted-string in all parameters, but IMHO that's a bogus argument because it currently doesn't support q-s *at all*; so it will need to be fixed to conform to the current spec as well (see <https://bugzilla.mozilla.org/show_bug.cgi?id=718409>).

+1. This is an important topic.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Mar 2012 07:44:26 -0700

> I suggest that either we remove the no user recourse advice, or else add a "hardfail" directive. Roll out with "hardfail=no", and if people don't complain, change to "hardfail=yes"

I support this idea. As we have seen with the rollout of DNSSEC, hardfails turn into bad publicity, which then turn into delayed deployment. The browser industry experiments with different ways to alert the user or hardfail, and the addition of this option would aid those experiments.

> Section 10.3 discusses the case where the server or some subdomain also hosts CRLs or OCSP and suggests some work-around to the "all TCP" port requirement. Fetching CRLs is a different context than…

This is a very good idea and will lead to fewer surprises. There is no need to SSL-protect CRL fetches. In fact, requiring SSL-protection on CRL fetches is impossible, since you need the CRL in order to get the CRL.

--Paul Hoffman

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 24 Mar 2012 13:20:19 +0100

> Greetings again. I have read the draft again, and am quite happy that this is moving forwards. Having said that, I have a list of issues that I think need to be dealt with, and a few editorial issu…
Hi Paul,
Thanks for very good comments. I am agreeing with all of them except for 
the one thing:
> RFC 2818 is listed as a normative reference, and yet it is Informational.
I disagree with you, it is normative for the definition of HTTPS.
> This will need to be called out in the PROTO report.
This would be fine. RFC 2818 is in the DownRef registry, so it doesn't 
even need to be explicitly called out during IETF LC.
> Alternately, it can be called an informative reference, since one does not need to understand it in order to implement this document.

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 24 Mar 2012 18:28:51 +0000

> I support this idea. As we have seen with the rollout of DNSSEC, hardfails turn into bad publicity, which then turn into delayed deployment. The browser industry experiments with different ways to…
<hat="individual">
Agree. Personally I'm not a fan of the temporary migration switch 
"hardfail=no" solution, but I can see the benefit for the transition. 
Still it would be important that servers switch to "hardfail=yes" at 
some point....
E.g. the document should state that a server SHOULD set the directive to 
"hardfail=yes" and only for testing and migration periods MAY use 
"hardfail=yes".

> This is a very good idea and will lead to fewer surprises. There is no need to SSL-protect CRL fetches. In fact, requiring SSL-protection on CRL fetches is impossible, since you need the CRL in ord…
<hat="individual">
Absolutely correct indeed. And also CRL are integrity protected by their 
signature.

>
> --Paul Hoffman
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec