1) Data baked into the browser

2) Data pushed out to the browser in a signed format out of band

3) Data acquired by the browser from HTTP headers

4) Data ac= quired by the browser via DNS/DNSSEC

The first cle= arly does not scale but has huge leverage since ten domains represent the b= iggest targets on the net for certain typs of criminal behavior.

The second does not scale either but provides us with a= vital tool to use when responding to an actual in-progress attack.=A0

The third scales but only gives secure after first con= tact. It is difficult to see how far hardfail will be practical.

The fourth scales but is dependent on deployment of inf= rastructure and access to that infrastructure which means that it is going = to be some time before clients can hardfail if the data is not available.= =A0

Having the three mechanisms using a comm= on data format allows for an agile approach to response.

For example let us imagine that p= aymentgate.com is attacked and a bogus cert is issued.

paymentgate.com = has decided that it is a likely target for attack and has implemented and p= ublished a security policy through DNS records and published it with DNSSEC= .

paymentgate.com = is not however sufficiently prominent to be amongst 10 or so security polic= ies that are baked into browsers.

A client that has _reliable_ access to DNSSEC data will detect the bogus ce= rt and reject it. But that is only going to be effective if the browser can= hardfail if the DNSSEC data is not present. If Iran is performing a networ= k level MITM attack you can be certain that they will strip all DNSSEC data= the minute that any deployed clients start relying on it.=A0

So perversely DNSSEC only provides direct security for = the people who are not likely being attacked. :-(

= We can however get some DNSSEC data through using other channels and so it = is quite reasonable to expect that we can get a notification that the attac= k is in in progress by those clients reading the security policy data in th= e DNS and then making use of whatever reporting infrastructure we build int= o those clients.

However we have the option of using the = Langley/Kaminsky hack of pickling a chain of DNS data and putting it into a= nother signed object. For example a certificate or an OCSP token.

So when a report is received, the browser provider look= s at the taget(s) of the attack and can attempt to retrieve security policy= from the DNS. If there is a published policy they can decide to add=A0paymentgate.com to the list of data driv= en security policy they push out.

So in summary, I would like to address a= ll four delivery mechanisms as if they are merely different delivery mechan= isms for the same data types.

Despi= te that, I would like all three mechanisms to employ the=A0

On Tue, Sep 13, 2011 at 2:11 PM, Chris Palmer <palmer@google.com<= /a>> wrote:

Hi everybody,

Thanks for your comments and questions =97 good ones! I'll try to
address them in the XMLified draft that I'm working on now, and which I'll send out today.

_________________________________________= ______
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec

--
= Website: http://hallambaker.com/

--0016368e2058ad337804acd97dce-- From palmer@google.com Tue Sep 13 14:53:41 2011 Return-Path: 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 9632311E812A for ; Tue, 13 Sep 2011 14:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 qhNfNbEhE-xS for ; Tue, 13 Sep 2011 14:53:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D78D811E8129 for ; Tue, 13 Sep 2011 14:53:40 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p8DLtkET010647 for ; Tue, 13 Sep 2011 14:55:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315950947; bh=ZDI792jBLbL0xAh/cD85MYfWXlk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=sicBLpN/ONzSnZop6EWGq8t3Vp7PPt58RayausFo/9QJdvXv2QvoEuLvesMjmx2eW ISJQI1L+4zJtHkEAINHnQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=qDZ4QNn/M1FXw/nnQkx7kPJxaJio/z8uOThBk9rK8t2jS6vwkZIoiTFX57Bx7gS3r Mi06vA1T3tFOyBjxS745w== Received: from wwi18 (wwi18.prod.google.com [10.241.243.18]) by wpaz29.hot.corp.google.com with ESMTP id p8DLtWEd021479 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 13 Sep 2011 14:55:45 -0700 Received: by wwi18 with SMTP id 18so1254713wwi.3 for ; Tue, 13 Sep 2011 14:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0mUR8h/M0jbcymyPVv7iT2O6efj5YqvGQBYrU5UwU6Q=; b=yFjAnOQ3GUlhvXYv0Z0ZSNZjveh8uNuW0O37MisUkkP2DQbkmmfdZ4ee+o0OrmK1YN xRke/bwQoPxizbbJhq7w== Received: by 10.216.220.220 with SMTP id o70mr1174223wep.19.1315950940779; Tue, 13 Sep 2011 14:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.220.220 with SMTP id o70mr1174121wep.19.1315950932971; Tue, 13 Sep 2011 14:55:32 -0700 (PDT) Received: by 10.216.61.16 with HTTP; Tue, 13 Sep 2011 14:55:32 -0700 (PDT) In-Reply-To: <4E6F5056.800@fifthhorseman.net> References: <4E6F5056.800@fifthhorseman.net> Date: Tue, 13 Sep 2011 14:55:32 -0700 Message-ID: From: Chris Palmer To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Chris Evans Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org 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: Tue, 13 Sep 2011 21:53:41 -0000 On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor wrote: > From my perspective, i see no advantage to pinning any of the CAs -- if > your EE is compromised, you're sunk. =C2=A0And since the mechanism provid= es a > mechanism (and nice instructions, thanks) for transition to an emergency > offline backup EE key+cert, that is all handled well. In the case of normal EE certificate expiration =E2=80=94 as opposed to compromise =E2=80=94 if you are pinned to (say) an intermediary signer, you can just get a fresh certificate from the same signer, deploy it, and change nothing else. Conversely, if you had pinned to an EE, you'd need to follow a procedure something like this near expiration time: 0. Generate the new cert. 1. Change your pins directive to include the new and the old public key fingerprints. 2. Wait long enough for "most, surely?" of your users to have received the new pins, or for their pins to expire by the normal maxAge means. 3. Decommission the old EE cert and deploy the new. Maybe that sounds reasonably easy to you, and you just never want to pin to a signer's public key. That's ok. Our goal with the "you can pin to any public key(s) in your cert chain" idea was to maximize flexibility and enable a range of policies and practices, knowing that one size does not fit all but that all achieve the goal. You could, of course, also just re-use your old key pair and get it re-signed, and no need to migrate keys as well as certs. In that case, no problem. Again, that's fine and one size does not fit all. From palmer@google.com Tue Sep 13 15:00:12 2011 Return-Path: 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 2802A21F84FD for ; Tue, 13 Sep 2011 15:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 rQZ-iTchit16 for ; Tue, 13 Sep 2011 15:00:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 460A121F84FA for ; Tue, 13 Sep 2011 15:00:11 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p8DM2HsT016597 for ; Tue, 13 Sep 2011 15:02:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315951337; bh=M/1S0/wXdz+9EQ9A9fQWEQitlWs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=ftC8FjIIj6qTLlCgwI9nYqrElgCatYI1mxaXBykm0hvNlXqmoWrzgrHE1DMb9wtoG OUcp06n6hxhK/mkG6OdTA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:content-type: content-transfer-encoding:x-system-of-record; b=CwtFOi8utQWzMIWePZqFBqEU6jzIfaxurtwYAjCOiI3ilTubuZuy4XFKlexjbpCOg SewCBgeFv1uq9Ik2AxQ5Q== Received: from wwi36 (wwi36.prod.google.com [10.241.243.36]) by hpaq2.eem.corp.google.com with ESMTP id p8DM1rEv016136 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 13 Sep 2011 15:02:16 -0700 Received: by wwi36 with SMTP id 36so1066096wwi.14 for ; Tue, 13 Sep 2011 15:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=hSpwn3Gkfj8fUKBBBb48vqumQci8YbJMA/+9lotb+OI=; b=MjEKkOuY1Dy5MmRnzsEYIUkvqZfSZQI3Z9RM9RxZAho1AmBtKo9Lrp/QojX8PRFN+r DGpOm1IOYTMdGDQaKi3g== Received: by 10.216.209.223 with SMTP id s73mr1054194weo.34.1315951336739; Tue, 13 Sep 2011 15:02:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.209.223 with SMTP id s73mr1054187weo.34.1315951336594; Tue, 13 Sep 2011 15:02:16 -0700 (PDT) Received: by 10.216.61.16 with HTTP; Tue, 13 Sep 2011 15:02:16 -0700 (PDT) In-Reply-To: <4E6F62EE.2070409@cisco.com> References: <4E6F62EE.2070409@cisco.com> Date: Tue, 13 Sep 2011 15:02:16 -0700 Message-ID: From: Chris Palmer To: Philip Gladstone , websec@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org 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: Tue, 13 Sep 2011 22:00:12 -0000 On Tue, Sep 13, 2011 at 7:04 AM, Philip Gladstone wrot= e: [ snip questions about revocation =E2=80=94 I'm trying to think about and clarify that stuff next ] > Does this proposal also support self-signed certificates? I.e. if you > connect to a site, accept the self-signed certificate, can that site then > pin itself using that self-signed cert? I.e. can the validation of the ce= rt > chain stop as soon as there is a pin match? This specification is agnostic on that issue. If your client lets you accept self-signed certificates, then there's no reason it can't also note it as a Known Pinned HSTS Host pinned to your self--signed public key. From marsh@extendedsubset.com Tue Sep 13 15:28:17 2011 Return-Path: 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 88CA621F8CAE for ; Tue, 13 Sep 2011 15:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] 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 0EHV9BCW4RQO for ; Tue, 13 Sep 2011 15:28:12 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7136E21F8CA5 for ; Tue, 13 Sep 2011 15:28:07 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1R3bUa-000I9T-W3; Tue, 13 Sep 2011 22:30:13 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A13376067; Tue, 13 Sep 2011 22:30:11 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Z/9pm0yhs22lMX4VrPlT5s6dS7r4ZSfM= Message-ID: <4E6FD975.9010502@extendedsubset.com> Date: Tue, 13 Sep 2011 17:30:13 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: davidillsley@gmail.com References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im> <4E6FB7CB.3020309@extendedsubset.com> <6D3E0CA6-E990-4D89-9AEE-C03066D0656E@gmail.com> In-Reply-To: <6D3E0CA6-E990-4D89-9AEE-C03066D0656E@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] Certificate Pinning via HSTS (.txt version) X-BeenThere: websec@ietf.org 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: Tue, 13 Sep 2011 22:28:17 -0000 On 09/13/2011 04:24 PM, davidillsley@gmail.com wrote: > > On 13 Sep 2011, at 21:35, Chris Palmer wrote: >> >> sites; small sites may have to choose no pinning or potentially >> bricking their site (up to the maxAge window). This is not worse than >> the status quo.""" > > What about sites which don't currently use https at all? The DNS records > for theregister.co.uk were redirected the > other week. An attacker who could do that could redirect to https, then > set a very long max-age pin. At that point, they'd be dependent on the > browser vendor unpinning affected users, right? Wouldn't they have to acquire a valid cert first? Not saying that's out of the realm of possibility, but... I think you have a point. The whole premise of this is that there are circumstances under which some attacker can obtain such a cert. If this feature translates to a risk of perma-DoS for the (100.0 - epsilon)% of sites that don't adopt it immediately then it may be more dangerous than it's worth. Consider an adversarial country like, say, Bananastan. They have an ISP or three, their own CA, and of course, no sense of humor. They may one day be subject to some criticisms in the online press which they perceive as unfair. Or maybe something on a video sharing site is contrary to their customs and traditions. So their local judge orders their local ISP to block the offending media provider. The ISP does this by advertising more specific BGP routes for the video site's netblocks(1). Being mostly streaming data of little consequence, the video site has not yet set up HSTS or even has full support for HTTPS (2). The ISP also sets the country's DNS resolvers to reply to name requests for the site with an IP address of a webserver where citizens can receive educational information(3). To be sure they get everybody, they do something I didn't know could be done with DNS (4). In order to save the the misguided users that accidentally used a subversive https: bookmark, the court orders the local CA to "do what it takes to make it work"(5). And just to be sure the message sticks, they set a long term HSTS pin on this cert and/or their CA (6). Hilarity ensues. - Marsh 1. YouTube - Pakistan - 2008 http://www.circleid.com/posts/82258_pakistan_hijacks_youtube_closer_look http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study 2. http://youtube.com/ 3. http://web.archive.org/web/20060418030141/http://chinadigitaltimes.net/2006/01/image_of_internet_police_jingjing_and_chacha_online_hon.php 4. China - 2010 https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.html http://www.zdnet.co.uk/news/networking/2010/10/11/mystery-of-web-traffic-redirect-to-china-remains-unsolved-40090476/ 5. [...] 6. Why wouldn't this attack work? From hallam@gmail.com Tue Sep 13 15:32:37 2011 Return-Path: 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 AE00E21F8CAE for ; Tue, 13 Sep 2011 15:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 RrXFuQYXCKs9 for ; Tue, 13 Sep 2011 15:32:33 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5021F8C43 for ; Tue, 13 Sep 2011 15:32:27 -0700 (PDT) Received: by yie12 with SMTP id 12so1006407yie.31 for ; Tue, 13 Sep 2011 15:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4zI8xxXCrDLhaNly1AaErBOHVAHE3RvzfWCFVNFo7ow=; b=EYgCPSi3EmOjO515bOA4SP6fuDwPNqHoYH1DkoCn27oD0eifXu9cQfb9BywXRxzgX9 XBpSVR5BYnp7oaa0JjVbceXICroph+W4Dr4hv8INJX18wvPM3yY4Rm4s6IhQjJyT5rzN +84LtdWJLb4TGazE+BjvIh9dR+8j/DfeBZdWs= MIME-Version: 1.0 Received: by 10.101.11.36 with SMTP id o36mr5799472ani.74.1315953274824; Tue, 13 Sep 2011 15:34:34 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Tue, 13 Sep 2011 15:34:34 -0700 (PDT) In-Reply-To: <6D3E0CA6-E990-4D89-9AEE-C03066D0656E@gmail.com> References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im> <4E6FB7CB.3020309@extendedsubset.com> <6D3E0CA6-E990-4D89-9AEE-C03066D0656E@gmail.com> Date: Tue, 13 Sep 2011 18:34:34 -0400 Message-ID: From: Phillip Hallam-Baker To: davidillsley@gmail.com Content-Type: multipart/alternative; boundary=0016e68ef4577ca9cc04acda3f52 Cc: IETF WebSec WG Subject: Re: [websec] Certificate Pinning via HSTS (.txt version) X-BeenThere: websec@ietf.org 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: Tue, 13 Sep 2011 22:32:37 -0000 --0016e68ef4577ca9cc04acda3f52 Content-Type: text/plain; charset=ISO-8859-1 I think that all this pinning stuff works a lot better if there is a mechanism that allows a return to ground truth. Since we are developing an Internet protocol, the mechanism for ground truth should be DNS in my opinion. It may be impractical to require DNSSEC secured responses in every case. There are Denial of Communication issues (DoC) and there are real performance concerns. If however we are dealing with a case where an exception has occurred, it seems reasonable to me for the response to be to attempt to pull DNSSEC records via whatever guerilla mechanisms we end up deploying to bypass censorship. In other words, use pinning via HTTP header to provide pinning with minimal performance impact but solve the tricky max age issues by relying on the DNS and DNSSEC to provide ground truth when a policy violation is detected. On Tue, Sep 13, 2011 at 5:24 PM, wrote: > > On 13 Sep 2011, at 21:35, Chris Palmer wrote: > > > sites; small sites may have to choose no pinning or potentially > bricking their site (up to the maxAge window). This is not worse than > the status quo.""" > > > What about sites which don't currently use https at all? The DNS records > for theregister.co.uk were redirected the other week. An attacker who > could do that could redirect to https, then set a very long max-age pin. At > that point, they'd be dependent on the browser vendor unpinning affected > users, right? > David > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > -- Website: http://hallambaker.com/ --0016e68ef4577ca9cc04acda3f52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that all this pinning stuff works a lot better if there is a mechan= ism that allows a return to ground truth.

Since we are d= eveloping an Internet protocol, the mechanism for ground truth should be DN= S in my opinion.

It may be impractical to require DNSSEC = secured responses in every case. There are Denial of Communication issues (= DoC) and there are real performance concerns.=A0

If however we are dealing with a case where an exception has occurred, it s= eems reasonable to me for the response to be to attempt to pull DNSSEC reco= rds via whatever guerilla mechanisms we end up deploying to bypass censorsh= ip.

In other words, use pinning via HTTP header t= o provide pinning with minimal performance impact but solve the tricky max = age issues by relying on the DNS and DNSSEC to provide ground truth when a = policy violation is detected.

On Tue, Sep 13, 2011 at 5:24 PM, <davidillsley@gma= il.com> wrote:

On 13 Sep 2011, at 21:35,= Chris Palmer wrote:
<snip>
sites; small sites may have = to choose no pinning or potentially
bricking their site (up to the maxAge window). This is not worse than
th= e status quo."""

What= about sites which don't currently use https at all? The DNS records fo= r theregister.co.uk<= /a> were redirected the other week. An attacker who could do that could red= irect to https, then set a very long max-age pin. At that point, they'd= be dependent on the browser vendor unpinning affected users, right?

David

__________________________________= _____________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec

--
Website:= http://hallambaker.com/

--0016e68ef4577ca9cc04acda3f52-- From davidillsley@gmail.com Tue Sep 13 15:36:38 2011 Return-Path: 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 AE84E21F88B6 for ; Tue, 13 Sep 2011 15:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 JnmT4-WhNmLH for ; Tue, 13 Sep 2011 15:36:38 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F18E321F8888 for ; Tue, 13 Sep 2011 15:36:37 -0700 (PDT) Received: by wyg24 with SMTP id 24so1069095wyg.31 for ; Tue, 13 Sep 2011 15:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=UvrHXb7WOIw2+C+83ec3O2LP8TTNQ/Q8Accjsa9L2Ww=; b=QkHQbmfEbg02eMuhPVX2jDyTTXAz19htON1VdsXN4WxwTuoaCeNFVeceMpjO7Rm6m7 bCwYwtdK3ztEbvQXHJsh7QAPzrYkZKbiEcuXQvpFC/tEZp6TciVPy1Wi5VL7oJGzgg8G 1LuVu5BJwxWIkbMw4Mf+GDKzO0sq2xycO+7gg= Received: by 10.227.198.18 with SMTP id em18mr3259166wbb.25.1315953524699; Tue, 13 Sep 2011 15:38:44 -0700 (PDT) Received: from unknown-04-0c-ce-d5-9a-fe.config (87-194-130-80.bethere.co.uk. [87.194.130.80]) by mx.google.com with ESMTPS id ek13sm1996577wbb.23.2011.09.13.15.38.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Sep 2011 15:38:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_8E6319D2-5828-4CB4-B8D7-64EE8FDCE03C" From: davidillsley@gmail.com In-Reply-To: <4E6FD975.9010502@extendedsubset.com> Date: Tue, 13 Sep 2011 23:38:41 +0100 Message-Id: References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im> <4E6FB7CB.3020309@extendedsubset.com> <6D3E0CA6-E990-4D89-9AEE-C03066D0656E@gmail.com> <4E6FD975.9010502@extendedsubset.com> To: Marsh Ray X-Mailer: Apple Mail (2.1244.3) Cc: IETF WebSec WG Subject: Re: [websec] Certificate Pinning via HSTS (.txt version) X-BeenThere: websec@ietf.org 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: Tue, 13 Sep 2011 22:36:38 -0000 --Apple-Mail=_8E6319D2-5828-4CB4-B8D7-64EE8FDCE03C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 13 Sep 2011, at 23:30, Marsh Ray wrote: > > Wouldn't they have to acquire a valid cert first? Not saying that's = out of the realm of possibility, but... Yeah, but in the case that you've gained control of a domains DNS, which = is what happened, how hard would it be to get a valid DV cert?= --Apple-Mail=_8E6319D2-5828-4CB4-B8D7-64EE8FDCE03C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

On 13 Sep 2011, at 23:30, Marsh Ray wrote:

<snip>
Wouldn't they have to acquire a valid cert first? Not saying that's out of the realm of possibility, but...

Yeah, but in the case that you've gained control of a domains DNS, which is what happened, how hard would it be to get a valid DV cert?

--Apple-Mail=_8E6319D2-5828-4CB4-B8D7-64EE8FDCE03C-- From tobias.gondrom@gondrom.org Tue Sep 13 15:52:10 2011 Return-Path: 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 98C7611E809F for ; Tue, 13 Sep 2011 15:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.366 X-Spam-Level: X-Spam-Status: No, score=-96.366 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 9Pe84no8hm7E for ; Tue, 13 Sep 2011 15:52:06 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2D80D11E809D for ; Tue, 13 Sep 2011 15:52:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=CIMEnZK8elkKjsQntL9V7/qk5f+0t/jvtCv2mxxHEORzi3UIF7WU1dH4k29hiQ2F2FUyAryT19ogverhajDY+8y/vaKz7fA+ToF4x2YJfqT2wW4hE0wLcVnUoOrkada/; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:Content-Type; Received: (qmail 28056 invoked from network); 14 Sep 2011 00:53:05 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.66?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Sep 2011 00:53:05 +0200 Message-ID: <4E6FDED1.9000209@gondrom.org> Date: Tue, 13 Sep 2011 23:53:05 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 2 (High) Content-Type: multipart/alternative; boundary="------------000707030300090301000907" Subject: [websec] websec meeting in Taipei - topics? X-BeenThere: websec@ietf.org 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: Tue, 13 Sep 2011 22:52:10 -0000 This is a multi-part message in MIME format. --------------000707030300090301000907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello dear websec fellows, to decide on a slot and length for our meeting in November in Taipei, this time we would like to start a bit earlier asking for presentations, topics and ideas. Please send proposals and ideas for presentations to Alexey, Yoav and/or me, if possible until Sep-25 so we can better decide on the length of the meeting slot, but later will also be ok. Rough ideas are fine at this stage, anything that will help us in planning the length and scope of the meeting. So far we had great progress on the origin draft, entering IESG next week. So this will most certainly be finished by then. We could focus on HSTS and the interesting parts of "certificate pinning" as important topics to make major progress now. But I want to also emphasise looking for further topics and presentations. Anything you would like to raise at the websec meeting, please drop me a quick note. Kind regards, Tobias & Alexey (chairs of websec) Tobias Gondrom email: tobias.gondrom@gondrom.org mobile: +447521003005 --------------000707030300090301000907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello dear websec fellows,

to decide on a slot and length for our meeting in November in Taipei, this time we would like to start a bit earlier asking for presentations, topics and ideas.

Please send proposals and ideas for presentations to Alexey, Yoav and/or me, if possible until Sep-25 so we can better decide on the length of the meeting slot, but later will also be ok. Rough ideas are fine at this stage, anything that will help us in planning the length and scope of the meeting.

So far we had great progress on the origin draft, entering IESG next week. So this will most certainly be finished by then.
We could focus on HSTS and the interesting parts of "certificate pinning" as important topics to make major progress now.

But I want to also emphasise looking for further topics and presentations.
Anything you would like to raise at the websec meeting, please drop me a quick note.

Kind regards,

Tobias & Alexey
(chairs of websec)

Tobias Gondrom
email: tobias.gondrom@gondrom.org
mobile: +447521003005 --------------000707030300090301000907-- From sm@resistor.net Tue Sep 13 16:06:38 2011 Return-Path: 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 1268121F85AE for ; Tue, 13 Sep 2011 16:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 z1INAn5WAh8w for ; Tue, 13 Sep 2011 16:06:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B429921F855F for ; Tue, 13 Sep 2011 16:06:22 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p8DN86kj019404; Tue, 13 Sep 2011 16:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315955294; bh=50jtqM/hrzCPs+OqW0g5EZvRE/37I355czhnIT92Doo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=mZSrTNJe+HNzud4U2wtlP4ONCWUXrgiRZA3W4TpIp/RB8JQWX7s/aCozsJVyL6+YL 0AKQQOrx4odRC4TAe8aTGfkbBRYY/EoXlf+TswCOKo6pt+3ASywOjvIY/jHZ1cHafJ q7VWENMREdcZ8cGyyj/CvJNs5V6dvO/s+RJ2Vis4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315955294; bh=50jtqM/hrzCPs+OqW0g5EZvRE/37I355czhnIT92Doo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=lRsfnXLJncEtWMmaYgGe7vNeKGD74H55M+A4PzJ1H6SBGXaTU42pOejyG82RVHwhb tF22KRXIoL5pW8adIjw/TkVldSbQu65GUpSKfEhdAdCkQYmtcAUU7at73FjniPeQDE /Mdh9uVvbTkGyr7kFCNpd9mbsZpmr1NDRGJcwIAQ= Message-Id: <6.2.5.6.2.20110913153237.0851f630@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 16:06:53 -0700 To: Yoav Nir From: SM In-Reply-To: References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF WebSec WG Subject: Re: [websec] Certificate Pinning via HSTS (.txt version) X-BeenThere: websec@ietf.org 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: Tue, 13 Sep 2011 23:06:38 -0000 Hi Yoav, At 11:41 13-09-2011, Yoav Nir wrote: >Six months ago we would not have thought that Comodo or DigiNotar >were easy to hack. In the latter case, the customers of DigiNotar >were left out in the cold. Without "The DigiNotar partnership has laid down its security policy in action protocols and technical protocols. For safety reasons, these documents are not publicly available, which means that they are unavailable for inspection." "A regular audit is performed by an independent external auditor to assess Comodo's compliance with the AICPA/CICA WebTrust program for Certification Authorities." People get sloppy. Businesses get complacent. At the end of the day, it is a business decision. Regards, -sm From palmer@google.com Tue Sep 13 17:45:18 2011 Return-Path: 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 28A5621F8B21 for ; Tue, 13 Sep 2011 17:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Z7I2Ly2cOWjo for ; Tue, 13 Sep 2011 17:45:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFCD21F8B1E for ; Tue, 13 Sep 2011 17:45:17 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p8E0lJD4008136 for ; Tue, 13 Sep 2011 17:47:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315961239; bh=gw1Fei6UEEOJX63iAz0LeClXeuA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=xsPzR4C+bqZWkq+/7xVokvozGaR6Rq64Aht8Ao9jX8l2aMHnXcUCjPr6ACxLSDNXt jO9kSBmN5BtpVql/Efrbw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:content-type: content-transfer-encoding:x-system-of-record; b=PkxsDjOSUyYjBrD68km3uO+jKxUuclsA+gc1EjoCdoEbW4NnVsK2yOIpePpMbzKeF t3U3OkMMKI2qEM3SjPIuA== Received: from wyh11 (wyh11.prod.google.com [10.241.226.203]) by hpaq12.eem.corp.google.com with ESMTP id p8E0l0iS012234 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 13 Sep 2011 17:47:18 -0700 Received: by wyh11 with SMTP id 11so1180809wyh.36 for ; Tue, 13 Sep 2011 17:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ysfWDmaQTlMg+JUC25vEntKgq76IztGsYEw11kyFInc=; b=NLemubQPkHc54DnY2bRPjNdcJgmN6qjmqfmdLWhfP8wL7rhH70DPV/B3D3fYTEzLlC u0eGyYLBCmw3H8WGM3vg== Received: by 10.216.220.144 with SMTP id o16mr849407wep.49.1315961238013; Tue, 13 Sep 2011 17:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.220.144 with SMTP id o16mr849403wep.49.1315961237837; Tue, 13 Sep 2011 17:47:17 -0700 (PDT) Received: by 10.216.61.16 with HTTP; Tue, 13 Sep 2011 17:47:17 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110913153237.0851f630@resistor.net> References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im> <6.2.5.6.2.20110913153237.0851f630@resistor.net> Date: Tue, 13 Sep 2011 17:47:17 -0700 Message-ID: From: Chris Palmer To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: Re: [websec] Certificate Pinning via HSTS (.txt version) X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 00:45:18 -0000 Hi all, Unfortunately I didn't finish the new, XMLified rev of the document today =E2=80=94 you raised too many difficult questions. :) It's coming alo= ng though. I might be able to get it to the list tomorrow, but I might end up dedicating tomorrow to a different (but related) code-writing effort, hence wouldn't get back to this until Thursday. But, it any case, Real Soon Now. Thanks again for all your comments and questions! It's been very helpful. From ynir@checkpoint.com Tue Sep 13 23:15:57 2011 Return-Path: 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 6A6FD21F8C9A for ; Tue, 13 Sep 2011 23:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.386 X-Spam-Level: X-Spam-Status: No, score=-10.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, 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 avyxFWmR8cCR for ; Tue, 13 Sep 2011 23:15:56 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB2821F8C12 for ; Tue, 13 Sep 2011 23:15:56 -0700 (PDT) X-CheckPoint: {4E705440-22-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p8E6HvMT032332; Wed, 14 Sep 2011 09:17:58 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 14 Sep 2011 09:17:57 +0300 From: Yoav Nir To: SM Date: Wed, 14 Sep 2011 09:17:57 +0300 Thread-Topic: [websec] Certificate Pinning via HSTS (.txt version) Thread-Index: AcxypgtRp9M0lsEJRVKxt1ce4bvg8Q== Message-ID: <05C4445E-96F3-4CB6-979A-E0C576C35DE2@checkpoint.com> References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im> <6.2.5.6.2.20110913153237.0851f630@resistor.net> In-Reply-To: <6.2.5.6.2.20110913153237.0851f630@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Certificate Pinning via HSTS (.txt version) X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 06:15:57 -0000 On Sep 14, 2011, at 2:06 AM, SM wrote: > Hi Yoav, > At 11:41 13-09-2011, Yoav Nir wrote: >> Six months ago we would not have thought that Comodo or DigiNotar=20 >> were easy to hack. In the latter case, the customers of DigiNotar=20 >> were left out in the cold. Without >=20 > "The DigiNotar partnership has laid down its security policy in=20 > action protocols > and technical protocols. For safety reasons, these documents are=20 > not publicly > available, which means that they are unavailable for inspection." >=20 > "A regular audit is performed by an independent external auditor to > assess Comodo's compliance with the AICPA/CICA WebTrust program for > Certification Authorities." >=20 > People get sloppy. Businesses get complacent. At the end of the=20 > day, it is a business decision. >=20 It's all legalese to me. I can read 180 such statements (for the 180 root C= As in Microsoft's store) and not get a sense of which one is safe enough fo= r me.=20 I don't think the average site administrator (or whoever it is who buys cer= tificates in your organization) has better information. Besides, they tend = not to put too much thought into such a small expenditure. From hallam@gmail.com Wed Sep 14 06:12:01 2011 Return-Path: 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 804C021F8BE9 for ; Wed, 14 Sep 2011 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 20K4eNDRTdqt for ; Wed, 14 Sep 2011 06:11:56 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D03721F8BE8 for ; Wed, 14 Sep 2011 06:11:56 -0700 (PDT) Received: by gyd12 with SMTP id 12so1539292gyd.31 for ; Wed, 14 Sep 2011 06:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=74/rduiXmE91rZuFfpDX90S0nrR3Ud0upwlfJIw/lrs=; b=kEfK4Y8ld4NcUT4+CdUQzZXEN3siMjAIj2gy9QP+QZrFlmeJqJUAB+pQplgfikUWTy 8SugRrSQ5+uTt+/LTEsVIXaPV7qCDEhWToBIPF1Hy0E3otS3aZqNY56ZZUavmU0e8KBi bYkcC0DZV625ETpYzFaWA/F/8IFgLMdDuzcjM= MIME-Version: 1.0 Received: by 10.100.55.34 with SMTP id d34mr1084715ana.30.1316006044987; Wed, 14 Sep 2011 06:14:04 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 06:14:04 -0700 (PDT) In-Reply-To: <4E6FD975.9010502@extendedsubset.com> References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im> <4E6FB7CB.3020309@extendedsubset.com> <6D3E0CA6-E990-4D89-9AEE-C03066D0656E@gmail.com> <4E6FD975.9010502@extendedsubset.com> Date: Wed, 14 Sep 2011 09:14:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Marsh Ray Content-Type: multipart/alternative; boundary=001485f6d9f4d5724004ace688b6 Cc: IETF WebSec WG Subject: Re: [websec] Certificate Pinning via HSTS (.txt version) X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 13:12:01 -0000 --001485f6d9f4d5724004ace688b6 Content-Type: text/plain; charset=ISO-8859-1 I totally agree that this is a feasible attack. It has been seen on a very large scale, Russia did a BGP redirect at a country level in their dispute with Georgia. DNSSEC on A records alone is practically worthless. There is some value but not a great deal. Most DNS attacks have been persuading registrars to put bad data into the system. On Tue, Sep 13, 2011 at 6:30 PM, Marsh Ray wrote: > On 09/13/2011 04:24 PM, davidillsley@gmail.com wrote: > >> >> On 13 Sep 2011, at 21:35, Chris Palmer wrote: >> >>> >>> sites; small sites may have to choose no pinning or potentially >>> bricking their site (up to the maxAge window). This is not worse than >>> the status quo.""" >>> >> >> What about sites which don't currently use https at all? The DNS records >> for theregister.co.uk were redirected the >> >> other week. An attacker who could do that could redirect to https, then >> set a very long max-age pin. At that point, they'd be dependent on the >> browser vendor unpinning affected users, right? >> > > Wouldn't they have to acquire a valid cert first? Not saying that's out of > the realm of possibility, but... > > I think you have a point. The whole premise of this is that there are > circumstances under which some attacker can obtain such a cert. If this > feature translates to a risk of perma-DoS for the (100.0 - epsilon)% of > sites that don't adopt it immediately then it may be more dangerous than > it's worth. > > Consider an adversarial country like, say, Bananastan. They have an ISP or > three, their own CA, and of course, no sense of humor. > > They may one day be subject to some criticisms in the online press which > they perceive as unfair. Or maybe something on a video sharing site is > contrary to their customs and traditions. > > So their local judge orders their local ISP to block the offending media > provider. The ISP does this by advertising more specific BGP routes for the > video site's netblocks(1). > > Being mostly streaming data of little consequence, the video site has not > yet set up HSTS or even has full support for HTTPS (2). > > The ISP also sets the country's DNS resolvers to reply to name requests for > the site with an IP address of a webserver where citizens can receive > educational information(3). > > To be sure they get everybody, they do something I didn't know could be > done with DNS (4). > > In order to save the the misguided users that accidentally used a > subversive https: bookmark, the court orders the local CA to "do what it > takes to make it work"(5). > > And just to be sure the message sticks, they set a long term HSTS pin on > this cert and/or their CA (6). > > Hilarity ensues. > > - Marsh > > > > 1. YouTube - Pakistan - 2008 > http://www.circleid.com/posts/**82258_pakistan_hijacks_** > youtube_closer_look > http://www.ripe.net/internet-**coordination/news/industry-** > developments/youtube-**hijacking-a-ripe-ncc-ris-case-**study > > 2. http://youtube.com/ > > > 3. http://web.archive.org/web/**20060418030141/http://** > chinadigitaltimes.net/2006/01/**image_of_internet_police_** > jingjing_and_chacha_online_**hon.php > > > 4. China - 2010 > https://lists.dns-oarc.net/**pipermail/dns-operations/2010-** > March/005260.html > http://www.zdnet.co.uk/news/**networking/2010/10/11/mystery-** > of-web-traffic-redirect-to-**china-remains-unsolved-**40090476/ > > > 5. [...] > > > 6. Why wouldn't this attack work? > > > ______________________________**_________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/**listinfo/websec > -- Website: http://hallambaker.com/ --001485f6d9f4d5724004ace688b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I totally agree that this is a feasible attack. It has been seen on a very = large scale, Russia did a BGP redirect at a country level in their dispute = with Georgia.

DNSSEC on A records alone is practically w= orthless. There is some value but not a great deal. Most DNS attacks have b= een persuading registrars to put bad data into the system.=A0

On Tue, Sep 13, 2011= at 6:30 PM, Marsh Ray <marsh@extendedsubset.com> wrote:

On 09/13/2011 04:24 PM, davidillsley@gmail.com wrote:

On 13 Sep 2011, at 21:35, Chris Palmer wrote:

<snip>
sites; small sites may have to choose no pinning or potentially
bricking their site (up to the maxAge window). This is not worse than
the status quo."""

What about sites which don't currently use https at all? The DNS record= s
for theregister.co.u= k <http://the= register.co.uk> were redirected the

other week. An attacker who could do that could redirect to https, then
set a very long max-age pin. At that point, they'd be dependent on the<= br> browser vendor unpinning affected users, right?

Wouldn't they have to acquire a valid cert first? Not saying that's= out of the realm of possibility, but...

I think you have a point. The whole premise of this is that there are circu= mstances under which some attacker can obtain such a cert. If this feature = translates to a risk of perma-DoS for the (100.0 - epsilon)% of sites that = don't adopt it immediately then it may be more dangerous than it's = worth.

Consider an adversarial country like, say, Bananastan. They have an ISP or = three, their own CA, and of course, no sense of humor.

They may one day be subject to some criticisms in the online press which th= ey perceive as unfair. Or maybe something on a video sharing site is contra= ry to their customs and traditions.

So their local judge orders their local ISP to block the offending media pr= ovider. The ISP does this by advertising more specific BGP routes for the v= ideo site's netblocks(1).

Being mostly streaming data of little consequence, the video site has not y= et set up HSTS or even has full support for HTTPS (2).

The ISP also sets the country's DNS resolvers to reply to name requests= for the site with an IP address of a webserver where citizens can receive = educational information(3).

To be sure they get everybody, they do something I didn't know could be= done with DNS (4).

In order to save the the misguided users that accidentally used a subversiv= e https: bookmark, the court orders the local CA to "do what it takes = to make it work"(5).

And just to be sure the message sticks, they set a long term HSTS pin on th= is cert and/or their CA (6).

Hilarity ensues.

- Marsh

1. YouTube - Pakistan - 2008
http://www.circleid.com/posts/82258_paki= stan_hijacks_youtube_closer_look
http://= www.ripe.net/internet-coordination/news/industry-developments= /youtube-hijacking-a-ripe-ncc-ris-case-study

2. http://youtube.com/

3. http://web.archive.org/web/20060418030141/http= ://chinadigitaltimes.net/2006/01/image_of_internet_police_= jingjing_and_chacha_online_hon.php

4. China - 2010
https://lists.dns-oarc.net/pipermail/d= ns-operations/2010-March/005260.html
ht= tp://www.zdnet.co.uk/news/networking/2010/10/11/mystery-of-we= b-traffic-redirect-to-china-remains-unsolved-40090476/

5. [...]

6. Why wouldn't this attack work?

_______________________________________________
websec mailing list
websec@ietf.org = https://www.ietf.org/mailman/listinfo/websec

--
= Website: http://hallambaker.com/

--001485f6d9f4d5724004ace688b6-- From dkg@fifthhorseman.net Wed Sep 14 06:12:44 2011 Return-Path: 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 5A45821F8CBA for ; Wed, 14 Sep 2011 06:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 zpPaCWpzscZB for ; Wed, 14 Sep 2011 06:12:43 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E30BE21F8C4D for ; Wed, 14 Sep 2011 06:12:41 -0700 (PDT) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 1F150F970; Wed, 14 Sep 2011 09:14:47 -0400 (EDT) Message-ID: <4E70A8F8.80102@fifthhorseman.net> Date: Wed, 14 Sep 2011 09:15:36 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110807 Icedove/5.0 MIME-Version: 1.0 To: Chris Palmer References: <4E6F5056.800@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.2.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3E071253BFE06FFBFE80D352" Cc: Chris Evans , websec@ietf.org Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF WebSec WG List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 13:12:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3E071253BFE06FFBFE80D352 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/13/2011 05:55 PM, Chris Palmer wrote: > On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor > wrote: >=20 >> From my perspective, i see no advantage to pinning any of the CAs -- i= f >> your EE is compromised, you're sunk. And since the mechanism provides= a >> mechanism (and nice instructions, thanks) for transition to an emergen= cy >> offline backup EE key+cert, that is all handled well. >=20 > In the case of normal EE certificate expiration =E2=80=94 as opposed to= > compromise =E2=80=94 if you are pinned to (say) an intermediary signer,= you > can just get a fresh certificate from the same signer, deploy it, and > change nothing else. >=20 > Conversely, if you had pinned to an EE, you'd need to follow a > procedure something like this near expiration time: >=20 > 0. Generate the new cert. > 1. Change your pins directive to include the new and the old public > key fingerprints. > 2. Wait long enough for "most, surely?" of your users to have received > the new pins, or for their pins to expire by the normal maxAge means. > 3. Decommission the old EE cert and deploy the new. Actually, if your certificate policy requires key rotation at certificate expiry, you can generate key N+1 at any time (preferably early in the life of the cert corresponding to key N), and introduce the secondary pin at that point, without having gotten certificate N+1 yet. Then, as certificate N approaches expiration, get a certificate made from key N+1 -- your pin is already well-known. Generate key N+2 (stored safely offline someplace?), deploy key N+1, and update your pin list to be (N+1,N+2). There's no waiting required. And this approach dovetails nicely with your recommendations for backup resiliency as well.= It still looks to me like pinning a CA does nothing more than give them the chance to hold you hostage at certificate renewal time, and to expose you to vulnerability should the CA itself be compromised. > You could, of course, also just re-use your old key pair and get it > re-signed, and no need to migrate keys as well as certs. In that case, > no problem. Yep; the only reason you'd need the more-complex approach above is if you require key rotation at certificate expiry. If all you care about is convenience and simplicity of operation, just get the existing key re-certified by any CA. In this case, there's still no need or advantage (and significant disadvantages) to pin to a CA instead of pinning to your EE. > Again, that's fine and one size does not fit all. Sure, one size does not fit all, but it looks like the document is (reasonably) trying to outline some common patterns of reasonable behavior to encourage best practices. I still don't see any best practice that involves pinning to a CA unless that CA is itself under the control of your own organization. I recommend that the draft make this explicit, to avoid encouraging system operators binding themselves even more tightly to a CA by misapplication of this mechanism. --dkg --------------enig3E071253BFE06FFBFE80D352 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJOcKj4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpT40P/1/CxWRNr0jjQobdjg0cGdQm HOvmqMZosCXJm1y3OoAY3+bM445GfwXhza0pLtR9lsP5bcA4pGz5MyjvCf6j0H4k S1XBN3tKukwu/75yyz3p26E1Fv4BoLvn8T2aTNjKVn0yzyuuiR/CoHcYDSKWesCt eOArUY8N6ppC9+sdrq/P4q+xCwHDd0N8e0vlXhdN4HyncBvFJBJWbpnGVhAfb/Dg Ete505P9XcWE30vVuGEnCaUyVOZMNlHlk4InKVveo6vNPiEbtfTr9LGloFgvMpC2 0uxmy5d+5zAP5G/wo8RT4qrvfNUkGE2aFclONtJG6y1hl7tRl64NCdep1u+d7x3i i/k6ikLXy4DIbhskthzZx8/CbM2K3KOAxiWJkJdm/hu5pCBCHczEJwT9h2wZboAl C3IaSlQz5O5kDDc1oOn0ppm7B/UELYVgtCdoTxaIK8FWRP+cbkcYozA4rsK9r3AT ub3+LcCrmaUzlBoxiaB5SAZoxlOOeGdLTIgKImV3UZLUY3zfwfgNuPiDCs+XzrQA HsvbEWtVfJDtSKI8i9u0UZwsbEYpGXb1TtjDVj8tTxVKW4pouafcsUPZTB5TMs0g q+2DNSmXEniyLbcyMPrxXYCdOhQAeKVc835Cy89LpbJ2pJ9Va0ltBNo7lE7/IGre 4/ZHbsMd/xi7kseloipY =ANne -----END PGP SIGNATURE----- --------------enig3E071253BFE06FFBFE80D352-- From hallam@gmail.com Wed Sep 14 06:24:56 2011 Return-Path: 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 443BB21F8CB0 for ; Wed, 14 Sep 2011 06:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 UuQAoQMj0JuA for ; Wed, 14 Sep 2011 06:24:51 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4521F8C00 for ; Wed, 14 Sep 2011 06:24:51 -0700 (PDT) Received: by gwb20 with SMTP id 20so337817gwb.31 for ; Wed, 14 Sep 2011 06:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VI0noTB19GEXZjjJjxshFDduUHHFKkOix9/DjQEDe6c=; b=hs+LP6+tiO1RBJBfp/YhS20u6n3RDetW9c+KhJFzBEGGBBcWwgz/RAZvfbenaRZyHD BQS1tXDs+FU0IvAiLYlyZJOB+t/19ek9cpzsAcBDsCY1LuOdjAUUvnh1+XoEjR1944v6 EF03HslETzZRTAU+Z4HTxRH/DnwyzHmesbycY= MIME-Version: 1.0 Received: by 10.100.55.34 with SMTP id d34mr1100376ana.30.1316006820119; Wed, 14 Sep 2011 06:27:00 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 06:26:59 -0700 (PDT) In-Reply-To: <498A0E83-7C80-4226-9D69-7A7E93D8C929@bbn.com> References: <498A0E83-7C80-4226-9D69-7A7E93D8C929@bbn.com> Date: Wed, 14 Sep 2011 09:26:59 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=001485f6d9f409047604ace6b746 Cc: Chris Evans , websec@ietf.org Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 13:24:56 -0000 --001485f6d9f409047604ace6b746 Content-Type: text/plain; charset=ISO-8859-1 Or maybe DANE should consider migrating to the WEBSEC approach. I was pushing for DANE to consider the pinning and 'must be SSL' approach from the start. The consensus of the group has been that they don't want to consider those use cases at all. Furthermore the response I have got from the key contributors has been 'we don't want to consider those issues because we can't understand the issues and have no interest in attempting to do so'. The reason that I was pushing hard to get the use of prefixes fixed was because I have been looking at these use cases for two years now and I don't see the naive prefix approach that has been insisted on will allow for effective security policy. If you want DANE to be compatible with the WebSec approach I suggest that DANE make the accommodations to the deployed HTTP and TLS infrastructure rather than propose a completely new infrastructure and then demand that everyone work around the legacy you have just created. There is 20 years of Web legacy. It is big, ugly and complex. There is 0 years of DANE legacy. PKI is really hard for reasons that go beyond the syntax and structure of X.509v3. The complexity of PKIX comes mostly from the fact that the original design did not have enough flexibility to meet real world needs and so a heck of a lot that should have been in the core ended up as ad-hoc extensions and patches. In particular X.509 was originally designed round a PEM style monolithic hierarchy. On Mon, Sep 12, 2011 at 8:54 PM, Richard L. Barnes wrote: > Hey Chris & Chris, > > This seems like a useful near-term approach, but also probably something > that might want to migrate to DANE over time. > > Is there any particular reason you're using key fingerprints instead of > cert fingerprints? It seems like the latter might be slightly easier to > implement, since you don't have to parse the cert. > > --Richard > > > > On Sep 12, 2011, at 5:56 PM, Chris Palmer wrote: > > > Hi all, > > > > Chris Evans and I work at Google on the Chrome security team. We have > > devised this specification for a new extension to Strict Transport > > Security to allow site operators to "pin" certificates: UAs will > > require that TLS connections be validated with at least one of the > > public keys identified in the new "pins" directive in the HSTS header. > > (Sites can pin to one or more public keys in end entity, subordinate > > CA, and/or root CA certificates, for flexibility and disaster > > recovery.) > > > > We hope that this mechanism opens up the benefits of certificate > > pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior > > and certificate pins for sites, but the mechanism for doing this > > (email us!) does not scale. > > > > We eagerly anticipate your comments, questions, concerns, et c. As you > > can see from the Ideas section, there are some unanswered questions > > about the behavior of UAs and hosts, and possible extensions to the > > policy. > > > _______________________________________________ > > websec mailing list > > websec@ietf.org > > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --001485f6d9f409047604ace6b746 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Or maybe DANE should consider migrating to the WEBSEC approach.

I was pushing for DANE to consider the pinning and 'must be SSL= ' approach from the start. The consensus of the group has been that the= y don't want to consider those use cases at all. Furthermore the respon= se I have got from the key contributors has been 'we don't want to = consider those issues because we can't understand the issues and have n= o interest in attempting to do so'.

The reason that I was pushing hard to get the use of pr= efixes fixed was because I have been looking at these use cases for two yea= rs now and I don't see the naive prefix approach that has been insisted= on will allow for effective security policy.

If you want DANE to be compatible with the WebSec appro= ach I suggest that DANE make the=A0accommodations=A0to the deployed HTTP an= d TLS infrastructure rather than propose a completely new infrastructure an= d then demand that everyone work around the legacy you have just created.

There is 20 years of Web legacy. It is big, ugly and co= mplex. There is 0 years of DANE legacy.

PKI is really hard for reasons that go beyond the syntax and structure= of X.509v3. The complexity of PKIX comes mostly from the fact that the ori= ginal design did not have enough flexibility to meet real world needs and s= o a heck of a lot that should have been in the core ended up as ad-hoc exte= nsions and patches. In particular X.509 was originally designed round a PEM= style monolithic hierarchy.=A0

On Mon, Sep 12, 2011 at = 8:54 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:

Hey Chris & Chris,

This seems like a useful near-term approach, but also probably something th= at might want to migrate to DANE over time.

Is there any particular reason you're using key fingerprints instead of= cert fingerprints? =A0It seems like the latter might be slightly easier to= implement, since you don't have to parse the cert.

--Richard

On Sep 12, 2011, at 5:56 PM, Chris Palmer wrote:

> Hi all,
>
> Chris Evans and I work at Google on the Chrome security team. We have<= br> > devised this specification for a new extension to Strict Transport
> Security to allow site operators to "pin" certificates: UAs = will
> require that TLS connections be validated with at least one of the
> public keys identified in the new "pins" directive in the HS= TS header.
> (Sites can pin to one or more public keys in end entity, subordinate > CA, and/or root CA certificates, for flexibility and disaster
> recovery.)
>
> We hope that this mechanism opens up the benefits of certificate
> pinning to more sites. Currently, Chrome can "pre-load" HSTS= behavior
> and certificate pins for sites, but the mechanism for doing this
> (email us!) does not scale.
>
> We eagerly anticipate your comments, questions, concerns, et c. As you=
> can see from the Ideas section, there are some unanswered questions > about the behavior of UAs and hosts, and possible extensions to the > policy.

> <CertificatePinningExtensionforHSTS.pdf>____________= ___________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec

_______________________________________________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec

--
Website: http://hallambaker.com/

--001485f6d9f409047604ace6b746-- From hallam@gmail.com Wed Sep 14 06:44:00 2011 Return-Path: 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 21CE321F8BEC for ; Wed, 14 Sep 2011 06:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] 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 HzYiVMFMJpOi for ; Wed, 14 Sep 2011 06:43:55 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80ACC21F8C06 for ; Wed, 14 Sep 2011 06:43:55 -0700 (PDT) Received: by gyd12 with SMTP id 12so1572220gyd.31 for ; Wed, 14 Sep 2011 06:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wj1nyooP+V8USvN+ou2blIDs3GFbGnu5F5JKzIBR/WE=; b=tLkDSaZT1eI6UWYbPriCMAew6t+HVBFyAD4npJc23Jq212w9hdPqXAh/clwlT/fZ7m AuFqd2OaoXTKKANsSqFMFNgoW7lvLxWeF7KmdtyULdra2GooxQHcgqxf6BguSXr5b+fa PIFfyQqhxxvoR15WihoQEsuwEV5IdrHwR6Uvg= MIME-Version: 1.0 Received: by 10.101.11.36 with SMTP id o36mr310576ani.74.1316007964340; Wed, 14 Sep 2011 06:46:04 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 06:46:04 -0700 (PDT) In-Reply-To: <4E70A8F8.80102@fifthhorseman.net> References: <4E6F5056.800@fifthhorseman.net> <4E70A8F8.80102@fifthhorseman.net> Date: Wed, 14 Sep 2011 09:46:04 -0400 Message-ID: From: Phillip Hallam-Baker To: IETF WebSec WG Content-Type: multipart/alternative; boundary=0016e68ef4573c72f704ace6fb0b Cc: Chris Evans Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 13:44:00 -0000 --0016e68ef4573c72f704ace6fb0b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Sep 14, 2011 at 9:15 AM, Daniel Kahn Gillmor wrote: > On 09/13/2011 05:55 PM, Chris Palmer wrote: > > On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor > > wrote: > > > >> From my perspective, i see no advantage to pinning any of the CAs -- i= f > >> your EE is compromised, you're sunk. And since the mechanism provides= a > >> mechanism (and nice instructions, thanks) for transition to an emergen= cy > >> offline backup EE key+cert, that is all handled well. > > > > In the case of normal EE certificate expiration =97 as opposed to > > compromise =97 if you are pinned to (say) an intermediary signer, you > > can just get a fresh certificate from the same signer, deploy it, and > > change nothing else. > > > > Conversely, if you had pinned to an EE, you'd need to follow a > > procedure something like this near expiration time: > > > > 0. Generate the new cert. > > 1. Change your pins directive to include the new and the old public > > key fingerprints. > > 2. Wait long enough for "most, surely?" of your users to have received > > the new pins, or for their pins to expire by the normal maxAge means. > > 3. Decommission the old EE cert and deploy the new. > > Actually, if your certificate policy requires key rotation at > certificate expiry, you can generate key N+1 at any time (preferably > early in the life of the cert corresponding to key N), and introduce the > secondary pin at that point, without having gotten certificate N+1 yet. > Yep. > It still looks to me like pinning a CA does nothing more than give them > the chance to hold you hostage at certificate renewal time, and to > expose you to vulnerability should the CA itself be compromised. It gives you scaling and administrative convenience. If you have 10,000 hosts in your enterprise network you really do not want to have to be managing trust on a per host level. Now consider the case where you are renting your compute power in the cloud and so the machine instances are existing for a few hours at a time. Any scheme that insists on only tying to the EE cert or key is going to create a major operational headache for those sites. It is really easy to design a scheme that is easy to administer. It is also going to cause huge amounts of state that the client has to manage. If you have 10,000 front end web servers you are going to need 10,000 different client keys to do the job right. So what most of the large enterprises would likely do if they introduced an= y form of security policy would be to have a private CA run up that is an intermediate in a larger hierarchy. This is why the bogus EFF study came up with the absurd number of 600 CAs. What they have never come clean on is th= e fact that 150 of those 'CAs' are in fact merely intermediate roots tied to = a single customer that are managed in the same infrastructure as the root CA operations. What pinning to a CA does raise is the absolute need to have the ability to pin more than one CA at a time. > Again, that's fine and one size does not fit all. > > Sure, one size does not fit all, but it looks like the document is > (reasonably) trying to outline some common patterns of reasonable > behavior to encourage best practices. I still don't see any best > practice that involves pinning to a CA unless that CA is itself under > the control of your own organization. > > I recommend that the draft make this explicit, to avoid encouraging > system operators binding themselves even more tightly to a CA by > misapplication of this mechanism. > There is certainly a difference in the risk factor here between pinning in the browser and CAA as currently specd (i.e. without the client enforcement capability). [I originally wrote big, but thinking it through, maybe not so much] CA issue of certs is never a 100% automated process. There are some cases where automated issue is possible but there are inevitably exceptions. CAA does not prevent a CA issuing a cert, it merely triggers an exception. So the CA that received the failed application is going to circle back to the customer and ask what is up. If the CAA record was inserted maliciously or without informed consent then the customer is going to be mighty peeved with their old CA and likely contact slashdot with a nasty story. If there is client enforcement of the records then there is a potential to use them maliciously. But even so, I can't see this being much of a practical concern. The main value add CAs bring in practice is teaching people how to configure crypto and install certs properly without making a mess of it. Every customer call center I have been in the conversations you hear are salespeople walking a customer through install for Apache or ISS. So provided there is an escape hole from the pinning mechanism, the CAs are going to be more than capable of talking the customer through how to untie themselves from the attempted customer capture. --=20 Website: http://hallambaker.com/ --0016e68ef4573c72f704ace6fb0b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 14, 2011 at 9:15 AM, Daniel = Kahn Gillmor <dkg@fifthhorseman.net> wrote:

On 09/13/2011 05:55 PM, Chris Palmer wrote:
> On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor
> <dkg@fifthhorseman.net= > wrote:
>
>> From my perspective, i see no advantage to pinning any of the CAs = -- if
>> your EE is compromised, you're sunk. =A0And since the mechanis= m provides a
>> mechanism (and nice instructions, thanks) for transition to an eme= rgency
>> offline backup EE key+cert, that is all handled well.
>
> In the case of normal EE certificate expiration =97 as opposed to
> compromise =97 if you are pinned to (say) an intermediary signer, you<= br> > can just get a fresh certificate from the same signer, deploy it, and<= br> > change nothing else.
>
> Conversely, if you had pinned to an EE, you'd need to follow a
> procedure something like this near expiration time:
>
> 0. Generate the new cert.
> 1. Change your pins directive to include the new and the old public > key fingerprints.
> 2. Wait long enough for "most, surely?" of your users to hav= e received
> the new pins, or for their pins to expire by the normal maxAge means.<= br> > 3. Decommission the old EE cert and deploy the new.

Actually, if your certificate policy requires key rotation at
certificate expiry, you can generate key N+1 at any time (preferably
early in the life of the cert corresponding to key N), and introduce the secondary pin at that point, without having gotten certificate N+1 yet.
=

Yep.

=A0

It still looks to me like pinning a CA does nothing more than give them
the chance to hold you hostage at certificate renewal time, and to
expose you to vulnerability should the CA itself be compromised.

It gives you scaling and administrative convenience.<= /div>

If you have 10,000 hosts in your enterprise networ= k you really do not want to have to be managing trust on a per host level. = Now consider the case where you are renting your compute power in the cloud= and so the machine instances are existing for a few hours at a time.

Any scheme that insists on only tying to the EE cert or= key is going to create a major operational headache for those sites. It is= really easy to design a scheme that is easy to administer.

It is also going to cause huge amounts of state that the client = has to manage. If you have 10,000 front end web servers you are going to ne= ed 10,000 different client keys to do the job right.

=A0

So what most of the large enterprises would likely do if the= y introduced any form of security policy would be to have a private CA run = up that is an intermediate in a larger hierarchy. This is why the bogus EFF= study came up with the absurd number of 600 CAs. What they have never come= clean on is the fact that 150 of those 'CAs' are in fact merely in= termediate roots tied to a single customer that are managed in the same inf= rastructure as the root CA operations.

What pinning to a CA does raise is the a= bsolute need to have the ability to pin more than one CA at a time.

> Again, that's fine and one size does not fit all= .

Sure, one size does not fit all, but it looks like the document is (reasonably) trying to outline some common patterns of reasonable
behavior to encourage best practices. =A0I still don't see any best
practice that involves pinning to a CA unless that CA is itself under
the control of your own organization.

I recommend that the draft make this explicit, to avoid encouraging
system operators binding themselves even more tightly to a CA by
misapplication of this mechanism.

There is certain= ly a difference in the risk factor here between pinning in the browser and = CAA as currently specd (i.e. without the client enforcement capability). [I= originally wrote big, but thinking it through, maybe not so much]

CA issue of certs is never a 100% automated process. Th= ere are some cases where automated issue is possible but there are inevitab= ly exceptions.

CAA does not prevent a CA issuing a= cert, it merely triggers an exception. So the CA that received the failed = application is going to circle back to the customer and ask what is up. If = the CAA record was inserted maliciously or without informed consent then th= e customer is going to be mighty peeved with their old CA and likely contac= t slashdot with a nasty story.

If there is client enforcement of the re= cords then there is a potential to use them maliciously.

But even so, I can't see this being much of a practical concern.= The main value add CAs bring in practice is teaching people how to configu= re crypto and install certs properly without making a mess of it. Every cus= tomer call center I have been in the conversations you hear are salespeople= walking a customer through install for Apache or ISS.=A0

So provided there is an escape hole from the pinning me= chanism, the CAs are going to be more than capable of talking the customer = through how to untie themselves from the attempted customer capture.

--
Website: http://h= allambaker.com/

--0016e68ef4573c72f704ace6fb0b-- From hallam@gmail.com Wed Sep 14 06:58:04 2011 Return-Path: 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 CD24121F8BFE for ; Wed, 14 Sep 2011 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 vvdpBqzjQNTL for ; Wed, 14 Sep 2011 06:58:00 -0700 (PDT) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA5721F8B52 for ; Wed, 14 Sep 2011 06:58:00 -0700 (PDT) Received: by gxk28 with SMTP id 28so2199786gxk.27 for ; Wed, 14 Sep 2011 07:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kjxBPOnM5/+Y66rYrerhc/MIRYoS/eN2FRVkyw47Igo=; b=ie+sfW+k4JvQDdTtVsuHsKKkcTagbNtTDpDGmZDEv8MXcOePnEFwpWFzccU4g/Cn6i 8sI+pcT6FIfr+oE0NNo9wmyXvTd8zLarBHAs7W0r9x0GEvxzAK4X97UieEzOpSOk27uP rgCPg3dXzD6IQteHlPoiUi0aK/4yBYR9CbmWc= MIME-Version: 1.0 Received: by 10.101.11.36 with SMTP id o36mr326696ani.74.1316008808974; Wed, 14 Sep 2011 07:00:08 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 07:00:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Sep 2011 10:00:08 -0400 Message-ID: From: Phillip Hallam-Baker To: Chris Palmer Content-Type: multipart/alternative; boundary=0016e68ef4579489bf04ace72d63 Cc: Chris Evans , websec@ietf.org Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 13:58:04 -0000 --0016e68ef4579489bf04ace72d63 Content-Type: text/plain; charset=ISO-8859-1 One technical point, have you considered the ODI mechanism that we developed for CAA up to the -01 version when the client enforcement bit got kiboshed? The name is confuising, but lets say we call it the DIGEST URI type and the digest data consists of DIGEST: < Base64 ( + + ) The idea was that this is something we could write code into various crypto libs to generate as a fixed ASCII blob that the user can then cut and paste. It is thus easier for the admin to manage than having the digest alg being a separate parameter that they have to get right. A practical benefit here is that it makes it easy to have multiple digests in the same header without the need for bracketing: Pin: DIGEST:w2eoiuweoifuweoi== DIGEST:weowoeifwoeifj== Is easier to parse than: Pin: [alg=sha1 fingerprint=odoiweoifjio==] [alg=sha256 fingerprint=wejwekhjw==] This makes it easy to provide two versions of the digest so that old and new browsers can make use of the same data. This is the type of capability that I think will be essential in emergency response if we ever have a SHA2 breach to cope with. It also means that the digest format is intrinsically proof against content type substitution attacks. If the code expects a cert or a key, it can check that it is not being fed a cunningly crafted object of another type. One minor point, the draft mentions SHA1. Could we just dump that? I can't see a good reason to use SHA1 in new code at this point. I would like all new code to be SHA3 capable from the start. Which is why the ODI scheme used ASN.1. Any code that is going to touch certs is going to have to have an ASN.1 algorithm type mechanism. But knowing what the IANA situation is takes an additional bit of data. [As a matter of policy I would prefer that the IETF get out of the business of giving code points that recognize vanity crypto and only ever issue code points for algorithms that the IETF endorses as MUSTs for IETF protocols.] On Mon, Sep 12, 2011 at 5:56 PM, Chris Palmer wrote: > Hi all, > > Chris Evans and I work at Google on the Chrome security team. We have > devised this specification for a new extension to Strict Transport > Security to allow site operators to "pin" certificates: UAs will > require that TLS connections be validated with at least one of the > public keys identified in the new "pins" directive in the HSTS header. > (Sites can pin to one or more public keys in end entity, subordinate > CA, and/or root CA certificates, for flexibility and disaster > recovery.) > > We hope that this mechanism opens up the benefits of certificate > pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior > and certificate pins for sites, but the mechanism for doing this > (email us!) does not scale. > > We eagerly anticipate your comments, questions, concerns, et c. As you > can see from the Ideas section, there are some unanswered questions > about the behavior of UAs and hosts, and possible extensions to the > policy. > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > -- Website: http://hallambaker.com/ --0016e68ef4579489bf04ace72d63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One technical point, have you considered the ODI mechanism that we develope= d for CAA up to the -01 version when the client enforcement bit got kiboshe= d?

The name is confuising, but lets say we call it the D= IGEST URI type and the digest data consists of

DIGEST: < Base64 ( <Object-type> + <Digest-= alg> + <Digest-value>)=A0

The idea was th= at this is something we could write code into various crypto libs to genera= te as a fixed ASCII blob that the user can then cut and paste.

It is thus easier for the admin to manage than having t= he digest alg being a separate parameter that they have to get right.=A0

A practical benefit here is that it m= akes it easy to have multiple digests in the same header without the need f= or bracketing:

Pin: DIGEST:w2eoiuweoifuweoi=3D=3D =A0DIGEST:weowoeifwo= eifj=3D=3D

Is easier to parse than:

Pin: [alg=3Dsha1 fingerprint=3Dodoiweoifjio=3D=3D] =A0[alg=3Dsha= 256 fingerprint=3Dwejwekhjw=3D=3D]=A0

This makes it easy to provide two versions of the diges= t so that old and new browsers can make use of the same data.=A0

This is the type of capability that I think will be essentia= l in emergency response if we ever have a SHA2 breach to cope with.

It also means that the digest format is = intrinsically proof against content type substitution attacks. If the code = expects a cert or a key, it can check that it is not being fed a cunningly = crafted object of another type.

One minor point, the draft mentions SHA1= . Could we just dump that? I can't see a good reason to use SHA1 in new= code at this point. I would like all new code to be SHA3 capable from the = start.

Which is why the ODI scheme used ASN.1. Any code that i= s going to touch certs is going to have to have an ASN.1 algorithm type mec= hanism. But knowing what the IANA situation is takes an additional bit of d= ata.

[As a matter of policy I would prefer that the IETF get= out of the business of giving code points that recognize vanity crypto and= only ever issue code points for algorithms that the IETF endorses as MUSTs= for IETF protocols.]

On Mon, Sep 12, 201= 1 at 5:56 PM, Chris Palmer <palmer@google.com> wrote:

Hi all,

Chris Evans and I work at Google on the Chrome security team. We have
devised this specification for a new extension to Strict Transport
Security to allow site operators to "pin" certificates: UAs will<= br> require that TLS connections be validated with at least one of the
public keys identified in the new "pins" directive in the HSTS he= ader.
(Sites can pin to one or more public keys in end entity, subordinate
CA, and/or root CA certificates, for flexibility and disaster
recovery.)

We hope that this mechanism opens up the benefits of certificate
pinning to more sites. Currently, Chrome can "pre-load" HSTS beha= vior
and certificate pins for sites, but the mechanism for doing this
(email us!) does not scale.

We eagerly anticipate your comments, questions, concerns, et c. As you
can see from the Ideas section, there are some unanswered questions
about the behavior of UAs and hosts, and possible extensions to the
policy.

_______________________________________________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec

--
Website:= http://hallambaker.com/

--0016e68ef4579489bf04ace72d63-- From dkg@fifthhorseman.net Wed Sep 14 08:10:58 2011 Return-Path: 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 4C8E621F8B71 for ; Wed, 14 Sep 2011 08:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] 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 rR8V33cJvGSd for ; Wed, 14 Sep 2011 08:10:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDFB21F8B84 for ; Wed, 14 Sep 2011 08:10:57 -0700 (PDT) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id DF0E0F970; Wed, 14 Sep 2011 11:12:58 -0400 (EDT) Message-ID: <4E70C4AB.7050206@fifthhorseman.net> Date: Wed, 14 Sep 2011 11:13:47 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110807 Icedove/5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E6F5056.800@fifthhorseman.net> <4E70A8F8.80102@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.2.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig59D969115E03CB39ED0224AB" Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF WebSec WG List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 15:10:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig59D969115E03CB39ED0224AB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/14/2011 09:46 AM, Phillip Hallam-Baker wrote: > It gives you scaling and administrative convenience. >=20 > If you have 10,000 hosts in your enterprise network you really do not w= ant > to have to be managing trust on a per host level. You're not "managing trust on a per host level" -- you're managing *identity* on a per-host level, which is exactly what it should be. If you have 10K hosts, you need to think clearly about the identity presented by each of those hosts. > Now consider the case > where you are renting your compute power in the cloud and so the machin= e > instances are existing for a few hours at a time. > > Any scheme that insists on only tying to the EE cert or key is going to= > create a major operational headache for those sites. It is really easy = to > design a scheme that is easy to administer. is it more of an operational headache to get an external CA to sign a new key for each host each time it comes up "for a few hours"? or to just push the relevant pre-existing keys+certificates onto the hosts in question? > It is also going to cause huge amounts of state that the client has to > manage. If you have 10,000 front end web servers you are going to need > 10,000 different client keys to do the job right. eh? why? if these are front-end web servers hosting the same service, wouldn't they just share a key (and a certificate)? The only large organization i know of that uses one key per server is citibank, and many people are making decent arguments that this is problematic for other methods of identity verification (e.g. Perspectives and Convergence plugins) > So what most of the large enterprises would likely do if they introduce= d any > form of security policy would be to have a private CA run up that is an= > intermediate in a larger hierarchy. Sure, as i pointed out, the only reason you'd want to pin a CA is if the CA is under your own organization's direct control. > This is why the bogus EFF study came up > with the absurd number of 600 CAs. What they have never come clean on i= s the > fact that 150 of those 'CAs' are in fact merely intermediate roots tied= to a > single customer that are managed in the same infrastructure as the root= CA > operations. if those intermediate authorities are not explicitly domain-restricted *in their own certificate*, then yes -- the risk is larger. i don't > What pinning to a CA does raise is the absolute need to have the abilit= y to > pin more than one CA at a time. i think for rollover purposes, you already need to be able to pin multiple certs if you're pinning an EE. Still unconvinced, --dkg --------------enig59D969115E03CB39ED0224AB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJOcMSrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznppjgQAJW17j2DioWcGAmzXB9Daik0 MlA/EDZFvVFZorVxco9zGonneAdUmHQdLGRWW/YXjptG+LnwrhvS+o5Jk1N5BRY+ rw6iyHQ5N4MUygiBR6APmPHJqVyCsHesZA0O7o0/ugweK0L/tZ8JHjRmGZzi+Pum wHR/jfEZHApMtANSd0xS9LhbJwElGv4dPHxGIdGLYS66SIYcaikOBSFZXWGIdIl3 yh9cT6rFu3wTk4jaSTpYle/ADulh/eAJ5cWY29H6Guc2Xc2/imaOOCRv7U9YXzPm XbcVetjzkFH4g2bb3MtezDLtF2rGWkD52lThF1N0JltKDBFWts2DZZTTBcjw6bhn 3Av1lg/QQkn7ii1Qasp/XECtTatvKKLzBiLEoyVRBRgSxqG/d2xEtv9VW+5FtBtW 2TG3d7JCSMAi1IqAkMT/PHO3nSrV/hHnX/thi3X23WJPjE1BpSAC3tNM37fnJYBj xQJTvNtqg000yFCvApHZDEzXvHupndAiswkio+zcCyql9Zz+yvtr8zsvidOjYVxr 9nIcnBXuj1GRqsZVvhKKvnTMhDfJsCqfy6E4Wa7LNbPbN/trCF4F3xx1khiENsII k46BaG9lqMmU5QuS4tB6U/3EJIMD9g7OoUI7gLavvcM9NHFac5nA7/+lJ0p/AntJ Sucjhf7gDPl7X4/kR6am =8dD8 -----END PGP SIGNATURE----- --------------enig59D969115E03CB39ED0224AB-- From dkg@fifthhorseman.net Wed Sep 14 08:28:51 2011 Return-Path: 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 BFBC621F8B3D for ; Wed, 14 Sep 2011 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 xFWnOlR6sgF2 for ; Wed, 14 Sep 2011 08:28:51 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4431F21F8B3C for ; Wed, 14 Sep 2011 08:28:51 -0700 (PDT) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 61468F970; Wed, 14 Sep 2011 11:30:59 -0400 (EDT) Message-ID: <4E70C8E2.3050604@fifthhorseman.net> Date: Wed, 14 Sep 2011 11:31:46 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110807 Icedove/5.0 MIME-Version: 1.0 To: IETF WebSec WG References: <4E6F5056.800@fifthhorseman.net> <4E70A8F8.80102@fifthhorseman.net> <4E70C4AB.7050206@fifthhorseman.net> In-Reply-To: <4E70C4AB.7050206@fifthhorseman.net> X-Enigmail-Version: 1.2.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig116AFA6A43637BA26646DB54" Cc: Chris Evans Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF WebSec WG List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 15:28:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig116AFA6A43637BA26646DB54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/14/2011 11:13 AM, Daniel Kahn Gillmor wrote: >> This is why the bogus EFF study came up >> with the absurd number of 600 CAs. What they have never come clean on = is the >> fact that 150 of those 'CAs' are in fact merely intermediate roots tie= d to a >> single customer that are managed in the same infrastructure as the roo= t CA >> operations. >=20 > if those intermediate authorities are not explicitly domain-restricted > *in their own certificate*, then yes -- the risk is larger. i don't sorry -- this got cut off somehow. =2E.. i don't think EFFs study is bogus in its analysis. "the same infrastructure" doesn't mean "using the same access controls" -- certainly customers in control of an intermediate root have more access to that root than other people, so there are additional risks to relying parties from them if they're not explicitly domain-restricted. Were these 150 intermediate certs explicitly domain-restricted in the certificates themselves? --dkg --------------enig116AFA6A43637BA26646DB54 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJOcMjiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpJsMQAILImwt5jrPe7FvfqBRmVh06 6iqtzHsUm2rRei93BrWScAba6WieTOLr0PX7vAeI21hLfRTWqDsS0lF+PgRGbWS3 KJEQFNSxxCdBqWbsvYOkIBP1RvIeyA3gplrb2SU2g7u3ToK9BPLgKDBcz1MaP4/w xFJhjzqSOztOXLlbQ2EQ86j3q9AhdxXxUtStb6qdixbTdaE+ZRup6KPpB66RwtEm 1DNFgrqcBClv+S6DvD+Dxk8GD/vxXqyk7sWxqHOOfM3p94qcY1wWtUWIl5v0JhZ0 VRGsK5BMxaEyAT1dKqBOyECtCN0jz6Z0lTde3/WqGCU0BFahZH90SdI/Wljb7i7G rUVquZsK4xjbdcH6bFVQu4lfLI4uTDOD76/bgoZ/zTJi22EnKG4ghpSbZ/lVHNku dMwCQuBX5Du+jUtN10QK0CYdSbQFgrtRRsuWuAx6UtC2sek7zCpZAWCLA13ayySz g8Vwaz6NifOBN5N0k2u4ONFZlblXNlAvx+5vdkfE9vZK85F8Q3Oq561m1kslV/TM 2LOEpcY8mioT3EjlxA0hmIBLxRcETgtWaLV+RZpMrSX+5mqIBvgJm76Wz6NpG6Td JScgqt13GJ2UpOfEnYxB2WuaxHHBKaokMFjDIGaODjoD/Tk9jrUPoEAwYxWpQYpY /yitiZ+F6yRUeP1qqRbO =U/YS -----END PGP SIGNATURE----- --------------enig116AFA6A43637BA26646DB54-- From hallam@gmail.com Wed Sep 14 09:42:22 2011 Return-Path: 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 01EF721F8B9B for ; Wed, 14 Sep 2011 09:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 DvDWpR21nYBW for ; Wed, 14 Sep 2011 09:42:20 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C00D321F8B6C for ; Wed, 14 Sep 2011 09:42:20 -0700 (PDT) Received: by yxt33 with SMTP id 33so1753630yxt.31 for ; Wed, 14 Sep 2011 09:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ef4qx3mIh+WU2EACEXtEQEY94PjcJCUW5gow2WEtvQA=; b=J45i1aAuU3iU1pYaXZUJoE3j99yHKgAUkyvLP7D/0Eu4csbgy85xwR22d6V9k6LPTW gHgUQLjq/kEQJiXSZd3fPTgUhuOxCVT3/YtpnUakilQn/DRsq7jA+Lha39TE8xAdRlml HFTUF34MLFbr12gm0EpgN4DUQ+G4ibL/V4Pv4= MIME-Version: 1.0 Received: by 10.101.11.36 with SMTP id o36mr47912ani.74.1316018670038; Wed, 14 Sep 2011 09:44:30 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 09:44:29 -0700 (PDT) In-Reply-To: <4E70C4AB.7050206@fifthhorseman.net> References: <4E6F5056.800@fifthhorseman.net> <4E70A8F8.80102@fifthhorseman.net> <4E70C4AB.7050206@fifthhorseman.net> Date: Wed, 14 Sep 2011 12:44:29 -0400 Message-ID: From: Phillip Hallam-Baker To: IETF WebSec WG Content-Type: multipart/alternative; boundary=0016e68ef45758701104ace979ab Cc: Chris Evans Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 16:42:22 -0000 --0016e68ef45758701104ace979ab Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 14, 2011 at 11:13 AM, Daniel Kahn Gillmor wrote: > On 09/14/2011 09:46 AM, Phillip Hallam-Baker wrote: > > It gives you scaling and administrative convenience. > > > > If you have 10,000 hosts in your enterprise network you really do not > want > > to have to be managing trust on a per host level. > > You're not "managing trust on a per host level" -- you're managing > *identity* on a per-host level, which is exactly what it should be. If > you have 10K hosts, you need to think clearly about the identity > presented by each of those hosts. Identity is a property of the site, the host is merely an implementation detail. > > Now consider the case > > where you are renting your compute power in the cloud and so the machine > > instances are existing for a few hours at a time. > > > > Any scheme that insists on only tying to the EE cert or key is going to > > create a major operational headache for those sites. It is really easy to > > design a scheme that is easy to administer. > > is it more of an operational headache to get an external CA to sign a > new key for each host each time it comes up "for a few hours"? or to > just push the relevant pre-existing keys+certificates onto the hosts in > question? I really hate having private keys move off a host. If people are going to be doing that pattern of hosting I would prefer to have keys tied to the virtual hosts such that they are generated in place and never ever move from the host. Then have certs generated with short lived expiry (36 hours), that way the attack surface is kept to a bare minimum. > > It is also going to cause huge amounts of state that the client has to > > manage. If you have 10,000 front end web servers you are going to need > > 10,000 different client keys to do the job right. > > eh? why? if these are front-end web servers hosting the same service, > wouldn't they just share a key (and a certificate)? The only large > organization i know of that uses one key per server is citibank, and > many people are making decent arguments that this is problematic for > other methods of identity verification (e.g. Perspectives and > Convergence plugins) Keys should be unique to the host and never move from the host. It is certainly not just citibank that has that scheme. > > > This is why the bogus EFF study came up > > with the absurd number of 600 CAs. What they have never come clean on is > the > > fact that 150 of those 'CAs' are in fact merely intermediate roots tied > to a > > single customer that are managed in the same infrastructure as the root > CA > > operations. > > if those intermediate authorities are not explicitly domain-restricted > *in their own certificate*, then yes -- the risk is larger. i don't Not if the signing keys are in the same hardware module as the intermediate they are signed under. The problem is that PKIX policy constraints don't really have the leverage they should in the real world. And even if they did they don't necessarily map to real world organizational divisions. A large organization will typically own many DNS names. The issue is where validation is performed and if the RA has independent issue authority or not. At this point the government of Iran has solved that particular problem. > > What pinning to a CA does raise is the absolute need to have the ability > to > > pin more than one CA at a time. > > i think for rollover purposes, you already need to be able to pin > multiple certs if you're pinning an EE. > > Still unconvinced, It is an operational issue. There is practically no difference in the code between only checking the EE cert or key and checking intermediate certs/keys. Designs should be as simple as possible BUT NO SIMPLER. The 'I don't see the need, therefore I will obstruct feature X' approach is the reason that PKIX has become what it is. We could have had policy constraints and cross certificate mechanisms that really worked the way we wanted if they had been baked in on day one. Instead they have become a black art which can be practiced by a very small circle of people and even they will tell you how broken the system is. Give operators the tools to do their job, do not presume to tell them how to secure their systems. -- Website: http://hallambaker.com/ --0016e68ef45758701104ace979ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 14, 2011 at 11:13 AM, Daniel= Kahn Gillmor <dkg@fifthhorseman.net> wrote:

On 09/14/2011 09:46 AM, Phillip Hallam-Baker wrote:
> It gives you scaling and administrative convenience.
>
> If you have 10,000 hosts in your enterprise network you really do not = want
> to have to be managing trust on a per host level.

You're not "managing trust on a per host level" -- you&= #39;re managing
*identity* on a per-host level, which is exactly what it should be. =A0If you have 10K hosts, you need to think clearly about the identity
presented by each of those hosts.

Identity = is a property of the site, the host is merely an implementation detail.

=A0

> Now consider the case
> where you are renting your compute power in the cloud and so the machi= ne
> instances are existing for a few hours at a time.
>
> Any scheme that insists on only tying to the EE cert or key is going t= o
> create a major operational headache for those sites. It is really easy= to
> design a scheme that is easy to administer.

is it more of an operational headache to get an external CA to sign a=
new key for each host each time it comes up "for a few hours"? = =A0or to
just push the relevant pre-existing keys+certificates onto the hosts in
question?

I really hate having private keys= move off a host.=A0

If people are going to be doi= ng that pattern of hosting I would prefer to have keys tied to the virtual = hosts such that they are generated in place and never ever move from the ho= st. Then have certs generated with short lived expiry (36 hours), that way = the attack surface is kept to a bare minimum.

=A0

> It is also going to cause huge amounts of state that the client has to=
> manage. If you have 10,000 front end web servers you are going to need=
> 10,000 different client keys to do the job right.

eh? =A0why? =A0if these are front-end web servers hosting the same se= rvice,
wouldn't they just share a key (and a certificate)? =A0The only large organization i know of that uses one key per server is citibank, and
many people are making decent arguments that this is problematic for
other methods of identity verification (e.g. Perspectives and
Convergence plugins)

Keys should be unique = to the host and never move from the host.

It is ce= rtainly not just citibank that has that scheme.=A0

=A0

> This is why the bogus EFF study came up
> with the absurd number of 600 CAs. What they have never come clean on = is the
> fact that 150 of those 'CAs' are in fact merely intermediate r= oots tied to a
> single customer that are managed in the same infrastructure as the roo= t CA
> operations.

if those intermediate authorities are not explicitly domain-restricte= d
*in their own certificate*, then yes -- the risk is larger. =A0i don't<= /blockquote>

Not if the signing keys are in the same har= dware module as the intermediate they are signed under.

The problem is that PKIX policy constraints don't really have the = leverage they should in the real world. And even if they did they don't= necessarily map to real world organizational divisions. A large organizati= on will typically own many DNS names.=A0

The issue is where validation is performed and if the R= A has independent issue authority or not.=A0

At th= is point the government of Iran has solved that particular problem.=A0

=A0
> What pinning to a CA does raise is the absolute need to have the abili= ty to
> pin more than one CA at a time.

i think for rollover purposes, you already need to be able to pin
multiple certs if you're pinning an EE.

Still unconvinced,

It is an operational iss= ue. There is practically no difference in the code between only checking th= e EE cert or key and checking intermediate certs/keys.

Designs should be as simple as possible BUT NO SIMPLER.

The 'I don't see the need, therefore I will ob= struct feature X' approach is the reason that PKIX has become what it i= s. We could have had policy constraints and cross certificate mechanisms th= at really worked the way we wanted if they had been baked in on day one. In= stead they have become a black art which can be practiced by a very small c= ircle of people and even they will tell you how broken the system is.

Give operators the tools to do their job, do not presum= e to tell them how to secure their systems.

--
Webs= ite: http://hallambaker.com/
--0016e68ef45758701104ace979ab-- From hallam@gmail.com Wed Sep 14 09:44:44 2011 Return-Path: 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 8307721F8BB9 for ; Wed, 14 Sep 2011 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 84z3xTdc6XYe for ; Wed, 14 Sep 2011 09:44:44 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E392821F8BB2 for ; Wed, 14 Sep 2011 09:44:43 -0700 (PDT) Received: by yxt33 with SMTP id 33so1755914yxt.31 for ; Wed, 14 Sep 2011 09:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RorZ0UeDNpbU65vPv9tKUML34Z/bY3fkHOkUtAYFLc8=; b=emn58RfR1LKXWCQ+635Ra+WF+of60FxzLC4QMbFGUnZzD13UolGTZRrcRSbmZEvpQM fda5SdM5Tu6fr5kphVre//hxOslnWyTQlI2lQdJnaCLiYO6c8+8grWUFyRUpQOHxO9UC Ccg92Bw41EbVH2Jva/LTNtGudPQe2v00OsGI0= MIME-Version: 1.0 Received: by 10.100.192.5 with SMTP id p5mr40963anf.96.1316018812976; Wed, 14 Sep 2011 09:46:52 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 09:46:52 -0700 (PDT) In-Reply-To: <4E70C8E2.3050604@fifthhorseman.net> References: <4E6F5056.800@fifthhorseman.net> <4E70A8F8.80102@fifthhorseman.net> <4E70C4AB.7050206@fifthhorseman.net> <4E70C8E2.3050604@fifthhorseman.net> Date: Wed, 14 Sep 2011 12:46:52 -0400 Message-ID: From: Phillip Hallam-Baker To: IETF WebSec WG Content-Type: multipart/alternative; boundary=0016e6440216dd7d6504ace98187 Cc: Chris Evans Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 16:44:44 -0000 --0016e6440216dd7d6504ace98187 Content-Type: text/plain; charset=ISO-8859-1 They claimed 600 CAs on the Internet. Their claim was disproved, the intermediate roots are not under direct control of the customers. They did not retract or clarify That is not how reputable academics do their work. They were making a political statement using Fox News type tactics. On Wed, Sep 14, 2011 at 11:31 AM, Daniel Kahn Gillmor wrote: > On 09/14/2011 11:13 AM, Daniel Kahn Gillmor wrote: > >> This is why the bogus EFF study came up > >> with the absurd number of 600 CAs. What they have never come clean on is > the > >> fact that 150 of those 'CAs' are in fact merely intermediate roots tied > to a > >> single customer that are managed in the same infrastructure as the root > CA > >> operations. > > > > if those intermediate authorities are not explicitly domain-restricted > > *in their own certificate*, then yes -- the risk is larger. i don't > > sorry -- this got cut off somehow. > > ... i don't think EFFs study is bogus in its analysis. "the same > infrastructure" doesn't mean "using the same access controls" -- > certainly customers in control of an intermediate root have more access > to that root than other people, so there are additional risks to relying > parties from them if they're not explicitly domain-restricted. > > Were these 150 intermediate certs explicitly domain-restricted in the > certificates themselves? > > --dkg > > -- Website: http://hallambaker.com/ --0016e6440216dd7d6504ace98187 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable They claimed 600 CAs on the Internet.=A0

Their claim was= disproved, the intermediate roots are not under direct control of the cust= omers.=A0

They did not retract or clarify

That is not how reputable academics do their = work. They were making a political statement using Fox News type tactics.

On Wed, Sep 14, 2011 at 11:= 31 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

On 09/14/2011 11:13 AM, D= aniel Kahn Gillmor wrote:
>> This is why the bogus EFF study came up
>> with the absurd number of 600 CAs. What they have never come clean= on is the
>> fact that 150 of those 'CAs' are in fact merely intermedia= te roots tied to a
>> single customer that are managed in the same infrastructure as the= root CA
>> operations.
>
> if those intermediate authorities are not explicitly domain-restricted=
> *in their own certificate*, then yes -- the risk is larger. =A0i don&#= 39;t

sorry -- this got cut off somehow.

... i don't think EFFs study is bogus in its analysis. =A0"the sam= e
infrastructure" doesn't mean "using the same access controls&= quot; --
certainly customers in control of an intermediate root have more access
to that root than other people, so there are additional risks to relying parties from them if they're not explicitly domain-restricted.

Were these 150 intermediate certs explicitly domain-restricted in the
certificates themselves?

=A0 =A0 =A0 =A0--dkg

--
Websi= te: http://hallambaker.com/

--0016e6440216dd7d6504ace98187-- From dkg@fifthhorseman.net Wed Sep 14 10:35:08 2011 Return-Path: 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 3AF3521F8C60 for ; Wed, 14 Sep 2011 10:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] 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 JxsRlA4Dn5bQ for ; Wed, 14 Sep 2011 10:35:07 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8A621F8C10 for ; Wed, 14 Sep 2011 10:35:07 -0700 (PDT) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 5F3A4F970; Wed, 14 Sep 2011 13:37:14 -0400 (EDT) Message-ID: <4E70E67A.5030409@fifthhorseman.net> Date: Wed, 14 Sep 2011 13:38:02 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110807 Icedove/5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E6F5056.800@fifthhorseman.net> <4E70A8F8.80102@fifthhorseman.net> <4E70C4AB.7050206@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.2.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig940CB68BE9D238B8A7C5FD5D" Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF WebSec WG List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 17:35:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig940CB68BE9D238B8A7C5FD5D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/14/2011 12:44 PM, Phillip Hallam-Baker wrote: > On Wed, Sep 14, 2011 at 11:13 AM, Daniel Kahn Gillmor > wrote: > I really hate having private keys move off a host. >=20 > If people are going to be doing that pattern of hosting I would prefer = to > have keys tied to the virtual hosts such that they are generated in pla= ce > and never ever move from the host. Then have certs generated with short= > lived expiry (36 hours), that way the attack surface is kept to a bare > minimum. I personally like this approach and i use multiple keys for different hosts serving the same domain for at least one domain i administer myself. i also note that it is diametrically opposed to your earlier stated goal of avoiding "major operational headache", particularly when using an external CA. I was trying to offer a way to avoid major operational headache in my proposal. Of course, the other way to avoid the headache in this is to use an in-house CA, but of course that gets back to my "the only reasonable CA to pin is an in-house CA". > Keys should be unique to the host and never move from the host. >=20 > It is certainly not just citibank that has that scheme. Are these other organizations public? I'm looking to compile a list of groups that do this to raise this concern with the Convergence/Perpsectives folks, since these always show up as bad under their model of analysis. Feel free to mail the the list privately if you don't want to publish it, or if you feel it is off-topic for this lis= t. >> if those intermediate authorities are not explicitly domain-restricted= >> *in their own certificate*, then yes -- the risk is larger. i don't >=20 > Not if the signing keys are in the same hardware module as the intermed= iate > they are signed under. You're asking me to assume a whole stack of things about operational integrity, access control, system maintenance, and coding practice at various CAs. I have no idea whether any of these things are true for any CA in particular. All i know is that there is a CA that is nominally under the control of a separate organization. I'd happy if someone could prove that these intermediate CAs are actually all locked down under very high security and properly limited in what kinds of certificates they can issue; but i'm not convinced such a proof is possible. And given the recent events, i'd have no confidence in an unproved assertion of secure operations of these subordinate CAs. > It is an operational issue. There is practically no difference in the c= ode > between only checking the EE cert or key and checking intermediate > certs/keys. >=20 > Designs should be as simple as possible BUT NO SIMPLER. >=20 > The 'I don't see the need, therefore I will obstruct feature X' approac= h is > the reason that PKIX has become what it is. We could have had policy > constraints and cross certificate mechanisms that really worked the way= we > wanted if they had been baked in on day one. Instead they have become a= > black art which can be practiced by a very small circle of people and e= ven > they will tell you how broken the system is. >=20 > Give operators the tools to do their job, do not presume to tell them h= ow to > secure their systems. The draft as initially proposed included both explicit mechanism and several "best practice" recommendations (e.g. pin rollover and backup). I think these recommendations were good ones, and contribute a lot toward making the draft clear and useful to the people who will have to deploy the mechanism. If this becomes an RFC, i'd hope these recommendations would persist in a "SECURITY CONSIDERATIONS" section or the equivalent. I'm proposing an additional recommendation: unless you control and operate your own CA, you probably only want to pin EEs. Regards, --dkg --------------enig940CB68BE9D238B8A7C5FD5D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJOcOZ7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpqlgP+gIT4+R3tzs3QCpHVhcKxkMo 3P0UrZ0rXJkmcLiDYSWXWE2V8Za9NR9Sxd8xF5m8UAMfTWXH1R8JiHrnruEwZt0I bV9Prc/Qu83FfHks5zJ36+CHH610T1FIc+s52u8Er3gyT15oKFlFbNxuRCflVxKm 6hDKH8ZwABxYWWxDy7OxyQfgCc1olfPStMzRKf2xAjkhHSPEHb56CPfV4IXBFVYd 0lLmg1OgiCLGDnQ5DeaMZSktMwIWsz8YH/WpATXnmR4T68az+AOT+n3yaXnLj/2i dJNOlwCyI0PHmd4Njw+FR954NqSJxpDPeOiwUbVcNj5I+6me27qSRDHUoMOHTp0I sLm3rVuvtlaKQKLbdFJrCRySf0FODSvvZF7AdoJi22Dc39Aqgl5VXXBGaWQFhLZ9 SPTjpqmub1hT4lHO5qimEQMmnZLbwBGXAX3zcqIV3HLIf814RXv4agPyD9/NYYb1 39I3fZEYed6991mpHTxgq8jXSyOcNoTmcPkY/5rh1fYEYwGznotmdglO9nwDhYeS qrCvrosuWhpXV67CjFTg8UI4KKL9uxQID/lUt8atSWtDTHG7GmUAu3oVNYZYKawq 5ngYx/iAMP/HNL6tIC2Q4TEoNEsNRbG5miujAZulZOoJNYfLr61GmQ9UWjEzjOxa jgoG/RuSKWgHGN7IcyIR =W+ta -----END PGP SIGNATURE----- --------------enig940CB68BE9D238B8A7C5FD5D-- From hallam@gmail.com Wed Sep 14 11:48:38 2011 Return-Path: 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 6EB8821F8BEB for ; Wed, 14 Sep 2011 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 IVc-cIvTsN-7 for ; Wed, 14 Sep 2011 11:48:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B850721F8C29 for ; Wed, 14 Sep 2011 11:48:36 -0700 (PDT) Received: by yxt33 with SMTP id 33so1873227yxt.31 for ; Wed, 14 Sep 2011 11:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pRgL+lyfIVoELznZjkEqSpWyMCXDxLNcaYlnovizpZ8=; b=g+hxMt1gC/i7ng0WKmFqYRTuz2g+Ve0cR066gw6agHcRlYDl7CwVrr+LWjZk7nb+1l ICVisQYoz2GSVYVhIntvATbT1dkMecWFrR2lG+z8MOEDzRTbVEt3rFawFcIJlZoYhiPB lKrwhGWTZS69UPNlzRACPzccpapFa6lvwH4U4= MIME-Version: 1.0 Received: by 10.101.63.5 with SMTP id q5mr156204ank.140.1316026246230; Wed, 14 Sep 2011 11:50:46 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 11:50:46 -0700 (PDT) In-Reply-To: <4E70E67A.5030409@fifthhorseman.net> References: <4E6F5056.800@fifthhorseman.net> <4E70A8F8.80102@fifthhorseman.net> <4E70C4AB.7050206@fifthhorseman.net> <4E70E67A.5030409@fifthhorseman.net> Date: Wed, 14 Sep 2011 14:50:46 -0400 Message-ID: From: Phillip Hallam-Baker To: IETF WebSec WG Content-Type: multipart/alternative; boundary=001636eee26debf3a104aceb3c56 Cc: Chris Evans Subject: Re: [websec] Certificate Pinning via HSTS X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 18:48:38 -0000 --001636eee26debf3a104aceb3c56 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 14, 2011 at 1:38 PM, Daniel Kahn Gillmor wrote: > > I personally like this approach and i use multiple keys for different > hosts serving the same domain for at least one domain i administer > myself. i also note that it is diametrically opposed to your earlier > stated goal of avoiding "major operational headache", particularly when > using an external CA. I was trying to offer a way to avoid major > operational headache in my proposal. > Not really. Operating infrastructure on a large scale, the issue is not the number of operations required but the number of interdependencies between systems. Having keys that never leave the machine eliminates a lot of the management issues to do with equipment that is lost, stolen etc with the keys loaded. If you have 10 machines it is pretty obvious that you have lost one. On a large installation racks of equipment can be appearing/disappearing on a bewildering basis. And it is not uncommon for theft to be an insider who is selling off machinery that is being booked as destroyed. The way I would ideally lock a key to a host is to have a permanent host key that is unique to that device and only used for authenticating cert requests. To instantiate an instance of some server the data center pushes out the server image and a one time use authentication key that is used to authenticate a cert request for that specific machine. The host generates a new key per cert request. That approach allows a system where all the data flows are unidirectional, no three way synchronization etc. > Of course, the other way to avoid the headache in this is to use an > in-house CA, but of course that gets back to my "the only reasonable CA > to pin is an in-house CA". We can get to agreement on a 'house specific CA'. Running it in-house is a pain and is going to get worse over time as the criteria for public CAs are raised by the browser providers. Where I think we might want to shoot for with this would be to look for dual control points and a key splitting type approach. > > Keys should be unique to the host and never move from the host. > > > > It is certainly not just citibank that has that scheme. > > Are these other organizations public? I'm looking to compile a list of > groups that do this to raise this concern with the > Convergence/Perpsectives folks, since these always show up as bad under > their model of analysis. Feel free to mail the the list privately if > you don't want to publish it, or if you feel it is off-topic for this list I would think that would be proprietary and customer confidential and I would have to ask a former employer. It is easier to measure than make the request. Just look for companies that have multiple A records and then see if they have the same cert or not. >> if those intermediate authorities are not explicitly domain-restricted > >> *in their own certificate*, then yes -- the risk is larger. i don't > > > > Not if the signing keys are in the same hardware module as the > intermediate > > they are signed under. > > You're asking me to assume a whole stack of things about operational > integrity, access control, system maintenance, and coding practice at > various CAs. I have no idea whether any of these things are true for > any CA in particular. All i know is that there is a CA that is > nominally under the control of a separate organization. > No, it is not a CA, according to the defined terms, the CA performs the validation and signature function. If there are 150 keys in one HSM they are under control of one CA, not 150. The fact that a CA issues some certs for a given customer off a different intermediate to their other customers does not increase the number of signing parties. Such a customer might well have had a local RA capability, but that should have been locked down so they could only issue for their roots. At this point I very much doubt that there are any such RAs being operated as a true RA without the CA performing full validation of the requests. Thank the Iranian government for that change in practice. There is a slight difference in the trust model in that such an intermediate root can be and is frequently used to provide authorization data. This is mostly used for client certs. But if the proposal being discussed here went through there would be a real value to the key splitting approach outlined above for servers. I'd happy if someone could prove that these intermediate CAs are > actually all locked down under very high security and properly limited > in what kinds of certificates they can issue; but i'm not convinced such > a proof is possible. > It is the job of the certificate policy requirements to make those demands explicit and of the auditors to ensure that they are enforced. One of the reasons that Comodo has been pushing to introduce baseline requirements for all public CA issued certs is to get some controls into the system that can be checked by auditors. We have these requirements for EV certs, until recently we did not have the requirements for DV certs. > And given the recent events, i'd have no confidence in an unproved > assertion of secure operations of these subordinate CAs. It definitely needs to be audited. But we definitely need to have additional controls that can be used when the auditors don't do their job. The fact that the Diginotar root was revoked has woken up anyone who still needed it. > The draft as initially proposed included both explicit mechanism and > several "best practice" recommendations (e.g. pin rollover and backup). > I think these recommendations were good ones, and contribute a lot > toward making the draft clear and useful to the people who will have to > deploy the mechanism. > > If this becomes an RFC, i'd hope these recommendations would persist in > a "SECURITY CONSIDERATIONS" section or the equivalent. > That is fine. I think we can write a set of security considerations that are pretty much the advice you give and direct them at the smaller to medium sites that turn SCs into operational policy. > I'm proposing an additional recommendation: unless you control and > operate your own CA, you probably only want to pin EEs. > How about we split the difference? We can leave in control. Just take out 'operate'. My preference for the larger enterprise would be a split key approach. That reduces my liability and risk. By the time this is all through I think the number of people still willing to operate CAs is going to be a much smaller set than in the past. Regards, > > --dkg > > -- Website: http://hallambaker.com/ --001636eee26debf3a104aceb3c56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 14, 2011 at 1:38 PM, Daniel = Kahn Gillmor <dkg@fifthhorseman.net> wrote:

I personally like this approach and i use multi= ple keys for different
hosts serving the same domain for at least one domain i administer
myself. =A0i also note that it is diametrically opposed to your earlier
stated goal of avoiding "major operational headache", particularl= y when
using an external CA. =A0I was trying to offer a way to avoid major
operational headache in my proposal.

No= t really. Operating infrastructure on a large scale, the issue is not the n= umber of operations required but the number of interdependencies between sy= stems.=A0

Having keys that never leave the machine eliminates a l= ot of the management issues to do with equipment that is lost, stolen etc w= ith the keys loaded. If you have 10 machines it is pretty obvious that you = have lost one. On a large installation racks of equipment can be appearing/= disappearing on a bewildering basis. And it is not uncommon for theft to be= an insider who is selling off machinery that is being booked as destroyed.= =A0

The way I would ideally lock a key to a = host is to have a permanent host key that is unique to that device and only= used for authenticating cert requests. To instantiate an instance of some = server the data center pushes out the server image and a one time use authe= ntication key that is used to authenticate a cert request for that specific= machine. The host generates a new key per cert request.

That approach allows a system where all the data flows = are unidirectional, no three way synchronization etc.

<= div>=A0
Of course, the other way to avoid the headache in this is to use an
in-house CA, but of course that gets back to my "the only reasonable C= A
to pin is an in-house CA".

We can get = to agreement on a 'house specific CA'.

Run= ning it in-house is a pain and is going to get worse over time as the crite= ria for public CAs are raised by the browser providers.

Where I think we might want to shoot for with this woul= d be to look for dual control points and a key splitting type approach.=A0<= /div>
=A0

> Keys should be unique to the host and never move from the host.
>
> It is certainly not just citibank that has that scheme.

Are these other organizations public? =A0I'm looking to compile a= list of
groups that do this to raise this concern with the
Convergence/Perpsectives folks, since these always show up as bad under
their model of analysis. =A0Feel free to mail the the list privately if
you don't want to publish it, or if you feel it is off-topic for this l= ist

I would think that would be proprietary= and customer confidential and I would have to ask a former employer.

It is easier to measure than make the request. Just loo= k for companies that have multiple A records and then see if they have the = same cert or not.

>> if those intermediate authorities are not explicitly domain-restri= cted
>> *in their own certificate*, then yes -- the risk is larger. =A0i d= on't
>
> Not if the signing keys are in the same hardware module as the interme= diate
> they are signed under.

You're asking me to assume a whole stack of things about operatio= nal
integrity, access control, system maintenance, and coding practice at
various CAs. =A0I have no idea whether any of these things are true for
any CA in particular. =A0All i know is that there is a CA that is
nominally under the control of a separate organization.

No, it is not a CA, according to the defined terms, the CA= performs the validation and signature function. If there are 150 keys in o= ne HSM they are under control of one CA, not 150.

The fact that a CA issues some certs for a given custom= er off a different intermediate to their other customers does not increase = the number of signing parties.

Such a customer mig= ht well have had a local RA capability, but that should have been locked do= wn so they could only issue for their roots. At this point I very much doub= t that there are any such RAs being operated as a true RA without the CA pe= rforming full validation of the requests. Thank the Iranian government for = that change in practice.

There is a slight difference in the trust model in that= such an intermediate root can be and is frequently used to provide authori= zation data. This is mostly used for client certs. But if the proposal bein= g discussed here went through there would be a real value to the key splitt= ing approach outlined above for servers.

I'd happy if someone could prove that these intermediate CAs are
actually all locked down under very high security and properly limited
in what kinds of certificates they can issue; but i'm not convinced suc= h
a proof is possible.

It is the job of t= he certificate policy requirements to make those demands explicit and of th= e auditors to ensure that they are enforced.

One of the reasons that Comodo has been pushing to introduce baseline requi= rements for all public CA issued certs is to get some controls into the sys= tem that can be checked by auditors.

We have these= requirements for EV certs, until recently we did not have the requirements= for DV certs.=A0

=A0
And given the recent events, i'd have no confidence in an unproved
assertion of secure operations of these subordinate CAs.
<= br>
It definitely needs to be audited. But we definitely need to = have additional controls that can be used when the auditors don't do th= eir job.

The fact that the Diginotar root was revoked has woken = up anyone who still needed it.
=A0
The draft as initially proposed included both explicit mechanism and
several "best practice" recommendations (e.g. pin rollover and ba= ckup).
=A0I think these recommendations were good ones, and contribute a lot
toward making the draft clear and useful to the people who will have to
deploy the mechanism.

If this becomes an RFC, i'd hope these recommendations would persist in=
a "SECURITY CONSIDERATIONS" section or the equivalent.

That is fine.

I think we= can write a set of security considerations that are pretty much the advice= you give and direct them at the smaller to medium sites that turn SCs into= operational policy.

=A0
I'm proposing an additional recommendation: unless you control and
operate your own CA, you probably only want to pin EEs.

How about we split the difference? We can leave in control= . Just take out 'operate'.

My preference f= or the larger enterprise would be a split key approach. That reduces my lia= bility and risk.

By the time this is all through I think the number of p= eople still willing to operate CAs is going to be a much smaller set than i= n the past.=A0

Regards,

=A0 =A0 =A0 =A0--dkg

--
Websi= te: http://hallambaker.com/

--001636eee26debf3a104aceb3c56-- From hallam@gmail.com Wed Sep 14 12:48:33 2011 Return-Path: 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 16E4621F86DD for ; Wed, 14 Sep 2011 12:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 u-Bwhafa5j3b for ; Wed, 14 Sep 2011 12:48:32 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3377821F86D0 for ; Wed, 14 Sep 2011 12:48:32 -0700 (PDT) Received: by yie12 with SMTP id 12so1932559yie.31 for ; Wed, 14 Sep 2011 12:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0PhmdM4Z9vIwqpyLH1wdAq2Eswt0YsY+7GNvoTQPfnY=; b=qRn1CGrY49i9Ev46YyAMexRpq0jEca4jth8E4KyxeXIL0fQMHAGllsy5BelMRFc6l9 t4+8FlOXFKpTmY3hMIDmt87QnmBLD/IdDXKDuoPoJikoxROSlihu8/PdAukD8tijA+ea sdlL9sf/lCrgzaf6CpHogw03yftveonRmHxhs= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr250957anb.52.1316029841707; Wed, 14 Sep 2011 12:50:41 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 12:50:41 -0700 (PDT) In-Reply-To: <4E6FDED1.9000209@gondrom.org> References: <4E6FDED1.9000209@gondrom.org> Date: Wed, 14 Sep 2011 15:50:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Tobias Gondrom Content-Type: multipart/alternative; boundary=005045016fd73a950604acec13b4 Cc: websec@ietf.org Subject: Re: [websec] websec meeting in Taipei - topics? X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 19:48:33 -0000 --005045016fd73a950604acec13b4 Content-Type: text/plain; charset=ISO-8859-1 I would like to know early if cert pinning is going to be on the agenda as that is likely to be the reason I would decide to go to Taipei or not. I am not actually that bothered about the choice of format or syntax. But as I posted earlier, we have four potential types of data that are security policy related and four distinct delivery mechanisms. I would like us to end up with one syntax and one set of semantics across all four delivery mechanisms. To do otherwise is to take a ticket to hell in a handbasket. On Tue, Sep 13, 2011 at 6:53 PM, Tobias Gondrom wrote: > Hello dear websec fellows, > > to decide on a slot and length for our meeting in November in Taipei, this > time we would like to start a bit earlier asking for presentations, topics > and ideas. > > Please send proposals and ideas for presentations to Alexey, Yoav and/or > me, if possible until Sep-25 so we can better decide on the length of the > meeting slot, but later will also be ok. Rough ideas are fine at this stage, > anything that will help us in planning the length and scope of the meeting. > > So far we had great progress on the origin draft, entering IESG next week. > So this will most certainly be finished by then. > We could focus on HSTS and the interesting parts of "certificate pinning" > as important topics to make major progress now. > > But I want to also emphasise looking for further topics and presentations. > Anything you would like to raise at the websec meeting, please drop me a > quick note. > > Kind regards, > > Tobias & Alexey > (chairs of websec) > > > > Tobias Gondrom > email: tobias.gondrom@gondrom.org > mobile: +447521003005 > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > -- Website: http://hallambaker.com/ --005045016fd73a950604acec13b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to know early if cert pinning is going to be on the agenda as = that is likely to be the reason I would decide to go to Taipei or not.

I am not actually that bothered about the cho= ice of format or syntax. But as I posted earlier, we have four potential ty= pes of data that are security policy related and four distinct delivery mec= hanisms.=A0

I would like us to end up with one syntax and one set o= f semantics across all four delivery mechanisms. To do otherwise is to take= a ticket to hell in a handbasket.

On Tue, Sep 13, 2011 at 6:53 PM, Tobias Gondrom <tobias.gondrom@gondrom.org>= wrote:

=20 =20 =20
Hello dear websec fellows,

to decide on a slot and length for our meeting in November in Taipei, this time we would like to start a bit earlier asking for presentations, topics and ideas.

Please send proposals and ideas for presentations to Alexey, Yoav and/or me, if possible until Sep-25 so we can better decide on the length of the meeting slot, but later will also be ok. Rough ideas are fine at this stage, anything that will help us in planning the length and scope of the meeting.

So far we had great progress on the origin draft, entering IESG next week. So this will most certainly be finished by then.
We could focus on HSTS and the interesting parts of "certificate pinning" as important topics to make major progress now.

But I want to also emphasise looking for further topics and presentations.
Anything you would like to raise at the websec meeting, please drop me a quick note.

Kind regards,

Tobias & Alexey
(chairs of websec)

Tobias Gondrom
email: = tobias.gondrom@gondrom.org
mobile: +447521003005

_______________________________________________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec

--
Website:= http://hallambaker.com/

--005045016fd73a950604acec13b4-- From Jeff.Hodges@KingsMountain.com Wed Sep 14 14:06:06 2011 Return-Path: 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 95A3521F8CE3 for ; Wed, 14 Sep 2011 14:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.524 X-Spam-Level: X-Spam-Status: No, score=-100.524 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 mz6KO--saOLD for ; Wed, 14 Sep 2011 14:06:06 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 27BA521F8CC3 for ; Wed, 14 Sep 2011 14:06:05 -0700 (PDT) Received: (qmail 20393 invoked by uid 0); 14 Sep 2011 21:08:15 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 14 Sep 2011 21:08:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=AMsrKIJA8ZktQbvh5LD3Dp17n2ZbUQQTVqMbTUikBNI=; b=5k1ssk5ozkB5jJ0/frvZbeVv9h+/80gH5Ol2xo+VEQZGu+eesp8Ug4BUiyerDSkQJoXMyGfUb6kgk5G+hsj+2SA9rlF2s0lk8uQTPV9bMhWANnw2eqS94jFTRc5V7M+G; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.226]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R3wgo-0007tJ-U2 for websec@ietf.org; Wed, 14 Sep 2011 15:08:14 -0600 Message-ID: <4E7117BF.1040608@KingsMountain.com> Date: Wed, 14 Sep 2011 14:08:15 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] effective request URI def, was: I-D Action: draft-ietf-websec-strict-transport-sec-02.txt X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 21:06:06 -0000 thx again for the review Julian. Julian noted.. > > On 2011-08-06 01:34, =JeffH wrote: >> ... >> 12. Removed any and all dependencies on >> [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending >> on [RFC2616] only. Fixes issue ticket #12 >> . >> ... > > Not sure this is a good idea. > > The current text copies a known bug from > draft-ietf-httpbis-p1-messaging-15 (see > ). Fixed in my working copy: s/GET/OPTIONS/ > Also, the ABNF claims it's based on RFC 2616's definitions, but mentions > RFC 3986 in ABNF comments. This needs to be checked. Ok, checked it, found bugs (thanks), fixed in my working copy. Will certainly need further review. > Furthermore, there's a risk that HTTPbis will have to tune the > definition of Effective Request URI furthermore -- see > . (I realize > that's not your fault, but we somehow have to deal with this). Agreed. =JeffH From Jeff.Hodges@KingsMountain.com Wed Sep 14 14:06:17 2011 Return-Path: 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 EA9D521F8CF5 for ; Wed, 14 Sep 2011 14:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.523 X-Spam-Level: X-Spam-Status: No, score=-100.523 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 g6z3h6pjmknF for ; Wed, 14 Sep 2011 14:06:17 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 71B9C21F8CC3 for ; Wed, 14 Sep 2011 14:06:17 -0700 (PDT) Received: (qmail 598 invoked by uid 0); 14 Sep 2011 21:08:27 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 14 Sep 2011 21:08:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=eDzGCvhN7k9w6mJ6kgpENY8oFC8fDLzhXXrUPTfrNn4=; b=7N0R9by/APtZ+nxUr5GUc4EpnirHCKHTkAm+KC96zDD+3FilcXRGaEqW+syutgq/XHIrpz36ePR9BJuKaaVmN8IidA9QenytyCjhtRWi+mvxfwEPw9zPrrCBmuZGCpk4; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.226]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R3wh1-000844-AW for websec@ietf.org; Wed, 14 Sep 2011 15:08:27 -0600 Message-ID: <4E7117CB.9050203@KingsMountain.com> Date: Wed, 14 Sep 2011 14:08:27 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Strict-Transport-Security syntax X-BeenThere: websec@ietf.org 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: Wed, 14 Sep 2011 21:06:18 -0000 > a few questions about the header field syntax: > > Strict-Transport-Security = > "Strict-Transport-Security" ":" OWS STS-v OWS > > So the header field is *not* using the RFC2616 list syntax. So you can have > > Strict-Transport-Security: a; b > > but *not* > > Strict-Transport-Security: a > Strict-Transport-Security: b > > because that would be equivalent to > > Strict-Transport-Security: a, b > > (is this intentional?) well, it was not necessarily intentional as far as I recall. We either managed to overlook, or regarded as inappropriate for this header, the RFC2616 list syntax (i.e., the "#rule"), that defines such implicit comma-separated lists. Also, we'd noted that quite a number of header field definitions used semi-colons as a delimiter, but perhaps hadn't noted that those overall productions often are embedded within such comma-separated lists. However, in thinking about it a little bit, for this particular header field, as it's presently defined, it doesn't seem appropriate to have it explicitly be comma-separated repeatable (aka #rule), because only one instance of "S-T-S: max-age=n" is effective in terms of established the cached Known HSTS Host in the UA. > Also in > > ; value > STS-v = STS-d > / STS-d *( OWS ";" OWS STS-d OWS ) > > ; STS directive > STS-d = STS-d-cur / STS-d-ext > > ; defined STS directives > STS-d-cur = maxAge / [ includeSubDomains ] > > having includeSubDomains optional is a bit weird. > > This means that the empty string would be a valid STS-d-cur, thus an > empty header field is allowed... Ah, thanks, yes -- i was unsure of how to make includeSubDomains optional while max-age is required, and that hack didn't work. I've now re-worked it as below -- how's that look? thanks again, =JeffH Strict-Transport-Security = "Strict-Transport-Security" ":" OWS STS-v OWS ; STS header field value; must have a max-age: STS-v = max-age / max-age *( OWS ";" OWS STS-d OWS ) ; additional STS directives: STS-d = STS-d-cur / STS-d-ext ; currently defined STS directives, ; delta-seconds is 1*DIGIT and is from [RFC2616]: max-age = "max-age" OWS "=" OWS delta-seconds [ OWS v-ext ] STS-d-cur = includeSubDomains includeSubDomains = "includeSubDomains" [ OWS v-ext ] ; extension points STS-d-ext = name ; STS extension directive v-ext = value ; STS extension value name = token value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or ; [ ! .. : ] [ < .. ~ ] any visible chars other than ";" token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA ; visible (printing) characters, except visible ; separators. ; DIGIT, ALPHA, separators are from [RFC2616] ; Basic rules: OWS = *( [ CRLF ] WSP ) ; Optional White Space WSP = SP / HTAB CRLF = CR LF ; CR, LF, SP, HTAB are from [RFC2616] --- end From trac+websec@trac.tools.ietf.org Wed Sep 14 14:42:27 2011 Return-Path: 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 D7D6221F8CB8 for ; Wed, 14 Sep 2011 14:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 vDtcys3bmnEh for ; Wed, 14 Sep 2011 14:42:17 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B3D4A21F8CA4 for ; Wed, 14 Sep 2011 14:42:17 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R3xFk-0007QI-Kh; Wed, 14 Sep 2011 17:44:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Wed, 14 Sep 2011 21:44:20 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/14 Message-ID: <070.b5593d5ae1f599f191177a5e921f48e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110914214217.B3D4A21F8CA4@ietfa.amsl.com> Resent-Date: Wed, 14 Sep 2011 14:42:17 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #14: Effective Request URI definition issues X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 21:42:28 -0000 #14: Effective Request URI definition issues https://www.ietf.org/mail-archive/web/websec/current/msg00473.html: On 2011-08-06 01:34, =JeffH wrote: ... 12. Removed any and all dependencies on [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending on [RFC2616] only. Fixes issue ticket #12 . ... Not sure this is a good idea. The current text copies a known bug from draft-ietf- httpbis-p1-messaging-15 (see ). [ the HTTP method in the example should OPTIONS rather than GET ] Also, the ABNF claims it's based on RFC 2616's definitions, but mentions RFC 3986 in ABNF comments. This needs to be checked. -- -------------------------------------------+-------------------------------- Reporter: jeff.hodges@… | Owner: draft-ietf-websec-strict-transport-sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict-transport-sec | Version: 2.0 Severity: - | Keywords: -------------------------------------------+-------------------------------- Ticket URL: websec From Jeff.Hodges@KingsMountain.com Mon Sep 19 11:59:35 2011 Return-Path: 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 2E72821F8CA9 for ; Mon, 19 Sep 2011 11:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.629 X-Spam-Level: X-Spam-Status: No, score=-100.629 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 qLmOVhYySSLQ for ; Mon, 19 Sep 2011 11:59:34 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 8E2B121F8C9D for ; Mon, 19 Sep 2011 11:59:34 -0700 (PDT) Received: (qmail 2750 invoked by uid 0); 19 Sep 2011 19:01:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 19 Sep 2011 19:01:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=EkzYlINam7Qsmv83shIMzhlqm6c9NzZWxqqJbfheO8A=; b=cHcL6OTkmc6+rRjkbIMoOHM7lksRUxeMCLxG7NNjJrlbZMh0WXuUQZ46zaHPW3ZxIX+ZjVBONxOSMTEGzqXKKA4MsZ4nyU4ci8jVEaRMiv80AUH5O0siHlxw8w6FDBsi; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R5j6K-0003wA-41 for websec@ietf.org; Mon, 19 Sep 2011 13:01:56 -0600 Message-ID: <4E7791A2.5050903@KingsMountain.com> Date: Mon, 19 Sep 2011 12:01:54 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [websec] fyi: host-meta approved as RFC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: ,

The reason I think these will be essential wi= th pinning is that very few sites will be able to go from insecure to stric= t security in one bound while managing SSL certs centrally is something tha= t many sites always do.

Thus I think that either pinning should have a new head= er (they are cheap, IANA does not bite) or if we don't yet have a legac= y issue on the strict header it should be reworked as security properties a= nd strictness should be one of the dimensions.

Promiscuous security is really useful. In fact I suspec= t that most of the use cases that drove the creation of DV could be met by = strict security and transparent browser upgrade to SSL.=A0

I would also like to see a scope and protocol par= ameter reserved. This would define the domain to which the assertion applie= d and be ignored in HTTP transactions. Adding in scope means that the forma= t can be used as a mechanism for pushing out security policy as an emergenc= y measure. It could also be used to configure host or browser specific secu= rity policy configuration.

So for example, let us walk back the cat on the Diginot= ar incident but assume that some of the sites affected by the attack are pu= blishing security policy records with pinning and we have some browser side= capability.

The response team takes the list of affected sites and = pings each one for an HTTP transaction and looks for a security header with= pinning, if there is one they add in a scope (and protocol parameter if ne= cessary) and add it to their list. At the end they sign the list with a PKC= S#7/CMS wrapper and push it out. So browsers see something like:

Strict-Transport-Security: scope=3D*.cia.gov; protocol=3D_http._tcp;

=A0 =A0 max-age=3D..= . =A0pin=3D..... =A0unpin=3D.....

Strict-Transport-Security:= scope=3D*.paypal.com; protocol=3D_http._= tcp;

=A0 =A0 max-age=3D... =A0pin=3D..... =A0unpin=3D....

<= div>Strict-Transport-Security: scope=3Dlogin.twitter.com protocol=3D_http._tcp;

=A0 =A0 max-age=3D.= .. =A0pin=3D..... =A0unpin=3D....

Such a file with 500 odd entries would essentiall= y cover 98% of the sites likely to be of interest in the attacks on Iranian= citizens and likely most other state level attacks.

This type of mechanism would provide for secure on firs= t contact. It can be communicated even when the Internet connection is seve= rely compromised. Iranian ISPs are not going to be allowed to pass DNSSEC r= ecords once there is any infrastructure in place that would allow them to b= e applied to prevent the attacks by the Iranian government. In fact last we= ek China and Russia proposed a set of 'best practices' to the UN th= at to me at least appear to lay the ground for justifying that type of move= .

So we can also put the same information into a DNS reco= rd and it could be useful in some circumstances, but defeating a nation sta= te level attacker requires looking more than one move ahead.

Agreeing on a common format allows for agility in the distri= bution mechanism to get round that type of block. If the only file that can= be used by Chrome is a Chrome specific file it is going to be much harder = to transport the files than if we can have one file that also supports Tor,= Firefox, IE etc.

This type of file can be communicated by USB thumbdrive= if necessary (which is already one of the principal means of communication= for important data in such areas). It can be pushed out by anti-virus prod= ucts, etc.

Using CMS as the package format means that there can be= multiple signatures. That helps solve the administrative problem of gettin= g Microsoft or Google to trust a package signed by another party. Relying p= arties can even take a quorum of signers if they choose. That helps to solv= e an administrative problem on the back end which is how to make sure that = we protect all the browsers that people might use without expanding the cir= cle of responders to include the attackers.=A0

Note that with this approach the response team can resp= ond without having to contact the sites targeted in the attack. This is cri= tical because there may not be time to do so. We want to be able to respond= in hours, not days.=A0

--0016e68ef45702a84b04ad736906-- From sm@resistor.net Wed Sep 21 23:07:22 2011 Return-Path: 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 063E321F8B3D for ; Wed, 21 Sep 2011 23:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ODIOfC4WjHgs for ; Wed, 21 Sep 2011 23:07:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FC421F8B3C for ; Wed, 21 Sep 2011 23:07:19 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p8M69feH006063; Wed, 21 Sep 2011 23:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1316671787; bh=hSblmnpRZK4e0IdKLebx+/lPeuFOwIKa59cEOvCP6Ks=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=GlH7LGjvEYhRRtkAS7SYHH4lut9Ns2fOoZAO6cNyVX4FoHfRP4FNZGKa32MVOJAZi thEt2sP4IRfKE7T0b4iXTbE1Wz5yX4/ATiCkguk1kPBG4zN5hMe5LTGILP/eTdDQAl 8xb86SEKqDh22Y8cQS9c4gLwyY2UdWR9Mvc6j/is= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1316671787; bh=hSblmnpRZK4e0IdKLebx+/lPeuFOwIKa59cEOvCP6Ks=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Fftp7Fhyyu0+MMiq9g7jmR4yrv0oNMbo/VeSGm8JY6kMAWEXbS9iKURG+m6xvjrkX f0yfyEZx/HCs4maMQQcqFGtUo1Gjb8tvBgzuPbj3csa8pKt9bA2sx/hW/ON+JSleDW fZ7wKMgvixP3aQ2bP5+1V5gFfpUAlkIDMDhXEHvQ= Message-Id: <6.2.5.6.2.20110921222714.0c03e750@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Sep 2011 22:46:45 -0700 To: Chris Palmer , Chris Evans From: SM In-Reply-To: References: <6.2.5.6.2.20110920130003.0a9f43e0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF WebSec WG Subject: Re: [websec] Next rev of HSTS certificate pinning draft X-BeenThere: websec@ietf.org 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: Thu, 22 Sep 2011 06:07:22 -0000 Hi Chris, At 18:06 20-09-2011, Chris Palmer wrote: >I didn't write that text, it was auto-generated by the xml2rfc tool >itself. If that tool does the wrong thing, we should poke its >maintainer... The I-D which you submitted has the correct text. BTW, even though the text is auto-generated, it is still considered as an assertion by the author. Regards, -sm From gerv@mozilla.org Thu Sep 22 01:37:15 2011 Return-Path: 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 85F3921F8BF3 for ; Thu, 22 Sep 2011 01:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9FdSLDgfeJei for ; Thu, 22 Sep 2011 01:37:14 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDFD21F8B92 for ; Thu, 22 Sep 2011 01:37:14 -0700 (PDT) Received: from [192.168.0.39] (cpc3-enfi7-0-0-cust199.hari.cable.virginmedia.com [82.45.122.200]) (Authenticated sender: gerv@mozilla.org) by dm-mail03.mozilla.org (Postfix) with ESMTP id C35034AEE2F; Thu, 22 Sep 2011 01:39:43 -0700 (PDT) Message-ID: <4E7AF44E.9060803@mozilla.org> Date: Thu, 22 Sep 2011 09:39:42 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20110808 Thunderbird/6.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG , Chris Evans Subject: Re: [websec] Pinning and beyond Was: Next rev of HSTS certificate pinning draft X-BeenThere: websec@ietf.org 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: Thu, 22 Sep 2011 08:37:15 -0000 On 21/09/11 14:18, Phillip Hallam-Baker wrote: > Promiscuous security: > The site deploys SSL as an option that browsers can choose to use. > Pages may include transcluded content from insecure sites. The cert may > just be a self signed cert, browsers should just silently upgrade the > transport to TLS and not bother the user. The trouble with this idea (in general) is the following scenario: - User has relationship with MyBank.com, and a bookmark to http://www.mybank.com/. - MyBank is not entirely dumb, and so redirects straight to SSL when requests come in over unsecured HTTP. - Attacker gains control of user's connection. - User uses bookmark to access bank (supposedly a 'best practice') - Attacker redirects HTTP request to own MITM server, with self-signed cert. Browser "silently upgrades transport to TLS, and doesn't bother the user." Attacker passes through data from real site. - Effect is: user's browser shows connection as secure, but is MITMed. This is why silent acceptance of self-signed certs is not a good thing. We cannot rely on the user's browser always remembering the previous cert used, or the CA via something like pinning, because for privacy reasons any pin cache needs to be cleared if the user clears their history. > Thus I think that either pinning should have a new header (they are > cheap, IANA does not bite) But the list of required headers get bigger and bigger. As Brendan Eich says, "it's not the last cookie that makes you fat". Gerv From paul.hoffman@vpnc.org Thu Sep 22 07:39:55 2011 Return-Path: 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 6911621F8CD3 for ; Thu, 22 Sep 2011 07:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 nb9yLu0l9aQ3 for ; Thu, 22 Sep 2011 07:39:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F413D21F8CB2 for ; Thu, 22 Sep 2011 07:39:53 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p8MEgOT0012608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 22 Sep 2011 07:42:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <4E7AF44E.9060803@mozilla.org> Date: Thu, 22 Sep 2011 07:42:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E7AF44E.9060803@mozilla.org> To: IETF WebSec WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [websec] Pinning and beyond Was: Next rev of HSTS certificate pinning draft X-BeenThere: websec@ietf.org 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: Thu, 22 Sep 2011 14:39:55 -0000 On Sep 22, 2011, at 1:39 AM, Gervase Markham wrote: > On 21/09/11 14:18, Phillip Hallam-Baker wrote: >> Promiscuous security: >> The site deploys SSL as an option that browsers can choose to use. >> Pages may include transcluded content from insecure sites. The cert = may >> just be a self signed cert, browsers should just silently upgrade the >> transport to TLS and not bother the user. >=20 > The trouble with this idea (in general) is the following scenario: >=20 > - User has relationship with MyBank.com, and a bookmark to > http://www.mybank.com/. >=20 > - MyBank is not entirely dumb, and so redirects straight to SSL when > requests come in over unsecured HTTP. >=20 > - Attacker gains control of user's connection. >=20 > - User uses bookmark to access bank (supposedly a 'best practice') >=20 > - Attacker redirects HTTP request to own MITM server, with self-signed > cert. Browser "silently upgrades transport to TLS, and doesn't bother > the user." Attacker passes through data from real site. >=20 > - Effect is: user's browser shows connection as secure, but is MITMed. The "Attacker gains control of user's connection" step isn't necessary = if the attacker is already an MITM, such as an TLS proxy like the one = that has been in the news lately (or the attacker gains admin access on = a corporate TLS proxy). > This is why silent acceptance of self-signed certs is not a good = thing. >=20 > We cannot rely on the user's browser always remembering the previous > cert used, or the CA via something like pinning, because for privacy > reasons any pin cache needs to be cleared if the user clears their = history. >=20 >> Thus I think that either pinning should have a new header (they are >> cheap, IANA does not bite) >=20 > But the list of required headers get bigger and bigger. As Brendan = Eich > says, "it's not the last cookie that makes you fat". Not sure what you mean by "required". The new one Phill proposed here = would be required to support this functionality, not required for every = browser. I agree with him: granularity for semantics of each header is = better than overloading semantics to save a few bytes. --Paul Hoffman From hallam@gmail.com Thu Sep 22 13:40:39 2011 Return-Path: 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 2CBD511E80B3 for ; Thu, 22 Sep 2011 13:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] 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 eMUr462k+igz for ; Thu, 22 Sep 2011 13:40:38 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32DEE11E80B2 for ; Thu, 22 Sep 2011 13:40:38 -0700 (PDT) Received: by ywa6 with SMTP id 6so2769334ywa.31 for ; Thu, 22 Sep 2011 13:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XbRXoSySzS9qaAoLHCm0CGdNvMQ1xRaEXC/gP7vZZSg=; b=ns3x2Z4KP5cegsP/X348tjp6K+NIzy1QXpQ249ZgUa7RtbMTbjJFNVqwlKCf4euebB ICSpY26ejiQdG0XzXGhyE4lklkbzteZkjIP7vjNZBRP3TlGwXhN6SigkBaCn1/2PC/V/ MlUMaD7TE/VI+p7dvlg0fDpRytUZG+JI5k4OM= MIME-Version: 1.0 Received: by 10.101.28.40 with SMTP id f40mr2458623anj.30.1316724190335; Thu, 22 Sep 2011 13:43:10 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Thu, 22 Sep 2011 13:43:10 -0700 (PDT) In-Reply-To: <4E7AF44E.9060803@mozilla.org> References: <4E7AF44E.9060803@mozilla.org> Date: Thu, 22 Sep 2011 16:43:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Gervase Markham Content-Type: multipart/alternative; boundary=001b2413b4c1a1d32104ad8dbd57 Cc: IETF WebSec WG , Chris Evans Subject: Re: [websec] Pinning and beyond Was: Next rev of HSTS certificate pinning draft X-BeenThere: websec@ietf.org 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: Thu, 22 Sep 2011 20:40:39 -0000 --001b2413b4c1a1d32104ad8dbd57 Content-Type: text/plain; charset=ISO-8859-1 First off, this is really not something that should be considered acceptable for banks. The objective here is purely to increase the amount of SSL traffic on the web so that unencrypted traffic becomes the exception rather than the rule. On Thu, Sep 22, 2011 at 4:39 AM, Gervase Markham wrote: > On 21/09/11 14:18, Phillip Hallam-Baker wrote: > > Promiscuous security: > > The site deploys SSL as an option that browsers can choose to use. > > Pages may include transcluded content from insecure sites. The cert may > > just be a self signed cert, browsers should just silently upgrade the > > transport to TLS and not bother the user. > > The trouble with this idea (in general) is the following scenario: > > - User has relationship with MyBank.com, and a bookmark to > http://www.mybank.com/. > > - MyBank is not entirely dumb, and so redirects straight to SSL when > requests come in over unsecured HTTP. > Hang on here. What I said was that I wanted this to be part of the pinning mechanism and have persistence. The idea here is to get rid of that browser redirect so that the browser always goes to https. So what would be stored by the browser is: Bookmark: http://www.mybank.com www.mybank.com Always use TLS, Don't enforce strictness, pin=xx, unpin=yy, until=2012-01-12 > - Attacker gains control of user's connection. > > - User uses bookmark to access bank (supposedly a 'best practice') > > - Attacker redirects HTTP request to own MITM server, with self-signed > cert. Browser "silently upgrades transport to TLS, and doesn't bother > the user." Attacker passes through data from real site. > OK so if you use a mechanism that gives secure after first contact you are not going to be secure on first contact. I don't see how this attack is sustained unless you can also sustain the MITM attack. The user should be looking at their browser and wondering why there is no padlock or any security indicator in any case. As far as they would be concerned the silent upgrade looks no different from going to the sit en-clair. - Effect is: user's browser shows connection as secure, but is MITMed. > Nope, no display of any security chrome whatsoever. I don't want security chrome for DV certs. Why would I want it for self signed certs? The only chrome notification should be for certs that establish accountability. This is why silent acceptance of self-signed certs is not a good thing. > If the user can see the acceptance then its not silent. By silent I mean, do not say anything at all, not do not annoy the user with some braindamaged notification. > We cannot rely on the user's browser always remembering the previous > cert used, or the CA via something like pinning, because for privacy > reasons any pin cache needs to be cleared if the user clears their history. Which is why I am going to want to push out the exact same information via the DNS once there is DNSSEC to back it up. Just take the HTTP header and stick it into a DNS RR record we define. > > Thus I think that either pinning should have a new header (they are > > cheap, IANA does not bite) > > But the list of required headers get bigger and bigger. As Brendan Eich > says, "it's not the last cookie that makes you fat". > Security policy is an important use case. At this point we can kill the cache control stuff as nobody is going to be able to use it once everyone is using TLS :-) I would much prefer to have one security policy header and for strict to be a special case rather than have two. -- Website: http://hallambaker.com/ --001b2413b4c1a1d32104ad8dbd57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First off, this is really not something that should be considered acceptabl= e for banks.

The objective here is purely to increase th= e amount of SSL traffic on the web so that unencrypted traffic becomes the = exception rather than the rule.

On Thu, Sep 22, 2011 at 4:39 AM, Gervase Mar= kham <gerv@mozilla= .org> wrote:

On 21/09/11 14:18, Phillip Hallam-Baker wrote:
> Promiscuous security:
> =A0 =A0 The site deploys SSL as an option that browsers can choose to = use.
> Pages may include transcluded content from insecure sites. The cert ma= y
> just be a self signed cert, browsers should just silently upgrade the<= br> > transport to TLS and not bother the user.

The trouble with this idea (in general) is the following scenario:
- User has relationship with MyBank.com, and a bookmark to
=A0http://www.mybank.= com/.

- MyBank is not entirely dumb, and so redirects straight to SSL when
=A0requests come in over unsecured HTTP.

Hang on here. What I said was that I wanted this to be part of the pinni= ng mechanism and have persistence. The idea here is to get rid of that brow= ser redirect so that the browser always goes to https.

So what would be stored by the browser is:

Bookmark:=A0http://www.mybank.com

www.mybank.com=A0Always use TLS, Don't enforce str= ictness, pin=3Dxx, unpin=3Dyy, until=3D2012-01-12

=A0

- Attacker gains control of user's connection.

- User uses bookmark to access bank (supposedly a 'best practice')<= br>
- Attacker redirects HTTP request to own MITM server, with self-signed
=A0cert. Browser "silently upgrades transport to TLS, and doesn't= bother
=A0the user." Attacker passes through data from real site.

OK so if you use a mechanism that gives secure af= ter first contact you are not going to be secure on first contact.

I don't see how this attack is sustained unless you= can also sustain the MITM attack.

= The user should be looking at their browser and wondering why there is no p= adlock or any security indicator in any case. As far as they would be conce= rned the silent upgrade looks no different from going to the sit en-clair.<= /div>

- Effect is: user's browser shows connection as secure, but is MITMed.<= br>

Nope, no display of any security chrome= whatsoever.

I don't want security chrome for = DV certs. Why would I want it for self signed certs? The only chrome notifi= cation should be for certs that establish accountability.

This is why silent acceptance of self-signed certs is not a good thing.
=

If the user can see the acceptance then it= s not silent. By silent I mean, do not say anything at all, not do not anno= y the user with some braindamaged notification.

=A0
We cannot rely on the user's browser always remembering the previous cert used, or the CA via something like pinning, because for privacy
reasons any pin cache needs to be cleared if the user clears their history.=

Which is why I am going to want to push ou= t the exact same information via the DNS once there is DNSSEC to back it up= .

Just take the HTTP header and stick it into a DNS RR re= cord we define.

=A0

> Thus I think that either pinning should have a new header (they are > cheap, IANA does not bite)

But the list of required headers get bigger and bigger. As Brendan Ei= ch
says, "it's not the last cookie that makes you fat".

Security policy is an important use case. At th= is point we can kill the cache control stuff as nobody is going to be able = to use it once everyone is using TLS :-)

I would much prefer to have one security policy header = and for strict to be a special case rather than have two.=A0

--
Website: http://hall= ambaker.com/

--001b2413b4c1a1d32104ad8dbd57-- From palmer@google.com Thu Sep 22 15:08:29 2011 Return-Path: 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 41CEF11E80C7 for ; Thu, 22 Sep 2011 15:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 PjqzD+L4+BtJ for ; Thu, 22 Sep 2011 15:08:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C010D11E80AA for ; Thu, 22 Sep 2011 15:08:28 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p8MMB0kG003446 for ; Thu, 22 Sep 2011 15:11:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316729460; bh=kM+R8/QeVrwlp4ZBWc0H0WGSHd4=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=OXzyMgmPtmFx+Z9RPALKhDjA3Ni0TkS13q0BW5goaET4uPQGwFtS7Pyd/Vp+IuMFx LMyDq/jR1H4CQPjUYe4Aw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:date:message-id:subject:from:to:cc: content-type:x-system-of-record; b=kVw0JGgwcdBJLzEdqnlQEa16D59uB1wF/CsHMmJAR+2qTp2eGCpcuRra7W5GXd74W nILO/zx6TYYG05wC5auUg== Received: from wyg10 (wyg10.prod.google.com [10.241.226.138]) by hpaq2.eem.corp.google.com with ESMTP id p8MMA4Nn002686 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 22 Sep 2011 15:10:59 -0700 Received: by wyg10 with SMTP id 10so4648897wyg.35 for ; Thu, 22 Sep 2011 15:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=UV0mJTwfyF7Eom1i+NZZvmlbGbvp1Nbj3bcapi+u6UY=; b=QZLTSMZoW38t5gLwzaLzZ2WMeLNAabnl5LSR5T6GXrHNV4bOdZGPHzLrzHAMuIMgLR x6U1ptfRhusEDl20xauQ== Received: by 10.216.23.72 with SMTP id u50mr2816071weu.34.1316729458965; Thu, 22 Sep 2011 15:10:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.23.72 with SMTP id u50mr2816062weu.34.1316729458809; Thu, 22 Sep 2011 15:10:58 -0700 (PDT) Received: by 10.216.61.16 with HTTP; Thu, 22 Sep 2011 15:10:58 -0700 (PDT) Date: Thu, 22 Sep 2011 15:10:58 -0700 Message-ID: From: Chris Palmer To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Chris Evans Subject: [websec] HSTS certificate pinning draft is now in the tracker X-BeenThere: websec@ietf.org 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: Thu, 22 Sep 2011 22:08:29 -0000 https://datatracker.ietf.org/doc/draft-evans-palmer-hsts-pinning/ From internet-drafts@ietf.org Thu Sep 22 15:33:52 2011 Return-Path: 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 A15A41F0CA7; Thu, 22 Sep 2011 15:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 jldf26yVQ7NI; Thu, 22 Sep 2011 15:33:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C811F0C77; Thu, 22 Sep 2011 15:33:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110922223352.30413.93196.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2011 15:33:52 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-origin-05.txt X-BeenThere: websec@ietf.org 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: Thu, 22 Sep 2011 22:33:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IET= F. Title : The Web Origin Concept Author(s) : Adam Barth Filename : draft-ietf-websec-origin-05.txt Pages : 27 Date : 2011-09-22 This document defines the concept of an "origin", which is oft= en used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document defines how to determine the origin of a URI, how to serialize an origin into a string, and an HTTP header field, named "Origin", that indic= ates which origins are associated with an HTTP request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-origin-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-origin-05.txt From julian.reschke@gmx.de Fri Sep 23 00:26:44 2011 Return-Path: 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 7B4BC21F8B5C for ; Fri, 23 Sep 2011 00:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.165 X-Spam-Level: X-Spam-Status: No, score=-104.165 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tnNw2fXl9ZFQ for ; Fri, 23 Sep 2011 00:26:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1A54621F8B42 for ; Fri, 23 Sep 2011 00:26:42 -0700 (PDT) Received: (qmail invoked by alias); 23 Sep 2011 07:29:14 -0000 Received: from p508FD649.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.214.73] by mail.gmx.net (mp008) with SMTP; 23 Sep 2011 09:29:14 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18awbZFMS0aYeb5Cz8VHtkdcqGOejAR+2O7mhI67U o/wyGR9hU8gTSY Message-ID: <4E7C3547.5070405@gmx.de> Date: Fri, 23 Sep 2011 09:29:11 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: websec@ietf.org References: <20110922223352.30413.93196.idtracker@ietfa.amsl.com> In-Reply-To: <20110922223352.30413.93196.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [websec] I-D Action: draft-ietf-websec-origin-05.txt X-BeenThere: websec@ietf.org 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: Fri, 23 Sep 2011 07:26:44 -0000 On 2011-09-23 00:33, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. > ... Nits...: > The OWS (optional whitespace) rule is used where zero or more linear > whitespace characters MAY appear: > > OWS = *( [ obs-fold ] WSP ) > ; "optional" whitespace > obs-fold = CRLF We changed the definition of OWS nin HTTPbis: > 1. If the URI does not use a hierarchical element as a naming > authority (see [RFC3986], Section 3.2), or if the URI is not an > absolute URI, then generate a fresh globally unique identifier > and return that value. > > 1. NOTE: Running this algorithm multiple times for the same URI > can produce different values each time. Typically, user > agents compute the origin of, for example, an HTML document > once and use that origin for subsequent security checks > rather than recomputing the origin for each security check. It seems the NOTE shouldn't be in a numbered list (same for item 4). > 7.1. Syntax > > > The Origin header field has the following syntax: > > > origin = "Origin:" OWS origin-list-or-null OWS > origin-list-or-null = "null" / origin-list > origin-list = serialized-origin *( SP serialized-origin ) > serialized-origin = scheme "://" host [ ":" port ] > ; , , productions from RFC3986 a) Reformat do it doesn't need to be outdented b) "null" in ABNF means case-insensitive; consider replacing with octet sequence and putting the literal "null" into a comment. References: may need updates, such as WEBSOCKETS. Also consider sorting them (xml2rfc sortrefs PI). Best regards, Julian From Jeff.Hodges@KingsMountain.com Fri Sep 23 14:56:27 2011 Return-Path: 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 BBD6321F8CF1 for ; Fri, 23 Sep 2011 14:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.455 X-Spam-Level: X-Spam-Status: No, score=-100.455 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 of4CaKluHgwx for ; Fri, 23 Sep 2011 14:56:26 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id BBF8F21F8CD8 for ; Fri, 23 Sep 2011 14:56:26 -0700 (PDT) Received: (qmail 26471 invoked by uid 0); 23 Sep 2011 21:59:02 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 23 Sep 2011 21:59:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=2gW+FCD4ptzIPodtp9zT9dLY2iynP62dYFbvzmIstD8=; b=O3x0OEPRnZaZA4/dTzSpPJMT3FKJrD6As6Die4HLFpD2ocvv/3bMKWDJQzzWWVuI+It+KMHfjWUNf0HDbJD+F3fmXWN6UppOVLGXngxDTt7MldzTHWEu8yR2+u7H6WbJ; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R7Dlt-0006cu-Fu; Fri, 23 Sep 2011 15:59:01 -0600 Message-ID: <4E7D0124.4090308@KingsMountain.com> Date: Fri, 23 Sep 2011 14:59:00 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: IETF WebSec WG , Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] AD review of -strict-transport-sec-02 (was: Strict-Transport-Security syntax and effective request URI def) X-BeenThere: websec@ietf.org 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: Fri, 23 Sep 2011 21:56:27 -0000 Hi, apologies for latency. I was trying to get this reply and a -03 rev of the spec out the door last week, but some recent events have pushed that down my stack. I haven't yet submitted the -03 draft, will try to do that early-to-mid next week. it may not address absolutely everything below, as I've noted. anyway, am issuing this reply in order to spark any discussion you may wish to have on any of these items and as a headsup that progress is being made. thanks =JeffH StPeter held forth.. > > On 8/6/11 8:27 AM, =JeffH wrote: > >> ALL: now's a good time to review draft-ietf-websec-strict-transport-sec >> in detail -- as mentioned in Quebec last week, we want to get this spec >> in shape for WG LC sooner rather than later (and I believe it's pretty >> close to ready as of now). I'll be popping it back up to the top of my >> to-do list after this next week. > > Thanks for the poke. I've had a chance to read the spec again. Here is > some mostly minor feedback. Thanks for the review Peter. > You can consider this an AD review. :) cool. > SECTION 1 > > s/Universal Resource Identifier/Uniform Resource Identifier/ doh. thanks. > Expand "UA" on first use. it already is expanded in the first para of the Introduction. > This specification embodies and refines the approach proposed in > [ForceHTTPS], e.g. a HTTP response header field, named "Strict- > Transport-Security", is used to convey the site HSTS policy to the UA > rather than a cookie. > > Do you mean "i.e." instead of "e.g."? I suggest: > > This specification embodies and refines the approach proposed in > [ForceHTTPS]; i.e. instead of using a cookie it defines and uses > an HTTP response header field, named "Strict-Transport-Security", > to convey the site HSTS policy to the UA. done in my working copy. > The document is a bit unclear about the denotation of "HSTS policy". > Sometimes it refers to the site's policy and sometimes to the overall > recommendations defined in the spec. > > This specification also incorporates notions > from [JacksonBarth2008] in that the HSTS policy is applied on an > "entire-host" basis: it applies to all TCP ports on the host. > Additionally, HSTS policy can be applied to the entire domain name > subtree rooted at a given host name. This enables HSTS to protect > so-called "domain cookies", which are applied to all subdomains of a > given domain. > > Perhaps it would be helpful to contrast the all ports and entire subtree > principles with the same origin policy also being worked on in this WG, > with an informational reference to the appropriate spec. Have not yet addressed this item. will either do in present working copy or in next one. > SECTION 2.1 > > o Web browser user wishes to discover, or be introduced to, and/or > utilize various web sites (some arbitrary, some known) in a secure > fashion. > > Does this specification really talk about discovery? I don't see > anything about that later in the document. Also it's not clear to me > what the spec means by "be introduced to". I suggest: > > o Web browser user wishes to interact with various web sites (some > arbitrary, some known) in a secure fashion. done in my working copy. > SECTION 2.3.1.3 > > The term "mixed content" threw me off because it is also used in XML: > > http://www.w3.org/TR/2008/REC-xml-20081126/#sec-mixed-content LOL -- was unaware of that, thx for reference. > Also, it might be good to consistently use and prefer the term "mixed > security context" in this specification. So this term "mixed content" has (unfortunately) been used in the web security world since at least as early as IE6's release and perhaps (much?) earlier. The immediate audience of this spec is going to understand the "mixed content" term as used in that section, and wouldn't at first understand "mixed security context". That's why I'm equating them in this spec and will try to promulgate "mixed security context" (or something else if someone has a better idea) going forward in general). But I don't expect the web security usage of "mixed content" to go away -- its just too deeply embedded, unfortunately. > SECTION 3 > > Please use the RFC 2119 boilerplate rather than inventing your own. done in my working copy. > SECTION 4 > > Regarding the terms "Domain Name" and "Domain Name Label", I'm leery of > defining them anew and would suggest referring to the definitions in, > say, RFC 5890 (or ideally RFC 1034 and RFC 1035). i'm going to leave that in the draft for now. they are listed there with approrpriate references to RFC 1034 and RFC 1035 et al for completeness/disambiguation/convenience. referencing RFC 5890 would be incorrect thing for these terms IMV. > SECTION 7 > > We have a normative reference to RFC 3490, which has been obsoleted by > RFC 5890 and friends. Why not cite the definition of A-label from > Section 2.3.2.1 of RFC 5890? To wit: > > o An "A-label" is the ASCII-Compatible Encoding (ACE, see > Section 2.3.2.5) form of an IDNA-valid string. It must be a > complete label: IDNA is defined for labels, not for parts of them > and not for complete domain names. This means, by definition, > that every A-label will begin with the IDNA ACE prefix, "xn--" > (see Section 2.3.2.5), followed by a string that is a valid output > of the Punycode algorithm [RFC3492] and hence a maximum of 59 > ASCII characters in length. The prefix and string together must > conform to all requirements for a label that can be stored in the > DNS including conformance to the rules for LDH labels > (Section 2.3.1). If and only if a string meeting the above > requirements can be decoded into a U-label is it an A-label. I've been recently discussing aspects of the above (with you, Pete Resnick, and others) and the more broad issues with how to properly describe "host name canonicalization". for now I've placed into my working copy essentially the same approach as that we recently did in RFC6265 HTTP State Management (cookies). i understand that we may want to enhance/modify this approach going forward, but this is a step in that direction for now. > SECTION 7.1.1 > > What does it mean to "congruently match"? It's defined in S 7.1.2. > SECTION 7.3 > > Isn't RFC 2560 the right spec for OCSP? yes, fixed in my working copy. > SECTION 7.5 > > I can't parse this clause: > > the UA SHOULD continue to treat the host as a Known > HSTS Host until the max age for the knowledge that Known HSTS Host is > reached. fixed in my working copy. > SECTION 8 > > Once again we're normatively referencing RFC 3490 instead of IDNA2008. fixed in my working copy. > SECTION 11 > > Is "effective request URI" defined anywhere that we can reference? well, it was originally defined in this here spec :) it will be defined in the new HTTPbis specs once they are finalized, but we wanted to decouple the HSTS spec from that scheduling dependency. Thus we are retaining the definition here, but have incorporated the refinements to the definition made by Julian. > SECTION 12.2 > > Let's add an informational reference to RFC 4732. > > Can we add some more details to the description of the denial of service > attack? IMHO it's a bit thin. Have not yet addressed this item. will either do in present working copy or in next one. > GLOBAL > > There are various spelling and grammar errors, but I assume those will > be fixed along the way. indeed, yes. :) --- end From julian.reschke@gmx.de Sat Sep 24 04:00:30 2011 Return-Path: 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 254B621F8B62 for ; Sat, 24 Sep 2011 04:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.155 X-Spam-Level: X-Spam-Status: No, score=-104.155 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YFCcpfFFO72W for ; Sat, 24 Sep 2011 04:00:29 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3383521F8B59 for ; Sat, 24 Sep 2011 04:00:28 -0700 (PDT) Received: (qmail invoked by alias); 24 Sep 2011 11:03:03 -0000 Received: from p508FBCA2.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.188.162] by mail.gmx.net (mp062) with SMTP; 24 Sep 2011 13:03:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX198Vos4Mod8QsBYpMGGR4V2Xc977Dmr0mMDK/i79y 9U0JQmqlxLlrJw Message-ID: <4E7DB8E4.9040208@gmx.de> Date: Sat, 24 Sep 2011 13:03:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: websec@ietf.org References: <20110508004502.3883.40670.idtracker@ietfa.amsl.com> In-Reply-To: <20110508004502.3883.40670.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt X-BeenThere: websec@ietf.org 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: Sat, 24 Sep 2011 11:00:30 -0000 On 2011-05-08 02:45, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Security Working Group of the IETF. > > > Title : Media Type Sniffing > Author(s) : A. Barth, I. Hickson > Filename : draft-ietf-websec-mime-sniff-03.txt > Pages : 24 > Date : 2011-05-07 > ... I think it would be good if the Internet Drafts database could be updates to say that draft-ietf-websec-mime-sniff replaces draft-abarth-mime-sniff (this helps with various tools that try to check for upto-date-ness and successor documents). Best regards, Julian From alexey.melnikov@isode.com Sat Sep 24 07:49:21 2011 Return-Path: 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 9EB5521F8AB8 for ; Sat, 24 Sep 2011 07:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3V21X32EJbWx for ; Sat, 24 Sep 2011 07:49:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id E41E921F85D1 for ; Sat, 24 Sep 2011 07:49:20 -0700 (PDT) Received: from [188.28.106.38] (188.28.106.38.threembb.co.uk [188.28.106.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 24 Sep 2011 15:51:55 +0100 Message-ID: <4E7DEE84.40806@isode.com> Date: Sat, 24 Sep 2011 15:51:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Julian Reschke References: <20110508004502.3883.40670.idtracker@ietfa.amsl.com> <4E7DB8E4.9040208@gmx.de> In-Reply-To: <4E7DB8E4.9040208@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt X-BeenThere: websec@ietf.org 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: Sat, 24 Sep 2011 14:49:21 -0000 Julian Reschke wrote: > On 2011-05-08 02:45, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Security Working Group of the IETF. >> >> >> Title : Media Type Sniffing >> Author(s) : A. Barth, I. Hickson >> Filename : draft-ietf-websec-mime-sniff-03.txt >> Pages : 24 >> Date : 2011-05-07 >> ... > > I think it would be good if the Internet Drafts database could be > updates to say that draft-ietf-websec-mime-sniff replaces > draft-abarth-mime-sniff (this helps with various tools that try to > check for upto-date-ness and successor documents). Will do. From julian.reschke@gmx.de Sun Sep 25 05:31:36 2011 Return-Path: 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 397A221F8B54 for ; Sun, 25 Sep 2011 05:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.14 X-Spam-Level: X-Spam-Status: No, score=-104.14 tagged_above=-999 required=5 tests=[AWL=-1.541, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bJrjl6ldVomK for ; Sun, 25 Sep 2011 05:31:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2636621F8B4B for ; Sun, 25 Sep 2011 05:31:34 -0700 (PDT) Received: (qmail invoked by alias); 25 Sep 2011 12:34:13 -0000 Received: from p508FD77C.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.215.124] by mail.gmx.net (mp070) with SMTP; 25 Sep 2011 14:34:13 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19rGc9yKEprhfUfqnAFXb6kihia63iTlNBK/xDrMP sQhN8u6/HTNHIJ Message-ID: <4E7F1FC1.9020805@gmx.de> Date: Sun, 25 Sep 2011 14:34:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =JeffH References: <4E7117CB.9050203@KingsMountain.com> In-Reply-To: <4E7117CB.9050203@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax X-BeenThere: websec@ietf.org 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: Sun, 25 Sep 2011 12:31:36 -0000 On 2011-09-14 23:08, =JeffH wrote: > > a few questions about the header field syntax: > > > > Strict-Transport-Security = > > "Strict-Transport-Security" ":" OWS STS-v OWS > > > > So the header field is *not* using the RFC2616 list syntax. So you > can have > > > > Strict-Transport-Security: a; b > > > > but *not* > > > > Strict-Transport-Security: a > > Strict-Transport-Security: b > > > > because that would be equivalent to > > > > Strict-Transport-Security: a, b > > > > (is this intentional?) > > well, it was not necessarily intentional as far as I recall. We either > managed to overlook, or regarded as inappropriate for this header, the > RFC2616 list syntax (i.e., the "#rule"), that defines such implicit > comma-separated lists. > Also, we'd noted that quite a number of header field definitions used > semi-colons as a delimiter, but perhaps hadn't noted that those overall > productions often are embedded within such comma-separated lists. Yes, that's the list-of-parametrized-things format. > However, in thinking about it a little bit, for this particular header > field, as it's presently defined, it doesn't seem appropriate to have it > explicitly be comma-separated repeatable (aka #rule), because only one > instance of "S-T-S: max-age=n" is effective in terms of established the > cached Known HSTS Host in the UA. In that case, as this is security related, you may want to talk about what recipients are to do when (a) they *do* get multiple instances, and (b) when an intermediate folds multiple headers using the comma syntax. > > Also in > > > > ; value > > STS-v = STS-d > > / STS-d *( OWS ";" OWS STS-d OWS ) > > > > ; STS directive > > STS-d = STS-d-cur / STS-d-ext > > > > ; defined STS directives > > STS-d-cur = maxAge / [ includeSubDomains ] > > > > having includeSubDomains optional is a bit weird. > > > > This means that the empty string would be a valid STS-d-cur, thus an > > empty header field is allowed... > > Ah, thanks, yes -- i was unsure of how to make includeSubDomains > optional while max-age is required, and that hack didn't work. > > I've now re-worked it as below -- how's that look? > > thanks again, > > =JeffH > > > Strict-Transport-Security = > "Strict-Transport-Security" ":" OWS STS-v OWS > > ; STS header field value; must have a max-age: > > STS-v = max-age > / max-age *( OWS ";" OWS STS-d OWS ) ...which makes putting max-age first required. > ; additional STS directives: > > STS-d = STS-d-cur / STS-d-ext > > ; currently defined STS directives, > ; delta-seconds is 1*DIGIT and is from [RFC2616]: > > max-age = "max-age" OWS "=" OWS delta-seconds [ OWS v-ext ] > > STS-d-cur = includeSubDomains > > includeSubDomains = "includeSubDomains" [ OWS v-ext ] > > > ; extension points > STS-d-ext = name ; STS extension directive > > v-ext = value ; STS extension value > > name = token > > value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or > ; [ ! .. : ] [ < .. ~ ] any visible chars other than ";" > > token = 1*tchar > > tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" > / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" > / DIGIT / ALPHA > ; visible (printing) characters, except visible > ; separators. > ; DIGIT, ALPHA, separators are from [RFC2616] > > ; Basic rules: > > OWS = *( [ CRLF ] WSP ) > ; Optional White Space > > WSP = SP / HTAB > > CRLF = CR LF > > ; CR, LF, SP, HTAB are from [RFC2616] > > > --- > end I think it would be simpler not to try to express this in the ABNF. Just use the ABNF to state the core syntax (that a parser will need to understand), and then put additional requirements about what directives must be there in prose (we're doing the same in HTTPbis, but aren't done yet... :-). Best regards, Julian From hallam@gmail.com Tue Sep 27 10:08:09 2011 Return-Path: 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 0ABBA21F8CE9 for ; Tue, 27 Sep 2011 10:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7EtDbVlf2fsK for ; Tue, 27 Sep 2011 10:08:08 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60E4D21F8CE7 for ; Tue, 27 Sep 2011 10:08:08 -0700 (PDT) Received: by yxt33 with SMTP id 33so6883243yxt.31 for ; Tue, 27 Sep 2011 10:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=IJOfXbUa6oWaNoBSi02rDiMcH3KARcOjG5akZ3tAU4w=; b=ftN99lfFxsolEb+GTL18HVtTSVAH9s0aI/bz5N6wr3sOf++zZT2pCDhwjuJtb5eQxk TK5Vq4i2mzoGLF7sacF+HRugkGVVEUH1ZdsTwHuLWQAq+fziUWGsST1DrrN1vXVa/gNI BYgEs0Ho4S0KEJ1NCUbujMUh1ICotsI54NED8= MIME-Version: 1.0 Received: by 10.101.208.2 with SMTP id k2mr7259933anq.8.1317143454112; Tue, 27 Sep 2011 10:10:54 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 27 Sep 2011 10:10:54 -0700 (PDT) Date: Tue, 27 Sep 2011 13:10:54 -0400 Message-ID: From: Phillip Hallam-Baker To: websec Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] Digest URI scheme X-BeenThere: websec@ietf.org 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: Tue, 27 Sep 2011 17:08:09 -0000 As I mentioned previously, the need to refer to a static data object by means of a digest comes up frequently. Rather than re-invent the mechanism for creating a reference each time we need one, it would be better if we had a single format that could be re-used. We used to have this back in the days when we trusted MD5 since we used that everywhere as a 'fingerprint'. Then things got muddy after the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it will be very muddy. This would be relevant to the cert pinning debate. I wrote a draft making the proposal: http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt On the digest front the objective would be to make it possible to use the URI format with any digest at all in theory but strongly encourage people to only use the digests IETF is confident in. Use of OIDs as the identifier has the nice property that anyone can get an identifier to distinguish their algorithm from other people's but getting an OID does not produce any paper trail that can be used to imply an IETF endorsement. We could add in support for the text based identifiers as well, but since the only identifiers that I would want to encourage are SHA2 and SHA3, I don't see a need. For all applications that make sense it is going to be perfectly OK to simply generate the prefix for the identifier part as a static array of octets and append / verify it as such whenever it is needed. I do not see any need to write ASN.1 handling code for these apps :-) The basic idea here is that we need to allow for algorithm agility and to prevent a content substitution attack. So imagine that we have web page A linking to some off site static content via a digest. Site A regards the static content as a PNG and has checked out the page and it works fine. What they don't know is that buried in the PNG there is some malicious Jscript and if the content server delivers it as application/script the result will be a series of syntax errors (that are silently ignored because the app is stupid) and then it finds the malicious code... ooops. OK, so maybe not an attack that you find to be a worry in every circumstance, but it is definitely an attack vector we should address in a general purpose crypto building block. Having produced a static building block like this it is very easy to generate a fingerprint for a static data object in a cut and paste ready format. I don't need a separate tool to generate digest identifiers for WebSec vs other applications. In terms of ease of use we get back to what things were like when we used MD5 fingerprints. It is also quite easy to make use of truncated fingerprints should that be necessary. For example, to put on a business card. -- Website: http://hallambaker.com/ From hallam@gmail.com Tue Sep 27 11:13:26 2011 Return-Path: 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 DFFE621F8BF3 for ; Tue, 27 Sep 2011 11:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QUU-gQrxzcuq for ; Tue, 27 Sep 2011 11:13:26 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5D8D21F8BB0 for ; Tue, 27 Sep 2011 11:13:25 -0700 (PDT) Received: by yic13 with SMTP id 13so6623072yic.31 for ; Tue, 27 Sep 2011 11:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y69hvRPSNIgLJFhWrcrU3GXJOl20TWH4VXjP0zPbti0=; b=GOXu1sCp8AAXQs8DSQRE70UGqcd01KjeMWwiyL2mYUYv5tui14ngOJUJegdWZlMCxm I2mEfMGRNq+EBSbh+7yldfH4nAFiOrmz/4ZXxc1Y/A3bTPoC3JWQTuq3/v1BXDS6JZ2S von0TOGiUVKMhxIpymooSujnAopPUWIzsEfEM= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr7449945anb.52.1317147371874; Tue, 27 Sep 2011 11:16:11 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 27 Sep 2011 11:16:11 -0700 (PDT) In-Reply-To: <4E7F1FC1.9020805@gmx.de> References: <4E7117CB.9050203@KingsMountain.com> <4E7F1FC1.9020805@gmx.de> Date: Tue, 27 Sep 2011 14:16:11 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax X-BeenThere: websec@ietf.org 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: Tue, 27 Sep 2011 18:13:27 -0000 Agreed, just write the syntax so that it specified a MIME header-ish tag-value list. Then define the tags and the syntax of the corresponding values separately. That makes it much easier to extend the protocol at the API level since the API can simply deliver the tag-value list to the caller. Hasn't this been specified somewhere already? On Sun, Sep 25, 2011 at 8:34 AM, Julian Reschke wro= te: > On 2011-09-14 23:08, =3DJeffH wrote: >> >> =A0> a few questions about the header field syntax: >> =A0> >> =A0> Strict-Transport-Security =3D >> =A0> "Strict-Transport-Security" ":" OWS STS-v OWS >> =A0> >> =A0> So the header field is *not* using the RFC2616 list syntax. So you >> can have >> =A0> >> =A0> Strict-Transport-Security: a; b >> =A0> >> =A0> but *not* >> =A0> >> =A0> Strict-Transport-Security: a >> =A0> Strict-Transport-Security: b >> =A0> >> =A0> because that would be equivalent to >> =A0> >> =A0> Strict-Transport-Security: a, b >> =A0> >> =A0> (is this intentional?) >> >> well, it was not necessarily intentional as far as I recall. We either >> managed to overlook, or regarded as inappropriate for this header, the >> RFC2616 list syntax (i.e., the "#rule"), that defines such implicit >> comma-separated lists. >> Also, we'd noted that quite a number of header field definitions used >> semi-colons as a delimiter, but perhaps hadn't noted that those overall >> productions often are embedded within such comma-separated lists. > > Yes, that's the list-of-parametrized-things format. > >> However, in thinking about it a little bit, for this particular header >> field, as it's presently defined, it doesn't seem appropriate to have it >> explicitly be comma-separated repeatable (aka #rule), because only one >> instance of "S-T-S: max-age=3Dn" is effective in terms of established th= e >> cached Known HSTS Host in the UA. > > In that case, as this is security related, you may want to talk about wha= t > recipients are to do when (a) they *do* get multiple instances, and (b) w= hen > an intermediate folds multiple headers using the comma syntax. > >> =A0> Also in >> =A0> >> =A0> ; value >> =A0> STS-v =3D STS-d >> =A0> / STS-d *( OWS ";" OWS STS-d OWS ) >> =A0> >> =A0> ; STS directive >> =A0> STS-d =3D STS-d-cur / STS-d-ext >> =A0> >> =A0> ; defined STS directives >> =A0> STS-d-cur =3D maxAge / [ includeSubDomains ] >> =A0> >> =A0> having includeSubDomains optional is a bit weird. >> =A0> >> =A0> This means that the empty string would be a valid STS-d-cur, thus a= n >> =A0> empty header field is allowed... >> >> Ah, thanks, yes -- i was unsure of how to make includeSubDomains >> optional while max-age is required, and that hack didn't work. >> >> I've now re-worked it as below -- how's that look? >> >> thanks again, >> >> =3DJeffH >> >> >> Strict-Transport-Security =3D >> "Strict-Transport-Security" ":" OWS STS-v OWS >> >> ; STS header field value; must have a max-age: >> >> STS-v =3D max-age >> / max-age *( OWS ";" OWS STS-d OWS ) > > ...which makes putting max-age first required. > >> ; additional STS directives: >> >> STS-d =3D STS-d-cur / STS-d-ext >> >> ; currently defined STS directives, >> ; delta-seconds is 1*DIGIT and is from [RFC2616]: >> >> max-age =3D "max-age" OWS "=3D" OWS delta-seconds [ OWS v-ext ] >> >> STS-d-cur =3D includeSubDomains >> >> includeSubDomains =3D "includeSubDomains" [ OWS v-ext ] >> >> >> ; extension points >> STS-d-ext =3D name ; STS extension directive >> >> v-ext =3D value ; STS extension value >> >> name =3D token >> >> value =3D OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or >> ; [ ! .. : ] [ < .. ~ ] any visible chars other than ";" >> >> token =3D 1*tchar >> >> tchar =3D "!" / "#" / "$" / "%" / "&" / "'" / "*" >> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" >> / DIGIT / ALPHA >> ; visible (printing) characters, except visible >> ; separators. >> ; DIGIT, ALPHA, separators are from [RFC2616] >> >> ; Basic rules: >> >> OWS =3D *( [ CRLF ] WSP ) >> ; Optional White Space >> >> WSP =3D SP / HTAB >> >> CRLF =3D CR LF >> >> ; CR, LF, SP, HTAB are from [RFC2616] >> >> >> --- >> end > > I think it would be simpler not to try to express this in the ABNF. > > Just use the ABNF to state the core syntax (that a parser will need to > understand), and then put additional requirements about what directives m= ust > be there in prose (we're doing the same in HTTPbis, but aren't done yet..= . > :-). > > Best regards, Julian > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > --=20 Website: http://hallambaker.com/ From Jeff.Hodges@KingsMountain.com Tue Sep 27 16:14:13 2011 Return-Path: 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 D7C5521F8F38 for ; Tue, 27 Sep 2011 16:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.483 X-Spam-Level: X-Spam-Status: No, score=-100.483 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 yz63bILsHhrM for ; Tue, 27 Sep 2011 16:14:11 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id C4F5D21F8EC8 for ; Tue, 27 Sep 2011 16:14:09 -0700 (PDT) Received: (qmail 21031 invoked by uid 0); 27 Sep 2011 23:16:54 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 27 Sep 2011 23:16:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=tkAnmpFwydb7SKJAMGWMPCo5j8napIsgD4byRKpiI7M=; b=LkRGethSJcpfEWF96018PFrnMiPo7REE5Khd1llsJbmoUn1bJmYmPF7QyporaASMYtPwApqtldMFOJspWXgxWO0Fsl5+RF2Z8isjG7kzOLX9Kmh2NdU56plM3j2Se3Bm; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.88]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R8gtS-0004Ci-JS; Tue, 27 Sep 2011 17:16:54 -0600 Message-ID: <4E825968.1020601@KingsMountain.com> Date: Tue, 27 Sep 2011 16:16:56 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: IETF WebSec WG , Julian Reschke Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Strict-Transport-Security syntax X-BeenThere: websec@ietf.org 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: Tue, 27 Sep 2011 23:14:13 -0000 thx for the comments Julian. > On 2011-09-14 23:08, =JeffH wrote: >> > a few questions about the header field syntax: >> > >> > Strict-Transport-Security = >> > "Strict-Transport-Security" ":" OWS STS-v OWS >> > >> > So the header field is *not* using the RFC2616 list syntax. So you >> can have >> > >> > Strict-Transport-Security: a; b >> > >> > but *not* >> > >> > Strict-Transport-Security: a >> > Strict-Transport-Security: b >> > >> > because that would be equivalent to >> > >> > Strict-Transport-Security: a, b >> > >> > (is this intentional?) >> >> well, it was not necessarily intentional as far as I recall. We either >> managed to overlook, or regarded as inappropriate for this header, the >> RFC2616 list syntax (i.e., the "#rule"), that defines such implicit >> comma-separated lists. >> Also, we'd noted that quite a number of header field definitions used >> semi-colons as a delimiter, but perhaps hadn't noted that those overall >> productions often are embedded within such comma-separated lists. > > Yes, that's the list-of-parametrized-things format. > >> However, in thinking about it a little bit, for this particular header >> field, as it's presently defined, it doesn't seem appropriate to have it >> explicitly be comma-separated repeatable (aka #rule), because only one >> instance of "S-T-S: max-age=n" is effective in terms of established the >> cached Known HSTS Host in the UA. > > In that case, as this is security related, you may want to talk about > what recipients are to do when (a) they *do* get multiple instances, that's already done in -websec-strict-transport-sec-02 in S 7.1. > and > (b) when an intermediate folds multiple headers using the comma syntax. ah, so an intermediate can/might do that to multiple occurrences of any header field in a message ? >> > Also in >> > >> > ; value >> > STS-v = STS-d >> > / STS-d *( OWS ";" OWS STS-d OWS ) >> > >> > ; STS directive >> > STS-d = STS-d-cur / STS-d-ext >> > >> > ; defined STS directives >> > STS-d-cur = maxAge / [ includeSubDomains ] >> > >> > having includeSubDomains optional is a bit weird. >> > >> > This means that the empty string would be a valid STS-d-cur, thus an >> > empty header field is allowed... >> >> Ah, thanks, yes -- i was unsure of how to make includeSubDomains >> optional while max-age is required, and that hack didn't work. >> >> I've now re-worked it as below -- how's that look? >> >> thanks again, >> >> =JeffH >> >> >> Strict-Transport-Security = >> "Strict-Transport-Security" ":" OWS STS-v OWS >> >> ; STS header field value; must have a max-age: >> >> STS-v = max-age >> / max-age *( OWS ";" OWS STS-d OWS ) > > ...which makes putting max-age first required. > >> ; additional STS directives: >> >> STS-d = STS-d-cur / STS-d-ext >> >> ; currently defined STS directives, >> ; delta-seconds is 1*DIGIT and is from [RFC2616]: >> >> max-age = "max-age" OWS "=" OWS delta-seconds [ OWS v-ext ] >> >> STS-d-cur = includeSubDomains >> >> includeSubDomains = "includeSubDomains" [ OWS v-ext ] >> >> >> ; extension points >> STS-d-ext = name ; STS extension directive >> >> v-ext = value ; STS extension value >> >> name = token >> >> value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or >> ; [ ! .. : ] [ < .. ~ ] any visible chars other than ";" >> >> token = 1*tchar >> >> tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" >> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" >> / DIGIT / ALPHA >> ; visible (printing) characters, except visible >> ; separators. >> ; DIGIT, ALPHA, separators are from [RFC2616] >> >> ; Basic rules: >> >> OWS = *( [ CRLF ] WSP ) >> ; Optional White Space >> >> WSP = SP / HTAB >> >> CRLF = CR LF >> >> ; CR, LF, SP, HTAB are from [RFC2616] >> >> >> --- >> end > > I think it would be simpler not to try to express this in the ABNF. what do you mean by "this" ? > Just use the ABNF to state the core syntax (that a parser will need to > understand), and then put additional requirements about what directives > must be there in prose (we're doing the same in HTTPbis, but aren't done > yet... :-). do you have a particular example in mind? I'm guessing that the Expect header might be a good example, from -httpbis-p2-semantics-16, yes? thanks again, =JeffH From paul.hoffman@vpnc.org Tue Sep 27 17:20:06 2011 Return-Path: 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 DD5D921F8FD2 for ; Tue, 27 Sep 2011 17:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hUUCBE9jiIqP for ; Tue, 27 Sep 2011 17:20:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6411E21F8FB3 for ; Tue, 27 Sep 2011 17:20:06 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p8S0Mqb5075134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 27 Sep 2011 17:22:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Tue, 27 Sep 2011 17:22:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90CBD0BD-FFF0-4657-915F-ED5391B21D01@vpnc.org> References: To: websec X-Mailer: Apple Mail (2.1244.3) Subject: Re: [websec] Digest URI scheme X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: