W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: [MIX] 4 possible solutions to the problem of Mixed Content Blocking stalling HTTPS deployment

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 :)


Received on Thursday, 5 February 2015 22:54:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC