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

There's no coupling between HSTS and the particular algorithm a UA
uses to verify certificates.  The UA is free to use whatever
verification mechanism it desires.  You can remove whatever CAs you
consider sloppy from the list of trusted certificate authorities and
add in whatever other verification mechanism you like.

For example, if/when certificate verification through DNSSEC becomes
widespread, we won't need to change anything about the HSTS spec.  Of
course, we'll need to change our implementations, but that's true
regardless of what the HSTS spec says.

Adam

On Tue, Mar 29, 2011 at 12:22 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> (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
>
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>
>