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
[email protected]
https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
