From ynir@checkpoint.com Sat Jun 1 23:42:07 2013 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 2822021F9F99 for ; Sat, 1 Jun 2013 23:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 QxiDF0F4eCcy for ; Sat, 1 Jun 2013 23:42:01 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1558121F9F90 for ; Sat, 1 Jun 2013 23:42:00 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r526fxeU026225 for ; Sun, 2 Jun 2013 09:41:59 +0300 X-CheckPoint: {51AAE937-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sun, 2 Jun 2013 09:41:58 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] Consensus call: Issue #57 (max-max-age) Thread-Index: AQHOSvJfUWwKnsbs2U6hMAgGMyNIfJkAPs4AgABLswCAAL0DAIAGBnoAgAPHdQCABoGgAIAAI4SAgAASTgCACJ5sAIAA0hIAgABR5YCAAUIOgIAFHwiA Date: Sun, 2 Jun 2013 06:41:57 +0000 Message-ID: <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11ef87c86b845f307e13d4a88e7361f40e0af50096 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 02 Jun 2013 06:42:07 -0000 Hi Just trying to get us close to consensus. Still no hats. There are two argu= ments for limiting max-age: 1. With unlimited max-age, it's possible for the legitimate site owner to b= y mistake damage their sites. You could pin the CA certificate, and lock yo= urself in to that CA for all eternity. You could pin a current and future E= E public keys, and then when the current public key expires, you might not = use the future one because you mistyped it (or your CA no longer accepts 10= 24-bit keys). For whatever reason, a bad choice you make while trying out H= PKP either bricks your site or constrains your behavior for a while. 2. With unlimited max-age, a current owner of a domain name can set a pin t= hat a future owner cannot honor. So if Mr. diaper consultant[1] ever decide= s to retire, he could set a long-lived pin such that I would not be able to= use the domain even if I buy it. A variation on this is the case where an = attacker like ComodoHacker manages to MitM a popular site, and he sets a lo= ng-lived pin that prevents users from accessing the site not through the Mi= tM. This means that browser support for HPKP could serve to amplify attacks= that are plenty bad enough as they are. Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty b= ig gun with which users can shoot themselves in the foot. A website that's = important for its owner (whether it's social networking, political action, = or business) cannot afford to be inaccessible for any length of time. A mon= th is no less a disaster than a year. As for constraining your behavior, th= is merits deployment advice, not limiting the usefulness of the protocol fo= r other sites. #2 is more worrying. I think the previous owner issue would be served even = with a 1 year hard limit, and I don't think anyone here is arguing that a 1= -year limit is too short. But the attack amplification is a real thing, and= it works against sites that haven't even implemented HPKP. Sites that depl= oy HPKP are protected from a MitM such as ComodoHacker (or his "friends"). = But having HPKP in the browser (but not in the website) allows his friends = to lock out browsers by inserting a pin. So if browsers implement this, it = amplifies attacks against the general population of SSL-protected web sites= . I'm not sure whether in the grand scheme of things this makes the Interne= t better or worse. Note, though, that this issue exists even if max-age is limited. Bricking t= he site for a month (for some users in Iran) is a bad enough outcome, only = slightly mitigated by it being only for a month. I started out writing this message thinking it was going to have a proposal= that we could all reach consensus about. I'm not sure I got there. I guess= if this was a vote, I would vote for a year-long max-max-age, but I'm not = really as sure about this as I was when I started writing this message. Yoav [1] http://www.yoavnir.com= From trevp@trevp.net Sun Jun 2 23:29:27 2013 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 15F1121F88FB for ; Sun, 2 Jun 2013 23:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 B-nS0KMNWMvl for ; Sun, 2 Jun 2013 23:29:23 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1821F89EB for ; Sun, 2 Jun 2013 23:29:22 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k13so2338860wgh.0 for ; Sun, 02 Jun 2013 23:29:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XxRqaBfibIovcNkOlKAr5SKKzHcsgHX3cy9PX4+A9qE=; b=AHoSv7cFUkrN9qivY380/qvhz/chooHy7rfafdcAzDwDnIHvMX5DtDR9Rq6IvyOqti UKTIUkjFy8ghY9WijMBmZeqMMt1Y0PeEYuPN1vgWOUZQbDJBzoMlvSDNjNCwWLxCUngC WWUAwmK2LI1OGXqN5vuPWLMgE9vmhHRPqogUMVTx3zcVjE4Nl6jb+34+n+fxOJp5ltOI a9dKIapXFQZRJ7JkkyeEexkfD80/JZ2XvYXVdV07FcgQBwYN68LE3kVsBSGp8wFof9en k0oNmYmNYBCmkHyEPHzibpKA9XD2A2Nf1gTECwf10pEYRRXc9otwntjyX+9+Za6fum0b jS8g== MIME-Version: 1.0 X-Received: by 10.194.59.72 with SMTP id x8mr17400413wjq.49.1370240961460; Sun, 02 Jun 2013 23:29:21 -0700 (PDT) Received: by 10.217.110.129 with HTTP; Sun, 2 Jun 2013 23:29:21 -0700 (PDT) X-Originating-IP: [166.147.108.64] In-Reply-To: <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> Date: Sun, 2 Jun 2013 23:29:21 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7ba97308c3cd1d04de3a1510 X-Gm-Message-State: ALoCoQkyB4snm+BixRJnefEtKKqH5qGcqKbs17iZ8GbmAAOrdXjMMHqSVZTj7tHVOwn88CvEHN57 Cc: IETF WebSec WG Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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: Mon, 03 Jun 2013 06:29:27 -0000 --047d7ba97308c3cd1d04de3a1510 Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav, all, We've talked a lot about the risks of long-lived pins. We should also think more about the benefits. I'll argue that pin lifetimes past a certain point don't get you much. Browser-based "key continuity" will hopefully be supplemented by systems that scan pin assertions regularly from different points on the Internet (like Perspectives, Convergence, Vantages, etc.). Such systems would derive pins more reliably than individual browsers, and could use several methods to distribute these pins. Since scanning of sites can be done frequently, and distribution would also be fast, long-lived pins aren't needed for this. The hard part of this isn't scanning, it's pin distribution. Here's three ways that could be done: Links: Pins could be embedded in hyperlinks served over HTTPS. Since much browsing consists of following links from the web's major "introducers" (search engines, social networks, etc.), having these sites embed pins would protect a lot of traffic. See the recent "S-links" paper [1]. Lists: Modern browsers download lists of security info on a regular basis, including lists of malware and phishing sites [2], commonly-downloaded files [3], and revoked certs [4]. You could imagine pin lists being downloaded, so that every browser has a current list of pins for, say, 10,000 major sites. Lookups: Browsers are reluctant to do per-connection blocking lookups (see OCSP, Convergence, and DNSSEC). But there might be more efficient and less-problematic ways to combine pin and DNS lookups (e.g. connections to DNS resolvers via VPNs, or some simpler form of response authentication). Also, non-blocking pin lookups could be used after-the-fact to detect attacks (if a MITM blocks the lookup for an extended period, the browser would start complaining). Anyways, 30-day pins seem adequate for any of these. Assuming sites can be rescanned weekly, pins received through links, lists, or lookups are likely to have 20+ days of validity left in them, which is plenty of time for the browser to follow a link, or use a list without its entries expiring. This is a complicated issue, and I don't expect this email to resolve it. But I at least hope this lessens any perception that short-lived pins would offer weak security. Trevor [1] http://research.google.com/pubs/archive/41138.pdf [2] https://developers.google.com/safe-browsing/ [3] http://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequently-asked-questions-ie9 [4] http://www.imperialviolet.org/2012/02/05/crlsets.html On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir wrote: > Hi > > Just trying to get us close to consensus. Still no hats. There are two > arguments for limiting max-age: > > 1. With unlimited max-age, it's possible for the legitimate site owner to > by mistake damage their sites. You could pin the CA certificate, and lock > yourself in to that CA for all eternity. You could pin a current and future > EE public keys, and then when the current public key expires, you might not > use the future one because you mistyped it (or your CA no longer accepts > 1024-bit keys). For whatever reason, a bad choice you make while trying out > HPKP either bricks your site or constrains your behavior for a while. > > 2. With unlimited max-age, a current owner of a domain name can set a pin > that a future owner cannot honor. So if Mr. diaper consultant[1] ever > decides to retire, he could set a long-lived pin such that I would not be > able to use the domain even if I buy it. A variation on this is the case > where an attacker like ComodoHacker manages to MitM a popular site, and he > sets a long-lived pin that prevents users from accessing the site not > through the MitM. This means that browser support for HPKP could serve to > amplify attacks that are plenty bad enough as they are. > > Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty > big gun with which users can shoot themselves in the foot. A website that's > important for its owner (whether it's social networking, political action, > or business) cannot afford to be inaccessible for any length of time. A > month is no less a disaster than a year. As for constraining your behavior, > this merits deployment advice, not limiting the usefulness of the protocol > for other sites. > > #2 is more worrying. I think the previous owner issue would be served even > with a 1 year hard limit, and I don't think anyone here is arguing that a > 1-year limit is too short. But the attack amplification is a real thing, > and it works against sites that haven't even implemented HPKP. Sites that > deploy HPKP are protected from a MitM such as ComodoHacker (or his > "friends"). But having HPKP in the browser (but not in the website) allows > his friends to lock out browsers by inserting a pin. So if browsers > implement this, it amplifies attacks against the general population of > SSL-protected web sites. I'm not sure whether in the grand scheme of things > this makes the Internet better or worse. > > Note, though, that this issue exists even if max-age is limited. Bricking > the site for a month (for some users in Iran) is a bad enough outcome, only > slightly mitigated by it being only for a month. > > I started out writing this message thinking it was going to have a > proposal that we could all reach consensus about. I'm not sure I got there. > I guess if this was a vote, I would vote for a year-long max-max-age, but > I'm not really as sure about this as I was when I started writing this > message. > > Yoav > > [1] http://www.yoavnir.com > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > --047d7ba97308c3cd1d04de3a1510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Yoav, all,

We've talked a lot about the risks of long-lived pins. =A0We should al= so think more about the benefits. =A0

I'll arg= ue that pin lifetimes past a certain point don't get you much. =A0Brows= er-based "key continuity" will hopefully be supplemented by syste= ms that scan pin assertions regularly from different points on the Internet= (like Perspectives, Convergence, Vantages, etc.). =A0Such systems would de= rive pins more reliably than individual browsers, and could use several met= hods to distribute these pins. =A0Since scanning of sites can be done frequ= ently, and distribution would also be fast, long-lived pins aren't need= ed for this.

The hard part of this isn't scanning, it's pin = distribution. =A0Here's three ways that could be done:

Links: =A0Pins could be embedded in hyperlinks served over HTTPS. = =A0Since much browsing consists of following links from the web's major= "introducers" (search engines, social networks, etc.), having th= ese sites embed pins would protect a lot of traffic. =A0See the recent &quo= t;S-links" paper [1].

Lists: =A0Modern browsers download lists of security in= fo on a regular basis, including lists of malware and phishing sites [2], c= ommonly-downloaded files [3], and revoked certs [4]. =A0You could imagine p= in lists being downloaded, so that every browser has a current list of pins= for, say, 10,000 major sites.

Lookups: =A0Browsers are reluctant to do per-connection= blocking lookups (see OCSP, Convergence, and DNSSEC). =A0But there might b= e more efficient and less-problematic ways to combine pin and DNS lookups (= e.g. connections to DNS resolvers via VPNs, or some simpler form of respons= e authentication). =A0Also, non-blocking pin lookups could be used after-th= e-fact to detect attacks (if a MITM blocks the lookup for an extended perio= d, the browser would start complaining).


Anyways, 30-day pins seem adequate for a= ny of these. =A0Assuming sites can be rescanned weekly, pins received throu= gh links, lists, or lookups are likely to have 20+ days of validity left in= them, which is plenty of time for the browser to follow a link, or use a l= ist without its entries expiring.

This is a complicated issue, and I don't expect thi= s email to resolve it. =A0But I at least hope this lessens any perception t= hat short-lived pins would offer weak security.


Trevor




On Sat, J= un 1, 2013 at 11:41 PM, Yoav Nir <ynir@checkpoint.com> wro= te:
Hi

Just trying to get us close to consensus. Still no hats. There are two argu= ments for limiting max-age:

1. With unlimited max-age, it's possible for the legitimate site owner = to by mistake damage their sites. You could pin the CA certificate, and loc= k yourself in to that CA for all eternity. You could pin a current and futu= re EE public keys, and then when the current public key expires, you might = not use the future one because you mistyped it (or your CA no longer accept= s 1024-bit keys). For whatever reason, a bad choice you make while trying o= ut HPKP either bricks your site or constrains your behavior for a while.
2. With unlimited max-age, a current owner of a domain name can set a pin t= hat a future owner cannot honor. So if Mr. diaper consultant[1] ever decide= s to retire, he could set a long-lived pin such that I would not be able to= use the domain even if I buy it. A variation on this is the case where an = attacker like ComodoHacker manages to MitM a popular site, and he sets a lo= ng-lived pin that prevents users from accessing the site not through the Mi= tM. This means that browser support for HPKP could serve to amplify attacks= that are plenty bad enough as they are.

Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pret= ty big gun with which users can shoot themselves in the foot. A website tha= t's important for its owner (whether it's social networking, politi= cal action, or business) cannot afford to be inaccessible for any length of= time. A month is no less a disaster than a year. As for constraining your = behavior, this merits deployment advice, not limiting the usefulness of the= protocol for other sites.

#2 is more worrying. I think the previous owner issue would be served even = with a 1 year hard limit, and I don't think anyone here is arguing that= a 1-year limit is too short. But the attack amplification is a real thing,= and it works against sites that haven't even implemented HPKP. Sites t= hat deploy HPKP are protected from a MitM such as ComodoHacker (or his &quo= t;friends"). But having HPKP in the browser (but not in the website) a= llows his friends to lock out browsers by inserting a pin. So if browsers i= mplement this, it amplifies attacks against the general population of SSL-p= rotected web sites. I'm not sure whether in the grand scheme of things = this makes the Internet better or worse.

Note, though, that this issue exists even if max-age is limited. Bricking t= he site for a month (for some users in Iran) is a bad enough outcome, only = slightly mitigated by it being only for a month.

I started out writing this message thinking it was going to have a proposal= that we could all reach consensus about. I'm not sure I got there. I g= uess if this was a vote, I would vote for a year-long max-max-age, but I= 9;m not really as sure about this as I was when I started writing this mess= age.

Yoav

[1] http://www.yoavnir= .com
___________________________________= ____________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec

--047d7ba97308c3cd1d04de3a1510-- From tobias.gondrom@gondrom.org Tue Jun 4 04:12:23 2013 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 6589F21F9AD8 for ; Tue, 4 Jun 2013 04:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=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 u2RQacZ65iDT for ; Tue, 4 Jun 2013 04:12:09 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id F2B2521F9B45 for ; Tue, 4 Jun 2013 03:04:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=s10nw3siqRWOar+/RG6ew5XV73uFbtKR6Txo3/f8Z5fs2ODswQCWqSe71lQvBIWpd3z6zVV6qvOnj+qzfqg9/Fa6PVSAowKV2Lcu0dfe1l3GxSuXu15ya57ONcSfbFBW; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 9659 invoked from network); 4 Jun 2013 12:04:20 +0200 Received: from 188-222-173-238.zone13.bethere.co.uk (HELO ?192.168.1.94?) (188.222.173.238) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Jun 2013 12:04:20 +0200 Message-ID: <51ADBBA3.3000105@gondrom.org> Date: Tue, 04 Jun 2013 11:04:19 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: trevp@trevp.net References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------090307020203030907010703" Cc: websec@ietf.org Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 04 Jun 2013 11:12:23 -0000 This is a multi-part message in MIME format. --------------090307020203030907010703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Trevor, hi all, (again no hats) actually regarding browser lookups of pin lists: I rather have the pins work unlimited and all the time even without pin lists. But your idea might in fact be a solution to enable the unlimited pin times. Instead of constantly distributing the list of pins, we could actually have browsers use whitelists of pins that have been "revoked" and where the browser is allowed to refresh. That could e.g. happen with a browser update. That way we can have a unlimited time pin (and pre-caching of pins) and solve the scenario of malicious domain blocking by previous owners. And hopefully that scenario will hardly happen at all (especially if there is a provision for solving it and the attempt is futile, the motivation for an attacker trying it might be close to zero). Best regards, Tobias On 03/06/13 07:29, Trevor Perrin wrote: > > Hi Yoav, all, > > We've talked a lot about the risks of long-lived pins. We should also > think more about the benefits. > > I'll argue that pin lifetimes past a certain point don't get you much. > Browser-based "key continuity" will hopefully be supplemented by > systems that scan pin assertions regularly from different points on > the Internet (like Perspectives, Convergence, Vantages, etc.). Such > systems would derive pins more reliably than individual browsers, and > could use several methods to distribute these pins. Since scanning of > sites can be done frequently, and distribution would also be fast, > long-lived pins aren't needed for this. > > The hard part of this isn't scanning, it's pin distribution. Here's > three ways that could be done: > > Links: Pins could be embedded in hyperlinks served over HTTPS. Since > much browsing consists of following links from the web's major > "introducers" (search engines, social networks, etc.), having these > sites embed pins would protect a lot of traffic. See the recent > "S-links" paper [1]. > > Lists: Modern browsers download lists of security info on a regular > basis, including lists of malware and phishing sites [2], > commonly-downloaded files [3], and revoked certs [4]. You could > imagine pin lists being downloaded, so that every browser has a > current list of pins for, say, 10,000 major sites. > > Lookups: Browsers are reluctant to do per-connection blocking lookups > (see OCSP, Convergence, and DNSSEC). But there might be more > efficient and less-problematic ways to combine pin and DNS lookups > (e.g. connections to DNS resolvers via VPNs, or some simpler form of > response authentication). Also, non-blocking pin lookups could be > used after-the-fact to detect attacks (if a MITM blocks the lookup for > an extended period, the browser would start complaining). > > > Anyways, 30-day pins seem adequate for any of these. Assuming sites > can be rescanned weekly, pins received through links, lists, or > lookups are likely to have 20+ days of validity left in them, which is > plenty of time for the browser to follow a link, or use a list without > its entries expiring. > > This is a complicated issue, and I don't expect this email to resolve > it. But I at least hope this lessens any perception that short-lived > pins would offer weak security. > > > Trevor > > [1] http://research.google.com/pubs/archive/41138.pdf > [2] https://developers.google.com/safe-browsing/ > [3] > http://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequently-asked-questions-ie9 > [4] http://www.imperialviolet.org/2012/02/05/crlsets.html > > > > On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir > wrote: > > Hi > > Just trying to get us close to consensus. Still no hats. There are > two arguments for limiting max-age: > > 1. With unlimited max-age, it's possible for the legitimate site > owner to by mistake damage their sites. You could pin the CA > certificate, and lock yourself in to that CA for all eternity. You > could pin a current and future EE public keys, and then when the > current public key expires, you might not use the future one > because you mistyped it (or your CA no longer accepts 1024-bit > keys). For whatever reason, a bad choice you make while trying out > HPKP either bricks your site or constrains your behavior for a while. > > 2. With unlimited max-age, a current owner of a domain name can > set a pin that a future owner cannot honor. So if Mr. diaper > consultant[1] ever decides to retire, he could set a long-lived > pin such that I would not be able to use the domain even if I buy > it. A variation on this is the case where an attacker like > ComodoHacker manages to MitM a popular site, and he sets a > long-lived pin that prevents users from accessing the site not > through the MitM. This means that browser support for HPKP could > serve to amplify attacks that are plenty bad enough as they are. > > Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a > pretty big gun with which users can shoot themselves in the foot. > A website that's important for its owner (whether it's social > networking, political action, or business) cannot afford to be > inaccessible for any length of time. A month is no less a disaster > than a year. As for constraining your behavior, this merits > deployment advice, not limiting the usefulness of the protocol for > other sites. > > #2 is more worrying. I think the previous owner issue would be > served even with a 1 year hard limit, and I don't think anyone > here is arguing that a 1-year limit is too short. But the attack > amplification is a real thing, and it works against sites that > haven't even implemented HPKP. Sites that deploy HPKP are > protected from a MitM such as ComodoHacker (or his "friends"). But > having HPKP in the browser (but not in the website) allows his > friends to lock out browsers by inserting a pin. So if browsers > implement this, it amplifies attacks against the general > population of SSL-protected web sites. I'm not sure whether in the > grand scheme of things this makes the Internet better or worse. > > Note, though, that this issue exists even if max-age is limited. > Bricking the site for a month (for some users in Iran) is a bad > enough outcome, only slightly mitigated by it being only for a month. > > I started out writing this message thinking it was going to have a > proposal that we could all reach consensus about. I'm not sure I > got there. I guess if this was a vote, I would vote for a > year-long max-max-age, but I'm not really as sure about this as I > was when I started writing this message. > > Yoav > > [1] http://www.yoavnir.com > _______________________________________________ > 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 --------------090307020203030907010703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Trevor, hi all,

(again no hats)

actually regarding browser lookups of pin lists:
I rather have the pins work unlimited and all the time even without pin lists.

But your idea might in fact be a solution to enable the unlimited pin times.
Instead of constantly distributing the list of pins, we could actually have browsers use whitelists of pins that have been "revoked" and where the browser is allowed to refresh. That could e.g. happen with a browser update.
That way we can have a unlimited time pin (and pre-caching of pins) and solve the scenario of malicious domain blocking by previous owners. And hopefully that scenario will hardly happen at all (especially if there is a provision for solving it and the attempt is futile, the motivation for an attacker trying it might be close to zero).

Best regards, Tobias




On 03/06/13 07:29, Trevor Perrin wrote:

Hi Yoav, all,

We've talked a lot about the risks of long-lived pins.  We should also think more about the benefits.  

I'll argue that pin lifetimes past a certain point don't get you much.  Browser-based "key continuity" will hopefully be supplemented by systems that scan pin assertions regularly from different points on the Internet (like Perspectives, Convergence, Vantages, etc.).  Such systems would derive pins more reliably than individual browsers, and could use several methods to distribute these pins.  Since scanning of sites can be done frequently, and distribution would also be fast, long-lived pins aren't needed for this.

The hard part of this isn't scanning, it's pin distribution.  Here's three ways that could be done:

Links:  Pins could be embedded in hyperlinks served over HTTPS.  Since much browsing consists of following links from the web's major "introducers" (search engines, social networks, etc.), having these sites embed pins would protect a lot of traffic.  See the recent "S-links" paper [1].

Lists:  Modern browsers download lists of security info on a regular basis, including lists of malware and phishing sites [2], commonly-downloaded files [3], and revoked certs [4].  You could imagine pin lists being downloaded, so that every browser has a current list of pins for, say, 10,000 major sites.

Lookups:  Browsers are reluctant to do per-connection blocking lookups (see OCSP, Convergence, and DNSSEC).  But there might be more efficient and less-problematic ways to combine pin and DNS lookups (e.g. connections to DNS resolvers via VPNs, or some simpler form of response authentication).  Also, non-blocking pin lookups could be used after-the-fact to detect attacks (if a MITM blocks the lookup for an extended period, the browser would start complaining).


Anyways, 30-day pins seem adequate for any of these.  Assuming sites can be rescanned weekly, pins received through links, lists, or lookups are likely to have 20+ days of validity left in them, which is plenty of time for the browser to follow a link, or use a list without its entries expiring.

This is a complicated issue, and I don't expect this email to resolve it.  But I at least hope this lessens any perception that short-lived pins would offer weak security.


Trevor




On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi

Just trying to get us close to consensus. Still no hats. There are two arguments for limiting max-age:

1. With unlimited max-age, it's possible for the legitimate site owner to by mistake damage their sites. You could pin the CA certificate, and lock yourself in to that CA for all eternity. You could pin a current and future EE public keys, and then when the current public key expires, you might not use the future one because you mistyped it (or your CA no longer accepts 1024-bit keys). For whatever reason, a bad choice you make while trying out HPKP either bricks your site or constrains your behavior for a while.

2. With unlimited max-age, a current owner of a domain name can set a pin that a future owner cannot honor. So if Mr. diaper consultant[1] ever decides to retire, he could set a long-lived pin such that I would not be able to use the domain even if I buy it. A variation on this is the case where an attacker like ComodoHacker manages to MitM a popular site, and he sets a long-lived pin that prevents users from accessing the site not through the MitM. This means that browser support for HPKP could serve to amplify attacks that are plenty bad enough as they are.

Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty big gun with which users can shoot themselves in the foot. A website that's important for its owner (whether it's social networking, political action, or business) cannot afford to be inaccessible for any length of time. A month is no less a disaster than a year. As for constraining your behavior, this merits deployment advice, not limiting the usefulness of the protocol for other sites.

#2 is more worrying. I think the previous owner issue would be served even with a 1 year hard limit, and I don't think anyone here is arguing that a 1-year limit is too short. But the attack amplification is a real thing, and it works against sites that haven't even implemented HPKP. Sites that deploy HPKP are protected from a MitM such as ComodoHacker (or his "friends"). But having HPKP in the browser (but not in the website) allows his friends to lock out browsers by inserting a pin. So if browsers implement this, it amplifies attacks against the general population of SSL-protected web sites. I'm not sure whether in the grand scheme of things this makes the Internet better or worse.

Note, though, that this issue exists even if max-age is limited. Bricking the site for a month (for some users in Iran) is a bad enough outcome, only slightly mitigated by it being only for a month.

I started out writing this message thinking it was going to have a proposal that we could all reach consensus about. I'm not sure I got there. I guess if this was a vote, I would vote for a year-long max-max-age, but I'm not really as sure about this as I was when I started writing this message.

Yoav

[1] http://www.yoavnir.com
_______________________________________________
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

--------------090307020203030907010703-- From ynir@checkpoint.com Tue Jun 4 05:32:38 2013 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 9ACB821F9C85 for ; Tue, 4 Jun 2013 05:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UeShPU1Iugtn for ; Tue, 4 Jun 2013 05:32:24 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 55D9D21F9B43 for ; Tue, 4 Jun 2013 04:07:46 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r54B7dxB022513; Tue, 4 Jun 2013 14:07:39 +0300 X-CheckPoint: {51ADCA7B-1E-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Tue, 4 Jun 2013 14:07:39 +0300 From: Yoav Nir To: Tobias Gondrom Thread-Topic: [websec] Consensus call: Issue #57 (max-max-age) Thread-Index: AQHOSvJfUWwKnsbs2U6hMAgGMyNIfJkAPs4AgABLswCAAL0DAIAGBnoAgAPHdQCABoGgAIAAI4SAgAASTgCACJ5sAIAA0hIAgABR5YCAAUIOgIAFHwiAgAGOz4CAAc5lgIAAEbEA Date: Tue, 4 Jun 2013 11:07:38 +0000 Message-ID: <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> <51ADBBA3.3000105@gondrom.org> In-Reply-To: <51ADBBA3.3000105@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11735080455fbe502cc39cd07edeb47ee7e91b9fc8 Content-Type: multipart/alternative; boundary="_000_77BFAD4136DD46C7A277D1416F7EE958checkpointcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 04 Jun 2013 12:32:38 -0000 --_000_77BFAD4136DD46C7A277D1416F7EE958checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But doesn't this introduce a lot of infrastructure? If we want to find out a hash of the public key for an HTTPS server using h= eavy infrastructure, we might as well use DANE, no? Yoav On Jun 4, 2013, at 1:04 PM, Tobias Gondrom > wrote: Hi Trevor, hi all, (again no hats) actually regarding browser lookups of pin lists: I rather have the pins work unlimited and all the time even without pin lis= ts. But your idea might in fact be a solution to enable the unlimited pin times= . Instead of constantly distributing the list of pins, we could actually have= browsers use whitelists of pins that have been "revoked" and where the bro= wser is allowed to refresh. That could e.g. happen with a browser update. That way we can have a unlimited time pin (and pre-caching of pins) and sol= ve the scenario of malicious domain blocking by previous owners. And hopefu= lly that scenario will hardly happen at all (especially if there is a provi= sion for solving it and the attempt is futile, the motivation for an attack= er trying it might be close to zero). Best regards, Tobias On 03/06/13 07:29, Trevor Perrin wrote: Hi Yoav, all, We've talked a lot about the risks of long-lived pins. We should also thin= k more about the benefits. I'll argue that pin lifetimes past a certain point don't get you much. Bro= wser-based "key continuity" will hopefully be supplemented by systems that = scan pin assertions regularly from different points on the Internet (like P= erspectives, Convergence, Vantages, etc.). Such systems would derive pins = more reliably than individual browsers, and could use several methods to di= stribute these pins. Since scanning of sites can be done frequently, and d= istribution would also be fast, long-lived pins aren't needed for this. The hard part of this isn't scanning, it's pin distribution. Here's three = ways that could be done: Links: Pins could be embedded in hyperlinks served over HTTPS. Since much= browsing consists of following links from the web's major "introducers" (s= earch engines, social networks, etc.), having these sites embed pins would = protect a lot of traffic. See the recent "S-links" paper [1]. Lists: Modern browsers download lists of security info on a regular basis,= including lists of malware and phishing sites [2], commonly-downloaded fil= es [3], and revoked certs [4]. You could imagine pin lists being downloade= d, so that every browser has a current list of pins for, say, 10,000 major = sites. Lookups: Browsers are reluctant to do per-connection blocking lookups (see= OCSP, Convergence, and DNSSEC). But there might be more efficient and les= s-problematic ways to combine pin and DNS lookups (e.g. connections to DNS = resolvers via VPNs, or some simpler form of response authentication). Also= , non-blocking pin lookups could be used after-the-fact to detect attacks (= if a MITM blocks the lookup for an extended period, the browser would start= complaining). Anyways, 30-day pins seem adequate for any of these. Assuming sites can be= rescanned weekly, pins received through links, lists, or lookups are likel= y to have 20+ days of validity left in them, which is plenty of time for th= e browser to follow a link, or use a list without its entries expiring. This is a complicated issue, and I don't expect this email to resolve it. = But I at least hope this lessens any perception that short-lived pins would= offer weak security. Trevor [1] http://research.google.com/pubs/archive/41138.pdf [2] https://developers.google.com/safe-browsing/ [3] http://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequent= ly-asked-questions-ie9 [4] http://www.imperialviolet.org/2012/02/05/crlsets.html On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir > wrote: Hi Just trying to get us close to consensus. Still no hats. There are two argu= ments for limiting max-age: 1. With unlimited max-age, it's possible for the legitimate site owner to b= y mistake damage their sites. You could pin the CA certificate, and lock yo= urself in to that CA for all eternity. You could pin a current and future E= E public keys, and then when the current public key expires, you might not = use the future one because you mistyped it (or your CA no longer accepts 10= 24-bit keys). For whatever reason, a bad choice you make while trying out H= PKP either bricks your site or constrains your behavior for a while. 2. With unlimited max-age, a current owner of a domain name can set a pin t= hat a future owner cannot honor. So if Mr. diaper consultant[1] ever decide= s to retire, he could set a long-lived pin such that I would not be able to= use the domain even if I buy it. A variation on this is the case where an = attacker like ComodoHacker manages to MitM a popular site, and he sets a lo= ng-lived pin that prevents users from accessing the site not through the Mi= tM. This means that browser support for HPKP could serve to amplify attacks= that are plenty bad enough as they are. Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty b= ig gun with which users can shoot themselves in the foot. A website that's = important for its owner (whether it's social networking, political action, = or business) cannot afford to be inaccessible for any length of time. A mon= th is no less a disaster than a year. As for constraining your behavior, th= is merits deployment advice, not limiting the usefulness of the protocol fo= r other sites. #2 is more worrying. I think the previous owner issue would be served even = with a 1 year hard limit, and I don't think anyone here is arguing that a 1= -year limit is too short. But the attack amplification is a real thing, and= it works against sites that haven't even implemented HPKP. Sites that depl= oy HPKP are protected from a MitM such as ComodoHacker (or his "friends"). = But having HPKP in the browser (but not in the website) allows his friends = to lock out browsers by inserting a pin. So if browsers implement this, it = amplifies attacks against the general population of SSL-protected web sites= . I'm not sure whether in the grand scheme of things this makes the Interne= t better or worse. Note, though, that this issue exists even if max-age is limited. Bricking t= he site for a month (for some users in Iran) is a bad enough outcome, only = slightly mitigated by it being only for a month. I started out writing this message thinking it was going to have a proposal= that we could all reach consensus about. I'm not sure I got there. I guess= if this was a vote, I would vote for a year-long max-max-age, but I'm not = really as sure about this as I was when I started writing this message. Yoav [1] http://www.yoavnir.com _______________________________________________ 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 Email secured by Check Point --_000_77BFAD4136DD46C7A277D1416F7EE958checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2FC9442DF487274F81986ED07CAC4B45@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable But doesn't this introduce a lot of infrastructure?

If we want to find out a hash of the public key for an HTTPS server us= ing heavy infrastructure, we might as well use DANE, no?

Yoav

On Jun 4, 2013, at 1:04 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

Hi Trevor, hi all,

(again no hats)

actually regarding browser lookups of pin lists:
I rather have the pins work unlimited and all the time even without pin lis= ts.

But your idea might in fact be a solution to enable the unlimited pin times= .
Instead of constantly distributing the list of pins, we could actually have= browsers use whitelists of pins that have been "revoked" and whe= re the browser is allowed to refresh. That could e.g. happen with a browser= update.
That way we can have a unlimited time pin (and pre-caching of pins) and sol= ve the scenario of malicious domain blocking by previous owners. And hopefu= lly that scenario will hardly happen at all (especially if there is a provi= sion for solving it and the attempt is futile, the motivation for an attacker trying it might be close to zero= ).

Best regards, Tobias




On 03/06/13 07:29, Trevor Perrin wrote:

Hi Yoav, all,

We've talked a lot about the risks of long-lived pins.  We should= also think more about the benefits.  

I'll argue that pin lifetimes past a certain point don't get you much.=  Browser-based "key continuity" will hopefully be supplemen= ted by systems that scan pin assertions regularly from different points on = the Internet (like Perspectives, Convergence, Vantages, etc.).  Such systems would derive pins more reliably than individual = browsers, and could use several methods to distribute these pins.  Sin= ce scanning of sites can be done frequently, and distribution would also be= fast, long-lived pins aren't needed for this.

The hard part of this isn't scanning, it's pin distribution.  Her= e's three ways that could be done:

Links:  Pins could be embedded in hyperlinks served over HTTPS. &= nbsp;Since much browsing consists of following links from the web's major &= quot;introducers" (search engines, social networks, etc.), having thes= e sites embed pins would protect a lot of traffic.  See the recent "S-links" paper [1].

Lists:  Modern browsers download lists of security info on a regu= lar basis, including lists of malware and phishing sites [2], commonly-down= loaded files [3], and revoked certs [4].  You could imagine pin lists = being downloaded, so that every browser has a current list of pins for, say, 10,000 major sites.

Lookups:  Browsers are reluctant to do per-connection blocking lo= okups (see OCSP, Convergence, and DNSSEC).  But there might be more ef= ficient and less-problematic ways to combine pin and DNS lookups (e.g. conn= ections to DNS resolvers via VPNs, or some simpler form of response authentication).  Also, non-blocking pin loo= kups could be used after-the-fact to detect attacks (if a MITM blocks the l= ookup for an extended period, the browser would start complaining).


Anyways, 30-day pins seem adequate for any of these.  Assuming si= tes can be rescanned weekly, pins received through links, lists, or lookups= are likely to have 20+ days of validity left in them, which is plenty = of time for the browser to follow a link, or use a list without its entries expiring.

This is a complicated issue, and I don't expect this email to resolve = it.  But I at least hope this lessens any perception that short-lived = pins would offer weak security.


Trevor




On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi

Just trying to get us close to consensus. Still no hats. There are two argu= ments for limiting max-age:

1. With unlimited max-age, it's possible for the legitimate site owner to b= y mistake damage their sites. You could pin the CA certificate, and lock yo= urself in to that CA for all eternity. You could pin a current and future E= E public keys, and then when the current public key expires, you might not use the future one because you m= istyped it (or your CA no longer accepts 1024-bit keys). For whatever reaso= n, a bad choice you make while trying out HPKP either bricks your site or c= onstrains your behavior for a while.

2. With unlimited max-age, a current owner of a domain name can set a pin t= hat a future owner cannot honor. So if Mr. diaper consultant[1] ever decide= s to retire, he could set a long-lived pin such that I would not be able to= use the domain even if I buy it. A variation on this is the case where an attacker like ComodoHacker manage= s to MitM a popular site, and he sets a long-lived pin that prevents users = from accessing the site not through the MitM. This means that browser suppo= rt for HPKP could serve to amplify attacks that are plenty bad enough as they are.

Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty b= ig gun with which users can shoot themselves in the foot. A website that's = important for its owner (whether it's social networking, political action, = or business) cannot afford to be inaccessible for any length of time. A month is no less a disaster than a = year. As for constraining your behavior, this merits deployment advice, not= limiting the usefulness of the protocol for other sites.

#2 is more worrying. I think the previous owner issue would be served even = with a 1 year hard limit, and I don't think anyone here is arguing that a 1= -year limit is too short. But the attack amplification is a real thing, and= it works against sites that haven't even implemented HPKP. Sites that deploy HPKP are protected from a MitM su= ch as ComodoHacker (or his "friends"). But having HPKP in the bro= wser (but not in the website) allows his friends to lock out browsers by in= serting a pin. So if browsers implement this, it amplifies attacks against the general population of SSL-protected web s= ites. I'm not sure whether in the grand scheme of things this makes the Int= ernet better or worse.

Note, though, that this issue exists even if max-age is limited. Bricking t= he site for a month (for some users in Iran) is a bad enough outcome, only = slightly mitigated by it being only for a month.

I started out writing this message thinking it was going to have a proposal= that we could all reach consensus about. I'm not sure I got there. I guess= if this was a vote, I would vote for a year-long max-max-age, but I'm not = really as sure about this as I was when I started writing this message.

Yoav

[1] http://www.yoavnir.com
_______________________________________________
websec mailing list
websec@ietf.org=
https://www.ietf.org/mailman/listinfo/websec 



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



Email secured by Check Point


--_000_77BFAD4136DD46C7A277D1416F7EE958checkpointcom_-- From tobias.gondrom@gondrom.org Tue Jun 4 05:48:19 2013 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 3FD4C21F9058 for ; Tue, 4 Jun 2013 05:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=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 Bv7ZqNY-KT-F for ; Tue, 4 Jun 2013 05:47:55 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id B934821F9B3D for ; Tue, 4 Jun 2013 04:21:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=pMW11BKJsW1imlDMKsQzGxYL6/T4jK5TfkaWuKfOvAKNRihWfDBk/fv2ApTY6xORzeAb6xh6bbNbbDHj7DucTi/Es0b/CnpI/D9MWrQ2ABSZ5CVFBoSXmBAf17YExkJ4; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 10155 invoked from network); 4 Jun 2013 13:21:26 +0200 Received: from 188-222-173-238.zone13.bethere.co.uk (HELO ?192.168.1.94?) (188.222.173.238) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Jun 2013 13:21:26 +0200 Message-ID: <51ADCDB5.3010505@gondrom.org> Date: Tue, 04 Jun 2013 12:21:25 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ynir@checkpoint.com References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> <51ADBBA3.3000105@gondrom.org> <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> In-Reply-To: <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------000002060802050508070301" Cc: websec@ietf.org Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 04 Jun 2013 12:48:19 -0000 This is a multi-part message in MIME format. --------------000002060802050508070301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well. I am not strongly voting for it. The point is, to have a hard limit of 30 days under the assumption of the existence of such infrastructure would be worse, because then we would need to rely on such infrastructure in all normal operation cases. While with my approach we would need the infrastructure only in the exception (of a malicious attacker abusing key pinning to block a domain), which may or may not happen at all. Best, Tobias On 04/06/13 12:07, Yoav Nir wrote: > But doesn't this introduce a lot of infrastructure? > > If we want to find out a hash of the public key for an HTTPS server > using heavy infrastructure, we might as well use DANE, no? > > Yoav > > On Jun 4, 2013, at 1:04 PM, Tobias Gondrom > wrote: > >> Hi Trevor, hi all, >> >> (again no hats) >> >> actually regarding browser lookups of pin lists: >> I rather have the pins work unlimited and all the time even without >> pin lists. >> >> But your idea might in fact be a solution to enable the unlimited pin >> times. >> Instead of constantly distributing the list of pins, we could >> actually have browsers use whitelists of pins that have been >> "revoked" and where the browser is allowed to refresh. That could >> e.g. happen with a browser update. >> That way we can have a unlimited time pin (and pre-caching of pins) >> and solve the scenario of malicious domain blocking by previous >> owners. And hopefully that scenario will hardly happen at all >> (especially if there is a provision for solving it and the attempt is >> futile, the motivation for an attacker trying it might be close to zero). >> >> Best regards, Tobias >> >> >> >> >> On 03/06/13 07:29, Trevor Perrin wrote: >>> >>> Hi Yoav, all, >>> >>> We've talked a lot about the risks of long-lived pins. We should >>> also think more about the benefits. >>> >>> I'll argue that pin lifetimes past a certain point don't get you >>> much. Browser-based "key continuity" will hopefully be supplemented >>> by systems that scan pin assertions regularly from different points >>> on the Internet (like Perspectives, Convergence, Vantages, etc.). >>> Such systems would derive pins more reliably than individual >>> browsers, and could use several methods to distribute these pins. >>> Since scanning of sites can be done frequently, and distribution >>> would also be fast, long-lived pins aren't needed for this. >>> >>> The hard part of this isn't scanning, it's pin distribution. Here's >>> three ways that could be done: >>> >>> Links: Pins could be embedded in hyperlinks served over HTTPS. >>> Since much browsing consists of following links from the web's >>> major "introducers" (search engines, social networks, etc.), having >>> these sites embed pins would protect a lot of traffic. See the >>> recent "S-links" paper [1]. >>> >>> Lists: Modern browsers download lists of security info on a regular >>> basis, including lists of malware and phishing sites [2], >>> commonly-downloaded files [3], and revoked certs [4]. You could >>> imagine pin lists being downloaded, so that every browser has a >>> current list of pins for, say, 10,000 major sites. >>> >>> Lookups: Browsers are reluctant to do per-connection blocking >>> lookups (see OCSP, Convergence, and DNSSEC). But there might be >>> more efficient and less-problematic ways to combine pin and DNS >>> lookups (e.g. connections to DNS resolvers via VPNs, or some simpler >>> form of response authentication). Also, non-blocking pin lookups >>> could be used after-the-fact to detect attacks (if a MITM blocks the >>> lookup for an extended period, the browser would start complaining). >>> >>> >>> Anyways, 30-day pins seem adequate for any of these. Assuming sites >>> can be rescanned weekly, pins received through links, lists, or >>> lookups are likely to have 20+ days of validity left in them, which >>> is plenty of time for the browser to follow a link, or use a list >>> without its entries expiring. >>> >>> This is a complicated issue, and I don't expect this email to >>> resolve it. But I at least hope this lessens any perception that >>> short-lived pins would offer weak security. >>> >>> >>> Trevor >>> >>> [1] http://research.google.com/pubs/archive/41138.pdf >>> >>> [2] https://developers.google.com/safe-browsing/ >>> >>> [3] >>> http://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequently-asked-questions-ie9 >>> [4] http://www.imperialviolet.org/2012/02/05/crlsets.html >>> >>> >>> >>> On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir >> > wrote: >>> >>> Hi >>> >>> Just trying to get us close to consensus. Still no hats. There >>> are two arguments for limiting max-age: >>> >>> 1. With unlimited max-age, it's possible for the legitimate site >>> owner to by mistake damage their sites. You could pin the CA >>> certificate, and lock yourself in to that CA for all eternity. >>> You could pin a current and future EE public keys, and then when >>> the current public key expires, you might not use the future one >>> because you mistyped it (or your CA no longer accepts 1024-bit >>> keys). For whatever reason, a bad choice you make while trying >>> out HPKP either bricks your site or constrains your behavior for >>> a while. >>> >>> 2. With unlimited max-age, a current owner of a domain name can >>> set a pin that a future owner cannot honor. So if Mr. diaper >>> consultant[1] ever decides to retire, he could set a long-lived >>> pin such that I would not be able to use the domain even if I >>> buy it. A variation on this is the case where an attacker like >>> ComodoHacker manages to MitM a popular site, and he sets a >>> long-lived pin that prevents users from accessing the site not >>> through the MitM. This means that browser support for HPKP could >>> serve to amplify attacks that are plenty bad enough as they are. >>> >>> Regarding #1 I'm not convinced. HPKP (much like HSTS) is already >>> a pretty big gun with which users can shoot themselves in the >>> foot. A website that's important for its owner (whether it's >>> social networking, political action, or business) cannot afford >>> to be inaccessible for any length of time. A month is no less a >>> disaster than a year. As for constraining your behavior, this >>> merits deployment advice, not limiting the usefulness of the >>> protocol for other sites. >>> >>> #2 is more worrying. I think the previous owner issue would be >>> served even with a 1 year hard limit, and I don't think anyone >>> here is arguing that a 1-year limit is too short. But the attack >>> amplification is a real thing, and it works against sites that >>> haven't even implemented HPKP. Sites that deploy HPKP are >>> protected from a MitM such as ComodoHacker (or his "friends"). >>> But having HPKP in the browser (but not in the website) allows >>> his friends to lock out browsers by inserting a pin. So if >>> browsers implement this, it amplifies attacks against the >>> general population of SSL-protected web sites. I'm not sure >>> whether in the grand scheme of things this makes the Internet >>> better or worse. >>> >>> Note, though, that this issue exists even if max-age is limited. >>> Bricking the site for a month (for some users in Iran) is a bad >>> enough outcome, only slightly mitigated by it being only for a >>> month. >>> >>> I started out writing this message thinking it was going to have >>> a proposal that we could all reach consensus about. I'm not sure >>> I got there. I guess if this was a vote, I would vote for a >>> year-long max-max-age, but I'm not really as sure about this as >>> I was when I started writing this message. >>> >>> Yoav >>> >>> [1] http://www.yoavnir.com >>> _______________________________________________ >>> 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 >> >> >> >> Email secured by Check Point >> > --------------000002060802050508070301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Well. I am not strongly voting for it.

The point is, to have a hard limit of 30 days under the assumption of the existence of such infrastructure would be worse, because then we would need to rely on such infrastructure in all normal operation cases. While with my approach we would need the infrastructure only in the exception (of a malicious attacker abusing key pinning to block a domain), which may or may not happen at all.

Best, Tobias


On 04/06/13 12:07, Yoav Nir wrote:
But doesn't this introduce a lot of infrastructure?

If we want to find out a hash of the public key for an HTTPS server using heavy infrastructure, we might as well use DANE, no?

Yoav

On Jun 4, 2013, at 1:04 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

Hi Trevor, hi all,

(again no hats)

actually regarding browser lookups of pin lists:
I rather have the pins work unlimited and all the time even without pin lists.

But your idea might in fact be a solution to enable the unlimited pin times.
Instead of constantly distributing the list of pins, we could actually have browsers use whitelists of pins that have been "revoked" and where the browser is allowed to refresh. That could e.g. happen with a browser update.
That way we can have a unlimited time pin (and pre-caching of pins) and solve the scenario of malicious domain blocking by previous owners. And hopefully that scenario will hardly happen at all (especially if there is a provision for solving it and the attempt is futile, the motivation for an attacker trying it might be close to zero).

Best regards, Tobias




On 03/06/13 07:29, Trevor Perrin wrote:

Hi Yoav, all,

We've talked a lot about the risks of long-lived pins.  We should also think more about the benefits.  

I'll argue that pin lifetimes past a certain point don't get you much.  Browser-based "key continuity" will hopefully be supplemented by systems that scan pin assertions regularly from different points on the Internet (like Perspectives, Convergence, Vantages, etc.).  Such systems would derive pins more reliably than individual browsers, and could use several methods to distribute these pins.  Since scanning of sites can be done frequently, and distribution would also be fast, long-lived pins aren't needed for this.

The hard part of this isn't scanning, it's pin distribution.  Here's three ways that could be done:

Links:  Pins could be embedded in hyperlinks served over HTTPS.  Since much browsing consists of following links from the web's major "introducers" (search engines, social networks, etc.), having these sites embed pins would protect a lot of traffic.  See the recent "S-links" paper [1].

Lists:  Modern browsers download lists of security info on a regular basis, including lists of malware and phishing sites [2], commonly-downloaded files [3], and revoked certs [4].  You could imagine pin lists being downloaded, so that every browser has a current list of pins for, say, 10,000 major sites.

Lookups:  Browsers are reluctant to do per-connection blocking lookups (see OCSP, Convergence, and DNSSEC).  But there might be more efficient and less-problematic ways to combine pin and DNS lookups (e.g. connections to DNS resolvers via VPNs, or some simpler form of response authentication).  Also, non-blocking pin lookups could be used after-the-fact to detect attacks (if a MITM blocks the lookup for an extended period, the browser would start complaining).


Anyways, 30-day pins seem adequate for any of these.  Assuming sites can be rescanned weekly, pins received through links, lists, or lookups are likely to have 20+ days of validity left in them, which is plenty of time for the browser to follow a link, or use a list without its entries expiring.

This is a complicated issue, and I don't expect this email to resolve it.  But I at least hope this lessens any perception that short-lived pins would offer weak security.


Trevor




On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi

Just trying to get us close to consensus. Still no hats. There are two arguments for limiting max-age:

1. With unlimited max-age, it's possible for the legitimate site owner to by mistake damage their sites. You could pin the CA certificate, and lock yourself in to that CA for all eternity. You could pin a current and future EE public keys, and then when the current public key expires, you might not use the future one because you mistyped it (or your CA no longer accepts 1024-bit keys). For whatever reason, a bad choice you make while trying out HPKP either bricks your site or constrains your behavior for a while.

2. With unlimited max-age, a current owner of a domain name can set a pin that a future owner cannot honor. So if Mr. diaper consultant[1] ever decides to retire, he could set a long-lived pin such that I would not be able to use the domain even if I buy it. A variation on this is the case where an attacker like ComodoHacker manages to MitM a popular site, and he sets a long-lived pin that prevents users from accessing the site not through the MitM. This means that browser support for HPKP could serve to amplify attacks that are plenty bad enough as they are.

Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty big gun with which users can shoot themselves in the foot. A website that's important for its owner (whether it's social networking, political action, or business) cannot afford to be inaccessible for any length of time. A month is no less a disaster than a year. As for constraining your behavior, this merits deployment advice, not limiting the usefulness of the protocol for other sites.

#2 is more worrying. I think the previous owner issue would be served even with a 1 year hard limit, and I don't think anyone here is arguing that a 1-year limit is too short. But the attack amplification is a real thing, and it works against sites that haven't even implemented HPKP. Sites that deploy HPKP are protected from a MitM such as ComodoHacker (or his "friends"). But having HPKP in the browser (but not in the website) allows his friends to lock out browsers by inserting a pin. So if browsers implement this, it amplifies attacks against the general population of SSL-protected web sites. I'm not sure whether in the grand scheme of things this makes the Internet better or worse.

Note, though, that this issue exists even if max-age is limited. Bricking the site for a month (for some users in Iran) is a bad enough outcome, only slightly mitigated by it being only for a month.

I started out writing this message thinking it was going to have a proposal that we could all reach consensus about. I'm not sure I got there. I guess if this was a vote, I would vote for a year-long max-max-age, but I'm not really as sure about this as I was when I started writing this message.

Yoav

[1] http://www.yoavnir.com
_______________________________________________
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



Email secured by Check Point



--------------000002060802050508070301-- From charles.j.sheehe@nasa.gov Tue Jun 4 07:49:17 2013 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 3B63D21F9DD2 for ; Tue, 4 Jun 2013 07:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Svd-c7E4feZM for ; Tue, 4 Jun 2013 07:49:02 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::102]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8B21F907E for ; Tue, 4 Jun 2013 06:03:17 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (NDJSPPT103.ndc.nasa.gov [198.117.1.197]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id F0BCDA8048; Tue, 4 Jun 2013 08:03:16 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r54D3GUq016163; Tue, 4 Jun 2013 08:03:16 -0500 Received: from NDJSSCC04.ndc.nasa.gov ([10.58.58.14]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Tue, 4 Jun 2013 08:03:16 -0500 From: "Sheehe, Charles J. (GRC-DPC0)" To: Yoav Nir , Tobias Gondrom Date: Tue, 4 Jun 2013 08:03:15 -0500 Thread-Topic: [websec] Consensus call: Issue #57 (max-max-age) Thread-Index: Ac5hH52FMB5lewsqSVm80r0jW66ZzAAA7PFQ Message-ID: <838EDA30DAC59547BEDA5AB4C776DFC9014303815897@NDJSSCC04.ndc.nasa.gov> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> <51ADBBA3.3000105@gondrom.org> <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> In-Reply-To: <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_838EDA30DAC59547BEDA5AB4C776DFC9014303815897NDJSSCC04nd_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-06-04_04:2013-06-04, 2013-06-04, 1970-01-01 signatures=0 Cc: "" Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 04 Jun 2013 14:49:17 -0000 --_000_838EDA30DAC59547BEDA5AB4C776DFC9014303815897NDJSSCC04nd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why can't the Max-Max-AGE equal a formula Max age=3D (average usage)*2+1= day This should accommodate both and not the best for either. Chuck From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Tuesday, June 04, 2013 7:08 AM To: Tobias Gondrom Cc: Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) But doesn't this introduce a lot of infrastructure? If we want to find out a hash of the public key for an HTTPS server using h= eavy infrastructure, we might as well use DANE, no? Yoav On Jun 4, 2013, at 1:04 PM, Tobias Gondrom > wrote: Hi Trevor, hi all, (again no hats) actually regarding browser lookups of pin lists: I rather have the pins work unlimited and all the time even without pin lis= ts. But your idea might in fact be a solution to enable the unlimited pin times= . Instead of constantly distributing the list of pins, we could actually have= browsers use whitelists of pins that have been "revoked" and where the bro= wser is allowed to refresh. That could e.g. happen with a browser update. That way we can have a unlimited time pin (and pre-caching of pins) and sol= ve the scenario of malicious domain blocking by previous owners. And hopefu= lly that scenario will hardly happen at all (especially if there is a provi= sion for solving it and the attempt is futile, the motivation for an attack= er trying it might be close to zero). Best regards, Tobias On 03/06/13 07:29, Trevor Perrin wrote: Hi Yoav, all, We've talked a lot about the risks of long-lived pins. We should also thin= k more about the benefits. I'll argue that pin lifetimes past a certain point don't get you much. Bro= wser-based "key continuity" will hopefully be supplemented by systems that = scan pin assertions regularly from different points on the Internet (like P= erspectives, Convergence, Vantages, etc.). Such systems would derive pins = more reliably than individual browsers, and could use several methods to di= stribute these pins. Since scanning of sites can be done frequently, and d= istribution would also be fast, long-lived pins aren't needed for this. The hard part of this isn't scanning, it's pin distribution. Here's three = ways that could be done: Links: Pins could be embedded in hyperlinks served over HTTPS. Since much= browsing consists of following links from the web's major "introducers" (s= earch engines, social networks, etc.), having these sites embed pins would = protect a lot of traffic. See the recent "S-links" paper [1]. Lists: Modern browsers download lists of security info on a regular basis,= including lists of malware and phishing sites [2], commonly-downloaded fil= es [3], and revoked certs [4]. You could imagine pin lists being downloade= d, so that every browser has a current list of pins for, say, 10,000 major = sites. Lookups: Browsers are reluctant to do per-connection blocking lookups (see= OCSP, Convergence, and DNSSEC). But there might be more efficient and les= s-problematic ways to combine pin and DNS lookups (e.g. connections to DNS = resolvers via VPNs, or some simpler form of response authentication). Also= , non-blocking pin lookups could be used after-the-fact to detect attacks (= if a MITM blocks the lookup for an extended period, the browser would start= complaining). Anyways, 30-day pins seem adequate for any of these. Assuming sites can be= rescanned weekly, pins received through links, lists, or lookups are likel= y to have 20+ days of validity left in them, which is plenty of time for th= e browser to follow a link, or use a list without its entries expiring. This is a complicated issue, and I don't expect this email to resolve it. = But I at least hope this lessens any perception that short-lived pins would= offer weak security. Trevor [1] http://research.google.com/pubs/archive/41138.pdf [2] https://developers.google.com/safe-browsing/ [3] http://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequent= ly-asked-questions-ie9 [4] http://www.imperialviolet.org/2012/02/05/crlsets.html On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir > wrote: Hi Just trying to get us close to consensus. Still no hats. There are two argu= ments for limiting max-age: 1. With unlimited max-age, it's possible for the legitimate site owner to b= y mistake damage their sites. You could pin the CA certificate, and lock yo= urself in to that CA for all eternity. You could pin a current and future E= E public keys, and then when the current public key expires, you might not = use the future one because you mistyped it (or your CA no longer accepts 10= 24-bit keys). For whatever reason, a bad choice you make while trying out H= PKP either bricks your site or constrains your behavior for a while. 2. With unlimited max-age, a current owner of a domain name can set a pin t= hat a future owner cannot honor. So if Mr. diaper consultant[1] ever decide= s to retire, he could set a long-lived pin such that I would not be able to= use the domain even if I buy it. A variation on this is the case where an = attacker like ComodoHacker manages to MitM a popular site, and he sets a lo= ng-lived pin that prevents users from accessing the site not through the Mi= tM. This means that browser support for HPKP could serve to amplify attacks= that are plenty bad enough as they are. Regarding #1 I'm not convinced. HPKP (much like HSTS) is already a pretty b= ig gun with which users can shoot themselves in the foot. A website that's = important for its owner (whether it's social networking, political action, = or business) cannot afford to be inaccessible for any length of time. A mon= th is no less a disaster than a year. As for constraining your behavior, th= is merits deployment advice, not limiting the usefulness of the protocol fo= r other sites. #2 is more worrying. I think the previous owner issue would be served even = with a 1 year hard limit, and I don't think anyone here is arguing that a 1= -year limit is too short. But the attack amplification is a real thing, and= it works against sites that haven't even implemented HPKP. Sites that depl= oy HPKP are protected from a MitM such as ComodoHacker (or his "friends"). = But having HPKP in the browser (but not in the website) allows his friends = to lock out browsers by inserting a pin. So if browsers implement this, it = amplifies attacks against the general population of SSL-protected web sites= . I'm not sure whether in the grand scheme of things this makes the Interne= t better or worse. Note, though, that this issue exists even if max-age is limited. Bricking t= he site for a month (for some users in Iran) is a bad enough outcome, only = slightly mitigated by it being only for a month. I started out writing this message thinking it was going to have a proposal= that we could all reach consensus about. I'm not sure I got there. I guess= if this was a vote, I would vote for a year-long max-max-age, but I'm not = really as sure about this as I was when I started writing this message. Yoav [1] http://www.yoavnir.com _______________________________________________ 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 Email secured by Check Point --_000_838EDA30DAC59547BEDA5AB4C776DFC9014303815897NDJSSCC04nd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Why can&#= 8217;t the Max-Max-AGE  equal a formula  Max age=3D  (averag= e usage)*2+1day

 = ;

This should accommodate both = and not the best for either.

 

Chuck=

From: Yoav Nir [mailto:ynir@che= ckpoint.com]
Sent: Tuesday, June 04, 2013 7:08 AM
To: = Tobias Gondrom
Cc: <websec@ietf.org>
Subject: Re:= [websec] Consensus call: Issue #57 (max-max-age)

 

But = doesn't this introduce a lot of infrastructure?

 

If we wa= nt to find out a hash of the public key for an HTTPS server using heavy inf= rastructure, we might as well use DANE, no?

 

Yoav

 

=

On Jun 4, 2013, at 1:04 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> w= rote:



=

Hi Trevor, hi all,

(again no hats)
actually regarding browser lookups of pin lists:
I rather have the pin= s work unlimited and all the time even without pin lists.

But your = idea might in fact be a solution to enable the unlimited pin times.
Ins= tead of constantly distributing the list of pins, we could actually have br= owsers use whitelists of pins that have been "revoked" and where = the browser is allowed to refresh. That could e.g. happen with a browser up= date.
That way we can have a unlimited time pin (and pre-caching of pin= s) and solve the scenario of malicious domain blocking by previous owners. = And hopefully that scenario will hardly happen at all (especially if there = is a provision for solving it and the attempt is futile, the motivation for= an attacker trying it might be close to zero).

Best regards, Tobias=




On 03/06/13 07:29, Trevor Perrin wrote:

<= /div>
<= p class=3DMsoNormal> 

Hi= Yoav, all,

 =

We've talked a lot about the risks of l= ong-lived pins.  We should also think more about the benefits.  <= o:p>

 

I'll argue that pin lifetimes past a certain point = don't get you much.  Browser-based "key continuity" will hop= efully be supplemented by systems that scan pin assertions regularly from d= ifferent points on the Internet (like Perspectives, Convergence, Vantages, = etc.).  Such systems would derive pins more reliably than individual b= rowsers, and could use several methods to distribute these pins.  Sinc= e scanning of sites can be done frequently, and distribution would also be = fast, long-lived pins aren't needed for this.

 

The h= ard part of this isn't scanning, it's pin distribution.  Here's three = ways that could be done:

 

Links:  Pins could be= embedded in hyperlinks served over HTTPS.  Since much browsing consis= ts of following links from the web's major "introducers" (search = engines, social networks, etc.), having these sites embed pins would protec= t a lot of traffic.  See the recent "S-links" paper [1].

 

=

Lists:  Modern browsers download lists of securit= y info on a regular basis, including lists of malware and phishing sites [2= ], commonly-downloaded files [3], and revoked certs [4].  You could im= agine pin lists being downloaded, so that every browser has a current list = of pins for, say, 10,000 major sites.

 

Lookups: &nbs= p;Browsers are reluctant to do per-connection blocking lookups (see OCSP, C= onvergence, and DNSSEC).  But there might be more efficient and less-p= roblematic ways to combine pin and DNS lookups (e.g. connections to DNS res= olvers via VPNs, or some simpler form of response authentication).  Al= so, non-blocking pin lookups could be used after-the-fact to detect attacks= (if a MITM blocks the lookup for an extended period, the browser would sta= rt complaining).

 <= /o:p>

 

Anyways, 30-day pins seem adequate for any of these. &nb= sp;Assuming sites can be rescanned weekly, pins received through links, lis= ts, or lookups are likely to have 20+ days of validity left in them, which = is plenty of time for the browser to follow a link, or use a list without i= ts entries expiring.

&nb= sp;

This is a complicated issue, a= nd I don't expect this email to resolve it.  But I at least hope this = lessens any perception that short-lived pins would offer weak security.

 

=

 

T= revor

 

 

On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir <ynir@checkpoint.com> wr= ote:

Hi

Just trying to get us clo= se to consensus. Still no hats. There are two arguments for limiting max-ag= e:

1. With unlimited max-age, it's possible for the legitimate site = owner to by mistake damage their sites. You could pin the CA certificate, a= nd lock yourself in to that CA for all eternity. You could pin a current an= d future EE public keys, and then when the current public key expires, you = might not use the future one because you mistyped it (or your CA no longer = accepts 1024-bit keys). For whatever reason, a bad choice you make while tr= ying out HPKP either bricks your site or constrains your behavior for a whi= le.

2. With unlimited max-age, a current owner of a domain name can = set a pin that a future owner cannot honor. So if Mr. diaper consultant[1] = ever decides to retire, he could set a long-lived pin such that I would not= be able to use the domain even if I buy it. A variation on this is the cas= e where an attacker like ComodoHacker manages to MitM a popular site, and h= e sets a long-lived pin that prevents users from accessing the site not thr= ough the MitM. This means that browser support for HPKP could serve to ampl= ify attacks that are plenty bad enough as they are.

Regarding #1 I'm= not convinced. HPKP (much like HSTS) is already a pretty big gun with whic= h users can shoot themselves in the foot. A website that's important for it= s owner (whether it's social networking, political action, or business) can= not afford to be inaccessible for any length of time. A month is no less a = disaster than a year. As for constraining your behavior, this merits deploy= ment advice, not limiting the usefulness of the protocol for other sites.
#2 is more worrying. I think the previous owner issue would be served= even with a 1 year hard limit, and I don't think anyone here is arguing th= at a 1-year limit is too short. But the attack amplification is a real thin= g, and it works against sites that haven't even implemented HPKP. Sites tha= t deploy HPKP are protected from a MitM such as ComodoHacker (or his "= friends"). But having HPKP in the browser (but not in the website) all= ows his friends to lock out browsers by inserting a pin. So if browsers imp= lement this, it amplifies attacks against the general population of SSL-pro= tected web sites. I'm not sure whether in the grand scheme of things this m= akes the Internet better or worse.

Note, though, that this issue exi= sts even if max-age is limited. Bricking the site for a month (for some use= rs in Iran) is a bad enough outcome, only slightly mitigated by it being on= ly for a month.

I started out writing this message thinking it was g= oing to have a proposal that we could all reach consensus about. I'm not su= re I got there. I guess if this was a vote, I would vote for a year-long ma= x-max-age, but I'm not really as sure about this as I was when I started wr= iting this message.

Yoav

[1] http://www.yoavnir.com

_______________________________________________
webse= c mailing list
websec@ietf.orghttps://www.ietf.org/mailman/listinfo/websec

 




__________________________________________=
_____
websec mailing list
websec@ietf.org
https://www.ietf.org/mai=
lman/listinfo/websec




Email secured by Check Point

 

= --_000_838EDA30DAC59547BEDA5AB4C776DFC9014303815897NDJSSCC04nd_-- From trevp@trevp.net Tue Jun 4 10:17:37 2013 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 939D021F9B38 for ; Tue, 4 Jun 2013 10:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 IrtmSYmG4wIE for ; Tue, 4 Jun 2013 10:17:32 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id F02BB21F9704 for ; Tue, 4 Jun 2013 08:21:15 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id c10so327452wiw.15 for ; Tue, 04 Jun 2013 08:21:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=fcPYbhDNQnm0f21em/5iHfs41R3qbqeaRDQuemclWYk=; b=A/PQTaWdPnNc+D6/R+oTzit+onw7DSfRIJA60cQqS596Akbhjfc8biArbjjijnB2Ps 6K6O54zeRRVgkSv6g/rUEtqSSVwutkIeLBuZJu4XNjQB8QiryUvAfdyobSYxYfM8VDJl TPXDgqazPKixOtODFanfS/VXgjwI3wXNrQX0go497JtuIyvC2ZP0/goAjgzud1Iko2WY h5zYHWiLlhUUyTCgXsn2kpfIjn79HlW0oDd5puQlvhaKaupqB60PhaDu0w1C9601Dciv iL5zEh1fapUMZm+MfRMODaApPC0As60+suWi/4ahz/hKdDGURB0/+D7E9PC0k0vJrZvU YBVQ== MIME-Version: 1.0 X-Received: by 10.194.59.72 with SMTP id x8mr24439799wjq.49.1370359275130; Tue, 04 Jun 2013 08:21:15 -0700 (PDT) Received: by 10.217.110.129 with HTTP; Tue, 4 Jun 2013 08:21:14 -0700 (PDT) X-Originating-IP: [166.147.108.64] In-Reply-To: <51ADBBA3.3000105@gondrom.org> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> <51ADBBA3.3000105@gondrom.org> Date: Tue, 4 Jun 2013 08:21:14 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: multipart/alternative; boundary=047d7ba97308cf20db04de55a111 X-Gm-Message-State: ALoCoQmpgj+bczMIrvxULTljbKYwQrtovo+/fAN9A5fslQVtmUQz+kOPqCcnAk8VI6/NXrsePxdY Cc: IETF WebSec WG Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 04 Jun 2013 17:17:37 -0000 --047d7ba97308cf20db04de55a111 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 3:04 AM, Tobias Gondrom wrote: > Hi Trevor, hi all, > > (again no hats) > > actually regarding browser lookups of pin lists: > I rather have the pins work unlimited and all the time even without pin > lists. > > But your idea might in fact be a solution to enable the unlimited pin > times. > Instead of constantly distributing the list of pins, we could actually > have browsers use whitelists of pins that have been "revoked" and where the > browser is allowed to refresh. That could e.g. happen with a browser update. > Hi Tobias, I agree there may need to be a mechanism for browser vendors (or other third parties) to push out "pin revocation lists" that delete bad pins. But if a bad pin occurs, there may be some latency before this list could be updated. And if a lot of bad pins occur, the list might not be large enough to contain them all. So I still think we want strong safeguards (such as max-age limits) to reduce the incidence of bad pins as much as possible. Trevor --047d7ba97308cf20db04de55a111 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Jun 4, 2013 at 3:04 AM, Tobias Gondrom <tobias.gondrom@go= ndrom.org> wrote:
=20 =20 =20
Hi Trevor, hi all,

(again no hats)

actually regarding browser lookups of pin lists:
I rather have the pins work unlimited and all the time even without pin lists.

But your idea might in fact be a solution to enable the unlimited pin times.
Instead of constantly distributing the list of pins, we could actually have browsers use whitelists of pins that have been "revoked" and where the browser is allowed to refresh. That= could e.g. happen with a browser update.

<= /div>
Hi Tobias,

I agree there may need to be = a mechanism for browser vendors (or other third parties) to push out "= pin revocation lists" that delete bad pins.

But if a bad pin occurs, there may be some latency befo= re this list could be updated. =A0And if a lot of bad pins occur, the list = might not be large enough to contain them all.=A0

So I still think we want strong safeguards (such as max-age limits) to redu= ce the incidence of bad pins as much as possible.

=
Trevor
--047d7ba97308cf20db04de55a111-- From trevp@trevp.net Tue Jun 4 10:18:20 2013 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 0A29A21F9B6B for ; Tue, 4 Jun 2013 10:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 jAOugD+y8iJL for ; Tue, 4 Jun 2013 10:18:15 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5BB21E80A1 for ; Tue, 4 Jun 2013 08:24:37 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id e11so348765wgh.14 for ; Tue, 04 Jun 2013 08:24:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=C0yUfwOl7nPRjqsBpd8RTN8Jl2LdjvqVFtc+gPm7TK4=; b=TAeKxgQoWUAprL/YLddQMPPNoRENyo+N30kj+sHJTZql5atqGzZ+/RYnEx5+mN2c7K 5yY3iBD9VvUAGX6KLF/nR2Ln65TtaAQQLvOsdOZ29sn9WcOkgiH87X5tRf8IC4pLGd6J dsYTCHDLm/Q6v2N6EkYSwXOHgX7nez3opgjhbrbdDJNO8jQBkZZrRvQ3xYkpb0fl/44f ub6oPBl+JyQd59wPo3fdxUTx4WyuXeZ7hsvPI0FiLXMa1YrLCvwHdziIJCL/hwieHM9m +ly4V10d7Py36ZUIkgH6Vl4FbfMILQvAoNlqMnYiKKdvqxRP/lV4bzW9ISzGkOOt4vRU f/DQ== MIME-Version: 1.0 X-Received: by 10.180.88.231 with SMTP id bj7mr2132091wib.5.1370359476713; Tue, 04 Jun 2013 08:24:36 -0700 (PDT) Received: by 10.217.110.129 with HTTP; Tue, 4 Jun 2013 08:24:36 -0700 (PDT) X-Originating-IP: [166.147.108.64] In-Reply-To: <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> <51ADBBA3.3000105@gondrom.org> <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> Date: Tue, 4 Jun 2013 08:24:36 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d0443048ad30f5204de55adf7 X-Gm-Message-State: ALoCoQkGKuhj/FZMUtQ+rfHFkt4Ii02+JqfO0Hw1Tq9KVXX0qY1k9p+lkFJ8iBrK3s6sxbeDQ+4X Cc: "" Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 04 Jun 2013 17:18:20 -0000 --f46d0443048ad30f5204de55adf7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 4:07 AM, Yoav Nir wrote: > > If we want to find out a hash of the public key for an HTTPS server > using heavy infrastructure, we might as well use DANE, no? > If TLSA records have typical DNS TTLs (a few hours or days), then they will probably be too short-lived to be effectively stored in lists and downloaded to browsers, etc. If they are longer-lived, then all the issues we're discussing here will still arise (a DNS hijacker or disgruntled sysadmin setting a long-lived DANE pin, etc.). Trevor --f46d0443048ad30f5204de55adf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Jun 4, 2013 at 4:07 AM, Yoav Nir <ynir@checkpoint.com> wrote:

If we want to find out a hash of the public key for an HTTPS server us= ing heavy infrastructure, we might as well use DANE, no?


If TLSA records have typical DNS T= TLs (a few hours or days), then they will probably be too short-lived to be= effectively stored in lists and downloaded to browsers, etc.

If they are longer-lived, then all the issues we're= discussing here will still arise (a DNS hijacker or disgruntled sysadmin s= etting a long-lived DANE pin, etc.).


Trevor=A0

--f46d0443048ad30f5204de55adf7-- From trevp@trevp.net Tue Jun 4 10:42:06 2013 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 5E18D21E817F for ; Tue, 4 Jun 2013 10:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 IU4UejNA+nAU for ; Tue, 4 Jun 2013 10:42:01 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D034B21F9D8C for ; Tue, 4 Jun 2013 09:31:46 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm9so928328wib.4 for ; Tue, 04 Jun 2013 09:31:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=PDuI/2tN8xTjxHAFW7VAPFqbqqPpEJ8fRg8NOfAd64k=; b=apZuOpxRdyzBGsht70i7t1NEDvq7c5zq28r62liRPAyFepTUeTIfT4fFkXIZIWhkJC J3ZW0DjtTJ1GqOFSIRcdxqVJBTHjeKbJnQikybcg00/9uGRi/GhV6YOc0F7IbVI9jkxc FT8DvF6aN0Z7dTUnE3Fpo5ra7S/pgCW6hb/MkAYZOV2ItfJrcOCoANDOXtaQ0a1pulAS a3eLcBYX45Z7XW5W0Ou9KVjHm0JBnMChQSrmlFCVAwygJ8pgvAMFGFaQRhPuXU/1QvNa 9E4/IV+JTiuR5KUG/6ut0wL0ch2tIKLEPY+XqhHgwbrHHNf+kGW+/+mEmaJSyljAJX7j mCdA== MIME-Version: 1.0 X-Received: by 10.180.74.207 with SMTP id w15mr2313352wiv.19.1370363505961; Tue, 04 Jun 2013 09:31:45 -0700 (PDT) Received: by 10.217.110.129 with HTTP; Tue, 4 Jun 2013 09:31:45 -0700 (PDT) X-Originating-IP: [166.147.108.64] In-Reply-To: <838EDA30DAC59547BEDA5AB4C776DFC9014303815897@NDJSSCC04.ndc.nasa.gov> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> <51ADBBA3.3000105@gondrom.org> <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> <838EDA30DAC59547BEDA5AB4C776DFC9014303815897@NDJSSCC04.ndc.nasa.gov> Date: Tue, 4 Jun 2013 09:31:45 -0700 Message-ID: From: Trevor Perrin To: "Sheehe, Charles J. (GRC-DPC0)" Content-Type: multipart/alternative; boundary=f46d04374a19fc84b304de569dec X-Gm-Message-State: ALoCoQnIpLV5MNRDMKe9PfOZS0M9cYLk0qonvC1GRwy25LNmYCS1yC1cH5TLr/jJYJbvy8tsu/2Z Cc: "" Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 04 Jun 2013 17:42:06 -0000 --f46d04374a19fc84b304de569dec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jun 4, 2013 at 6:03 AM, Sheehe, Charles J. (GRC-DPC0) < charles.j.sheehe@nasa.gov> wrote: > Why can=92t the Max-Max-AGE equal a formula Max age=3D (average > usage)*2+1day > Hi Charles, In the case of frequently visited sites, that would shrink pin lifetimes to the point that even a brief interruption of browsing habits (vacation, etc.) would deactivate the pins. Also, that wouldn't guarantee an upper-bound on pin lifetimes. While opinions differ on this, I think a guaranteed upper-bound is desirable, to provide sites clarity on how long ill-effects from pinning might last. Trevor --f46d04374a19fc84b304de569dec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= On Tue, Jun 4, 2013 at 6:03 AM, Sheehe, Charles J. (GRC-DPC0) <cha= rles.j.sheehe@nasa.gov> wrote:
Why can=92t the Max-Max-AGE =A0equal a formula=A0 Max age=3D =A0(av= erage usage)*2+1day


= Hi Charles,

In the case of frequently visited sites, that would shr= ink pin lifetimes to the point that even a brief interruption of browsing h= abits (vacation, etc.) would deactivate the pins.

Also, that wouldn't guarantee an upper-bound on pin lifetimes. =A0While= opinions differ on this, I think a guaranteed upper-bound is desirable, to= provide sites clarity on how long ill-effects from pinning might last.


Trevor

<= /div> --f46d04374a19fc84b304de569dec-- From charles.j.sheehe@nasa.gov Tue Jun 4 12:53:39 2013 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 66BC721F9AAD for ; Tue, 4 Jun 2013 12:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 ozzyBYP18M10 for ; Tue, 4 Jun 2013 12:53:33 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id B374921F9A90 for ; Tue, 4 Jun 2013 12:52:55 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (NDJSPPT103.ndc.nasa.gov [198.117.1.197]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 68DF02D807B; Tue, 4 Jun 2013 14:52:54 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r54Jqsl9013823; Tue, 4 Jun 2013 14:52:54 -0500 Received: from NDJSSCC04.ndc.nasa.gov ([10.58.58.14]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Tue, 4 Jun 2013 14:52:54 -0500 From: "Sheehe, Charles J. (GRC-DPC0)" To: Trevor Perrin Date: Tue, 4 Jun 2013 14:52:53 -0500 Thread-Topic: [websec] Consensus call: Issue #57 (max-max-age) Thread-Index: Ac5hVcGi9fswdpFlSOeLJ+U9gM02CgABi4PQ Message-ID: <838EDA30DAC59547BEDA5AB4C776DFC9014303815C24@NDJSSCC04.ndc.nasa.gov> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> <51ADBBA3.3000105@gondrom.org> <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> <838EDA30DAC59547BEDA5AB4C776DFC9014303815897@NDJSSCC04.ndc.nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_838EDA30DAC59547BEDA5AB4C776DFC9014303815C24NDJSSCC04nd_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-06-04_07:2013-06-04, 2013-06-04, 1970-01-01 signatures=0 Cc: "" Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 04 Jun 2013 19:53:39 -0000 --_000_838EDA30DAC59547BEDA5AB4C776DFC9014303815C24NDJSSCC04nd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Trevor. Ok so if we set the Max Age to 1 day or 10 days or 30 or 90 so what are the= realistic impacts? Increased Infrastructure how much? I have not seen the= tradeoffs cost(risks or added infrastructure) vs. benefits. I have been re= ading the argument pro's and con's and the issue does not seem to be an eng= ineering one it is a business/risk management issue. Upset customers, secu= rity, operations costs etc.. Not knowing the business cases and true costs= I would go with 28 days if a hard limit must be set. That seems long to m= e yet within most business systems reporting cycles etc.. Just my thoughts Chuck From: Trevor Perrin [mailto:trevp@trevp.net] Sent: Tuesday, June 04, 2013 12:32 PM To: Sheehe, Charles J. (GRC-DPC0) Cc: Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) On Tue, Jun 4, 2013 at 6:03 AM, Sheehe, Charles J. (GRC-DPC0) > wrote: Why can't the Max-Max-AGE equal a formula Max age=3D (average usage)*2+1= day Hi Charles, In the case of frequently visited sites, that would shrink pin lifetimes to= the point that even a brief interruption of browsing habits (vacation, etc= .) would deactivate the pins. Also, that wouldn't guarantee an upper-bound on pin lifetimes. While opini= ons differ on this, I think a guaranteed upper-bound is desirable, to provi= de sites clarity on how long ill-effects from pinning might last. Trevor --_000_838EDA30DAC59547BEDA5AB4C776DFC9014303815C24NDJSSCC04nd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Tr= evor. 

 

Ok so if we set the Max Age to 1 day or= 10 days or 30 or 90 so what are the realistic impacts? Increased Infrastru= cture how much?  I have not seen the tradeoffs cost(risks or added inf= rastructure) vs. benefits. I have been reading the argument pro’s and= con’s and the issue does not seem to be an engineering one it is a b= usiness/risk management issue.  Upset customers, security, operations = costs etc..  Not knowing the business cases and true costs I would go = with 28 days if a hard limit must be set.  That seems long to me yet w= ithin most business systems reporting cycles etc..

 

Just my thoughts

Chuck

 

=

 

 

 = ;

From: Trevor Perrin [mailto:trevp@trev= p.net]
Sent: Tuesday, June 04, 2013 12:32 PM
To: Sheeh= e, Charles J. (GRC-DPC0)
Cc: <websec@ietf.org>
Subjec= t: Re: [websec] Consensus call: Issue #57 (max-max-age)

 

<= o:p> 

On Tue, Jun 4, 2013 at 6= :03 AM, Sheehe, Charles J. (GRC-DPC0) <charles.j.sheehe@nasa.gov> wrote:=

Why can’t the Max-Max-AGE  equ= al a formula  Max age=3D  (average usage)*2+1day

 

=

Hi Charles,

 

In the case of fre= quently visited sites, that would shrink pin lifetimes to the point that ev= en a brief interruption of browsing habits (vacation, etc.) would deactivat= e the pins.

 =

Also, that wouldn't guarantee an upper-= bound on pin lifetimes.  While opinions differ on this, I think a guar= anteed upper-bound is desirable, to provide sites clarity on how long ill-e= ffects from pinning might last.

 

 

Trevor

 

= --_000_838EDA30DAC59547BEDA5AB4C776DFC9014303815C24NDJSSCC04nd_-- From trevp@trevp.net Wed Jun 5 09:42:52 2013 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 5F1DB21F9B3A for ; Wed, 5 Jun 2013 09:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=1.428, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 W0qWL8bcCI2D for ; Wed, 5 Jun 2013 09:42:46 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0721521F99C7 for ; Wed, 5 Jun 2013 09:42:45 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v10so2091809lbd.6 for ; Wed, 05 Jun 2013 09:42:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=aDh2dJqdQhYzUaAuZC+6zWlWirl1sGNnevGN8ST4lFM=; b=NwSq+4DkYOcD7sY+LLkHKlz8duMlpY7Te1LKCFq/AQ/+FI08T2fyrdFCsS8ckCRALx J1NaggSQZt95SPruI78KpihR6fTWDM2MHe1LFUkOnD4Yb5q+SeVzhJWbfWdwQ8F2YUwD hwN03gt57X8ju7Pjm6xfsl5P5IerQ1xISKP7tJDFZSKezf1Cl1Fks5xIREKPr5Nx3lU3 qxEfU3y5WFGOsau/bAelWQc57HOYXc5HcVUGxkZxstHp6c9mPikR/OzSs9J1XThtzllw ddsNvvGAdqQkp7oYiOyQW3r6EcJerTu/fGa3YP5Q/qhLn1fzmkLpexp8tiY4xILsvYxL XV4A== MIME-Version: 1.0 X-Received: by 10.152.1.230 with SMTP id 6mr15710227lap.21.1370450564890; Wed, 05 Jun 2013 09:42:44 -0700 (PDT) Received: by 10.114.16.138 with HTTP; Wed, 5 Jun 2013 09:42:44 -0700 (PDT) X-Originating-IP: [166.147.108.64] In-Reply-To: <838EDA30DAC59547BEDA5AB4C776DFC9014303815C24@NDJSSCC04.ndc.nasa.gov> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <519D3254.1040508@gondrom.org> <51A49A5C.5080002@gondrom.org> <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> <584386D2-223C-4B6F-89BA-78769113D293@checkpoint.com> <51ADBBA3.3000105@gondrom.org> <77BFAD41-36DD-46C7-A277-D1416F7EE958@checkpoint.com> <838EDA30DAC59547BEDA5AB4C776DFC9014303815897@NDJSSCC04.ndc.nasa.gov> <838EDA30DAC59547BEDA5AB4C776DFC9014303815C24@NDJSSCC04.ndc.nasa.gov> Date: Wed, 5 Jun 2013 09:42:44 -0700 Message-ID: From: Trevor Perrin To: "Sheehe, Charles J. (GRC-DPC0)" Content-Type: multipart/alternative; boundary=089e013c6c161a55a604de6ae316 X-Gm-Message-State: ALoCoQn2BKf6QMsRe+GM6hFFygQjsmD7FRdfkoTjWhonS5XtWCYkkHrzdVhpWzpTI55wbs7dqoxR Cc: "" Subject: Re: [websec] Consensus call: Issue #57 (max-max-age) 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, 05 Jun 2013 16:42:52 -0000 --089e013c6c161a55a604de6ae316 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 12:52 PM, Sheehe, Charles J. (GRC-DPC0) < charles.j.sheehe@nasa.gov> wrote: > Thanks Trevor. **** > > ** ** > > Ok so if we set the Max Age to 1 day or 10 days or 30 or 90 so what are > the realistic impacts? Increased Infrastructure how much? I have not seen > the tradeoffs cost(risks or added infrastructure) vs. benefits. > So, assuming (for sake of discussion) that we wanted *some* spec-defined max-max-age, what are the tradeoffs in choosing it? Good question, I think you'd want to start by being clear what use cases are in scope. I suggested expanding the scope to include pin-distribution methods like "downloaded lists", "secure links", and "online lookups". It would be fair for the working group to reject that scope expansion, or discuss further. Then we could look at how the effectiveness of pins varies over time for different use cases. I'd argue that for the expanded use cases, you get diminishing returns on effectiveness after a few weeks, though for the "browser key continuity" use case, it's a different story, so we'd have to decide how to weigh the use cases. Finally, you'd have to assess how the "dangers" of pinning increase with lifetime, and then subtract the dangers from the benefits to get some "pinning-lifetime-utility" curve. In my mind, this curve is a bell-like thing with a lot of mass between a few weeks and a few months, with 30 days being a good round number in the middle. At least that's how TACK got there, that's as methodical as we got... Trevor --089e013c6c161a55a604de6ae316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Jun 4, 2013 at 12:52 PM, Sheehe, Charles J. (GRC-DPC0) <ch= arles.j.sheehe@nasa.gov> wrote:
Thanks Trevor.=A0

=A0

Ok so if we set the Max Age to 1 day or 10 days or 30 or 90 s= o what are the realistic impacts? Increased Infrastructure how much?=A0 I h= ave not seen the tradeoffs cost(risks or added infrastructure) vs. benefits= .


So, assuming (for sake of= discussion) that we wanted *some* spec-defined max-max-age, what are the t= radeoffs in choosing it?

Good question, I think yo= u'd want to start by being clear what use cases are in scope. =A0I sugg= ested expanding the scope to include pin-distribution methods like "do= wnloaded lists", "secure links", and "online lookups&qu= ot;. =A0It would be fair for the working group to reject that scope expansi= on, or discuss further.
=A0
Then we could look at how the effectiveness of pins vari= es over time for different use cases. =A0I'd argue that for the expande= d use cases, you get diminishing returns on effectiveness after a few weeks= , though for the "browser key continuity" use case, it's a di= fferent story, so we'd have to decide how to weigh the use cases.

Finally, you'd have to assess how the "dangers= " of pinning increase with lifetime, and then subtract the dangers fro= m the benefits to get some "pinning-lifetime-utility" curve. =A0I= n my mind, this curve is a bell-like thing with a lot of mass between a few= weeks and a few months, with 30 days being a good round number in the midd= le.

At least that's how TACK got there, that's as m= ethodical as we got...


Trevor
=
=A0
--089e013c6c161a55a604de6ae316-- From internet-drafts@ietf.org Thu Jun 6 18:46:30 2013 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 E46E821F8F85; Thu, 6 Jun 2013 18:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.316 X-Spam-Level: X-Spam-Status: No, score=-102.316 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, NO_RELAYS=-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 mtoK-XBJ7Pux; Thu, 6 Jun 2013 18:46:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 757CE21F8F4D; Thu, 6 Jun 2013 18:46:24 -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: 4.50 Message-ID: <20130607014624.19641.43267.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 18:46:24 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-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, 07 Jun 2013 01:46:32 -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 IETF. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-05.txt Pages : 21 Date : 2013-06-06 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Tue Jun 11 14:51:46 2013 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 E2FCF21F99B0 for ; Tue, 11 Jun 2013 14:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 lPdmpwEe13o6 for ; Tue, 11 Jun 2013 14:51:41 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 52D2221F9A1D for ; Tue, 11 Jun 2013 14:51:40 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5BLpcbM009203 for ; Wed, 12 Jun 2013 00:51:38 +0300 X-CheckPoint: {51B79BEA-21-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 00:51:37 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Issue #57 - another try Thread-Index: AQHOZu3YXdSfjBUHRU677MEbdqdASw== Date: Tue, 11 Jun 2013 21:51:37 +0000 Message-ID: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.25] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11718662250c45a5b56e58bb50a724152000df5994 Content-Type: text/plain; charset="us-ascii" Content-ID: <359D62FD05FA744C9EE427C4B63E76E8@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Issue #57 - another try 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, 11 Jun 2013 21:51:47 -0000 Hi Version -05 of the draft has some proposed text for issue #57. UAs SHOULD set an upper limit on the value of max-age, so that UAs that have noted erroneous pins (whether by accident or due to attack) have some chance of recovering over time. If the server sets a max- age greater than the UA's upper limit, the UA SHOULD behave as if the server set the max-age to the UA's upper limit. For example, if the UA caps max-age at 2592000 seconds (30 days), and a Pinned Host sets a max-age directive of 60 days in its Valid Pinning Header, the UA SHOULD behave as if the max-age were effectively 30 days. (One way to achieve this behavior is for the UA to simply store a value of 30 days instead of the 60 day value provided by the Pinned Host.) For UA implementation guidance on how to select a maximum max-age, see Section 4.1. I think by now we've heard all the arguments back and forth for and against= limits on max-age. So the question to the group is, can you live with the = above text? If so, then I think we can move on to last call. With no hats, I can live with this text, although I have two issues with it= : 1. I think the 30 days recommended in section 4.1 is too low, as I can thi= nk of many cases where a user would connect to a site from a particular dev= ice less often than every 30 days. 2. I think it's a bad idea to leave the max-max-age to the discretion of t= he UA. If an erroneous pin was set for a domain for, say, 10 years, the dom= ain owner has no way of knowing how long the pin will be set on some device= s, and will have to assume the longest of all the UA implementation he's ev= er heard of. IOW having one popular browser set the maximum to 30 days, whi= le another sets it to 90 days means that as the domain owner, I have to ass= ume that the pin is "out there" for 90 days.=20 Yoav From tom@ritter.vg Tue Jun 11 16:03:06 2013 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 7964921F9A59 for ; Tue, 11 Jun 2013 16:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 n-B9kyeTKtx6 for ; Tue, 11 Jun 2013 16:03:06 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 043E721F9A27 for ; Tue, 11 Jun 2013 16:03:05 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so3568839pbc.35 for ; Tue, 11 Jun 2013 16:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iMGW6NfdMzS54j278FaAaQPjc3HLylaJZ+ccYqu2/Uw=; b=aAVgOHOJLOsHiUq1slEh546XrAzaNDG6RdHih8UVzUCNUAbvbqnD9dDM3YMJSSZvVv 4YPtN8CpdZ7mRVxn6AavzxRyhbYNaE5DFs+9r08ptvIrSTCByHlw4MQ2S/O9ZVQIlTgv 0JdSFLqR9mJ3cSmJ84TSbudYkvOTa9flwYP+o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=iMGW6NfdMzS54j278FaAaQPjc3HLylaJZ+ccYqu2/Uw=; b=FDS5se51Mht+fQghDDmr/vkFCBmYmRebdKDBA4rdZP/0U2V3uQm6tkaPg7RqyFfBKn GCOZi5ag43qApK08nvXZPOyrotKr//kt4Rs+0Mg5g0j65ryDz15FliGwXPwhvLu8+lfT GJDdDwfCtmGH+wAYSyy4l2XEO4eNjjUbOsqjPxpkfFLXjOv8pWyRmYkCXlqfmUQWYDwR ZY32Mg2tpJQtGqaKb4QOPpGTiUGynPrh1vVJ0NafWqRHrEUp+7C3lo1JuA1S/Df7rGO6 M9xnwZw2hqSZSFEViH2WldlzSiKa7ZncK/DCr2tevjQc8OGhOGYs4mUMHbdMxwdgKpcB i3Ww== X-Received: by 10.66.20.66 with SMTP id l2mr20714152pae.205.1370991785521; Tue, 11 Jun 2013 16:03:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.128.231 with HTTP; Tue, 11 Jun 2013 16:02:45 -0700 (PDT) In-Reply-To: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> References: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> From: Tom Ritter Date: Tue, 11 Jun 2013 19:02:45 -0400 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn9O2WLCPjQsODU6BClwD6eYdqcEVNCOnxeg1a5DTUjVO5fxgbZZo0nx7tpO24cVFJxLtxz Cc: IETF WebSec WG Subject: Re: [websec] Issue #57 - another try 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, 11 Jun 2013 23:03:06 -0000 I can live with it, although I also have lots of quibbles: I think a 'MAY' would be more appropriate, and I also think 30 days is too low. -tom From palmer@google.com Tue Jun 11 16:05:43 2013 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 D127321F9A71 for ; Tue, 11 Jun 2013 16:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 1QzdINV+sicx for ; Tue, 11 Jun 2013 16:05:43 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7D321F9A59 for ; Tue, 11 Jun 2013 16:05:43 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id d10so6338711vea.10 for ; Tue, 11 Jun 2013 16:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=woalYlrYE7YjnyU+YxemTkbzZHGLAd8hgSKsBvbejJg=; b=iuBjy+fG23QtBZ2lzAYsk2c+sBPxQK6CmV3cp1m5XNPkfp+XRT0ucqqh4my1RQgn4i HzC8J9rVmo2EGgGCdbQ6Uy+feAHTT5j1BPS/4gO8Amz9iL3cxbbgQx10Du6sS8JD+xOL UO3LrUf75wKDkqF4W9lTpJ+LoQhWoQkpdOedewgd3PuSRlbo3SDi6AnTl44gDIujC+gc YZX387foobXwqC5O997PnEUS9fjZg9Z7msprhjnXQfCxzH19brGMFbD1+039ivLV6UkO 2SoYJ8AX7xazPTUb1mIegzG3o2bnWqRB1L/c1nnbQ5CL3dv09xnlqtDAjnbSvVHTw5iH TO3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=woalYlrYE7YjnyU+YxemTkbzZHGLAd8hgSKsBvbejJg=; b=m+7CvlV4FqbImDvwR60nhSimvdBF98WPteIlaQXDruqLBsUyPS7tsTk9gUQUWtyvU/ s2/ZuunLh2z2s/dB2lyb+dXzEGRVlnEqHKk+0JMp/9pKYyMByucfp6VO3nQ6vaj7anxc RvfT8qzIoIXjkb43A/G5ZiImbweWkaUqixTV5WvjPUzynUptc7as4LihJbuGKnm0Zq1h JQcorJ+TDUy4BG0DaQty2Nqua2/MrgQ8cE5s1LZPeVUtIRDseR82TGVtETTQ+zGU9hnM F7BQSYm4w9Td/H8XgKlJZAFshQRnbGy/tGnrlBWlwDrhcBWJUJ3lvxKL8zs+B+T9k1em i5Pw== MIME-Version: 1.0 X-Received: by 10.52.67.1 with SMTP id j1mr7497035vdt.84.1370991942679; Tue, 11 Jun 2013 16:05:42 -0700 (PDT) Received: by 10.220.192.199 with HTTP; Tue, 11 Jun 2013 16:05:42 -0700 (PDT) In-Reply-To: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> References: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> Date: Tue, 11 Jun 2013 16:05:42 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnC9QOpipHtr8oKeEreYFumaqnWr1MVmJ5/9kiXOQd/0lbBlzr9qGrSMPZj5huiQaMFSZIcvKgg4FDa8Shddpm3LmWCa+dq9KrLFW8H7g9kuopMCw034npzgUO5UBwpzHnEdhVcCSCOAvYhcCLJz9bamdKKhbEa8ah71xEbzuuocRox1wvMaCoTmUNoy8pDI2zWRJPB Cc: IETF WebSec WG Subject: Re: [websec] Issue #57 - another try 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, 11 Jun 2013 23:05:44 -0000 On Tue, Jun 11, 2013 at 2:51 PM, Yoav Nir wrote: > UAs SHOULD set an upper limit on the value of max-age, so that UAs > that have noted erroneous pins (whether by accident or due to attack) > have some chance of recovering over time. If the server sets a max- > age greater than the UA's upper limit, the UA SHOULD behave as if the > server set the max-age to the UA's upper limit. For example, if the > UA caps max-age at 2592000 seconds (30 days), and a Pinned Host sets > a max-age directive of 60 days in its Valid Pinning Header, the UA > SHOULD behave as if the max-age were effectively 30 days. (One way > to achieve this behavior is for the UA to simply store a value of 30 > days instead of the 60 day value provided by the Pinned Host.) For > UA implementation guidance on how to select a maximum max-age, see > Section 4.1. > > I think by now we've heard all the arguments back and forth for and again= st limits on max-age. So the question to the group is, can you live with th= e above text? If so, then I think we can move on to last call. I can live with it. :) > 1. I think the 30 days recommended in section 4.1 is too low, as I can t= hink of many cases where a user would connect to a site from a particular d= evice less often than every 30 days. Noted. > 2. I think it's a bad idea to leave the max-max-age to the discretion of= the UA. If an erroneous pin was set for a domain for, say, 10 years, the d= omain owner has no way of knowing how long the pin will be set on some devi= ces, and will have to assume the longest of all the UA implementation he's = ever heard of. IOW having one popular browser set the maximum to 30 days, w= hile another sets it to 90 days means that as the domain owner, I have to a= ssume that the pin is "out there" for 90 days. Yes. But, FWIW, section 6 (Usability Considerations) says: UAs MUST have a way for users to clear current pins for Pinned Hosts. UAs SHOULD have a way for users to query the current state of Pinned Hosts. From charles.j.sheehe@nasa.gov Thu Jun 13 04:56:08 2013 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 F004821F99EC for ; Thu, 13 Jun 2013 04:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Lq61ss1qoV5E for ; Thu, 13 Jun 2013 04:56:03 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id AD29721F9A0B for ; Thu, 13 Jun 2013 04:56:02 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (NDJSPPT103.ndc.nasa.gov [198.117.1.197]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 012302D802E; Thu, 13 Jun 2013 06:56:01 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r5DBu1uJ024780; Thu, 13 Jun 2013 06:56:01 -0500 Received: from NDJSSCC04.ndc.nasa.gov ([10.58.58.14]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Thu, 13 Jun 2013 06:56:01 -0500 From: "Sheehe, Charles J. (GRC-DPC0)" To: Yoav Nir , IETF WebSec WG Date: Thu, 13 Jun 2013 06:56:00 -0500 Thread-Topic: [websec] Issue #57 - another try Thread-Index: Ac5nnxrI7ap+oQMRSnur0KxlLLVsPgAjWSbg Message-ID: <838EDA30DAC59547BEDA5AB4C776DFC9014303A03824@NDJSSCC04.ndc.nasa.gov> References: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> In-Reply-To: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-13_03:2013-06-12, 2013-06-13, 1970-01-01 signatures=0 Subject: Re: [websec] Issue #57 - another try 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, 13 Jun 2013 11:56:09 -0000 Hi I like the paragraph as written. Chuck RFC 2119 SHOULD =20 This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. MAY =20 This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Tuesday, June 11, 2013 5:52 PM To: IETF WebSec WG Subject: [websec] Issue #57 - another try Hi Version -05 of the draft has some proposed text for issue #57. UAs SHOULD set an upper limit on the value of max-age, so that UAs that have noted erroneous pins (whether by accident or due to attack) have some chance of recovering over time. If the server sets a max- age greater than the UA's upper limit, the UA SHOULD behave as if the server set the max-age to the UA's upper limit. For example, if the UA caps max-age at 2592000 seconds (30 days), and a Pinned Host sets a max-age directive of 60 days in its Valid Pinning Header, the UA SHOULD behave as if the max-age were effectively 30 days. (One way to achieve this behavior is for the UA to simply store a value of 30 days instead of the 60 day value provided by the Pinned Host.) For UA implementation guidance on how to select a maximum max-age, see Section 4.1. I think by now we've heard all the arguments back and forth for and against= limits on max-age. So the question to the group is, can you live with the = above text? If so, then I think we can move on to last call. With no hats, I can live with this text, although I have two issues with it= : 1. I think the 30 days recommended in section 4.1 is too low, as I can thi= nk of many cases where a user would connect to a site from a particular dev= ice less often than every 30 days. 2. I think it's a bad idea to leave the max-max-age to the discretion of t= he UA. If an erroneous pin was set for a domain for, say, 10 years, the dom= ain owner has no way of knowing how long the pin will be set on some device= s, and will have to assume the longest of all the UA implementation he's ev= er heard of. IOW having one popular browser set the maximum to 30 days, whi= le another sets it to 90 days means that as the domain owner, I have to ass= ume that the pin is "out there" for 90 days.=20 Yoav From tobias.gondrom@gondrom.org Tue Jun 18 03:57:31 2013 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 221B821F9DBB for ; Tue, 18 Jun 2013 03:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.97 X-Spam-Level: X-Spam-Status: No, score=-94.97 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=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 mu1tjHXJAgGL for ; Tue, 18 Jun 2013 03:57:26 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2011021F9E03 for ; Tue, 18 Jun 2013 03:57:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ekcyDa7rEEAVnIfzakRCmvx6Qml7P3eF1+cvExjj2lMqLuZQQfxk1ak6pCHT05QuCTjbHHjYwiI5IKX5jXBcrWlloStpnNF5GdB8oBAz3hCV/IrY9GkoFfjQhCCyyN/F; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 1429 invoked from network); 18 Jun 2013 12:57:18 +0200 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.33.127?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Jun 2013 12:57:18 +0200 Message-ID: <51C03D0A.8040609@gondrom.org> Date: Tue, 18 Jun 2013 18:57:14 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: tom@ritter.vg References: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Issue #57 - another try 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, 18 Jun 2013 10:57:31 -0000 On 12/06/13 07:02, Tom Ritter wrote: > I can live with it, although I also have lots of quibbles: I think a > 'MAY' would be more appropriate, and I also think 30 days is too low. > > -tom > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec I would agree with Tom and the "MAY" and please use an example of more then 30 days. But to be clear, I can also live with the "SHOULD". Best regards, Tobias From ynir@checkpoint.com Tue Jun 18 05:06:07 2013 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 000B621F92A5 for ; Tue, 18 Jun 2013 05:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 EpkusYRTrRJg for ; Tue, 18 Jun 2013 05:06:01 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 73FC221F926E for ; Tue, 18 Jun 2013 05:06:00 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5IC5weN003194 for ; Tue, 18 Jun 2013 15:05:58 +0300 X-CheckPoint: {51C04D26-33-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 18 Jun 2013 15:05:58 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] Issue #57 - another try Thread-Index: AQHOZu3YXdSfjBUHRU677MEbdqdAS5kw72uAgApI1oA= Date: Tue, 18 Jun 2013 12:05:58 +0000 Message-ID: References: <336CFF45-F007-44A3-AC79-AA5D088489F6@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.114] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1141e9195eec93d9bd80cc0167a669aba32d9e461f Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Issue #57 - another try 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, 18 Jun 2013 12:06:07 -0000 On Jun 12, 2013, at 2:02 AM, Tom Ritter wrote: > I can live with it, although I also have lots of quibbles: I think a > 'MAY' would be more appropriate, and I also think 30 days is too low. >=20 > -tom I've already stated my opinion about the 30 days, but Tom is right about th= e SHOULD. Unlike MUST, a SHOULD requires an explanation of when it is OK t= o not do the thing. So it's not enough to say "UAs SHOULD set a limit". You= should have "UAs SHOULD set a limit ... unless all trust anchors are manag= ed within the same administrative domain" (that's just an example - it's n= ot supposed to make sense).=20 So either make it a MAY (in both sections 3.2.3 and 4.1) or come up with a = good "unless" clause (like "UAs should set an upper limit... unless erroneo= us or malicious pins are not a concern"). I'd go with the MAY. Yoav= From internet-drafts@ietf.org Tue Jun 18 16:15:17 2013 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 4383111E8117; Tue, 18 Jun 2013 16:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-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 uOCrvdPq1ZVU; Tue, 18 Jun 2013 16:15:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4B11E8113; Tue, 18 Jun 2013 16:14:44 -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: 4.51.p2 Message-ID: <20130618231444.27227.46297.idtracker@ietfa.amsl.com> Date: Tue, 18 Jun 2013 16:14:44 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-06.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: Tue, 18 Jun 2013 23:15:17 -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 IETF. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-06.txt Pages : 21 Date : 2013-06-18 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Tue Jun 18 22:43:55 2013 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 B931B21F9EA7 for ; Tue, 18 Jun 2013 22:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.699 X-Spam-Level: X-Spam-Status: No, score=-10.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 rbYE55vnmE7f for ; Tue, 18 Jun 2013 22:43:45 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D415E21F9E88 for ; Tue, 18 Jun 2013 22:43:44 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5J5hgZs013582 for ; Wed, 19 Jun 2013 08:43:43 +0300 X-CheckPoint: {51C1450E-3-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 08:43:42 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: WGLC: draft-ietf-websec-key-pinning-06 Thread-Index: AQHObK/0YEErCx1OWki24upPLOqcTw== Date: Wed, 19 Jun 2013 05:43:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.177] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11aaba5de129c87520d02e5691607ee39bf565c871 Content-Type: text/plain; charset="us-ascii" Content-ID: <91FA6346DF3F86408B63A7C4E1445B35@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] WGLC: draft-ietf-websec-key-pinning-06 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, 19 Jun 2013 05:43:55 -0000 Hi all This is to announce a WGLC for the subject draft. Version -06 makes the following changes: Changed non-normative pin generation code from Go to POSIX shell=09 script using openssl.=09 =20 Changed max-max-age from SHOULD to MAY, and used the example of 60=09 days instead of 30. As we've started mid-week, let's give it a little more than two weeks, so p= lease get in your comments by July 5th, and maybe we can get it out of the = working group by Berlin. Thanks Yoav From trevp@trevp.net Thu Jun 20 14:09:47 2013 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 E7F7311E8121 for ; Thu, 20 Jun 2013 14:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.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 BYlyl1nYwZ5I for ; Thu, 20 Jun 2013 14:09:41 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6C12411E8127 for ; Thu, 20 Jun 2013 14:09:41 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so5997525wgg.22 for ; Thu, 20 Jun 2013 14:09:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=QFcNjirCx3CQuuPtQgcwyfMcGeIYJIrziyUdq0EBF/I=; b=LiuKdpkaZ1KyqansGiNtmgslKPgbFl4exE0H7wBrVGMAaMJsJbUZZJAbGtJTsB9b9b Qc10uHE9BQkaUOuAQ5yNJUbe0SWs2qvUO9wnGwdp6gIm4wWFruOetFVVASi+o23Cz8RL vFJOre4JQ8hOQKGMEdSTyNfKJYQ7RQ5pXrXbvT3PoeDvskWAYuT95D1Fb1fCGPf9HgFt Bh74G0Dr2LljxWs1+L5eg0K8D2Eaahd67qJWZkacjmjeX6zsFH2At2fJSBHgb377d0BC UgChVP1IOvxm2AAJfWAhScWV2NS5ue0ALZID3HCGRPAkrSJFnAmKtikxJssOBqnTf5N0 kwpg== MIME-Version: 1.0 X-Received: by 10.194.24.135 with SMTP id u7mr6965845wjf.7.1371762580286; Thu, 20 Jun 2013 14:09:40 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Thu, 20 Jun 2013 14:09:40 -0700 (PDT) X-Originating-IP: [208.70.28.214] Date: Thu, 20 Jun 2013 14:09:40 -0700 Message-ID: From: Trevor Perrin To: IETF WebSec WG Content-Type: multipart/alternative; boundary=047d7b5d304a50841004df9c5df1 X-Gm-Message-State: ALoCoQl1bPOkE7kKQ+qV5rmjXNFBJO9N3hPwrsDtsF8Ei9uCZvoHGNFJAI9E3m84S9tltaNXcSxS Subject: [websec] HPKP and preloaded pin lists 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, 20 Jun 2013 21:09:47 -0000 --047d7b5d304a50841004df9c5df1 Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm not sure I understand section 2.7 on "Interactions With Preloaded Pin Lists". At first glance it seems clear: Both preloaded and dynamic pins MUST store the "Effective Pin Date" when the pin was most recently observed, and browsers MUST use only the most recent information. E.g.: T10 - Crawler notes a pin for "example.com" T15 - Browser notes a different pin for "example.com" T20 - Crawler sends preloaded pin to Browser In this case, the browser MUST ignore the preloaded pin, and only apply the pin it noted at T15. But what if the browser-noted pin has a max-age of 0 or 1? Or what if the T15 connection occurs over a secure transport but has no PKP header? The spec says: "If the result of noting a Valid Pinning Header is to disable pinning for the host, such as through supplying a max-age directive with a value of 0, UAs MUST allow this new information to override any other pinning data. That is, a host must be able to un-pin itself, even in the presence of built-in pins." That seems to imply the browser needs to remember "un-pinning" responses it receives (i.e. max-age=0 or no PKP header), and expired pins, on the chance that any of these might "un-pin" a preloaded pin it receives later? That seems fairly complicated, and rather inflexible (I could imagine a browser might trust its preload data more than dynamic data, and prefer that take precedence). So what if browsers were simply allowed to apply *either* the preload or dynamic pin, or both? The browser could choose to apply a complex, time-based algorithm like above, or do something simpler like apply both pins, or let preloads take precedence. This also allows for implementations which don't need to store either the "Effective Pin Date" (only the expiration time), or "un-pinning" entries. Thoughts? Trevor --047d7b5d304a50841004df9c5df1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

I'm n= ot sure I understand section 2.7 on "Interactions With Preloaded Pin L= ists".

At first glance it seems clear: =A0Bot= h preloaded and dynamic pins MUST store the "Effective Pin Date" = when the pin was most recently observed, and browsers MUST use only the mos= t recent information. =A0E.g.:

T10 - Crawler notes a pin for "example.com"
T15 - Browser notes a different= pin for "example.com"
T20 - Crawler sends preloaded pin to Browser

In th= is case, the browser MUST ignore the preloaded pin, and only apply the pin = it noted at T15.

But what if the browser-noted pin= has a max-age of 0 or 1? =A0Or what if the T15 connection occurs over a se= cure transport but has no PKP header? =A0The spec says:=A0

"If the result of noting a Valid Pinning Header is= to disable pinning for the host, such as through supplying a max-age direc= tive with a value of 0, UAs MUST allow this new information to override any= other pinning data. =A0That is, a host must be able to un-pin itself, even= in the presence of built-in pins."

That seems to imply the browser needs to remember "= ;un-pinning" responses it receives (i.e. max-age=3D0 or no PKP header)= , and expired pins, on the chance that any of these might "un-pin"= ; a preloaded pin it receives later?


That seems fairly complicated, and rathe= r inflexible (I could imagine a browser might trust its preload data more t= han dynamic data, and prefer that take precedence).

So what if browsers were simply allowed to apply *either* the preload = or dynamic pin, or both?

The browser could choose = to apply a complex, time-based algorithm like above, or do something simple= r like apply both pins, or let preloads take precedence.

This also allows for implementations which don't ne= ed to store either the "Effective Pin Date" (only the expiration = time), or "un-pinning" entries.

Thoughts= ?


Trevor
--047d7b5d304a50841004df9c5df1-- From dmatson@microsoft.com Thu Jun 20 11:58:03 2013 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 E2C4311E8100 for ; Thu, 20 Jun 2013 11:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] 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 B1VrcSNO8r2p for ; Thu, 20 Jun 2013 11:57:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 115EE11E810D for ; Thu, 20 Jun 2013 11:57:21 -0700 (PDT) Received: from BY2FFO11FD018.protection.gbl (10.1.15.202) by BY2FFO11HUB030.protection.gbl (10.1.14.115) with Microsoft SMTP Server (TLS) id 15.0.707.0; Thu, 20 Jun 2013 18:57:18 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD018.mail.protection.outlook.com (10.1.14.106) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Thu, 20 Jun 2013 18:57:18 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.3.136.1; Thu, 20 Jun 2013 18:57:07 +0000 Received: from mail6-va3-R.bigfish.com (10.7.14.231) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 18:55:25 +0000 Received: from mail6-va3 (localhost [127.0.0.1]) by mail6-va3-R.bigfish.com (Postfix) with ESMTP id A07AA2001E7 for ; Thu, 20 Jun 2013 18:55:25 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 7 X-BigFish: PS7(zzc85fh148cI4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah1d7338h18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh17ej9a9j307m1155h) Received-SPF: softfail (mail6-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dmatson@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR03MB037; H:BN1PR03MB039.namprd03.prod.outlook.com; LANG:en; Received: from mail6-va3 (localhost.localdomain [127.0.0.1]) by mail6-va3 (MessageSwitch) id 1371754522794173_22387; Thu, 20 Jun 2013 18:55:22 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.226]) by mail6-va3.bigfish.com (Postfix) with ESMTP id ADA1560313 for ; Thu, 20 Jun 2013 18:55:22 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Jun 2013 18:55:20 +0000 Received: from BN1PR03MB037.namprd03.prod.outlook.com (10.255.225.145) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.324.0; Thu, 20 Jun 2013 18:55:19 +0000 Received: from BN1PR03MB039.namprd03.prod.outlook.com (10.255.225.147) by BN1PR03MB037.namprd03.prod.outlook.com (10.255.225.145) with Microsoft SMTP Server (TLS) id 15.0.702.21; Thu, 20 Jun 2013 18:55:18 +0000 Received: from BN1PR03MB039.namprd03.prod.outlook.com ([169.254.5.127]) by BN1PR03MB039.namprd03.prod.outlook.com ([169.254.5.127]) with mapi id 15.00.0702.005; Thu, 20 Jun 2013 18:55:17 +0000 From: David Matson To: "websec@ietf.org" Thread-Topic: Comments on draft-ietf-websec-key-pinning-06 Thread-Index: Ac5t5xheMaFE3h1jTOy+Nog0fBhFEQ== Date: Thu, 20 Jun 2013 18:55:17 +0000 Message-ID: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:0:fff:0:5efe:10.121.220.255] Content-Type: multipart/alternative; boundary="_000_8c03997da80b4e8da7100491011b8c12BN1PR03MB039namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BN1PR03MB037.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054003)(199002)(52604005)(189002)(31966008)(46102001)(47736001)(74502001)(50986001)(56776001)(33646001)(74366001)(63696002)(44976003)(80022001)(49866001)(54356001)(81342001)(69226001)(76482001)(79102001)(54316002)(81542001)(19300405004)(4396001)(20776003)(16676001)(47446002)(71186001)(65816001)(51856001)(56816003)(76576001)(15202345003)(47976001)(77096001)(16236675002)(76176001)(76786001)(77982001)(512954002)(74876001)(6806003)(53806001)(74662001)(76796001)(74316001)(74706001)(59766001)(7756002)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB030; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08831F51DC X-Mailman-Approved-At: Fri, 21 Jun 2013 20:43:34 -0700 Subject: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 20 Jun 2013 19:05:46 -0000 --_000_8c03997da80b4e8da7100491011b8c12BN1PR03MB039namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I sent the mail below to the draft-ietf-websec-key-pinning-06 authors, and = Chris Palmer suggested I raise the points on this mailing list. He also men= tioned a previous discussion (which I haven't been able to locate) around a= well-known host security information URL; if there's a good place to get u= p to speed on that discussion, a pointer would be much appreciated. Thanks, David I really like the overall approach taken in Public Key Pinning Extension fo= r HTTP (draft-ietf-websec-key-pinning-06). Particularly, the public key (in= cluding algorithm) seems like exactly the right thing to pin. A couple of thoughts on other areas of the draft (my apologies if these hav= e been discussed before elsewhere; I'm only familiar with the draft text): 1. It would be nice to avoid including full public key data with every HTTP= response. Particularly if there are multiple public keys in use, there's a= bit of potential data overhead on every response. Would it make more sense= to have the public key data in a separate resource? As a first step, perha= ps having every resource just have a pointer, using a header something like= the following: Public-Key-Pin-Location: /pins Where "/pins" would be a separate resource that would have Public-Key-Pins = header data. Or, to go one step further, this data could then appear in the entity-body = (perhaps in JSON format) and use normal HTTP resource-level mechanisms-for = example, using Cache-Control to specify the expiration rather than a custom= max-age header directive. 2. It would be nice to have the public key specified in a central place for= the host, rather than by any resource, since the public keys are at the TL= S level and don't vary per resource. I'm not sure there's an ideal solution= here, but a couple of options might be: a. Have a fixed, well-known resource per host for retrieving public key pin= data (such as "/well-known-pins" or something like that). b. An OPTIONS * request might be a good fit here, it was apparently intende= d for server-level information. Perhaps the response to an OPTIONS * could = have the public key data (like the Public-Key-Pins header). Alternatively, = to combine the two ideas, the OPTIONS * response could, instead of having t= he public key data itself, instead have a header with a URL for a public ke= y pins resource (like the Public-Key-Pin-Location header mentioned above). Thanks for considering these ideas. --_000_8c03997da80b4e8da7100491011b8c12BN1PR03MB039namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I sent the mail below to the draft-ietf-websec-key-p= inning-06 authors, and Chris Palmer suggested I raise the points on this ma= iling list. He also mentioned a previous discussion (which I haven’t = been able to locate) around a well-known host security information URL; if there’s a good place to get up to = speed on that discussion, a pointer would be much appreciated.

 

Thanks,

 

David

 

I really like the overall approach taken in Public K= ey Pinning Extension for HTTP (draft-ietf-websec-key-pinning-06). Particula= rly, the public key (including algorithm) seems like exactly the right thin= g to pin.

 

A couple of thoughts on other areas of the draft (my= apologies if these have been discussed before elsewhere; I’m only fa= miliar with the draft text):

 

1. It would be nice to avoid including full public k= ey data with every HTTP response. Particularly if there are multiple public= keys in use, there’s a bit of potential data overhead on every respo= nse. Would it make more sense to have the public key data in a separate resource? As a first step, perhaps having ev= ery resource just have a pointer, using a header something like the followi= ng:

Public-Key-Pin-Location: /pins

Where “/pins” would be a separate resour= ce that would have Public-Key-Pins header data.

Or, to go one step further, this data could then app= ear in the entity-body (perhaps in JSON format) and use normal HTTP resourc= e-level mechanisms—for example, using Cache-Control to specify the ex= piration rather than a custom max-age header directive.

 

2. It would be nice to have the public key specified= in a central place for the host, rather than by any resource, since the pu= blic keys are at the TLS level and don’t vary per resource. I’m= not sure there’s an ideal solution here, but a couple of options might be:

a. Have a fixed, well-known resource per host for re= trieving public key pin data (such as “/well-known-pins” or som= ething like that).

b. An OPTIONS * request might be a good fit here, it= was apparently intended for server-level information. Perhaps the response= to an OPTIONS * could have the public key data (like the Public-Key-Pins h= eader). Alternatively, to combine the two ideas, the OPTIONS * response could, instead of having the public = key data itself, instead have a header with a URL for a public key pins res= ource (like the Public-Key-Pin-Location header mentioned above).=

 

Thanks for considering these ideas.

--_000_8c03997da80b4e8da7100491011b8c12BN1PR03MB039namprd03pro_-- From internet-drafts@ietf.org Fri Jun 21 23:06:43 2013 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 E429C21F99F7; Fri, 21 Jun 2013 23:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-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 2IKi2Em33sU1; Fri, 21 Jun 2013 23:06:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2418C21F969F; Fri, 21 Jun 2013 23:06:43 -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: 4.51.p2 Message-ID: <20130622060643.18672.33108.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 23:06:43 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-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, 22 Jun 2013 06:06:44 -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 IETF. Title : HTTP Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-03.txt Pages : 11 Date : 2013-06-21 Abstract: To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tobias.gondrom@gondrom.org Fri Jun 21 23:10:28 2013 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 B7A6721F9DE4 for ; Fri, 21 Jun 2013 23:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=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 JeTX+1nCioFq for ; Fri, 21 Jun 2013 23:10:24 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id E63E021F9DC6 for ; Fri, 21 Jun 2013 23:10:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=CuWfRmgENdspH52PS8qOCTM7WFK1c8wPWVF2S5hDMadgnKf9/3u+LQB+3dKa70Uh/wiBq6Ob1oIHb0fqsZGJxnlf+bVZkU6b7hp/RpUshPds8tSrnBODXVKZ4uggJn4Q; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 1699 invoked from network); 22 Jun 2013 08:10:22 +0200 Received: from 198.82.247.60.static.bjtelecom.net (HELO ?172.31.8.88?) (60.247.82.198) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Jun 2013 08:10:22 +0200 Message-ID: <51C53FCD.4000306@gondrom.org> Date: Sat, 22 Jun 2013 14:10:21 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: websec@ietf.org References: <509BE1F0.4010701@KingsMountain.com> <509C07EB.5090806@gondrom.org> In-Reply-To: <509C07EB.5090806@gondrom.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] WGLC feedback for X-Frame-Options 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, 22 Jun 2013 06:10:28 -0000 Dear websec fellows, I just uploaded the latest version of XFO including the WGLC feedback I received. (Apologies for the delay, this happened due to some personal difficulties.) I hope the new revision is satisfactory and we can go to IETF LC. The changes were only very small: - the "deprecation of X-" comment is in the introduction section incl. reference to 6648 - and I removed the section 2.2.2 as recommended by Julian. Best regards, Tobias On 09/11/12 03:28, Tobias Gondrom wrote: > On 08/11/12 14:22, Barry Leiba wrote: >>> I suggest an explicit statement such as.. >>> >>> The purpose of this specification is to document existing practice. >>> >>> ..should appear in the abstract and the intoduction. >> ... >>> I wonder if also a note will be necessary to explain the use of the >>> "X-" >>> prefix in light of... >>> >>> 6648 Deprecating the "X-" Prefix and Similar Constructs in Application >>> Protocols. P. Saint-Andre, D. Crocker, M. Nottingham. June 2012. >> These are, of course, related, and one statement can cover both. I >> can pretty much guarantee you'll get DISCUSSes from the IESG if you >> don't do it. > > Thank you Jeff for reminding me. Forgot to include them. > Well, as we already have PSA's RFC on that (which btw. inspired XFO, > both (comment and reference) have been added to the text of working > copy (released in next version after this week). > > >> >> Barry, as AD >> _______________________________________________ >> 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 From jbonneau@gmail.com Sat Jun 22 08:45:43 2013 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 0477521F9F31 for ; Sat, 22 Jun 2013 08:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 83O89y0-ltqm for ; Sat, 22 Jun 2013 08:45:42 -0700 (PDT) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA4921F9DA0 for ; Sat, 22 Jun 2013 08:45:42 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id q12so6902085vbe.27 for ; Sat, 22 Jun 2013 08:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8beaT0TOguSOtT3sMMbOEhdFdSajfUJe4uTZWORyXKQ=; b=hhwIVuiouZU6H6g+2AORIguhfb7vGJKnyhMo/67xPO48CIVOoEE7Sg7Zu2XrHp1CDv TSv4ozezgS5HGkELstNfGp2OTkBT28T4fPyAhDJWlD/qiXMx5RVrk6GRh10z6qPeEeMc 69eTxDzazplMfRWYoFmZ1QHvmAWApToN9WqMAxsV8LjrgQNp1N4SCR/HMfc0Qz9q7VlU jh3PFIWv897PqIIvv1t+iR2HMhRKCfALDRNnCfJHNsp0VgAr8IHZCzk8KW9LzeDE8/6c cz95Nqy7+Fd8ieipXgr/Ktz/0SkhGkOH1YJ78yIBXk8QmkYRiOf8L58s5weZzaNjcoEs A2yw== X-Received: by 10.220.44.195 with SMTP id b3mr7805719vcf.62.1371915940887; Sat, 22 Jun 2013 08:45:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.103.69 with HTTP; Sat, 22 Jun 2013 08:45:20 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Sat, 22 Jun 2013 11:45:20 -0400 Message-ID: To: Trevor Perrin Content-Type: multipart/alternative; boundary=001a11c2c9ac51813404dfc0125f Cc: IETF WebSec WG Subject: Re: [websec] HPKP and preloaded pin lists 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, 22 Jun 2013 15:45:43 -0000 --001a11c2c9ac51813404dfc0125f Content-Type: text/plain; charset=UTF-8 > In this case, the browser MUST ignore the preloaded pin, and only apply > the pin it noted at T15. > I would support changing this from MUST to SHOULD, with the understanding that browsers may have forgotten the pin noted at T15 in Trevor's example for multiple possible reasons (space constraints, user clears history, etc.) in which case they will revert to the preloaded pin. In practice a site attempting to un-pin a bad preloaded pin will have to serve the "un-pin" header for the lifetime of the bad preloaded pin no matter what, because some browsers may never visit the site site until the end of the life of the bad preload. So I don't see that making this a MUST makes life any easier for site operators, and as Trevor pointed out it may cause excessive complexity for browsers. Joe --001a11c2c9ac51813404dfc0125f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In this case, the browser MUST ignore the preloaded pin, and only = apply the pin it noted at T15.

I would support changing this from M= UST to SHOULD, with the understanding that browsers may have forgotten the = pin noted at T15 in Trevor's example for multiple possible reasons (spa= ce constraints, user clears history, etc.) in which case they will revert t= o the preloaded pin. In practice a site attempting to un-pin a bad preloade= d pin will have to serve the "un-pin" header for the lifetime of = the bad preloaded pin no matter what, because some browsers may never visit= the site site until the end of the life of the bad preload. So I don't= see that making this a MUST makes life any easier for site operators, and = as Trevor pointed out it may cause excessive complexity for browsers.

Joe
--001a11c2c9ac51813404dfc0125f-- From jbonneau@gmail.com Sat Jun 22 09:05:18 2013 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 6410421F9F7D for ; Sat, 22 Jun 2013 09:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 wcrjy+l5z234 for ; Sat, 22 Jun 2013 09:05:17 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20E11E80FC for ; Sat, 22 Jun 2013 09:05:14 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so7331796veb.41 for ; Sat, 22 Jun 2013 09:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=qYWL988JuDvm3hJKVBYUEVS3adrOs+wUs9Led1c0gCA=; b=jqRFzk6gwICI8x08tQgaHgFIoorcyukzScp4rvoRQQ9gbiS8X3/YiFDYtgKTYmY8Na dCjPIifGHFSyyVos60tio1In7tnlU9QYNYyF5ZzCS/bIvSzy99kG6VWbQQpcqyUuQNj1 o6WYMl8OZP6cmR6yxTIftqP70WcgaZieHMomMJ8GGrsFcVzOUJOsgOjDRv+izDjwShA4 iN+lWCoYeBoEqzpnP8bKvsP3qvThkk503egYGsfkCJ1H0mGL89iiMiKveuo4lOHo2MFp NcBp/HWA1DQKtMZpjpnlkqpY4MjJ5CwB2bdl8fSIUCj1huIL6ZE59znNq7lzVDqAJfoI 0M1Q== X-Received: by 10.58.219.232 with SMTP id pr8mr8240342vec.80.1371917114027; Sat, 22 Jun 2013 09:05:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.103.69 with HTTP; Sat, 22 Jun 2013 09:04:53 -0700 (PDT) From: Joseph Bonneau Date: Sat, 22 Jun 2013 12:04:53 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bd6b88c3e373904dfc058b8 Subject: [websec] HPKP and privacy 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, 22 Jun 2013 16:05:18 -0000 --047d7bd6b88c3e373904dfc058b8 Content-Type: text/plain; charset=UTF-8 Reading over the new draft I was thinking of the privacy considerations of HPKP. A few thoughts: (a) Obviously the state of a user's pin store contains a lot of information about their browsing history. This is a primary concern. (b) A clever site could use this as a tracking mechanism to evade third-party cookie limits or other restrictions. For example, a tracking domain could have a set of N public keys available for use, pin different users to a unique sets of them, and then be included as N resources on a third-party page. By noting which TLS connections lead to actual data transfers, they can identify the user uniquely. This is an exotic threat model, perhaps, but it might become interesting if protection against other forms of third-party tracking improves. (c) Potentially HPKP could be used for history sniffing, though I can't think of a way to do this without the adversary having network-level access and malicious certificats for the target domain. Thinking of (a) and (b) is it worth adding a section to the spec on privacy considerations? The high points would be that (a) Browsers SHOULD remove dynamic pins for a domain whenever users request deletion of other browser-history state for that domain, such as a "clear history" request or the end of a private browsing session. (b) Browsers MAY decline to note pins for privacy reasons for third-party domains while browsing, similar to third-party cookie policies. Joe --047d7bd6b88c3e373904dfc058b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Reading over the new draft I was thinking of the privacy considerations of = HPKP. A few thoughts:

(a) Obviously the state of a user&= #39;s pin store contains a lot of information about their browsing history.= This is a primary concern.

(b) A clever site could use this as a tracking mechanis= m to evade third-party cookie limits or other restrictions. For example, a = tracking domain could have a set of N public keys available for use, pin di= fferent users to a unique sets of them, and then be included as N resources= on a third-party page. By noting which TLS connections lead to actual data= transfers, they can identify the user uniquely. This is an exotic threat m= odel, perhaps, but it might become interesting if protection against other = forms of third-party tracking improves.

(c) Potentially HPKP could be used for history sniffing= , though I can't think of a way to do this without the adversary having= network-level access and malicious certificats for the target domain.

Thinking of (a) and (b) is it worth adding a section to= the spec on privacy considerations? The high points would be that (a) Brow= sers SHOULD remove dynamic pins for a domain whenever users request deletio= n of other browser-history state for that domain, such as a "clear his= tory" request or the end of a private browsing session. (b) Browsers M= AY decline to note pins for privacy reasons for third-party domains while b= rowsing, similar to third-party cookie policies.=C2=A0

Joe
--047d7bd6b88c3e373904dfc058b8-- From ynir@checkpoint.com Sat Jun 22 23:19:23 2013 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 E185321E80A6 for ; Sat, 22 Jun 2013 23:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.607 X-Spam-Level: X-Spam-Status: No, score=-10.607 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JdxlDS9Wzy3A for ; Sat, 22 Jun 2013 23:19:16 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C473321E8098 for ; Sat, 22 Jun 2013 23:19:15 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5N6IxZi003872; Sun, 23 Jun 2013 09:19:13 +0300 X-CheckPoint: {51C69353-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Sun, 23 Jun 2013 09:19:06 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] HPKP and preloaded pin lists Thread-Index: AQHObfqEiA/KHYgBZ06jXAOOxwUP7plCpOmA Date: Sun, 23 Jun 2013 06:19:06 +0000 Message-ID: <07A8CBC1-D1D7-4C08-A53C-245D60D251F3@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.74] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1174cb14e16761ce7f755737e6ffef1c40715bbf32 Content-Type: multipart/alternative; boundary="_000_07A8CBC1D1D74C08A53C245D60D251F3checkpointcom_" MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] HPKP and preloaded pin lists 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, 23 Jun 2013 06:19:24 -0000 --_000_07A8CBC1D1D74C08A53C245D60D251F3checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think remembering the nullified and expired pins for max-max-age adds com= plexity. It's fine to do, but we shouldn't require it. A website that issues a bad pin for 30 days has to live with the consequenc= es of that pin for all of those 30 days. Getting a pre-loaded pin list coul= d save you and unpin a particular client, but that can turn on you and bite= you and pin a client that had not been pinned before. I think that on bala= nce it is still better to get the pins from a crawler. Maybe the crawlers s= hould have some web interface that allows someone (the website administrato= r in this case) to request that a particular server be scanned (much like S= SL-pulse has) So knowing that there is a chance for both good and bad interactions with p= re-loaded pins, and that the damage is anyway limited by max-max-age, I thi= nk we should leave it to implementations rather than add mandates. Yoav (with no hats) On Jun 21, 2013, at 12:09 AM, Trevor Perrin > wrote: Hi, I'm not sure I understand section 2.7 on "Interactions With Preloaded Pin L= ists". At first glance it seems clear: Both preloaded and dynamic pins MUST store= the "Effective Pin Date" when the pin was most recently observed, and brow= sers MUST use only the most recent information. E.g.: T10 - Crawler notes a pin for "example.com" T15 - Browser notes a different pin for "example.com" T20 - Crawler sends preloaded pin to Browser In this case, the browser MUST ignore the preloaded pin, and only apply the= pin it noted at T15. But what if the browser-noted pin has a max-age of 0 or 1? Or what if the = T15 connection occurs over a secure transport but has no PKP header? The s= pec says: "If the result of noting a Valid Pinning Header is to disable pinning for t= he host, such as through supplying a max-age directive with a value of 0, U= As MUST allow this new information to override any other pinning data. Tha= t is, a host must be able to un-pin itself, even in the presence of built-i= n pins." That seems to imply the browser needs to remember "un-pinning" responses it= receives (i.e. max-age=3D0 or no PKP header), and expired pins, on the cha= nce that any of these might "un-pin" a preloaded pin it receives later? That seems fairly complicated, and rather inflexible (I could imagine a bro= wser might trust its preload data more than dynamic data, and prefer that t= ake precedence). So what if browsers were simply allowed to apply *either* the preload or dy= namic pin, or both? The browser could choose to apply a complex, time-based algorithm like abov= e, or do something simpler like apply both pins, or let preloads take prece= dence. This also allows for implementations which don't need to store either the "= Effective Pin Date" (only the expiration time), or "un-pinning" entries. Thoughts? Trevor --_000_07A8CBC1D1D74C08A53C245D60D251F3checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <658918D87BC97C45BA944532941C6723@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable I think remembering the nullified and expired pins for max-max-age adds com= plexity. It's fine to do, but we shouldn't require it. 

A website that issues a bad pin for 30 days has to live with the conse= quences of that pin for all of those 30 days. Getting a pre-loaded pin list= could save you and unpin a particular client, but that can turn on you and= bite you and pin a client that had not been pinned before. I think that on balance it is still better to = get the pins from a crawler. Maybe the crawlers should have some web interf= ace that allows someone (the website administrator in this case) to request= that a particular server be scanned (much like SSL-pulse has)

So knowing that there is a chance for both good and bad interactions w= ith pre-loaded pins, and that the damage is anyway limited by max-max-age, = I think we should leave it to implementations rather than add mandates.

Yoav (with no hats)

On Jun 21, 2013, at 12:09 AM, Trevor Perrin <trevp@trevp.net> wrote:


Hi,

I'm not sure I understand section 2.7 on "Interactions With Prelo= aded Pin Lists".

At first glance it seems clear:  Both preloaded and dynamic pins = MUST store the "Effective Pin Date" when the pin was most recentl= y observed, and browsers MUST use only the most recent information.  E= .g.:

T10 - Crawler notes a pin for "ex= ample.com"
T15 - Browser notes a different pin for "example.com"
T20 - Crawler sends preloaded pin to Browser

In this case, the browser MUST ignore the preloaded pin, and only appl= y the pin it noted at T15.

But what if the browser-noted pin has a max-age of 0 or 1?  Or wh= at if the T15 connection occurs over a secure transport but has no PKP head= er?  The spec says: 

"If the result of noting a Valid Pinning Header is to disable pin= ning for the host, such as through supplying a max-age directive with a val= ue of 0, UAs MUST allow this new information to override any other pinning = data.  That is, a host must be able to un-pin itself, even in the presence of built-in pins."

That seems to imply the browser needs to remember "un-pinning&quo= t; responses it receives (i.e. max-age=3D0 or no PKP header), and expired p= ins, on the chance that any of these might "un-pin" a preloaded p= in it receives later?


That seems fairly complicated, and rather inflexible (I could imagine = a browser might trust its preload data more than dynamic data, and prefer t= hat take precedence).

So what if browsers were simply allowed to apply *either* the preload = or dynamic pin, or both?

The browser could choose to apply a complex, time-based algorithm like= above, or do something simpler like apply both pins, or let preloads take = precedence.

This also allows for implementations which don't need to store either = the "Effective Pin Date" (only the expiration time), or "un-= pinning" entries.

Thoughts?


Trevor

--_000_07A8CBC1D1D74C08A53C245D60D251F3checkpointcom_-- From ynir@checkpoint.com Sun Jun 23 00:26:07 2013 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 034EB21F9C5E for ; Sun, 23 Jun 2013 00:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.606 X-Spam-Level: X-Spam-Status: No, score=-10.606 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WzF8cGzXtY3i for ; Sun, 23 Jun 2013 00:26:02 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9493921F9BFE for ; Sun, 23 Jun 2013 00:26:01 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5N7PwYs011558; Sun, 23 Jun 2013 10:25:58 +0300 X-CheckPoint: {51C6A306-9-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Sun, 23 Jun 2013 10:25:58 +0300 From: Yoav Nir To: David Matson Thread-Topic: [websec] Comments on draft-ietf-websec-key-pinning-06 Thread-Index: Ac5t5xheMaFE3h1jTOy+Nog0fBhFEQB4q68A Date: Sun, 23 Jun 2013 07:25:58 +0000 Message-ID: <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> In-Reply-To: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.74] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1113787d79f99e2d990d94a2382159bdd646342e2c Content-Type: multipart/alternative; boundary="_000_6F2FE5F2D02C4B09A6CA7C3B63722E34checkpointcom_" MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 23 Jun 2013 07:26:07 -0000 --_000_6F2FE5F2D02C4B09A6CA7C3B63722E34checkpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David As far as I know, this idea was not discussed before. If we were to do this= , the proper URI for this would be some kind of RFC 5785 URI like "/.well-k= nown/pins" or "/.well-known/hpkp". Looking at the examples in the key-pinning draft, an HPKP header using SHA-= 1 takes just under 120 bytes. Compared to some of the stuff that gets sent = in HTTP headers (I'm looking at you, user-agent) this is pretty tame. Moreo= ver, the key-pinning header does not have to be sent in every response - it= 's enough to send it once per full TLS handshake. Another think to conside= r is HTTP/2, where the header compression is not yet specified, but the alg= orithm that is currently being discussed on the mailing list has the abilit= y to reference headers from previous responses, so that the full Public-Key= -Pin could be included only once, and referred back to in other responses, = although that's not really necessary. Still, I can see several merits in your proposal: - clients that don't support key pinning need not get a header they're not= going to process - Inserting a header only in the first response requires information from = the TLS layer, so it's easier to just insert the header in every response. - HTTP/2 is not yet here, let alone wide-spread. What do others think? Yoav On Jun 20, 2013, at 9:55 PM, David Matson > wrote: I sent the mail below to the draft-ietf-websec-key-pinning-06 authors, and = Chris Palmer suggested I raise the points on this mailing list. He also men= tioned a previous discussion (which I haven=92t been able to locate) around= a well-known host security information URL; if there=92s a good place to g= et up to speed on that discussion, a pointer would be much appreciated. Thanks, David I really like the overall approach taken in Public Key Pinning Extension fo= r HTTP (draft-ietf-websec-key-pinning-06). Particularly, the public key (in= cluding algorithm) seems like exactly the right thing to pin. A couple of thoughts on other areas of the draft (my apologies if these hav= e been discussed before elsewhere; I=92m only familiar with the draft text)= : 1. It would be nice to avoid including full public key data with every HTTP= response. Particularly if there are multiple public keys in use, there=92s= a bit of potential data overhead on every response. Would it make more sen= se to have the public key data in a separate resource? As a first step, per= haps having every resource just have a pointer, using a header something li= ke the following: Public-Key-Pin-Location: /pins Where =93/pins=94 would be a separate resource that would have Public-Key-P= ins header data. Or, to go one step further, this data could then appear in the entity-body = (perhaps in JSON format) and use normal HTTP resource-level mechanisms=97fo= r example, using Cache-Control to specify the expiration rather than a cust= om max-age header directive. 2. It would be nice to have the public key specified in a central place for= the host, rather than by any resource, since the public keys are at the TL= S level and don=92t vary per resource. I=92m not sure there=92s an ideal so= lution here, but a couple of options might be: a. Have a fixed, well-known resource per host for retrieving public key pin= data (such as =93/well-known-pins=94 or something like that). b. An OPTIONS * request might be a good fit here, it was apparently intende= d for server-level information. Perhaps the response to an OPTIONS * could = have the public key data (like the Public-Key-Pins header). Alternatively, = to combine the two ideas, the OPTIONS * response could, instead of having t= he public key data itself, instead have a header with a URL for a public ke= y pins resource (like the Public-Key-Pin-Location header mentioned above). Thanks for considering these ideas. Email secured by Check Point _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec --_000_6F2FE5F2D02C4B09A6CA7C3B63722E34checkpointcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <747A49CB9D2E0B478EBEF871B7D46A36@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi David

As far as I know, this idea was not discussed before. If we were to do= this, the proper URI for this would be some kind of RFC 5785 URI like &quo= t;/.well-known/pins" or "/.well-known/hpkp".

Looking at the examples in the key-pinning draft, an HPKP header using= SHA-1 takes just under 120 bytes. Compared to some of the stuff that gets = sent in HTTP headers (I'm looking at you, user-agent) this is pretty tame. = Moreover, the key-pinning header does not have to be sent in every response - it's enough to send it once p= er full TLS handshake.  Another think to consider is HTTP/2, where the= header compression is not yet specified, but the algorithm that is current= ly being discussed on the mailing list has the ability to reference headers from previous responses, so that the = full Public-Key-Pin could be included only once, and referred back to in ot= her responses, although that's not really necessary.

Still, I can see several merits in your proposal:
 - clients that don't support key pinning need not get a header t= hey're not going to process
 - Inserting a header only in the first response requires informa= tion from the TLS layer, so it's easier to just insert the header in every = response.
 - HTTP/2 is not yet here, let alone wide-spread. 

What do others think?

Yoav


On Jun 20, 2013, at 9:55 PM, David Matson <dmatson@microsoft.com> wrote:

I sent the mail below to the draft-ietf-websec-key-pinning-06 authors, and = Chris Palmer suggested I raise the points on this mailing list. He also men= tioned a previous discussion (which I haven=92t been able to locate) around= a well-known host security information URL; if there=92s a good place to get up to speed on that discussion, a po= inter would be much appreciated.
 
Thanks,
 
David
 
I really like the overall approach taken in Public Key Pinning Extension fo= r HTTP (draft-ietf-websec-key-pinning-06). Particularly, the public key (in= cluding algorithm) seems like exactly the right thing to pin.
 
A couple of thoughts on other areas of the draft (my apologies if these hav= e been discussed before elsewhere; I=92m only familiar with the draft text)= :
 
1. It would be nice to avoid including full public key data with every HTTP= response. Particularly if there are multiple public keys in use, there=92s= a bit of potential data overhead on every response. Would it make more sen= se to have the public key data in a separate resource? As a first step, perhaps having every resource just h= ave a pointer, using a header something like the following:
Public-Key-Pin-Location: /pins
Where =93/pins=94 would be a separate resource that would have Public-Key-P= ins header data.
Or, to go one step further, this data could then appear in the entity-body = (perhaps in JSON format) and use normal HTTP resource-level mechanisms=97fo= r example, using Cache-Control to specify the expiration rather than a cust= om max-age header directive.
 
2. It would be nice to have the public key specified in a central place for= the host, rather than by any resource, since the public keys are at the TL= S level and don=92t vary per resource. I=92m not sure there=92s an ideal so= lution here, but a couple of options might be:
a. Have a fixed, well-known resource per host for retrieving public key pin= data (such as =93/well-known-pins=94 or something like that).
b. An OPTIONS * request might be a good fit here, it was apparently intende= d for server-level information. Perhaps the response to an OPTIONS * could = have the public key data (like the Public-Key-Pins header). Alternatively, = to combine the two ideas, the OPTIONS * response could, instead of having the public key data itself, instead ha= ve a header with a URL for a public key pins resource (like the Public-Key-= Pin-Location header mentioned above).
 
Thanks for considering these ideas.


Email secured by Check Point 

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

--_000_6F2FE5F2D02C4B09A6CA7C3B63722E34checkpointcom_-- From trevp@trevp.net Sun Jun 23 18:13:30 2013 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 8645911E80E4 for ; Sun, 23 Jun 2013 18:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 rVkCMxHV1jb4 for ; Sun, 23 Jun 2013 18:13:25 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id DB49411E80F6 for ; Sun, 23 Jun 2013 18:13:24 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so7853831wev.28 for ; Sun, 23 Jun 2013 18:13:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Y1rSfbRb5YJB1MWOA3eJ/qw6aHaeJY/VppU2I0yV6oI=; b=mHvLSvKiKYEmjddT/wF5wPlokwGGxc31EPnOiBzFGzc7Nki5wmtlWujAFvOsc6kzdR L0KlHll/tPTRNxG2YjvACAoMu0lhhu89mKYmNEbVGP1bGwT6UK5PjF4SzgdvIN6DSNoC z8248h5jPUhl936oPcbjBzbz012sywLyO5KNX5tb0uQKyl1tuy3hqi5M8sqyHPGmu4ta i3irLB/qJBx3h+R4bktM/3mE5SaprnF9m7Jqwejd5Ra+HKxQGW+lT8naKBUlO6z0rC9T f5zEMtTymbDdeYmBUgI76UQKBzjpvJvTle1yO1ozgJDXjVlH3uAYSL91SsJ1YmdAm+hQ JlZQ== MIME-Version: 1.0 X-Received: by 10.194.24.40 with SMTP id r8mr7481244wjf.7.1372036402643; Sun, 23 Jun 2013 18:13:22 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Sun, 23 Jun 2013 18:13:22 -0700 (PDT) X-Originating-IP: [173.11.70.186] In-Reply-To: <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> Date: Sun, 23 Jun 2013 18:13:22 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b5d352866161004dfdc1e84 X-Gm-Message-State: ALoCoQndUJkwlDAtj9LyULQWWASnTwTHBJ/JlUq08H8VidWUc17AV/AmnzBb+a2srAjTXEs8ShMG Cc: David Matson , "websec@ietf.org" Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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: Mon, 24 Jun 2013 01:13:30 -0000 --047d7b5d352866161004dfdc1e84 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir wrote: > Hi David > > As far as I know, this idea was not discussed before. If we were to do > this, the proper URI for this would be some kind of RFC 5785 URI like > "/.well-known/pins" or "/.well-known/hpkp". > > Looking at the examples in the key-pinning draft, an HPKP header using > SHA-1 takes just under 120 bytes. > Depends on the number of pinned keys. Chrome's existing preloads [1] have 9, 5, 19, 36, 2, and 2 keys. That's a mean of 12, which would be >500 bytes with SHA256. > Compared to some of the stuff that gets sent in HTTP headers (I'm looking > at you, user-agent) this is pretty tame. Moreover, the key-pinning header > does not have to be sent in every response - it's enough to send it once > per full TLS handshake. > I thought so too, but draft-04 and later say: "If the Pinned Host does not include the PKP header field, and if the connection passed Pin Validation, UAs MUST treat the host as if it had set its max-age to 0 (see Section 2.3.1)." So apparently it *does* need to be sent on every response, to maintain the pin? Still, I can see several merits in your proposal: > - clients that don't support key pinning need not get a header they're > not going to process > - Inserting a header only in the first response requires information from > the TLS layer, so it's easier to just insert the header in every response. > - HTTP/2 is not yet here, let alone wide-spread. > Agreed it has merit, particularly if there's any possibility of future pinning policies growing larger with other types of data (e.g. policies for error-handling and reporting, or "pinning" to other things like CT, DNSSEC, TACK, etc...) Trevor --047d7b5d352866161004dfdc1e84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir <ynir@checkpoint.com><= /span> wrote:
Hi David

As far as I know, this idea was not discussed before. If we were to do= this, the proper URI for this would be some kind of RFC 5785 URI like &quo= t;/.well-known/pins" or "/.well-known/hpkp".

Looking at the examples in the key-pinning draft, an HPKP header using= SHA-1 takes just under 120 bytes.

<= div>
Depends on the number of pinned keys. =A0Chrome's existing pre= loads [1] have 9, 5, 19, 36, 2, and 2 keys. =A0That's a mean of 12, whi= ch would be >500 bytes with SHA256.

=A0
Compared to some of the stuff that gets sent in HTTP headers (I'm= looking at you, user-agent) this is pretty tame. Moreover, the key-pinning= header does not have to be sent in every response - it's enough to send it on= ce per full TLS handshake.

I thought so too, but draft-04 and later say:

"If the Pinned Host does not include the PKP header field, and if the = connection passed Pin Validation, UAs MUST treat the host as if it had set = its max-age to 0 (see Section 2.3.1)."

So app= arently it *does* need to be sent on every response, to maintain the pin?


Still, I can see several merits in your proposal:
=A0- clients that don't support key pinning need not get a header = they're not going to process
=A0- Inserting a header only in the first response requires informatio= n from the TLS layer, so it's easier to just insert the header in every= response.
=A0- HTTP/2 is not yet here, let alone wide-spread.

Agreed it has merit, particularly if there's = any possibility of future pinning policies growing larger with other types = of data (e.g. policies for error-handling and reporting, or "pinning&q= uot; to other things like CT, DNSSEC, TACK, etc...)


Trevor
--047d7b5d352866161004dfdc1e84-- From tobias.gondrom@gondrom.org Mon Jun 24 00:01:42 2013 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 EF23B21F9ABE for ; Mon, 24 Jun 2013 00:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=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 SHqpNR0jQffk for ; Mon, 24 Jun 2013 00:01:38 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id BDC2F21F9A6A for ; Mon, 24 Jun 2013 00:01:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=aB9E1NcW1AJr9i4gcZUULXrPNxXj2GqQfiu/JJsf9b23CKi80qMamoTyk4Vv9GVpCZRcq/rCqm+mU+V5NBqTjuQxrJRTAzHva+JtAgrr6kcOLrFpBO9liG2mTmAKzLh0; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 7324 invoked from network); 24 Jun 2013 09:01:31 +0200 Received: from 188.82.247.60.static.bjtelecom.net (HELO ?172.31.8.30?) (60.247.82.188) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Jun 2013 09:01:31 +0200 Message-ID: <51C7EECC.3020108@gondrom.org> Date: Mon, 24 Jun 2013 15:01:32 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: trevp@trevp.net References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------020605060500050603020007" Cc: websec@ietf.org, dmatson@microsoft.com Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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: Mon, 24 Jun 2013 07:01:43 -0000 This is a multi-part message in MIME format. --------------020605060500050603020007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, comments inline. Best regards, Tobias On 24/06/13 09:13, Trevor Perrin wrote: > > On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir > wrote: > > Hi David > > As far as I know, this idea was not discussed before. If we were > to do this, the proper URI for this would be some kind of RFC 5785 > URI like "/.well-known/pins" or "/.well-known/hpkp". > > Looking at the examples in the key-pinning draft, an HPKP header > using SHA-1 takes just under 120 bytes. > > > Depends on the number of pinned keys. Chrome's existing preloads [1] > have 9, 5, 19, 36, 2, and 2 keys. That's a mean of 12, which would be > >500 bytes with SHA256. > IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per host. Just for my understanding: Do you think this will create too much header overhead and there want to the reference to the pin? > > > Compared to some of the stuff that gets sent in HTTP headers (I'm > looking at you, user-agent) this is pretty tame. Moreover, the > key-pinning header does not have to be sent in every response - > it's enough to send it once per full TLS handshake. > > > I thought so too, but draft-04 and later say: > > "If the Pinned Host does not include the PKP header field, and if the > connection passed Pin Validation, UAs MUST treat the host as if it had > set its max-age to 0 (see Section 2.3.1)." > > So apparently it *does* need to be sent on every response, to maintain > the pin? Yes. That is my reading of the paragraph, too. I guess the assumption was that this shall function as a fail safe instead of actively setting it to value 0. > > > Still, I can see several merits in your proposal: > - clients that don't support key pinning need not get a header > they're not going to process > - Inserting a header only in the first response requires > information from the TLS layer, so it's easier to just insert the > header in every response. > - HTTP/2 is not yet here, let alone wide-spread. > > > Agreed it has merit, particularly if there's any possibility of future > pinning policies growing larger with other types of data (e.g. > policies for error-handling and reporting, or "pinning" to other > things like CT, DNSSEC, TACK, etc...) > > > Trevor > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------020605060500050603020007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi all,

<no hat>
comments inline.
Best regards, Tobias


On 24/06/13 09:13, Trevor Perrin wrote:

On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi David

As far as I know, this idea was not discussed before. If we were to do this, the proper URI for this would be some kind of RFC 5785 URI like "/.well-known/pins" or "/.well-known/hpkp".

Looking at the examples in the key-pinning draft, an HPKP header using SHA-1 takes just under 120 bytes.

Depends on the number of pinned keys.  Chrome's existing preloads [1] have 9, 5, 19, 36, 2, and 2 keys.  That's a mean of 12, which would be >500 bytes with SHA256.


IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per host.
Just for my understanding: Do you think this will create too much header overhead and there want to the reference to the pin?

 
Compared to some of the stuff that gets sent in HTTP headers (I'm looking at you, user-agent) this is pretty tame. Moreover, the key-pinning header does not have to be sent in every response - it's enough to send it once per full TLS handshake.

I thought so too, but draft-04 and later say:

"If the Pinned Host does not include the PKP header field, and if the connection passed Pin Validation, UAs MUST treat the host as if it had set its max-age to 0 (see Section 2.3.1)."

So apparently it *does* need to be sent on every response, to maintain the pin?

Yes. That is my reading of the paragraph, too. I guess the assumption was that this shall function as a fail safe instead of actively setting it to value 0.



Still, I can see several merits in your proposal:
 - clients that don't support key pinning need not get a header they're not going to process
 - Inserting a header only in the first response requires information from the TLS layer, so it's easier to just insert the header in every response.
 - HTTP/2 is not yet here, let alone wide-spread.

Agreed it has merit, particularly if there's any possibility of future pinning policies growing larger with other types of data (e.g. policies for error-handling and reporting, or "pinning" to other things like CT, DNSSEC, TACK, etc...)


Trevor


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

--------------020605060500050603020007-- From tobias.gondrom@gondrom.org Mon Jun 24 00:09:10 2013 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 500A921E80C4 for ; Mon, 24 Jun 2013 00:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=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 G9PgeuR1WzaC for ; Mon, 24 Jun 2013 00:09:05 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 420AA21E80C0 for ; Mon, 24 Jun 2013 00:09:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=gY103v5KEihcW+3pBdkVyCgK2Zd+Ng1GfBjxFrTastiMjQDib9s14VS3mVN5sCegTnNBrqog6WsK8AZt6ySMp6Ia5lo0SDtOqHHQNKXm2YrInK39ywBN7kcG3H+9fmC3; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 8033 invoked from network); 24 Jun 2013 09:09:02 +0200 Received: from 188.82.247.60.static.bjtelecom.net (HELO ?172.31.8.30?) (60.247.82.188) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Jun 2013 09:09:02 +0200 Message-ID: <51C7F08F.2090205@gondrom.org> Date: Mon, 24 Jun 2013 15:09:03 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: jbonneau@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------060100030408080503080300" Cc: websec@ietf.org Subject: Re: [websec] HPKP and privacy 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: Mon, 24 Jun 2013 07:09:10 -0000 This is a multi-part message in MIME format. --------------060100030408080503080300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I agree with the overall point of adding information on privacy concerns in the draft. I would agree with (a) and rather unlikely (c). Regarding (b): Actually maybe I misunderstand something, but I think it would be rather suicidal of a web page to try (b) because the pin acts before or at the establishment of the TLS connection. So you have no idea who the other party is yet and will most likely brick a lot of your users if you try to give them different pins that then don't work. But maybe I missed something? Best regards, Tobias On 23/06/13 00:04, Joseph Bonneau wrote: > Reading over the new draft I was thinking of the privacy > considerations of HPKP. A few thoughts: > > (a) Obviously the state of a user's pin store contains a lot of > information about their browsing history. This is a primary concern. > > (b) A clever site could use this as a tracking mechanism to evade > third-party cookie limits or other restrictions. For example, a > tracking domain could have a set of N public keys available for use, > pin different users to a unique sets of them, and then be included as > N resources on a third-party page. By noting which TLS connections > lead to actual data transfers, they can identify the user uniquely. > This is an exotic threat model, perhaps, but it might become > interesting if protection against other forms of third-party tracking > improves. > > (c) Potentially HPKP could be used for history sniffing, though I > can't think of a way to do this without the adversary having > network-level access and malicious certificats for the target domain. > > Thinking of (a) and (b) is it worth adding a section to the spec on > privacy considerations? The high points would be that (a) Browsers > SHOULD remove dynamic pins for a domain whenever users request > deletion of other browser-history state for that domain, such as a > "clear history" request or the end of a private browsing session. (b) > Browsers MAY decline to note pins for privacy reasons for third-party > domains while browsing, similar to third-party cookie policies. > > Joe > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------060100030408080503080300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

<no hats>
I agree with the overall point of adding information on privacy concerns in the draft.

I would agree with (a) and rather unlikely (c).
Regarding (b): Actually maybe I misunderstand something, but I think it would be rather suicidal of a web page to try (b) because the pin acts before or at the establishment of the TLS connection. So you have no idea who the other party is yet and will most likely brick a lot of your users if you try to give them different pins that then don't work. But maybe I missed something?

Best regards, Tobias




On 23/06/13 00:04, Joseph Bonneau wrote:
Reading over the new draft I was thinking of the privacy considerations of HPKP. A few thoughts:

(a) Obviously the state of a user's pin store contains a lot of information about their browsing history. This is a primary concern.

(b) A clever site could use this as a tracking mechanism to evade third-party cookie limits or other restrictions. For example, a tracking domain could have a set of N public keys available for use, pin different users to a unique sets of them, and then be included as N resources on a third-party page. By noting which TLS connections lead to actual data transfers, they can identify the user uniquely. This is an exotic threat model, perhaps, but it might become interesting if protection against other forms of third-party tracking improves.

(c) Potentially HPKP could be used for history sniffing, though I can't think of a way to do this without the adversary having network-level access and malicious certificats for the target domain.

Thinking of (a) and (b) is it worth adding a section to the spec on privacy considerations? The high points would be that (a) Browsers SHOULD remove dynamic pins for a domain whenever users request deletion of other browser-history state for that domain, such as a "clear history" request or the end of a private browsing session. (b) Browsers MAY decline to note pins for privacy reasons for third-party domains while browsing, similar to third-party cookie policies. 

Joe


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

--------------060100030408080503080300-- From trevp@trevp.net Mon Jun 24 14:06:26 2013 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 530D521E813B for ; Mon, 24 Jun 2013 14:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 GWDb-inxaVu7 for ; Mon, 24 Jun 2013 14:06:22 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AD77C21E811B for ; Mon, 24 Jun 2013 14:06:21 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so8311671wes.26 for ; Mon, 24 Jun 2013 14:06:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=br9jxQXqR2cE5sdxUww01G6r9wfMmLwmlIXIw2kEOro=; b=oZfnsZR2Co3eWoUtfCDMX7mMTLhk1neVhiXVGS+aNdLpQw3cawesQYeegqX84JYe5b aNkgLm9UadC8htHDhWIhVb6+jrbREMRY0YBLqE858qXTHuIiktO/wgflPzOU9jGwt8ps 4JSLmBJlgWtn8pm1WgobyaKQ+XAh+pLLT6Kj12xSVHzU8fp9K5xwoMaMfIE/YzCb6LZv aheG4ATYpw+u9U2Cly8kd0Z51U4VJ0FDW4ty731y0ltY2SuUyCtPepTZbwt5jgI3qsSE QAxPGacXzN/CbBKfI7mjzv1Q7JHbStzXQ4o6WJQOBRpmQ2iWmnT3Bf8RJk57lAFbzAgl Y55Q== MIME-Version: 1.0 X-Received: by 10.180.83.200 with SMTP id s8mr7068054wiy.48.1372107973398; Mon, 24 Jun 2013 14:06:13 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 24 Jun 2013 14:06:13 -0700 (PDT) X-Originating-IP: [12.27.66.5] In-Reply-To: <51C7EECC.3020108@gondrom.org> References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> <51C7EECC.3020108@gondrom.org> Date: Mon, 24 Jun 2013 14:06:13 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: multipart/alternative; boundary=14dae9cc92d45928f804dfecc833 X-Gm-Message-State: ALoCoQnmvol5ppapfe2y4nty89ar5Q2pkPTkzKb/owNhn4DIZa+UFMKkbB+FNLTeq4IfukNbx0S2 Cc: IETF WebSec WG , David Matson Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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: Mon, 24 Jun 2013 21:06:26 -0000 --14dae9cc92d45928f804dfecc833 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom wrote: > > On 24/06/13 09:13, Trevor Perrin wrote: > > Depends on the number of pinned keys. Chrome's existing preloads [1] > have 9, 5, 19, 36, 2, and 2 keys. That's a mean of 12, which would be >500 > bytes with SHA256. > > IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per host. > I don't know what the common case would be. The numbers I cited are from the Chromium's preloaded key pins: https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json Note that a commercial CA might have several subordinate and root certificates, with different keys. To pin yourself to this CA, you may need to list several of these keys, and to be conservative a site might pin multiple CAs. (Are you suggesting that sites would list both a SHA256 and SHA1 hash for each pinned key? That seems unnecessary.) > Just for my understanding: Do you think this will create too much header > overhead and there want to the reference to the pin? > I don't know how much data a site could add to every HTTP Response before it starts becoming a problem. But that's the issue David raised. If it's a real problem, the idea of putting pin assertions in, say, a JSON file at a "well-known" URI seems reasonable. E.g.: http://www.example.com/.well-known/public-key-pins Trevor --14dae9cc92d45928f804dfecc833 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom <tobias.gondrom@= gondrom.org> wrote:
=20 =20 =20

On 24/06/13 09:13, Trevor Perrin wrote:
=
Depends on the number of pinned keys. =A0Chrome's existing preloads [1] have 9, 5, 19, 36, 2, and 2 keys. =A0That's a mean of 12, which would be >500 bytes wi= th SHA256.

IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per host.

I don't know = what the common case would be. =A0The numbers I cited are from the Chromium= 's preloaded key pins:


Note that a commercial CA might have several subordinat= e and root certificates, with different keys. =A0To pin yourself to this CA= , you may need to list several of these keys, and to be conservative a site= might pin multiple CAs.

(Are you suggesting that sites would list both a SHA256= and SHA1 hash for each pinned key? =A0That seems unnecessary.)
=

=A0
Just for my understanding: Do you think this will create too much header overhead and there want to the reference to the pin?
<= /blockquote>

I don't know how much data a site = could add to every HTTP Response before it starts becoming a problem. =A0Bu= t that's the issue David raised. =A0

If it's a real problem, the idea of putting pin ass= ertions in, say, a JSON file at a "well-known" URI seems reasonab= le. =A0E.g.:



Trevor
--14dae9cc92d45928f804dfecc833-- From palmer@google.com Mon Jun 24 14:21:34 2013 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 CB52921E815B for ; Mon, 24 Jun 2013 14:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 AyVc8tIkpmXL for ; Mon, 24 Jun 2013 14:21:34 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8E35511E8143 for ; Mon, 24 Jun 2013 14:21:33 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id e12so8744491vbg.16 for ; Mon, 24 Jun 2013 14:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gtVW4vCEVcRW2wBmGLbLgSv2msSNjRYmirp4n+cJSDY=; b=AiMmUy1sN1joMRdxqjMYfpYBIJttE18lIGXYBp5nVipK1QYOgAQsnfe9SeA/B/34Tr Q/VIsEt0OYai4e+lVQ/XJTg8yMXjBH75lubIDMXuL3Uq22SKAU1rab9cCQbNdd6mzqFP KwC5ttvpspuucE7KgnipmBc9AouyokyYulsMxoX1iZGLnfirJg5BKpXUvAPYU5y3zplb btPa+z+nxyU19Sa3sO8YE5sjqVy2SLrtqeSaw3hueUp1rloUtAo3SXeSo4dobIEO4pHs gj8ccHVW9yEn5bodiagHZWktVlnOaLs7T6hSqBWL0SGYEV/gsRZhf/nB0e8KYXiSwR6H eDxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=gtVW4vCEVcRW2wBmGLbLgSv2msSNjRYmirp4n+cJSDY=; b=ive3MABq3ZwU36Axhwx5HngoFlje8uVwB2oyccVLBoLBXPFmKygso3Yrpo7pPpPn9I S/LZaLdtHr4b6F+2TDC+67VdqVHwvqC7fRH2FutyP1fCsJItZr3n5jvRCUqD43AScG8d Lu/uyU6lQ4rlU7dG9gNROq25OIB3JqHx5pQ45pOZssnOkjNoBztyQzwlXa/AUFY1/JeU V6VRMrgJIRw2bQdlFWO33/eknbnMJ+YeRdLCdv07lF9NNKI3kpnTp8bxsxaE5xfix4Ws KNswCCmfX5rix7dcPraUZvbWHFlSe5ZdGROqg19QTwegXJW6Q1atPiQgvw6m5CKYDYt1 wTKw== MIME-Version: 1.0 X-Received: by 10.52.228.226 with SMTP id sl2mr10687672vdc.52.1372108889906; Mon, 24 Jun 2013 14:21:29 -0700 (PDT) Received: by 10.220.3.73 with HTTP; Mon, 24 Jun 2013 14:21:29 -0700 (PDT) In-Reply-To: <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> Date: Mon, 24 Jun 2013 14:21:29 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmpzGY6r/eKbPQUDpORy0l+k6EBAH8JdQmGFuYLqZSn2qFWQUTDEVdIJZQ3oWIX7GkdfhGqyX4/5cJMe4qxDFUoGAGbMnSpMOxkqtGGH2sqBAFqN2VITJANH8zmamfeZEnICEgT2auV+UY2iHJMtYuazazL8oc2U2JuGyeq+kwt/h3SQ2q52pnWUHswRrnrxKxiswzP Cc: David Matson , "websec@ietf.org" Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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: Mon, 24 Jun 2013 21:21:35 -0000 On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir wrote: > As far as I know, this idea was not discussed before. If we were to do this, > the proper URI for this would be some kind of RFC 5785 URI like > "/.well-known/pins" or "/.well-known/hpkp". I think it has been brought up in another forum; Ryan Sleevi will know better than I. > Looking at the examples in the key-pinning draft, an HPKP header using SHA-1 > takes just under 120 bytes. Compared to some of the stuff that gets sent in > HTTP headers (I'm looking at you, user-agent) this is pretty tame. Not to mention the body. :) > Moreover, > the key-pinning header does not have to be sent in every response - it's > enough to send it once per full TLS handshake. Actually, we ended up changing that, a while back now. From the current draft: """ 2.2.1. HTTP-over-Secure-Transport Request Type When replying to an HTTP request that was conveyed over a secure transport, a Pinned Host SHOULD include in its response exactly one PKP header field that MUST satisfy the grammar specified above in Section 2.1. If the Pinned Host does not include the PKP header field, and if the connection passed Pin Validation, UAs MUST treat the host as if it had set its max-age to 0 (see Section 2.3.1). """ In most realistic web application scenarios, even sending an HPKP header on every response is likely to have negligible impact on overall application performance. Almost every web application I have seen has much lower-hanging fruit for performance optimization. From palmer@google.com Mon Jun 24 14:29:40 2013 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 B7E9911E818B for ; Mon, 24 Jun 2013 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 3P6QiFFayJqb for ; Mon, 24 Jun 2013 14:29:40 -0700 (PDT) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ECBE111E818F for ; Mon, 24 Jun 2013 14:29:36 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e15so8795432vbg.3 for ; Mon, 24 Jun 2013 14:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SEwP0HirmNb4Uw25sMF9x5OXyYybvahbeufiBZsUqu0=; b=H2UG0kVFtDmSE14fGbMwp5V4xb99kFVwe5HLHICDiY6k8AQKDMmiQQL8qllj3mnze+ ZCtyrnydWtVRPjE1zFtQweI4x0NoUtd+Ft0WMW6Vo3jACy/W7P/6sN7u2Us3YiA5MLaG DnaCTMpNmm64dFz1UdZIRI25v73IKvqN2hI2pGMSUo0Q1np0FYKGr7BuimYWpYq+Ir0P LNHuhk0PXLrnGwDDQmfgc1dYiqXWeuTNwsyI8v621//vISEazLwVA7fbf5/BybZvr+dX nOLhOtmQqxk3M0cf8B3w+MPsnKL6f8PSBFnzJI1lwR2UApS1WGRfrDc7hEj1UvNq2oR9 PW5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=SEwP0HirmNb4Uw25sMF9x5OXyYybvahbeufiBZsUqu0=; b=NSUVUieTmuOHO6dDHuvPyFVfK5zRTNzFmM33xg5RNT3kxOc/Lk3muNu2Cyz5MPB/cz luakcah3tfjbVAA7MRzPnYj9ahW64OXP4D/AcKjEZhyQK8C5XpCMlptTYbTtBKVMpjLn WwX62V0Ieg+pNPB1UHg1dbSa9pUp9dF2d/S6eMQfc1tw3+hMB8xFSaNN3HHdsxiESGPi N0jnm/cccY5sxgR3mUdEzUkZRuxBcmYu4I3HGmpcERhb2xrkWxG9XGENEEEl4D7Iu2Ts 8KBF8NaOoGhRWI2KwuKf9pIfPxw32ZGYMei+Z3fTkfW68P03eokItRDKCefI10ufg3xC VhDg== MIME-Version: 1.0 X-Received: by 10.52.228.226 with SMTP id sl2mr10698745vdc.52.1372109376402; Mon, 24 Jun 2013 14:29:36 -0700 (PDT) Received: by 10.220.3.73 with HTTP; Mon, 24 Jun 2013 14:29:36 -0700 (PDT) In-Reply-To: References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> Date: Mon, 24 Jun 2013 14:29:36 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQneGm1q/WR54lwoRy37SDQh1F14zdvp45Eq8Ksx8kmhYZhVrabi8WeeqlfRxaSRJSe9Cq9ed7t81yO3+DG2YBmqfrssr1a/tnpzxY3ZuImFQFijOoXgJq6Pn8W8maMgxj3wxuFB/3GRfk2b/Eh5CL7A5YAy7/xuie1L0JdQguDz91/A4lq1qZToHYlnDpnhtT1MwB3d Cc: David Matson , "websec@ietf.org" Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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: Mon, 24 Jun 2013 21:29:40 -0000 If you haven't already, I'd urge everyone to take pcaps of a web session to their bank or to their web mail provider or whatever. I think you'll quickly see that even a large HPKP header, say 500 bytes, is not going to be the thing that makes web traffic bloated. (Sometimes, the certificate chains themselves outweigh the pins =E2=80=94 a= nd that traffic occurs before the crucial point of widening the TCP window! Whereas HTTP headers most likely occur afterward.) Also, at one point somebody raised an idea of saying you could pin to a set of keys =E2=80=94 say, Symantec or StartCom's issuing certs =E2=80=94= with a single directive. Something like: Public-Key-Pins: max-age=3D...; pin-set: symantec; includeSubDomains There'd need to be some kind of registry for the names of sets, of course, which is complicated. And how do UAs learn of updates to the sets, and so on. It's a nice idea that would improve on-the-wire size in bytes, and also enable web application providers to pin more easily. If there is demand, perhaps we could create such an extension to HPKP/TACK/et c. But I don't think it should be a blocker for this I-D. From tobias.gondrom@gondrom.org Mon Jun 24 18:30:30 2013 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 A5E7A21E814A for ; Mon, 24 Jun 2013 18:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=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 NiabyMeD2z79 for ; Mon, 24 Jun 2013 18:30:26 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id D0C4921E812C for ; Mon, 24 Jun 2013 18:30:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=uAjOMAc9/TUc0NJln/sObNrmHnecI3V9zGauQGJyg+qC5Zr+ggfE6dgMiz2UPxM83TSTf2/9clsrag+QGf5l+KazIn+BlSdTVVHQUHVxAX1FRiHv1CqMPCYo/nfk08y1; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 32482 invoked from network); 25 Jun 2013 03:30:23 +0200 Received: from 191.82.247.60.static.bjtelecom.net (HELO ?172.31.8.200?) (60.247.82.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 25 Jun 2013 03:30:23 +0200 Message-ID: <51C8F2AE.5040101@gondrom.org> Date: Tue, 25 Jun 2013 09:30:22 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: trevp@trevp.net References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> <51C7EECC.3020108@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------020201030501090708080402" Cc: websec@ietf.org, dmatson@microsoft.com Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 25 Jun 2013 01:30:30 -0000 This is a multi-part message in MIME format. --------------020201030501090708080402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 25/06/13 05:06, Trevor Perrin wrote: > > On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom > > wrote: > > > On 24/06/13 09:13, Trevor Perrin wrote: >> Depends on the number of pinned keys. Chrome's existing preloads >> [1] have 9, 5, 19, 36, 2, and 2 keys. That's a mean of 12, which >> would be >500 bytes with SHA256. >> > IMHO the expected session will be 2 keys with SHA-160 to SHA-512 > per host. > > > I don't know what the common case would be. The numbers I cited are > from the Chromium's preloaded key pins: > > https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json > > Note that a commercial CA might have several subordinate and root > certificates, with different keys. To pin yourself to this CA, you > may need to list several of these keys, and to be conservative a site > might pin multiple CAs. > > (Are you suggesting that sites would list both a SHA256 and SHA1 hash > for each pinned key? That seems unnecessary.) No I am not suggesting to send both hashes. That would be unnecessary and of very use. So that means: 2 keys (the main key and the backup key) with one hash each (SHA-160 OR SHA-256 OR SHA-512 OR ...) Looking back at the discussions my perception is that in the case of many (though not all) implementations the server will have only one key active at the point of entry and then use a reverse proxy. (with a caveat: I remember one large bank that seems due to whatever historic reason is actually using different certificates for every singly server instance, which obviously could then go into the 100s or 1000s.... - but I don't worry about this too much as AFAIK this was more duet to misunderstanding regulation and a stupid architecture - so will just need to clean up before they can go to pinning - which is fair in my eyes.) > > > > Just for my understanding: Do you think this will create too much > header overhead and there want to the reference to the pin? > > > I don't know how much data a site could add to every HTTP Response > before it starts becoming a problem. But that's the issue David raised. > > If it's a real problem, the idea of putting pin assertions in, say, a > JSON file at a "well-known" URI seems reasonable. E.g.: > > http://www.example.com/.well-known/public-key-pins I see. From my humble experience, I would agree with Chris (in his later email) and don't see a performance problem with this. So I don't think we need to consider the URI option. Best regards, Tobias > > > Trevor --------------020201030501090708080402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 25/06/13 05:06, Trevor Perrin wrote:

On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

On 24/06/13 09:13, Trevor Perrin wrote:
Depends on the number of pinned keys.  Chrome's existing preloads [1] have 9, 5, 19, 36, 2, and 2 keys.  That's a mean of 12, which would be >500 bytes with SHA256.

IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per host.

I don't know what the common case would be.  The numbers I cited are from the Chromium's preloaded key pins:


Note that a commercial CA might have several subordinate and root certificates, with different keys.  To pin yourself to this CA, you may need to list several of these keys, and to be conservative a site might pin multiple CAs.

(Are you suggesting that sites would list both a SHA256 and SHA1 hash for each pinned key?  That seems unnecessary.)

No I am not suggesting to send both hashes. That would be unnecessary and of very use.
So that means: 2 keys (the main key and the backup key) with one hash each (SHA-160 OR SHA-256 OR SHA-512 OR ...)
Looking back at the discussions my perception is that in the case of many (though not all) implementations the server will have only one key active at the point of entry and then use a reverse proxy.
(with a caveat: I remember one large bank that seems due to whatever historic reason is actually using different certificates for every singly server instance, which obviously could then go into the 100s or 1000s.... - but I don't worry about this too much as AFAIK this was more duet to misunderstanding regulation and a stupid architecture - so will just need to clean up before they can go to pinning - which is fair in my eyes.)




 
Just for my understanding: Do you think this will create too much header overhead and there want to the reference to the pin?

I don't know how much data a site could add to every HTTP Response before it starts becoming a problem.  But that's the issue David raised.  

If it's a real problem, the idea of putting pin assertions in, say, a JSON file at a "well-known" URI seems reasonable.  E.g.:


I see. From my humble experience, I would agree with Chris (in his later email) and don't see a performance problem with this. So I don't think we need to consider the URI option.

Best regards, Tobias




Trevor

--------------020201030501090708080402-- From trevp@trevp.net Mon Jun 24 19:23:51 2013 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 55B4111E80F4 for ; Mon, 24 Jun 2013 19:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=1.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 RjfcZwEYQKYH for ; Mon, 24 Jun 2013 19:23:46 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 02F9C21E8063 for ; Mon, 24 Jun 2013 19:23:43 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so361885wid.5 for ; Mon, 24 Jun 2013 19:23:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=rPKwX6Yp+JqPL0evUvY+grTQmNiglg7ZMI3xyxLpjBA=; b=bOAvOi2ltMjfLhaQDsk/Dl5TIP9/6+XSQ3yiMgcxm+B9BL3EVL5nXhJdvteFH+sIxD Mp5DbI2YFBbB0Tk/UjL8MSKKhau59FCrCGZ6xeNNZBhG9x23xuN3ZPfmEQ7ud8VZBhAa G+D+yjIO6UrXBwLrqnA6c+c0WXsENuPSEFW9PcEjDSq862MivP5EisNzn5IvfpYOu0Ja MoUIMIDb3aq7rqLX03wwWPoeQAb+QG5lmds4LAHmex329BO0rBvydIvUYsPguGlugpJ3 NJtF0NboCq46Xt044WoSjwu+USR53y62iioTAnOTxDcn57Xg0yukFj07PuQyXuDwZiWK YqLw== MIME-Version: 1.0 X-Received: by 10.194.83.195 with SMTP id s3mr18696270wjy.82.1372127023121; Mon, 24 Jun 2013 19:23:43 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 24 Jun 2013 19:23:43 -0700 (PDT) X-Originating-IP: [12.27.66.5] In-Reply-To: <51C8F2AE.5040101@gondrom.org> References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> <51C7EECC.3020108@gondrom.org> <51C8F2AE.5040101@gondrom.org> Date: Mon, 24 Jun 2013 19:23:43 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: multipart/alternative; boundary=047d7bdc7c90ccd8f204dff13716 X-Gm-Message-State: ALoCoQki8kbsf8Eyv/yIwreJMIDZaAAKXX78hrUNR/zN7SV5CfhIFqSLUe9F3zHdpTdP8/WeAi0D Cc: IETF WebSec WG , David Matson Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 25 Jun 2013 02:23:51 -0000 --047d7bdc7c90ccd8f204dff13716 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 6:30 PM, Tobias Gondrom wrote: > On 25/06/13 05:06, Trevor Perrin wrote: > > > On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom < > tobias.gondrom@gondrom.org> wrote: > >> >> On 24/06/13 09:13, Trevor Perrin wrote: >> >> Depends on the number of pinned keys. Chrome's existing preloads [1] >> have 9, 5, 19, 36, 2, and 2 keys. That's a mean of 12, which would be >500 >> bytes with SHA256. >> >> IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per >> host. >> > > I don't know what the common case would be. The numbers I cited are > from the Chromium's preloaded key pins: > > > https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json > > Note that a commercial CA might have several subordinate and root > certificates, with different keys. To pin yourself to this CA, you may > need to list several of these keys, and to be conservative a site might pin > multiple CAs. > > (Are you suggesting that sites would list both a SHA256 and SHA1 hash > for each pinned key? That seems unnecessary.) > > > No I am not suggesting to send both hashes. That would be unnecessary and > of very use. > So that means: 2 keys (the main key and the backup key) with one hash each > (SHA-160 OR SHA-256 OR SHA-512 OR ...) > You're ignoring pinning to CAs, which is a major use case for HPKP. > I remember one large bank that seems due to whatever historic reason is > actually using different certificates for every singly server instance, > which obviously could then go into the 100s or 1000s.... - but I don't > worry about this too much as AFAIK this was more duet to misunderstanding > regulation and a stupid architecture - so will just need to clean up before > they can go to pinning - which is fair in my eyes.) > A single hostname could be using different SSL keys at the same time for various reasons, e.g. in-progress key changes, geographically distributed servers, HSM limitations, CDNs, etc. So you can't ignore this case quite so easily. It's one of the reasons I prefer pinning signing keys to pinning SSL keys. I see. From my humble experience, I would agree with Chris (in his later > email) and don't see a performance problem with this. So I don't think we > need to consider the URI option. > OK. Trevor --047d7bdc7c90ccd8f204dff13716 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Mon, Jun 24, 2013 at 6:30 PM, Tobias Gondrom <tobias.gondrom@g= ondrom.org> wrote:
=20 =20 =20
On 25/06/13 05:06, Trevor Perrin wrote:

On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

On 24/06/13 09:13, Trevor Perrin wrote:
Depends on the number of pinned keys. =A0Chrome's existing preloads [1] have 9,= 5, 19, 36, 2, and 2 keys. =A0That's a mean o= f 12, which would be >500 bytes with SHA256.

IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per host.

I don't know what the common case would be. =A0The numbers I cited are from the Chromium's preloaded key pins:


Note that a commercial CA might have several subordinate and root certificates, with different keys. =A0To pin yourself to this CA, you may need to list several of these keys, and to be conservative a site might pin multiple CAs.

(Are you suggesting that sites would list both a SHA256 and SHA1 hash for each pinned key? =A0That seems unnecessary.)

No I am not suggesting to send both hashes. That would be unnecessary and of very use.
So that means: 2 keys (the main key and the backup key) with one hash each (SHA-160 OR SHA-256 OR SHA-512 OR ...)
=

You're ignoring pinning to CAs, which is a major us= e case for HPKP.

=A0
=A0I remember one large bank that= seems due to whatever historic reason is actually using different certificates for every singly server instance, which obviously could then go into the 100s or 1000s.... - but I don't worry about this too much as AFAIK this was more duet to misunderstanding regulation and a stupid architecture - so will just need to clean up before they can go to pinning - which is fair in my eyes.)

<= div>
A single hostname could be using different SSL keys at the same ti= me for various reasons, e.g. in-progress key changes, geographically distri= buted servers, HSM limitations, CDNs, etc.

So you can't ignore this case quite so easily. =A0I= t's one of the reasons I prefer pinning signing keys to pinning SSL key= s.


I see. From my humble experience,= I would agree with Chris (in his later email) and don't see a performance problem with this. So I don't think we need to consider the URI option.

OK.


=
Trevor
--047d7bdc7c90ccd8f204dff13716-- From julian.reschke@gmx.de Tue Jun 25 01:49:56 2013 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 C7AEA21F9E71 for ; Tue, 25 Jun 2013 01:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 c7mYitmR99Lo for ; Tue, 25 Jun 2013 01:49:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8E46D21F915B for ; Tue, 25 Jun 2013 01:49:51 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MN7As-1UtZjv3uLw-006go4 for ; Tue, 25 Jun 2013 10:49:47 +0200 Received: (qmail invoked by alias); 25 Jun 2013 08:49:47 -0000 Received: from p5DD965C6.dip0.t-ipconnect.de (EHLO [192.168.1.103]) [93.217.101.198] by mail.gmx.net (mp033) with SMTP; 25 Jun 2013 10:49:47 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+5YP4UxiG5oJ1BuBBzPw9iXjVGGdL5dEtEpSGjns KSEoKGLPbp1hba Message-ID: <51C959A6.4060208@gmx.de> Date: Tue, 25 Jun 2013 10:49:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tobias Gondrom References: <509BE1F0.4010701@KingsMountain.com> <509C07EB.5090806@gondrom.org> <51C53FCD.4000306@gondrom.org> In-Reply-To: <51C53FCD.4000306@gondrom.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] WGLC feedback for X-Frame-Options 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, 25 Jun 2013 08:49:56 -0000 On 2013-06-22 08:10, Tobias Gondrom wrote: > Dear websec fellows, > > I just uploaded the latest version of XFO including the WGLC feedback I > received. > (Apologies for the delay, this happened due to some personal difficulties.) > > I hope the new revision is satisfactory and we can go to IETF LC. > The changes were only very small: > - the "deprecation of X-" comment is in the introduction section incl. > reference to 6648 > - and I removed the section 2.2.2 as recommended by Julian. > > Best regards, Tobias Thanks. A few nits: In 2.2, I'd replace The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header is: by The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header field value is: (emphasis on *value*) (Also fix remaining instances of "header" to say "header field" for consistency). In the appendices, please fix the W3C references to include the author names and the publication status, see and . Best regards, Julian From trevp@trevp.net Tue Jun 25 17:13:57 2013 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 0460B21E80EC for ; Tue, 25 Jun 2013 17:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 IYwNYFBd6H3T for ; Tue, 25 Jun 2013 17:13:52 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8721E80C9 for ; Tue, 25 Jun 2013 17:13:51 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so9902668wev.14 for ; Tue, 25 Jun 2013 17:13:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=t2vha9/GdP8V0cvpSaqtviVIQyXRqL6Pblte/bcqwi4=; b=NloUGVcriDoEbsMlxiLFHmYESEEC5IGwzcCuYX3ozDba68cO+xbFilbPwI0T2ICzaz NG/g7DcbN1f9/vCpJfOxRmqWkIw0tmXziTj1fUiGhLt3L0LO32q3nvwulD3MmzirYrZV 3enPjmwt3lAX/B5vrg7IasOWF4aqhri8YtuIH4uL9EzGdVB4ZUgmqSHLxR2kp1SzH/kd Yfr2rPlfw7A/k90usSiZtSEpjFhd/Akbs54Y+EhtbUpYqMNEpgVnobqE5Hjt0SJ/PqiS UcqaNGzrL9is3YS/x4u2rDl5AlFF+GBVsgPFhrloAkmndNro5nVkJrdwrjX5/zANoiuW Cuvw== MIME-Version: 1.0 X-Received: by 10.194.93.74 with SMTP id cs10mr1041130wjb.9.1372205629365; Tue, 25 Jun 2013 17:13:49 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Tue, 25 Jun 2013 17:13:49 -0700 (PDT) X-Originating-IP: [166.137.212.54] In-Reply-To: References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> Date: Tue, 25 Jun 2013 17:13:49 -0700 Message-ID: From: Trevor Perrin To: Chris Palmer Content-Type: multipart/alternative; boundary=047d7bf0c86c18f20f04e00385fe X-Gm-Message-State: ALoCoQn5NXuzNjEFoPkJq11d5ajXWiR4Sjcli1Y3auU4Vpxdl7w0S/+4K6hydd1A+NiluZVSUvmk Cc: "websec@ietf.org" , David Matson Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 26 Jun 2013 00:13:57 -0000 --047d7bf0c86c18f20f04e00385fe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jun 24, 2013 at 2:29 PM, Chris Palmer wrote: > If you haven't already, I'd urge everyone to take pcaps of a web > session to their bank or to their web mail provider or whatever. I > think you'll quickly see that even a large HPKP header, say 500 bytes, > is not going to be the thing that makes web traffic bloated. > (Sometimes, the certificate chains themselves outweigh the pins =97 and > that traffic occurs before the crucial point of widening the TCP > window! Whereas HTTP headers most likely occur afterward.) > > Also, at one point somebody raised an idea of saying you could pin to > a set of keys =97 say, Symantec or StartCom's issuing certs =97 with a > single directive. Something like: > > Public-Key-Pins: max-age=3D...; pin-set: symantec; includeSubDomains > I like that! It would be a lot easier to list your pin as "symantec,comodo,godaddy" than the equivalent set of keys, particularly since keys per CA change over time. > There'd need to be some kind of registry for the names of sets, of > course, which is complicated. And how do UAs learn of updates to the > sets, and so on. It seems like a registry IANA could maintain. Any CA in a major root store could register their name and a URL where they keep the list of keys necessary to pin them. Browser vendors will download these key lists (over pinned HTTPS, of course) and push updates to browsers on some regular basis. Seems pretty workable... > It's a nice idea that would improve on-the-wire size > in bytes, and also enable web application providers to pin more > easily. If there is demand, perhaps we could create such an extension > to HPKP/TACK/et c. But I don't think it should be a blocker for this > I-D. > TACK wouldn't do this, we're focused on self-chosen signing keys. But it would be a great v2 feature for HPKP, in my opinion... Trevor --047d7bf0c86c18f20f04e00385fe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= On Mon, Jun 24, 2013 at 2:29 PM, Chris Palmer <palmer@google.com> wrote:
If you haven't already, I'd urge everyone to take = pcaps of a web
session to their bank or to their web mail provider or whatever. I
think you'll quickly see that even a large HPKP header, say 500 bytes,<= br> is not going to be the thing that makes web traffic bloated.
(Sometimes, the certificate chains themselves outweigh the pins =97 and
that traffic occurs before the crucial point of widening the TCP
window! Whereas HTTP headers most likely occur afterward.)

Also, at one point somebody raised an idea of saying you could pin to
a set of keys =97 say, Symantec or StartCom's issuing certs =97 with a<= br> single directive. Something like:

=A0 =A0 Public-Key-Pins: max-age=3D...; pin-set: symantec; includeSubDomain= s

I like that! =A0It would be a l= ot easier to list your pin as "symantec,comodo,godaddy" than the = equivalent set of keys, particularly since keys per CA change over time.


=A0
There'd need to be some kind of registry for the names of sets, of
course, which is complicated. And how do UAs learn of updates to the
sets, and so on.

It seems like a regis= try IANA could maintain. =A0Any CA in a major root store could register the= ir name and a URL where they keep the list of keys necessary to pin them. = =A0Browser vendors will download these key lists (over pinned HTTPS, of cou= rse) and push updates to browsers on some regular basis. =A0

Seems pretty workable...

=A0
It's a nice idea that would improve on-the-wire size
in bytes, and also enable web application providers to pin more
easily. If there is demand, perhaps we could create such an extension
to HPKP/TACK/et c. But I don't think it should be a blocker for this I-D.

TACK wouldn't do this, w= e're focused on self-chosen signing keys. =A0But it would be a great v2= feature for HPKP, in my opinion...


Trevor
=A0=A0
--047d7bf0c86c18f20f04e00385fe-- From tobias.gondrom@gondrom.org Fri Jun 28 00:23:27 2013 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 B88A821F9C19 for ; Fri, 28 Jun 2013 00:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.253 X-Spam-Level: X-Spam-Status: No, score=-92.253 tagged_above=-999 required=5 tests=[FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.935, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=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 t1uGMh2ijq7p for ; Fri, 28 Jun 2013 00:23:18 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 05E4E21F9C24 for ; Fri, 28 Jun 2013 00:23:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=PWJes2ppy4DIaDa7jEiz4G6rOCjGJqrODfgqZnupj8agT8goikMucthVXsSLTuqfyFgBBbR8p8sBs1LTPoiQdfiSwSf8uWreXZ+MGr0ejyOAZfkvUGmh52QSVsD9MY42; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 30489 invoked from network); 28 Jun 2013 09:23:10 +0200 Received: from unknown (HELO ?172.31.9.119?) (222.220.35.78) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Jun 2013 09:23:09 +0200 Message-ID: <51CD39D9.1040801@gondrom.org> Date: Fri, 28 Jun 2013 15:23:05 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: trevp@trevp.net References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------080802030203090105040409" Cc: dmatson@microsoft.com, websec@ietf.org Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 28 Jun 2013 07:23:27 -0000 This is a multi-part message in MIME format. --------------080802030203090105040409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 26/06/13 08:13, Trevor Perrin wrote: > > On Mon, Jun 24, 2013 at 2:29 PM, Chris Palmer > wrote: > > If you haven't already, I'd urge everyone to take pcaps of a web > session to their bank or to their web mail provider or whatever. I > think you'll quickly see that even a large HPKP header, say 500 bytes, > is not going to be the thing that makes web traffic bloated. > (Sometimes, the certificate chains themselves outweigh the pins > --- and > that traffic occurs before the crucial point of widening the TCP > window! Whereas HTTP headers most likely occur afterward.) > > Also, at one point somebody raised an idea of saying you could pin to > a set of keys --- say, Symantec or StartCom's issuing certs --- with a > single directive. Something like: > > Public-Key-Pins: max-age=...; pin-set: symantec; includeSubDomains > > > I like that! It would be a lot easier to list your pin as > "symantec,comodo,godaddy" than the equivalent set of keys, > particularly since keys per CA change over time. > > > > > There'd need to be some kind of registry for the names of sets, of > course, which is complicated. And how do UAs learn of updates to the > sets, and so on. > > > It seems like a registry IANA could maintain. Any CA in a major root > store could register their name and a URL where they keep the list of > keys necessary to pin them. Browser vendors will download these key > lists (over pinned HTTPS, of course) and push updates to browsers on > some regular basis. > > Seems pretty workable... Actually it's a little it more complicated. This list seems pretty dynamic and may also need authentication and authorization before you add more keys to sets? Both things that IANA would not be very good for... Or am I missing something and this is easier? > > > It's a nice idea that would improve on-the-wire size > in bytes, and also enable web application providers to pin more > easily. If there is demand, perhaps we could create such an extension > to HPKP/TACK/et c. But I don't think it should be a blocker for this > I-D. > > > TACK wouldn't do this, we're focused on self-chosen signing keys. But > it would be a great v2 feature for HPKP, in my opinion... > > > Trevor > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------080802030203090105040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
<no hats>

On 26/06/13 08:13, Trevor Perrin wrote:

On Mon, Jun 24, 2013 at 2:29 PM, Chris Palmer <palmer@google.com> wrote:
If you haven't already, I'd urge everyone to take pcaps of a web
session to their bank or to their web mail provider or whatever. I
think you'll quickly see that even a large HPKP header, say 500 bytes,
is not going to be the thing that makes web traffic bloated.
(Sometimes, the certificate chains themselves outweigh the pins — and
that traffic occurs before the crucial point of widening the TCP
window! Whereas HTTP headers most likely occur afterward.)

Also, at one point somebody raised an idea of saying you could pin to
a set of keys — say, Symantec or StartCom's issuing certs — with a
single directive. Something like:

    Public-Key-Pins: max-age=...; pin-set: symantec; includeSubDomains

I like that!  It would be a lot easier to list your pin as "symantec,comodo,godaddy" than the equivalent set of keys, particularly since keys per CA change over time.


 
There'd need to be some kind of registry for the names of sets, of
course, which is complicated. And how do UAs learn of updates to the
sets, and so on.

It seems like a registry IANA could maintain.  Any CA in a major root store could register their name and a URL where they keep the list of keys necessary to pin them.  Browser vendors will download these key lists (over pinned HTTPS, of course) and push updates to browsers on some regular basis.  

Seems pretty workable...

Actually it's a little it more complicated. This list seems pretty dynamic and may also need authentication and authorization before you add more keys to sets?
Both things that IANA would not be very good for...
Or am I missing something and this is easier?


 
It's a nice idea that would improve on-the-wire size
in bytes, and also enable web application providers to pin more
easily. If there is demand, perhaps we could create such an extension
to HPKP/TACK/et c. But I don't think it should be a blocker for this
I-D.

TACK wouldn't do this, we're focused on self-chosen signing keys.  But it would be a great v2 feature for HPKP, in my opinion...


Trevor
  


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

--------------080802030203090105040409-- From internet-drafts@ietf.org Fri Jun 28 01:19:20 2013 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 315D421F9C0D; Fri, 28 Jun 2013 01:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-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 ORSbBSHBM8R2; Fri, 28 Jun 2013 01:19:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E466A21F9D27; Fri, 28 Jun 2013 01:19:08 -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: 4.51.p2 Message-ID: <20130628081908.31616.45436.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 01:19:08 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-04.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, 28 Jun 2013 08:19:20 -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 IETF. Title : HTTP Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-04.txt Pages : 11 Date : 2013-06-28 Abstract: To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tobias.gondrom@gondrom.org Fri Jun 28 01:19:52 2013 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 EA1ED21F9D5B for ; Fri, 28 Jun 2013 01:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.254 X-Spam-Level: X-Spam-Status: No, score=-92.254 tagged_above=-999 required=5 tests=[AWL=0.000, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.935, HELO_EQ_DE=0.35, RDNS_DYNAMIC=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 OE7bqvsceXvC for ; Fri, 28 Jun 2013 01:19:40 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36A21F9D4F for ; Fri, 28 Jun 2013 01:19:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=u7nI7EmspSuxrbRkt4cz0WBxoaqNFJt4KzqLT1Cxlrb7nfMTekVGXMrArzzIKbSQsBW6gd0QbaMf8CIgNIg+taXqFYoNWMDddmuA+RgpoZvgUhVEkbZJXptBf57PQeh+; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 31884 invoked from network); 28 Jun 2013 10:19:23 +0200 Received: from unknown (HELO ?172.31.9.119?) (222.220.35.78) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Jun 2013 10:19:22 +0200 Message-ID: <51CD4707.3090600@gondrom.org> Date: Fri, 28 Jun 2013 16:19:19 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: julian.reschke@gmx.de References: <509BE1F0.4010701@KingsMountain.com> <509C07EB.5090806@gondrom.org> <51C53FCD.4000306@gondrom.org> <51C959A6.4060208@gmx.de> In-Reply-To: <51C959A6.4060208@gmx.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] WGLC feedback for X-Frame-Options 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, 28 Jun 2013 08:19:52 -0000 Hi Julian, thanks a lot! Just uploaded the revised version correcting your two nits. Best regards, Tobias On 25/06/13 16:49, Julian Reschke wrote: > On 2013-06-22 08:10, Tobias Gondrom wrote: >> Dear websec fellows, >> >> I just uploaded the latest version of XFO including the WGLC feedback I >> received. >> (Apologies for the delay, this happened due to some personal >> difficulties.) >> >> I hope the new revision is satisfactory and we can go to IETF LC. >> The changes were only very small: >> - the "deprecation of X-" comment is in the introduction section incl. >> reference to 6648 >> - and I removed the section 2.2.2 as recommended by Julian. >> >> Best regards, Tobias > > Thanks. > > A few nits: > > In 2.2, I'd replace > > The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header is: > > by > > The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header field > value is: > > (emphasis on *value*) > > (Also fix remaining instances of "header" to say "header field" for > consistency). Fixed the existing instance. But I went through all the other instances and did not fix the remaining instances, because most of them were semantically referring to the header itself and not the specific field value and secondly some of them were using the term "header field" which I believe captures the semantic of the particular sentences appropriately. But let me know which instance you think should be corrected as well. > > In the appendices, please fix the W3C references to include the author > names and the publication status, see > > and > . Thanks. I corrected the refs. And I guess we will also revisit the reference links before publication in case there are any updates. Best regards, Tobias > > Best regards, Julian From hallam@gmail.com Fri Jun 28 08:00:58 2013 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 BF45121F9B99 for ; Fri, 28 Jun 2013 08:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 ZF-JzbDmy9Z5 for ; Fri, 28 Jun 2013 08:00:58 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8921F9BF8 for ; Fri, 28 Jun 2013 08:00:57 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so1737713wgg.22 for ; Fri, 28 Jun 2013 08:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q7438EHSEzAnLIl6Je8jlxL/ejWsGFauBoYQZP/t9C4=; b=pi5zu0k5Z8pxinljMLMLOh9CBBYd4Eqzh8+wXxOftwcicp7Q2YtJvS6dYP1pvtAPWm mg3k0siXfP8fPpmmB58Q4JdQm3RY3vcy6YhXDHuqAhHee1K7CUhaM8fOl+XpI5Aznsmg SzeOeCodFuVx0nGd0Yaq6z3BstbPsdp/iygpJ+5xEe81A5ckfX+qRUDjJwcxM0BP1dvf L9zXIjfr1VFisVIZGtMzWou7fSnwFbGfQPb5ufNKgDxnov8lhKSPL9WQhW7bfr8vBLSR fdCL+MipU/PP/0oavAAlwbvInxqGoNLrpQU66iVSXrMmE9K+z2YCTHGpJB95lISb5lHa WjbQ== MIME-Version: 1.0 X-Received: by 10.180.187.136 with SMTP id fs8mr2717900wic.18.1372431656755; Fri, 28 Jun 2013 08:00:56 -0700 (PDT) Received: by 10.194.54.10 with HTTP; Fri, 28 Jun 2013 08:00:56 -0700 (PDT) In-Reply-To: <51CD39D9.1040801@gondrom.org> References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> <51CD39D9.1040801@gondrom.org> Date: Fri, 28 Jun 2013 11:00:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Tobias Gondrom Content-Type: multipart/alternative; boundary=001a11c381ec612d4b04e03825a3 Cc: dmatson@microsoft.com, websec Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 28 Jun 2013 15:00:58 -0000 --001a11c381ec612d4b04e03825a3 Content-Type: text/plain; charset=ISO-8859-1 CAA faced the problem of identifying a CA. During the evolution of the draft we went through pretty much every scheme mentioned in this thread. In the end we decided to go with a domain name that is asserted for that purpose by the CA. So symantec.com / comodo.com / etc. At this point the main reason Cert Pinning should follow the same route is that it is already in use and absent a good reason, TLS CA pinning should follow the existing approach. This makes it more likely that we will get the support embedded into platforms accurately. The main reason for going with domain names in CAA was that it means there is no need to create a new registry. That is important as it feels wrong to have an IETF spec differentiate between commercial and private CAs. It feels even wronger to have IANA managing registries of commercial providers. There are good business reasons for the CAs to not want their business under the control of IANA and vice versa. There are several other advantages though. One is that it makes it much easier to work out how to put in mechanisms to 'unpin' since these can now key off Domain names. So hypothetically let us imagine that there was a Diginotar situation and several hundred thousand browsers are now pinned to the busted root. Ooops. One way that we could approach unpinning in this situation would be to use something involving DNSSEC Now that is not an argument for writing more code now. But putting DNS names there are at least as good as any other option but the fact that they are a discovery index provides a LOT of power that may be useful down the line. This might happen in CAA. An obvious next step for CAA is to have a cert request mechanism where the end entity looks at the CAA record to find out where it can get certs from. --001a11c381ec612d4b04e03825a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
CAA faced the problem of identifying a CA.

<= div style>During the evolution of the draft we went through pretty much eve= ry scheme mentioned in this thread. In the end we decided to go with a doma= in name that is asserted for that purpose by the CA. So symantec.com / comodo.com / etc.


At this point the main= reason Cert Pinning should follow the same route is that it is already in = use and absent a good reason, TLS CA pinning should follow the existing app= roach. This makes it more likely that we will get the support embedded into= platforms accurately.

The main reason for going with domain names= in CAA was that it means there is no need to create a new registry. That i= s important as it feels wrong to have an IETF spec differentiate between co= mmercial and private CAs. It feels even wronger to have IANA managing regis= tries of commercial providers. There are good business reasons for the CAs = to not want their business under the control of IANA and vice versa.


There are several othe= r advantages though. One is that it makes it much easier to work out how to= put in mechanisms to 'unpin' since these can now key off Domain na= mes.

So hypothetically let us imagine that there= was a Diginotar situation and several hundred thousand browsers are now pi= nned to the busted root. Ooops.

One wa= y that we could approach unpinning in this situation would be to use someth= ing involving DNSSEC


Now that is not an arg= ument for writing more code now. But putting DNS names there are at least a= s good as any other option but the fact that they are a discovery index pro= vides a LOT of power that may be useful down the line.

This might happen in CAA. An obvious next s= tep for CAA is to have a cert request mechanism where the end entity looks = at the CAA record to find out where it can get certs from.
--001a11c381ec612d4b04e03825a3-- From trevp@trevp.net Fri Jun 28 13:32:51 2013 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 9A62B21F9C8E for ; Fri, 28 Jun 2013 13:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KYggNE2CfCQz for ; Fri, 28 Jun 2013 13:32:47 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5B65421F9C8D for ; Fri, 28 Jun 2013 13:32:43 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so1547262wes.7 for ; Fri, 28 Jun 2013 13:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=cov/MbdQ/XpW9L7gSRCI++7WakU/R0GftKpKu4/pyXQ=; b=fX7/vveFEBVue7lMt2GawuhXsRJXZZiSEwVRODIpwFZxWW5zdl/dFty1EmTVcYPA32 mrcIrdvGrs2HMxqQZH281q7jcBOJ/+bsHMFR+t/Z+ohN8gxoGwWQvNimxd3rm4P1SRiw C2Dfk7e/y5lpgBsRagj9FFE6ROB1AcIXONxFP18Rxz6Qly7Xa7YT+WnTdPqaI8EqMXxX TVDboDQZwLnnIxVcsBzqdnWfnydzMqcUaV1gbdy4LpghO3IZ1e+/y0bt7+rmwSyfTZQ3 P2PUXC36Yw3SnA/x1G1gGO/VJTdE0p9VX56S04XJrysZTdyjRZ6hOzkf84swh4W12Ol6 roZA== MIME-Version: 1.0 X-Received: by 10.194.93.74 with SMTP id cs10mr11386034wjb.9.1372451563140; Fri, 28 Jun 2013 13:32:43 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Fri, 28 Jun 2013 13:32:43 -0700 (PDT) X-Originating-IP: [208.184.35.186] In-Reply-To: References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> <51CD39D9.1040801@gondrom.org> Date: Fri, 28 Jun 2013 13:32:43 -0700 Message-ID: From: Trevor Perrin To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7bf0c86ce48c2704e03cc7e2 X-Gm-Message-State: ALoCoQmYIkWxi35czrdTD+NxMPKHSkyz6rUTBJFhYergtP7A/a9knPvio1InkLA+Yi8/LRgSFq/R Cc: David Matson , websec Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 28 Jun 2013 20:32:51 -0000 --047d7bf0c86ce48c2704e03cc7e2 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 28, 2013 at 8:00 AM, Phillip Hallam-Baker wrote: > CAA faced the problem of identifying a CA. > > During the evolution of the draft we went through pretty much every scheme > mentioned in this thread. In the end we decided to go with a domain name > that is asserted for that purpose by the CA. So symantec.com / comodo.com/ etc. > Makes sense. How do CAs assert the domain name they'd like to be referenced by? Are these domain names something that could be tracked by the CAB Forum, browser root stores, or some other party? HPKP still needs to map the declared domain name to a set of keys. Perhaps CAs could maintain a list at a "well-known" URI derived from the domain name? https://comodo.com/.well-known/hpkp-keys.json Browser vendors could scan this list periodically and keep their browsers in sync with the latest keys from the major CAs. CAs would make sure to publish new keys in advance of issuing certs under a new root. If a browser encounters an unknown domain name, it could contact the URI itself, so this doesn't disenfanchise private CAs. Anyways, I rather like this. I think it's a much easier route to CA pinning than expecting websites to maintain key lists themselves. Others? Trevor --047d7bf0c86ce48c2704e03cc7e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Fri, Jun 28, 2013 at 8:00 AM, Phillip Hallam-Baker <= ;hallam@gmail.com= > wrote:
CAA faced the problem of identifying a CA= .

During the evolution of the draft we went through pretty muc= h every scheme mentioned in this thread. In the end we decided to go with a= domain name that is asserted for that purpose by the CA. So symantec.com / comodo.com / etc.

Makes sense.
<= br>
How do CAs assert the domain name they'd like to be= referenced by? =A0Are these domain names something that could be tracked b= y the CAB Forum, browser root stores, or some other party?


HPKP still needs = to map the declared domain name to a set of keys. =A0Perhaps CAs could main= tain a list at a "well-known" URI derived from the domain name?


Browser vendors could scan this list periodically and keep their br= owsers in sync with the latest keys from the major CAs. =A0CAs would make s= ure to publish new keys in advance of issuing certs under a new root.

If a browser encounters an unknown domain name, it coul= d contact the URI itself, so this doesn't disenfanchise private CAs.

Anyways, I rather like this. =A0I think it's a m= uch easier route to CA pinning than expecting websites to maintain key list= s themselves.

Others?


Trevor<= /div>

--047d7bf0c86ce48c2704e03cc7e2-- From hallam@gmail.com Sun Jun 30 10:53:30 2013 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 7A50821F8F4F for ; Sun, 30 Jun 2013 10:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 3IJ9K86m+j0d for ; Sun, 30 Jun 2013 10:53:29 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 87CFA21F8F0C for ; Sun, 30 Jun 2013 10:53:28 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so2555803wes.26 for ; Sun, 30 Jun 2013 10:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r0BUIIh3j38VJKXKByswz3h24mUciTz4dpojSpFI5+I=; b=BdTVBaa4AB4SkCPSTQfWeuWGqBHbI9vjDAk3a0oE1QDNpUZ2D3mzCKJT7+0y6MM4Ql IC7Ex76plxXhQ210d4oWl+fIexfMEhFw1JNfPzQf37XuwyafnU6vNaIB3b0xbMdzEgdJ 0fgCzNvMafGUCq5np4JPfzCplVN5G/8L017Ncd9QUBZNJQJ0AZnks1ipm1Jp1CnFmMi3 EtRXttZep3qI+HVryDVAcfR72OhsibLJrG4N+cASVOC5T42wOTPtGEhj/6CByzq1tKFr 2yhBRUA3nNpR/6RHLkF64hgGYj2if93XOLJG9INtJ1H3VlRx7+yGRK9N+DiOA0Ee0wi6 twUQ== MIME-Version: 1.0 X-Received: by 10.180.106.72 with SMTP id gs8mr9980089wib.51.1372614806503; Sun, 30 Jun 2013 10:53:26 -0700 (PDT) Received: by 10.194.125.202 with HTTP; Sun, 30 Jun 2013 10:53:26 -0700 (PDT) In-Reply-To: References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> <51CD39D9.1040801@gondrom.org> Date: Sun, 30 Jun 2013 13:53:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Trevor Perrin Content-Type: multipart/alternative; boundary=f46d044519a1f48a7b04e062c993 Cc: David Matson , websec Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06 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, 30 Jun 2013 17:53:30 -0000 --f46d044519a1f48a7b04e062c993 Content-Type: text/plain; charset=ISO-8859-1 CAA does not require a central registry. But it does require CAs to decide what DNS name(s) they are going to use. For key pinning to work the Web Browsers are going to have to track the correspondence of name to roots in any case. So it basically becomes a consistency thing. If it makes sense to do that centrally, it makes sense for CABForum to be the venue. But it is an 'emergent' process. On Fri, Jun 28, 2013 at 4:32 PM, Trevor Perrin wrote: > > On Fri, Jun 28, 2013 at 8:00 AM, Phillip Hallam-Baker wrote: > >> CAA faced the problem of identifying a CA. >> >> During the evolution of the draft we went through pretty much every >> scheme mentioned in this thread. In the end we decided to go with a domain >> name that is asserted for that purpose by the CA. So symantec.com / >> comodo.com / etc. >> > > Makes sense. > > How do CAs assert the domain name they'd like to be referenced by? Are > these domain names something that could be tracked by the CAB Forum, > browser root stores, or some other party? > > > HPKP still needs to map the declared domain name to a set of keys. > Perhaps CAs could maintain a list at a "well-known" URI derived from the > domain name? > > https://comodo.com/.well-known/hpkp-keys.json > > Browser vendors could scan this list periodically and keep their browsers > in sync with the latest keys from the major CAs. CAs would make sure to > publish new keys in advance of issuing certs under a new root. > > If a browser encounters an unknown domain name, it could contact the URI > itself, so this doesn't disenfanchise private CAs. > > Anyways, I rather like this. I think it's a much easier route to CA > pinning than expecting websites to maintain key lists themselves. > > Others? > > > Trevor > > -- Website: http://hallambaker.com/ --f46d044519a1f48a7b04e062c993 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
CAA does not require a central registry. But it does requi= re CAs to decide what DNS name(s) they are going to use.

For key pinning to work the Web Browsers are going to have to track = the correspondence of name to roots in any case. So it basically becomes a = consistency thing. If it makes sense to do that centrally, it makes sense f= or CABForum to be the venue. But it is an 'emergent' process.


On Fri,= Jun 28, 2013 at 4:32 PM, Trevor Perrin <trevp@trevp.net> wrot= e:

On Fri, Jun 28, 2013 at 8:= 00 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
CAA faced the problem of identifying a CA= .

During the evolution of the draft we went through pretty muc= h every scheme mentioned in this thread. In the end we decided to go with a= domain name that is asserted for that purpose by the CA. So symantec.com / comodo.com / etc.

Makes sense.

How do CAs assert the domain name they'd like to be referenced = by? =A0Are these domain names something that could be tracked by the CAB Fo= rum, browser root stores, or some other party?


HPKP still needs to map the declare= d domain name to a set of keys. =A0Perhaps CAs could maintain a list at a &= quot;well-known" URI derived from the domain name?

https://comodo.com/.well-known/hpkp-keys.json

Browser vendors could scan this list periodically= and keep their browsers in sync with the latest keys from the major CAs. = =A0CAs would make sure to publish new keys in advance of issuing certs unde= r a new root.

If a browser encounters an unknown domain name, it coul= d contact the URI itself, so this doesn't disenfanchise private CAs.

Anyways, I rather like this. =A0I think it's a m= uch easier route to CA pinning than expecting websites to maintain key list= s themselves.

Others?


Trevor




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