Re: [UPGRADE] Consider plan B for reduced complexity?

On Fri 2015-03-06 10:11:29 -0800, Daniel Kahn Gillmor wrote:
> Here's a strawman:
>
>  * create a new HTTP Response header, HSTS2.  HSTS2: has the same
>    semantics as Strict-Transport-Security:, except that it should only
>    be implemented by clients that do opportunistic upgrade of blockable
>    mixed content (that is, they try a secure upgrade for subresources
>    instead of blocking insecure content).
>
> New clients can do opportunistic upgrade of blockable mixed content on
> any secure connection.  Server operators can choose to opt into either
> Strict-Transport-Security: or HSTS2:, depending on whether their sites
> require this upgrade of blockable mixed content to work securely.

To be clear about the advantages i think this has over the current
MIX+UPGRADE proposal:

 * avoid having to keep legacy headers around forever

 * origin operators can set HSTS headers unconditionally

 * HSTS2 header is shorter (fewer bytes is a minor efficiency
   optimization)
 
 * large number of broken sites can get fixed without the operator
   learning and deploying CSP
 
 * navigational upgrade can be handled for subdomains or not at the
   server operator discretion by choosing whether to set
   "includeSubdomains" in the HSTS2: header.

 * Client implementations can be simplified because there is no need to
   decide whether to send Prefer or not.


(one issue i noticed with the strawman is a weird inconsstency issue in
case servers send both Strict-Transport-Security and HSTS2 headers.
this is pretty easily resolved, though: if both headers appear in a
response with different parameters, clients that do opportunistic
upgrade of blockable mixed-content should ignore the parameters for
Strict-Transport-Security).

        --dkg

Received on Sunday, 8 March 2015 21:52:21 UTC