Re: [websec] Decouple HSTS's two orthogonal effects?

[Daniel Kahn Gillmor <[e-mail]>]

(sorry for breaking the thread -- i'm only recently subscribed, and i
don't see a way to extract the message-id from the archives:
https://www.ietf.org/mail-archive/web/websec/current/msg00282.html
so i can't add a References: header)

FWIW, the coupling of the two orthogonal requirements for HSTS has the
effect of further entrenching the current (broken) CA model by making it
more difficult for alternate certificate verification models (e.g. TOFU,
corroborative certification, etc) to work with HSTS-enabled sites.

For example, the monkeysphere project (i'm a contributor to it) is now
seeing difficulty providing alternate certificate verification on
HSTS-enabled sites:

 https://labs.riseup.net/code/issues/2852

As a monkeysphere developer, as someone interested in security on the
'net, and as someone critical of the social/economic dynamics of the
current CA cartel, i think that the tight coupling of the two orthogonal
effects within HSTS has an overall negative effect.

Concretely, it makes it *more* difficult for security-conscious users to
remove known-sloppy CAs from their trusted-root lists, whether they
choose to rely on a TOFU approach, Perspectives-style notaries,
corroborative certification via OpenPGP, etc.

HSTS can do a lot of good just by fixing the trivial protocol-downgrade
(HTTPS->HTTP, e.g. sslstrip, cookie-stealing via spoofed plaintext img
src, etc) attack for sites that indicate it.

By forcing websites to also buy into (and thereby support) the CA
cartel, we're asking site operators to decide on a tradeoff between (a)
losing protection against protocol downgrade and (b) encouraging their
users to rely on a known-insecure cartel.

I think this is a poor tradeoff, and would like to see these choices
de-coupled.

If there is no consensus about de-coupling the effects in HSTS directly,
I'd like to propose an additional STS directive:

; defined STS directives
STS-d-cur  = maxAge / includeSubDomains

would become

; defined STS directives
STS-d-cur  = maxAge / includeSubDomains / alternateCertModels

The presence of the alternateCertModels directive would allow User
Agents to validate the certificate via other means than the traditional
(vulnerable) X.509 chaining to the
weakest-link-of-the-huge-pile-of-root-CAs (e.g. via existing user-driven
certificate exceptions or browser extensions relying on the same mechanism).

Any thoughts?


	--dkg