IETF Logo Mail Archive

Re: [websec] handling STS header field extendability

"Hill, Brad" <bhill@paypal-inc.com> Mon, 13 August 2012 17:59 UTC

Return-Path: <bhill@paypal-inc.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D928121F8736 for <websec@ietfa.amsl.com>; Mon, 13 Aug 2012 10:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.117
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka4DHS3fJdCO for <websec@ietfa.amsl.com>; Mon, 13 Aug 2012 10:59:02 -0700 (PDT)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 1099A21F8717 for <websec@ietf.org>; Mon, 13 Aug 2012 10:59:01 -0700 (PDT)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; 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; d=paypal-inc.com; i=bhill@paypal-inc.com; 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 den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-006.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 13 Aug 2012 10:58:59 -0700
Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-006.corp.ebay.com ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 11:58:54 -0600
From: "Hill, Brad" <bhill@paypal-inc.com>
To: Tom Ritter <tom@ritter.vg>, Chris Palmer <palmer@google.com>
Thread-Topic: [websec] handling STS header field extendability
Thread-Index: AQHNdnu9G2/cgF2QOE2DrHCPRwkn4JdT/HaAgAEaOQCAAvRWEA==
Date: Mon, 13 Aug 2012 17:58:53 +0000
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com>
References: <5024352D.4040604@KingsMountain.com> <CAOuvq23dxoKyV2No55WEYePhVj+Fcab5cF65C1FsiqgtmEkXMA@mail.gmail.com> <CA+cU71kx4Ck2aMeSHhnpb--aZ+mRmszQdojepM4aapVn2TsR=Q@mail.gmail.com>
In-Reply-To: <CA+cU71kx4Ck2aMeSHhnpb--aZ+mRmszQdojepM4aapVn2TsR=Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.245.27.242]
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 <ben@nostrum.com>, IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] handling STS header field extendability
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=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: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] 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 <palmer@google.com> 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
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec

v2.23.0 | Report a Bug | By Email