- From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- Date: Thu, 05 Feb 2015 17:54:15 -0500
- To: Peter Eckersley <pde@eff.org>, public-webappsec@w3.org
- Cc: technologists@eff.org
- Message-ID: <87a90s0y20.fsf@alice.fifthhorseman.net>
On Mon 2015-02-02 19:21:00 -0500, Peter Eckersley wrote: > Assuming that clients are following point 6.1.4 in RFC 6797 > (https://tools.ietf.org/html/rfc6797#section-6.1) correctly, it should > be practical to make this kind of functionality part of HSTS. This point in the RFC says: 4. UAs MUST ignore any STS header field containing directives, or other header field value data, that does not conform to the syntax defined in this specification. I read that to mean that STS headers which break *syntax* should be ignored. It does not say that any unknown directive should be ignored. in fact, the next point explicitly says that unknown directives should be ignored: 5. If an STS header field contains directive(s) not recognized by the UA, the UA MUST ignore the unrecognized directives, and if the STS header field otherwise satisfies the above requirements (1 through 4), the UA MUST process the recognized directives. So to make this "helpful" bit settable with the semantics you suggest, it actually needs to break the currently-defined syntax of Strict-Transport-Security, not just be a novel directive. Do you have an example of how something like that would look without requiring HTTP header parsers to be even more idiosyncratic than they already are? There are a lot of ways one could break the syntax :) --dkg
Received on Thursday, 5 February 2015 22:54:43 UTC