Re: [websec] handling STS header field extendability

"Hill, Brad" <> Mon, 13 August 2012 17:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D928121F8736 for <>; Mon, 13 Aug 2012 10:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.117
X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ka4DHS3fJdCO for <>; Mon, 13 Aug 2012 10:59:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1099A21F8717 for <>; Mon, 13 Aug 2012 10:59:01 -0700 (PDT)
DomainKey-Signature: s=ppinc;; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=sTEdi0cVyQ+bO6kvBWyP3Kwqqts9zgjFnuYQhNvOMC69d2cPbS+3m+tI Bk4BTxxuwvruXn+NOKQJjjiY3KNPzYXlTTHSgEzrI/OkpswHvvvC6vmzi 3CSXNxR5DTlIKbY;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=ppinc; t=1344880742; x=1376416742; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8eWfkggcPI7YYhNmnGVJWRBAXS9Sb/glfyH8pSt691I=; b=ix8ktrnUHczzjVVRSggBgZBRxBtbtxFg6RXvACsQlRmavqky7JtqgBuo C6Q7B/hunEyiPSdjFbT98oFT4gXBIKX7RyH6N/mbceUR9e5pTyuZm5Sds fBwNp167ZSezjBa;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.77,761,1336374000"; d="scan'208";a="9625515"
Received: from (HELO ([]) by with ESMTP; 13 Aug 2012 10:58:59 -0700
Received: from ([fe80::40c1:9cf7:d21e:46c]) by ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 11:58:54 -0600
From: "Hill, Brad" <>
To: Tom Ritter <>, Chris Palmer <>
Thread-Topic: [websec] handling STS header field extendability
Thread-Index: AQHNdnu9G2/cgF2QOE2DrHCPRwkn4JdT/HaAgAEaOQCAAvRWEA==
Date: Mon, 13 Aug 2012 17:58:53 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: Va++kfOLVR9lLOzqohWklg==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: Ben Campbell <>, IETF WebSec WG <>
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 17:59:03 -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: [] 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
> On 10 August 2012 17:52, Chris Palmer <> wrote:
> > 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.
> 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