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 On Mar 19, 2012, at 12:31 AM, Tobias Gondrom wrote: > 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
