Re: [websec] handling STS header field extendability

Paul Hoffman <> Mon, 13 August 2012 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5783A11E8087 for <>; Mon, 13 Aug 2012 14:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B6uXOcJbYJdR for <>; Mon, 13 Aug 2012 14:29:04 -0700 (PDT)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id BD7B111E8072 for <>; Mon, 13 Aug 2012 14:29:04 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id q7DLT3AM051862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 14:29:03 -0700 (MST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <>
In-Reply-To: <>
Date: Mon, 13 Aug 2012 14:29:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: "Hill, Brad" <>
X-Mailer: Apple Mail (2.1278)
Cc: IETF WebSec WG <>, Ben Campbell <>
Subject: Re: [websec] handling STS header field extendability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Aug 2012 21:29:05 -0000

On Aug 13, 2012, at 2:20 PM, Hill, Brad wrote:

> I have an EV certificate for  On the main page, it includes the following tag:
> <script src="">
> Mallory is presumably much more likely to be able to obtain a DV certificate for than an EV cert for  But Mallory can still use the DV certificate to attack the EV content at by MITMing the fetch of myscript.js, which will be transcluded into the DOM.  

If the security model is that and 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 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 "" using the DV certificate is the same origin as my "" using the EV one.

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 currently exists between HTTPS and HTTP.

...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 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.

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

--Paul Hoffman