[UPGRADE] Consider plan B for reduced complexity?

Hi webappsec--

pde and I were looking at UPGRADE today, and (as noted in pull request
#209) noticed that Prefer: return=secure-representation is going to need
to be sent for all navigational requests if we want to make HSTS
conditional on this behavior.

This also makes HSTS itself contingent on the browser in use, which
means that services which scan for HSTS headers and compile them into
lists for client use will be more complex.

In light of this complexity maybe we should consider a plan B, which
should accomplish the same goals while needing less network traffic and
better encouraging HTTPS and HSTS adoption.

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.

    --dkg

Received on Friday, 6 March 2015 18:11:54 UTC