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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 29 Mar 2011 15:22:35 -0400

(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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Mar 2011 21:57:53 +0200

My thoughts are that this is the third usecase that has been brought to the list for forcing TLS without enforcing stricter certificate validation.

The group rejected the two previous cases, because they're focused on the big web site use-case, which requires both.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Daniel Kahn Gillmor [[email-masked]]
Sent: Tuesday, March 29, 2011 21:22
To: [email-masked]
Subject: Re: [websec] Decouple HSTS's two orthogonal effects?

; defined STS directives

would become

; defined STS directives

Any thoughts?

        --dkg

Scanned by Check Point Total Security Gateway.

---

From: Adam Barth <[email-masked]>
Date: Tue, 29 Mar 2011 13:58:08 -0700

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
<[email-masked]> wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>
>

---

From: Tom Ritter <[email-masked]>
Date: Tue, 29 Mar 2011 17:29:46 -0400

On Tue, Mar 29, 2011 at 4:58 PM, Adam Barth <[email-masked]> wrote:
> verification mechanism it desires.

This is good, but perhaps some clarification to the draft would be in order:

Section 2.2 states:

   2.  The UA terminates, without user recourse, any secure transport
       connection attempts upon any and all secure transport errors or
       warnings, including those caused by a site presenting self-signed
       certificates

Knowing that HSTS allows any validation method a posteriori allows you
interpret this correctly - that self-signed certs *may* be allowed
under HSTS, if the user has added them to their store.  But without
that, it may be interpretted incorrectly - that no self-signed certs
would be allowed.  Furthermore, I'm not sure, but "any and all secure
transport errors or warnings" may be ambiguous.  I don't know if it's
an existing standard to enter a warning or error state in event of
(for example) a revocation check failure - although we do know that
most browsers do not present any warning or error.  There's more on
that in Adam Langley's thread.   If HSTS does not define whether or
not a revocation check failure is an error condition, I think it
should.

Also Section 9 recommends distributing root CA certs to users'
browsers, and does not mention the possibly of distributing the leaf
certs instead.  Less related, but I prefer to trust organizations leaf
certs individually than their root cert.

-tom

---

From: Adam Barth <[email-masked]>
Date: Tue, 29 Mar 2011 14:35:58 -0700

>       warnings, including those caused by a site presenting self-signed

If a self-signed certificate does not cause a secure transport error,
then you're all set.  For example, it's fine for a self-signed
certificate to be in the list of explicitly trusted certificates.  In
that case, no secure transport error is generated.  Try it.  :)

> would be allowed.

That's not what it says.

> Furthermore, I'm not sure, but "any and all secure

Indeed.  A reference there would be helpful.

> certs individually than their root cert.

I don't have a problem with also recommending leaf certs, but you
should check with =JeffH.

Adam

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 29 Mar 2011 18:25:25 -0400

> regardless of what the HSTS spec says.

I hear what you're saying; however, i'm unaware of any HSTS-compliant
User Agent that implements anything but the standard weakest-link X.509
certificate pool of trusted authorities.

Perhaps an explicit mention that says HSTS is not intended to be
incompatible with alternative certificate verification mechanisms would
provide useful guidance to browser vendors?

	--dkg

---

From: Adam Barth <[email-masked]>
Date: Tue, 29 Mar 2011 15:39:46 -0700

> provide useful guidance to browser vendors?

I don't think we need that guidance, but thanks.

Adam