Subject: [websec] handling STS header field extendability

From: =JeffH <[email-masked]>
Date: Thu, 09 Aug 2012 15:09:49 -0700

Hi, here's a write-up on the background of, and proposed resolution to the 
question of handling STS header field extendability more properly in the spec.

I also pose the question of which IANA policy to declare, down at the very end.

thanks,

=JeffH

Background:
----------

We've defined the Strict-Transport-Security (STS) header field like so..

      Strict-Transport-Security = "Strict-Transport-Security" ":"
                                  [ directive ]  *( ";" [ directive ] )

      directive                 = directive-name [ "=" directive-value ]
      directive-name            = token
      directive-value           = token | quoted-string

..such that the definition of new directives is open-ended, i.e., the STS header
field is extendable.

draft-ietf-websec-strict-transport-sec-11 presently states at the end of section 
6.1..

    Additional directives extending the semantic functionality of the STS
    header field can be defined in other specifications, with a registry
    defined for them at such time.

The only extensions we'd discussed in the past were the CertPinning, LockCA,
LockEV.  We've decided that cert pinning is an intersecting but orthogonal
policy to HSTS, and thus best handled at this point via a separate header field.
Also, the various LockFoo notions should be addressed in a cert pinning policy
context (i mentioned this in the WG session at IETF-82 Taipei).

Thus we don't have any presently anticipated extensions for the STS header field.

However, I don't believe we wish to change the (implicitly extensible) maner in 
which the ABNF is specified, nor necessarily close the door to defining some 
extension if we happen to come up with an appropriate need.

The IETF-84 Vancouver, WebSec WG meeting minutes [1] state on this topic..

   The group then discussed the registry management, particularly around
   “mandatory to understand” extensions. The sense of the room was that the
   group did not want to create mandatory to understand extensions ever. If
   such extensions are needed, they will need a new header. Where the draft
   says other specifications can update this one, say that any necessary
   registries may be created when such an update comes around.

Note that -11 already states that a registry should be created at that time. Ben 
indicated in his review that it isn't sufficient in his view (below).

Ben replied directly to me regarding the meeting minutes...
 >
 > I think we may be conflating two mostly orthangonal comments:
 >
(a)
 > -- If the working group doesn't expect "mandatory to understand" extensions,
 > then I'm fine with it, other than thinking it might be worth noting that any
 > such extensions must be safe to ignore.
 >
(b)
 > -- My questions about a registry don't depend on the mandatory to understand.
 > I'm skeptical of any draft that says "you can extend this, but we will leave
 > the creation of a registry until someone actually does it." In particular,
 > this defers making decisions about the documentation policy for extensions
 > (rfc5226 section 4.1), which is rarely a good idea. The only situation where
 > it seems to make sense to defer the registry would be if you really didn't
 > expect any extensions--in which case the draft probably shouldn't mention
 > extending it.
 >
 > That all being said, please keep in mind that I, as a gen-art reviewer, am
 > only offering my opinion like anyone else. It's up to the work group and the
 > ADs to decide if they agree with me or not. So it's okay to say "We disagree
 > with Ben here, and choose to leave it as is".

Proposed Resolution:
-------------------

For (a)

The spec already notes that UAs must ignore unrecognized directives. in any case 
I've composed a note regarding furture-defined directives being ignored by 
(legacy) UAs.

For (b)

Alter the spec text to include a reference of the required IANA Policy for any 
defined registry.

NOTE: we need to decide the type of IANA Policy (more below)

The spec text I now have in my -12 working copy at the end of section 6.1 is..

    Additional directives extending the semantic functionality of the STS
    header field can be defined in other specifications, with a registry
    (having an IANA policy definition of FOO [RFC5226]) defined for them
    at such time.

    NOTE:  Such future directives will be ignored by UAs implementing
           only this specification, as well as by generally non-
           conforming UAs.  See Section 14.1 "Non-Conformant User Agent
           Implications" for further discussion.

We need to decide what IANA policy definition [RFC5226] we wish to declare for 
FOO in the above text.

Since HSTS is a security policy, I lean towards wanting to have relatively 
rigorous review applied to any registry and its contents created for HSTS 
directives and thus am thinking a policy of "IETF Review" is what we ought to 
state here.

thoughts?

[1] https://www.ietf.org/proceedings/84/minutes/minutes-84-websec

---
end

---

From: Chris Palmer <[email-masked]>
Date: Fri, 10 Aug 2012 14:52:23 -0700

> context (i mentioned this in the WG session at IETF-82 Taipei).

Please forgive my ignorance, but do LockCA and/or LockEV offer any
functionality that you can't already get with public key pinning as
currently specified? You can pin to a given CA's public key(s), and
you can pin to any given EV issuers' public keys.

---

From: Tom Ritter <[email-masked]>
Date: Sat, 11 Aug 2012 10:42:30 -0400

> you can pin to any given EV issuers' public keys.

I can't think of one for Lock CA; but LockEV could be useful for sites
that want to deploy some additional measure, but can't/don't want to
a) commit to a CA or b) enumerate all possible EV authorities.  It
should be ('should be', not 'is') more difficult to get a fraudulent
EV certificate through trickery or treachery than a DV certificate.

I don't think browsers differentiate between OV and DV in any
meaningful way, but I could be wrong.

-tom

---

From: "Hill, Brad" <[email-masked]>
Date: Mon, 13 Aug 2012 17:58:53 +0000

There are, of course, non-browser HTTP clients that may respect HSTS, but EV certificates in particular are aimed at a browser audience as it is about user trust indicators.

EV is *not* a security boundary in browsers, however.  It is a brand awareness and consumer trust product. 

I am not aware of any user agents that treat EV and non-EV content as having different effective security principals for purposes of the Same Origin Policy.  So, although it is more difficult to get an EV certificate than a DV one, that does not provide any effective security against a MITM attacker who can obtain a DV certificate.  Such an attacker can always act as a partial MITM and provide, using a DV certificate, trojan script content in an iframe with no security indicators or substitute an external script in a legitimate page and that script will have full access to content delivered with an EV certificate.

I would posit that means a feature like LockEV has little to no practical value unless and until (not likely) Web user agents provide origin isolation between EV and non-EV content.

-Brad Hill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tom Ritter
> Sent: Saturday, August 11, 2012 7:43 AM
> To: Chris Palmer
> Cc: Ben Campbell; IETF WebSec WG
> Subject: Re: [websec] handling STS header field extendability
> 
> I can't think of one for Lock CA; but LockEV could be useful for sites that want
> to deploy some additional measure, but can't/don't want to
> a) commit to a CA or b) enumerate all possible EV authorities.  It should be
> ('should be', not 'is') more difficult to get a fraudulent EV certificate through
> trickery or treachery than a DV certificate.
> 
> I don't think browsers differentiate between OV and DV in any meaningful
> way, but I could be wrong.
> 
> -tom
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Collin Jackson <[email-masked]>
Date: Mon, 13 Aug 2012 12:21:37 -0700

> I would posit that means a feature like LockEV has little to no practical value unless and until (not likely) Web user agents provide origin isolation between EV and non-EV content.

Quite the opposite, you just made the argument in favor of LockEV. If
LockEV is being used, the MITM attack with a DV certificate would no
longer be possible, because the DV certificate would not be accepted
by the browser.

Collin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Aug 2012 14:00:37 -0700

> longer be possible, because the DV certificate would not be accepted

In what case is that attack useful? The public key would still be the one that the site thought they had an EV cert for.

Confused...

--Paul Hoffman

---

From: Collin Jackson <[email-masked]>
Date: Mon, 13 Aug 2012 14:09:05 -0700

I don't understand your question, but I'll attempt to rephrase my comment.

Brad was describing a network attacker that was able to obtain a DV
certificate (but not an EV certificate) for a target site. The
attacker can "act as a partial MITM and provide, using a DV
certificate, trojan script content in an iframe with no security
indicators or substitute an external script in a legitimate page and
that script will have full access to content delivered with an EV
certificate." This would allow, for example, the attacker to read
cookies and passwords entered into a bank's login form.

My point is that if the site is using LockEV, the network attacker's
DV certificate is useless, so LockEV is useful even if the browser's
script access checks don't pay attention to the EV/DV distinction.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Aug 2012 14:17:43 -0700

> script access checks don't pay attention to the EV/DV distinction.

If the site did LockEV without ever locking its public key or CA, you would be right. That seems like a ridiculous policy, though. LockCA seems much more likely.

--Paul Hoffman

---

From: "Hill, Brad" <[email-masked]>
Date: Mon, 13 Aug 2012 21:20:20 +0000

I have an EV certificate for www.example.com.  On the main page, it includes the following tag:

 <script src="https://scripts.example.com/myscript.js">

Mallory is presumably much more likely to be able to obtain a DV certificate for scripts.example.com than an EV cert for www.example.com.  But Mallory can still use the DV certificate to attack the EV content at www.example.com by MITMing the fetch of myscript.js, which will be transcluded into the DOM.  

Or alternately, assume that Mallory gets a DV certificate for www.example.com which is different (and has a different key pair) from my legitimate EV certificate.  Mallory can still MITM content loaded in some frame other than the one displaying the EV indicator and gain control of that content because her "www.example.com" using the DV certificate is the same origin as my "www.example.com" using the EV one.

So, Collin is right that perhaps I'm making the case *for* LockEV, but as my first example shows, it would have to include a full-fledged mixed-content distinction between EV and non-EV, as currently exists between HTTPS and HTTP.

When you start to consider more modern technologies for intercommunication between multiple instances of client-side apps with things like postMessage, webRTC, etc. I wonder if you wouldn't need a full-fledged origin distinction on EV/non-EV, as we do today on protocol, to create a strong barrier, and if it is worth it and there is any appetite among browser vendors for such a thing.

-Brad

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Monday, August 13, 2012 2:01 PM
> To: Collin Jackson
> Cc: Hill, Brad; Ben Campbell; IETF WebSec WG
> >> There are, of course, non-browser HTTP clients that may respect HSTS, but
> EV certificates in particular are aimed at a browser audience as it is about
> user trust indicators.
> >>
> >> I am not aware of any user agents that treat EV and non-EV content as
> having different effective security principals for purposes of the Same Origin
> Policy.  So, although it is more difficult to get an EV certificate than a DV one,
> that does not provide any effective security against a MITM attacker who can
> obtain a DV certificate.  Such an attacker can always act as a partial MITM and
> provide, using a DV certificate, trojan script content in an iframe with no
> security indicators or substitute an external script in a legitimate page and
> that script will have full access to content delivered with an EV certificate.
> >>
> >> I would posit that means a feature like LockEV has little to no practical
> value unless and until (not likely) Web user agents provide origin isolation
> between EV and non-EV content.
> >
> In what case is that attack useful? The public key would still be the one that
> the site thought they had an EV cert for.
> 
> Confused...
> 
> --Paul Hoffman

---

From: Chris Palmer <[email-masked]>
Date: Mon, 13 Aug 2012 14:22:30 -0700

> longer be possible, because the DV certificate would not be accepted

Not to intentionally pick on PayPal — sorry, Brad :) — but the attack
works because of explicit cross-origin script inclusion. The first
demo of this attack I saw was by Sotirov and Zusman at CanSecWest some
years ago. In the attack demo, EV paypal.com includes (included)
script from non-EV paypalobjects.com. If you distinguish EV paypal.com
and non-EV paypal.com as distinct origins, it doesn't help anything if
either origin explicitly includes script from any other origin (of any
security level).

Now, maybe you mean that we would treat EV and non-EV HTTPS mixed
scripting content as a new kind of mixed scripting problem, and then
have a rule of blocking mixed EV/non-EV scripting by default. We
recently changed Chrome to block mixed HTTP/HTTPS mixed scripting by
default, and that was "exciting" enough. Maybe someday we can block or
warn about mixed EV/non-EV content, but not in the next release,
probably...

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Aug 2012 14:29:03 -0700

> Mallory is presumably much more likely to be able to obtain a DV certificate for scripts.example.com than an EV cert for www.example.com.  But Mallory can still use the DV certificate to attack the…

If the security model is that www.example.com and scripts.example.com have the same security properties, then you are right. I don't see that in HSTS, but I could be missing something.

> Or alternately, assume that Mallory gets a DV certificate for www.example.com which is different (and has a different key pair) from my legitimate EV certificate.  Mallory can still MITM content lo…

Again: instead of "LockEV", wouldn't a much saner security policy be "LockKey"?

> So, Collin is right that perhaps I'm making the case *for* LockEV, but as my first example shows, it would have to include a full-fledged mixed-content distinction between EV and non-EV, as current…

...which seems like a bad idea whose only value is to sell EV certs.

> When you start to consider more modern technologies for intercommunication between multiple instances of client-side apps with things like postMessage, webRTC, etc. I wonder if you wouldn't need a…

Why not just use full-fledged origin non-distiction? What value does "EV" bring here?

--Paul Hoffman

---

From: "Hill, Brad" <[email-masked]>
Date: Mon, 13 Aug 2012 21:31:11 +0000

tl;dr version:

EV is not a security boundary today in web user agents, it is a way to get a user interface decoration.

If we want to ask browser vendors to make it into a security boundary which they will defend, we need to think about a fairly complex and broad threat model.

I'm not convinced that:

a) it's worth doing LockEV unless it's going to be a real security barrier
b) the complexity introduced in making it a real security barrier is worth it for such a rare attack

-Brad

> From: Hill, Brad
> Sent: Monday, August 13, 2012 2:20 PM
> To: 'Paul Hoffman'; Collin Jackson
> Subject: RE: [websec] handling STS header field extendability
> 
> Mallory is presumably much more likely to be able to obtain a DV certificate
> for scripts.example.com than an EV cert for www.example.com.  But Mallory
> can still use the DV certificate to attack the EV content at www.example.com
> by MITMing the fetch of myscript.js, which will be transcluded into the DOM.
> 
> Or alternately, assume that Mallory gets a DV certificate for
> www.example.com which is different (and has a different key pair) from my
> legitimate EV certificate.  Mallory can still MITM content loaded in some
> frame other than the one displaying the EV indicator and gain control of that
> content because her "www.example.com" using the DV certificate is the same
> origin as my "www.example.com" using the EV one.
> 
> So, Collin is right that perhaps I'm making the case *for* LockEV, but as my
> first example shows, it would have to include a full-fledged mixed-content
> distinction between EV and non-EV, as currently exists between HTTPS and
> HTTP.
> 
> When you start to consider more modern technologies for
> intercommunication between multiple instances of client-side apps with
> things like postMessage, webRTC, etc. I wonder if you wouldn't need a full-
> fledged origin distinction on EV/non-EV, as we do today on protocol, to create
> a strong barrier, and if it is worth it and there is any appetite among browser
> vendors for such a thing.
> 
> -Brad
> 
> > EV certificates in particular are aimed at a browser audience as it is
> > about user trust indicators.
> > >>
> > >> EV is *not* a security boundary in browsers, however.  It is a
> > >> brand
> > awareness and consumer trust product.
> > >>
> > having different effective security principals for purposes of the
> > Same Origin Policy.  So, although it is more difficult to get an EV
> > certificate than a DV one, that does not provide any effective
> > security against a MITM attacker who can obtain a DV certificate.
> > Such an attacker can always act as a partial MITM and provide, using a
> > DV certificate, trojan script content in an iframe with no security
> > indicators or substitute an external script in a legitimate page and that
> script will have full access to content delivered with an EV certificate.
> > >>
> > value unless and until (not likely) Web user agents provide origin
> > isolation between EV and non-EV content.
> > >
> > > Quite the opposite, you just made the argument in favor of LockEV.
> > > If LockEV is being used, the MITM attack with a DV certificate would
> > > no longer be possible, because the DV certificate would not be
> > > accepted by the browser.
> >
> > In what case is that attack useful? The public key would still be the
> > one that the site thought they had an EV cert for.
> >
> > Confused...
> >
> > --Paul Hoffman

---

From: "Hill, Brad" <[email-masked]>
Date: Mon, 13 Aug 2012 21:40:53 +0000

> Not to intentionally pick on PayPal — sorry, Brad :) — but the attack works
> because of explicit cross-origin script inclusion. The first demo of this attack I
> saw was by Sotirov and Zusman at CanSecWest some years ago. In the attack
> demo, EV paypal.com includes (included) script from non-EV
> paypalobjects.com. If you distinguish EV paypal.com and non-EV paypal.com
> as distinct origins, it doesn't help anything if either origin explicitly includes
> script from any other origin (of any security level).

[Hill, Brad] No apology needed.  https://www.paypalobjects.com/ is using an EV certificate now, BTW, but I'm quite sure if you looked you could find non-EV content that's being transcluded somewhere. (though hopefully not script src)  

I think that's important to consider about LockEV - PayPal is one of the sites most ready for and most pervasively EV, and it would not be prepared today to have a mixed-content policy enforced for EV/DV.  It would take a lot of work and a great deal of expense to achieve this, and not just for PayPal.  Consider how many sites use off-origin analytics, ads, CDNs, etc.  

The CDN cost also goes way up because EV certificates cannot include multiple logical subjects and XP, Android 2.x and other legacy OSs still prevent SNI from being widely used, so you need to pay for an exclusive IP address from the CDN, in addition to the cost of the EV cert itself.

Mixed-content blocking could very conceivably decrease the usage of EV certs dramatically.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Aug 2012 15:09:47 -0700

> b) the complexity introduced in making it a real security barrier is worth it for such a rare attack

+1 to all that.

--Paul Hoffman

---

From: Collin Jackson <[email-masked]>
Date: Mon, 13 Aug 2012 16:20:55 -0700

> So, Collin is right that perhaps I'm making the case *for* LockEV, but as my first example shows, it would have to include a full-fledged mixed-content distinction between EV and non-EV, as current…

I don't agree that browsers would need to include a mixed content
distinction between EV and non EV. In fact, I think that would be a
bad idea to do so. You can still make an all-EV site and benefit from
LockEV. The attacker will not be able to MITM it without an EV
certificate.

> When you start to consider more modern technologies for intercommunication between multiple instances of client-side apps with things like postMessage, webRTC, etc. I wonder if you wouldn't need a…

As we wrote in our 2008 paper on finer-grained origins, I agree that
browsers should not include EV in the origin distinction. However,
LockEV would still be helpful to all-EV sites.

> Again: instead of "LockEV", wouldn't a much saner security policy be "LockKey"?

Sites might want to commit to serving everything over EV, but might
not want to commit to keeping the same key, or the same CA.

> I think that's important to consider about LockEV - PayPal is one of the sites most ready for and most pervasively EV, and it would not be prepared today to have a mixed-content policy enforced for…

We agree. I am opposed to using EV in the mixed content distinction.
However, LockEV still prevents MITM attacks using DV certificates
against all-EV sites.

> a) it's worth doing LockEV unless it's going to be a real security barrier

As long as a site isn't using DV certs for scripts, it's a real
security barrier.

> b) the complexity introduced in making it a real security barrier is worth it for such a rare attack

There is very little complexity introduced if you don't introduce the
mixed content distinction.

Collin

---

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Aug 2012 00:13:35 -0400

> currently specified?

 Folks, this thread has rather been hijacked.  We need to have some WG
input on what registration policy to recommend for a possible future STS
header field registry.  That's what this thread is for, and I need to see
some WG discussion about it in order that Jeff may finish the document and
that I may move it forward.

Please take discussion of LockCA and LockEV to another thread.

Thanks,
Barry

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Aug 2012 10:12:16 +0300

Right.

As a reminder, the proposed resolution is as follows:

 * Do not establish a registry now 
      Let the first new header field specification establish it

 * A client that gets an unknown field ignores it 
      This means no mandatory-to-understand extensions

At this stage, a +1 response is OK though not necessary (we got plenty of those in the room), but any disagreement should come with an explanation.

Thanks

Yoav

================================================================
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Tuesday, August 14, 2012 7:14 AM
To: IETF WebSec WG
Subject: Re: [websec] handling STS header field extendability

 Folks, this thread has rather been hijacked.  We need to have some WG input on what registration policy to recommend for a possible future STS header field registry.  That's what this thread is for, and I need to see some WG discussion about it in order that Jeff may finish the document and that I may move it forward.

Thanks,
Barry

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 14 Aug 2012 10:54:56 +0100

> At this stage, a +1 response is OK though not necessary (we got plenty of those in the room), but any disagreement should come with an explanation.

<hat="individual">
+1. ;-)

Ps.: and thanks to Yoav for framing the topic.