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

On 21/03/12 14:44, Paul Hoffman wrote:
> On Mar 21, 2012, at 1:56 AM, Yoav Nir wrote:
>
>> 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"
> 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.
<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".

>> 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.
> 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.
<hat="individual">
Absolutely correct indeed. And also CRL are integrity protected by their 
signature.

>
> --Paul Hoffman
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec