From vinodkumarpm@gmail.com Thu May 2 02:50: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 0726921F991A for ; Thu, 2 May 2013 02:50:38 -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 6WRvNPnA2YRm for ; Thu, 2 May 2013 02:50:37 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 954BB21F89B2 for ; Thu, 2 May 2013 02:50:36 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id e19so174868bku.36 for ; Thu, 02 May 2013 02:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=2KL9GFIZx3fww4p2Y2UpbZDM73F9074ZAMgH3RsvGv8=; b=zL62QZOU8uLvP7WsdeA31H0YXWhK/+wYlednetmYs4vJjIymFCuMY61xEx1cgHUESj Lhiew44tJo1Nh8sSlAUKj288cu9y23YVCLa0+d8KFet8Yz7DYhjB3O4pfqtOULJoamQY kuC3P8C/bPLoT1V9egTfk8D96meNPd95kllhGPgb/JiZfVbFt82JSm7wDBO2CkYPRy70 oBcZ/kAWmhk9yUBsvKx08Zkg93hAsdTaRhQRRy7oiv2Yt+hJxqrrGWnNKyG7IStRAMUP A6DGkB6dKs2sU4F3JQaBKVCVQMUwJTw+t9O66bhym2al2wE5dUJeOKaSPaV2tZGJ5cBj mgJw== MIME-Version: 1.0 X-Received: by 10.205.43.197 with SMTP id ud5mr1878962bkb.126.1367488235607; Thu, 02 May 2013 02:50:35 -0700 (PDT) Received: by 10.205.34.13 with HTTP; Thu, 2 May 2013 02:50:35 -0700 (PDT) Date: Thu, 2 May 2013 15:20:35 +0530 Message-ID: From: vinod kumar To: websec@ietf.org Content-Type: multipart/alternative; boundary=bcaec52996bf84d9e104dbb92a25 Subject: [websec] HPKP and Certificate Revocation Check 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, 02 May 2013 09:50:38 -0000 --bcaec52996bf84d9e104dbb92a25 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I would like to discuss a possible vulnerability in Public Key Pinning scheme (http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ ), related to certificate revocation checking. I would appreciate if anybody can review and verify my observations. Section 2.6 the draft states that when the UA connects to a pinned host, it must terminate the TLS connection, if there are any errors. The referred rfc, RFC 6797, clarifies that error could be related to certificate revocation checking or server identity checking. But it is not mandatory that during TLS handshake, UA performs certificate revocation or an assertive answer is found about the revocation status of the certificate. The reasons could be: 1. OCSP is disabled by default at the UA and the user has not changed it. 2. OCSP checking is disabled by the user. 3. OCSP check is performed but no answer is obtained from the OCSP server within the stipulated timeout. So it is very much possible that the UA accepts the PKP header from the host without verifying the revocation status of the host certificate used in TLS handshake. In the case of the host losing its private key to an attacker, the attacker may be able to block the host permanently from connecting to the UA, as explained below. The host=92s CA would have revoked the certificate but the unreliability in revocation checking creates a vulnerability. Suppose an attacker is in possession of the private key of the host and the host certificate is duly revoked by the issued CA. Attacker may succeed in diverting the UA to his server when UA tries to connect to the valid host. Attacker may mount a DNS attack or a MIM attack to achieve this. Since he posses the valid private key, the TLS connection will be successful. The only other thing he needs is that UA doesn=92t get to know the revocation status of the certificate. Here, the attacker is able to make the UA accept whatever PKP headers sent in the HTTP response. Say, the attacker has two key pairs, KeyPair1 and Keypair2, and holds a valid certificate for KeyPair1. He constructs a PKP header, Public-Key-Pins: max-age=3D (maximum possible value); pin-sha1=3D (pin corresponding to compromised key); pin-sha1=3D (pin corresponding to KeyPair1); When UA accepts this PKP header, effectively the attacker is able to set a new backup pin. The attacker can set a new PKP header in subsequent connection. He can use KeyPair1 in the TLS handshake. Public-Key-Pins: max-age=3D (maximum possible value); pin-sha1=3D (pin corresponding to KeyPair1); pin-sha1=3D (pin corresponding to KeyPair2); Now the UA sets both pins to be attacker=92s pins and the valid host is permanently blocked from connecting to the UA. To avoid this attack, shouldn=92t we mandate revocation checking when PKP headers are accepted? Thanks, Vinod. --bcaec52996bf84d9e104dbb92a25 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

I would like to discuss a possible vulnerability in Public Key Pinning scheme (http://datatracker.ietf.org/doc/draft-ietf-webse= c-key-pinning/ ), related to certificate revocation checking. I would appreciate if anybod= y can review and verify my observations.

Section 2.6 the draft states that when the UA connects to a pinned host, it must terminate the TLS connection, if there are any error= s. The referred rfc, RFC 6797, clarifies that error could be related to certificat= e revocation checking or server identity checking.

But it is not mandatory that during TLS handshake, UA performs certificate revocation or an assertive answer is found about the revocation status of the certificate. The reasons could be:

1.=A0=A0=A0=A0=A0 OCSP is disabled by default at the UA and the user has not changed it.

2.=A0=A0=A0=A0=A0 OCSP checking is disabled by the user.

3.=A0=A0=A0=A0=A0 OCSP check is performed but no answer is obtained from the OCSP server within the stipulated timeout.

So it is very much possible that the UA accepts the PKP heade= r from the host without verifying the revocation status of the host certifica= te used in TLS handshake.

In the case of the host losing its private key to an attacker, the attacker may be able to block the host permanently from connecting to the UA, as explained below. The host=92s CA would have revoke= d the certificate but the unreliability in revocation checking creates a vulnerab= ility.

Suppose an attacker is in possession of the private key of the host and the host certificate is duly revoked by the issued CA. Atta= cker may succeed in diverting the UA to his server when UA tries to connect to t= he valid host. Attacker may mount a DNS attack or a MIM attack to achieve this. Sinc= e he posses the valid private key, the TLS connection will be successful. The on= ly other thing he needs is that UA doesn=92t get to know the revocation status= of the certificate. Here, the attacker is able to make the UA accept whatever = PKP headers sent in the HTTP response.

Say, the attacker has two key pairs, KeyPair1 and Keypair2, and holds a valid certificate for KeyPair1.

He constructs a PKP header,

Public-Key-Pins: max-age=3D (maximum possible value);

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pin-sha1=3D (pin corresponding to compromised key);

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pin-sha1=3D (pin corresponding to KeyPair1);

When UA accepts this PKP header, effectively the attacker is able to set a new backup pin.

The attacker can set a new PKP header in subsequent connection. He can use KeyPair1 in the TLS handshake.

Public-Key-Pins: max-age=3D (maximum possible value);

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pin-sha1=3D (pin corresponding to KeyPair1);

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pin-sha1=3D (pin corresponding to KeyPair2);

Now the UA sets both pins to be attacker=92s pins and the valid host is permanently blocked from connecting to the UA.

To avoid this attack, shouldn=92t we mandate revocation checking when PKP headers are accepted?


Thanks,

Vinod.

--bcaec52996bf84d9e104dbb92a25-- From ryan-ietfhasmat@sleevi.com Thu May 2 14:13:09 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 74D1221F8E8F for ; Thu, 2 May 2013 14:13:09 -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 XEhAXg6i2zPg for ; Thu, 2 May 2013 14:13:04 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9E68421F8EB2 for ; Thu, 2 May 2013 14:13:03 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 596201F0085; Thu, 2 May 2013 14:13:03 -0700 (PDT) Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPA id F04D41F0083; Thu, 2 May 2013 14:13:02 -0700 (PDT) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 2 May 2013 14:13:03 -0700 Message-ID: In-Reply-To: References: Date: Thu, 2 May 2013 14:13:03 -0700 From: "Ryan Sleevi" To: "vinod kumar" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] HPKP and Certificate Revocation Check X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 21:13:09 -0000 On Thu, May 2, 2013 2:50 am, vinod kumar wrote: > Hi, > > I would like to discuss a possible vulnerability in Public Key Pinning > scheme (http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/= ), > related to certificate revocation checking. I would appreciate if anyb= ody > can review and verify my observations. > > Section 2.6 the draft states that when the UA connects to a pinned hos= t, > it > must terminate the TLS connection, if there are any errors. The referr= ed > rfc, RFC 6797, clarifies that error could be related to certificate > revocation checking or server identity checking. > > But it is not mandatory that during TLS handshake, UA performs certifi= cate > revocation or an assertive answer is found about the revocation status= of > the certificate. The reasons could be: > > 1. OCSP is disabled by default at the UA and the user has not cha= nged > it. > > 2. OCSP checking is disabled by the user. > > 3. OCSP check is performed but no answer is obtained from the OCS= P > server within the stipulated timeout. > > So it is very much possible that the UA accepts the PKP header from th= e > host without verifying the revocation status of the host certificate u= sed > in TLS handshake. > > In the case of the host losing its private key to an attacker, the > attacker > may be able to block the host permanently from connecting to the UA, a= s > explained below. The host=92s CA would have revoked the certificate bu= t the > unreliability in revocation checking creates a vulnerability. > > Suppose an attacker is in possession of the private key of the host an= d > the > host certificate is duly revoked by the issued CA. Attacker may succee= d in > diverting the UA to his server when UA tries to connect to the valid h= ost. > Attacker may mount a DNS attack or a MIM attack to achieve this. Since= he > posses the valid private key, the TLS connection will be successful. T= he > only other thing he needs is that UA doesn=92t get to know the revocat= ion > status of the certificate. Here, the attacker is able to make the UA > accept > whatever PKP headers sent in the HTTP response. > > Say, the attacker has two key pairs, KeyPair1 and Keypair2, and holds = a > valid certificate for KeyPair1. > > He constructs a PKP header, > > Public-Key-Pins: max-age=3D (maximum possible value); > > pin-sha1=3D (pin corresponding to compromised key); > > pin-sha1=3D (pin corresponding to KeyPair1); > > When UA accepts this PKP header, effectively the attacker is able to s= et a > new backup pin. > > The attacker can set a new PKP header in subsequent connection. He can= use > KeyPair1 in the TLS handshake. > > Public-Key-Pins: max-age=3D (maximum possible value); > > pin-sha1=3D (pin corresponding to KeyPair1); > > pin-sha1=3D (pin corresponding to KeyPair2); > > Now the UA sets both pins to be attacker=92s pins and the valid host i= s > permanently blocked from connecting to the UA. > > To avoid this attack, shouldn=92t we mandate revocation checking when = PKP > headers are accepted? > > > Thanks, > > Vinod. This attack exists even if you're not in possession of the server's private key - you may have obtained a fraudulently issued certificate for a site that wasn't using HPKP already, an attack that's been discussed at some length so far. If I understand your proposal correctly, you would see UAs establish an SSL/TLS connection, send a request (which may include sensitive data that is otherwise desired to be protected - such as cookies), and then on receipt of the request, when the server sends back an HPKP header, perfor= m a secondary revocation check? 1) What if the user has explicitly disabled revocation checking 2) I'm assuming you mean "revocation checking in hard(est) fail(ure) mode", since anything short of that would be pointless, given all the attacks that trivially exist. If we think about the risk/benefits carefully - from the side of the attacker, the site operator who deploys HPKP, the site operator that doesn't deploy HPKP, and the user - I think the solution is much less compelling. >From the attacker: - Strengths * Attacker can DOS a site by deploying a malicious HPKP header - Weaknesses * Deploying an HPKP header would force revocation checking, potentially revealing their attack. However, by simply *not deploying an HPKP header*, their attack MAY not be noticed (even by clients who DO revocation checking) * It requires some form of privileged connection/MITM to deploy. An attacker with such a position can equally DOS a site at lower layers in the protocol. - Questions: * Whether or not the window of time that an attacker can DOS a site via HPKP is less than, equal to, or greater than the window of time that an attacker can DOS a site via lower-level protocol. This is the ongoing max-age discussion. >From the site operator who deploys HPKP: - Strengths: * None particular over HPKP - Weaknesses: * Users will pay significant additional latency costs when connecting to a site, and a non-trivial percentage of users will outright fail. This is (one of) the many reasons why administrators and user agents have disabled revocation checking to begin with. - Question: * Whether the security advantages of HPKP and the attack(s) they guard against (eg: misissuance) are worth the significant tradeoffs in performance and reachability. >From the site operator who doesn't deploy HPKP: - Strengths: * An attacker who attempts to deploy an HPKP header with a revoked certificate will be prevented. - Weaknesses: * As noted, the attacker can simply choose not to deploy the HPKP header and continue unimpeded. >From the user's perspective: - Strengths: * None particular for the user (since, as noted above, sensitive information will already be disclosed in the HTTP stream) - Weaknesses: * The increased unreliability (due to hard-fail) may condition users to clear pinning data [on a per-site or global basis], as a "get things working" last effort, thus undermining many of the security benefits of pinning. Because of this, it seems like it significantly disadvantages all sites that opt-in to HPKP as a means of trying to mitigate the risk of a stolen certificate. Sites that don't opt into HPKP are already at risk (as noted), so this is only a mitigation for sites that are at risk. I'm not convinced of the security benefits of such a change. It certainly seems reasonable to mention in the security considerations (if not already...), and it seems useful to mention potential proposals to deal with this issue - for example, pinning to a certificate that contains the CA/Browser Forum's proposed OCSP must-staple OID, which has 'hard fail' semantics - but I don't think HPKP itself should be the conveyance mechanism for such policies. Have I missed something in my analysis? From vinodkumarpm@gmail.com Sat May 4 10:23: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 87B7F21F9667 for ; Sat, 4 May 2013 10:23:22 -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 sdpzQPONPbLe for ; Sat, 4 May 2013 10:23:20 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 026EA21F86F4 for ; Sat, 4 May 2013 10:23:19 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id y8so1116033bkt.27 for ; Sat, 04 May 2013 10:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pQuJadhrbAYyC8fmBgo3Bz8cEccR/ylZ3ew7EzyhwfQ=; b=v1jZMNOExYH6116fLGQApjhqQr/LrXTZm1pX7xT1bSapfiNeLzjrhlVLL5rm6S9yFa H8ENlH4R+uZD7+eMNAUt/Xovw0nTItYvsYdCc7Yj2sY8XCTu2NxL5AUGXe+ktOvhXmwq Ea6bppOzJyCSvzWE6qCgVK2Ty3Yz3cuhz+gmKX3Vo7huIa9hUSn0oy4Jxj0M05nAiwS4 ismwSYBMAzQcmmSz67YeXDgh9wMmjWh9CjNd8lSIbil3Hftx+i3tRkaDoP+fo/eWlPna iDhvv1W2kzcinxa2+0hwBkG6z7YbnaPt1xlFqpkN/6tk0InW7BIKpiMw2fC62jXTGqUu M0jw== MIME-Version: 1.0 X-Received: by 10.205.105.8 with SMTP id do8mr5559258bkc.3.1367688199022; Sat, 04 May 2013 10:23:19 -0700 (PDT) Received: by 10.205.34.13 with HTTP; Sat, 4 May 2013 10:23:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 May 2013 22:53:18 +0530 Message-ID: From: vinod kumar To: ryan-ietfhasmat@sleevi.com Content-Type: multipart/alternative; boundary=f46d042186b9445aba04dbe7b9ce Cc: websec@ietf.org Subject: Re: [websec] HPKP and Certificate Revocation Check 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, 04 May 2013 17:23:23 -0000 --f46d042186b9445aba04dbe7b9ce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks very much for the detailed analysis of the proposal. I was mainly thinking of security problems introduced by HPKP scheme. So, i think, some of the problems you mentioned do not fall in that category. Those are general problems associated with lack of revocation checking, like, 1. The first HTTP request is sent to the attacker anyway, revealing session cookies. 2. If the attacker does not employ HPKP headers, the attack will not be detected. But HPKP introduces a few DOS attacks on the host. These are: 1. attacker gets a fraudulently issued certificate for a host which is not using HPKP. He can add HPKP headers in the response to block out the host. 2. attacker steals host=92s private key. This attack applies to hosts supporting HPKP and those who don=92t. You generalize these attacks as DOS attacks. In the case of a typical DOS attack, once the host finds out the occurrence of the attack, he can take remedial action and recover from the situation. But in the above attacks, host gets permanently blocked from connecting to the affected UA=92s and there is no way the host can unblock the UA. Of course, the user can remove the pin for the host (how does he decide?), but any user action is always tricky and introduces other security vulnerabilities. Coming back to revocation checking for HPKP, it addresses DOS attack(2). We don=92t have to mandate revocation check whenever HPKP headers are received but only in the following cases: 1. The host is not a pinned host and an HPKP header is received. 2. The host is a pinned host and the HPKP header contains a new pin set. 3. The host is a pinned host and the max age value is less than the remaining age(?). I don=92t think the attacker gets any benefit by extendin= g the max age of the current pins. We may stipulate that if revocation check doesn=92t pass in the above cases= , the HPKP headers will not be accepted. I hope this modification alleviate the concern expressed in =91From the sit= e operator who deploys HPKP: weakness=92 section. We may be able to provide some solution using OCSP stapling as you suggested, that is something to explore. On Fri, May 3, 2013 at 2:43 AM, Ryan Sleevi wro= te: > On Thu, May 2, 2013 2:50 am, vinod kumar wrote: > > Hi, > > > > I would like to discuss a possible vulnerability in Public Key Pinning > > scheme (http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/= ), > > related to certificate revocation checking. I would appreciate if > anybody > > can review and verify my observations. > > > > Section 2.6 the draft states that when the UA connects to a pinned hos= t, > > it > > must terminate the TLS connection, if there are any errors. The referr= ed > > rfc, RFC 6797, clarifies that error could be related to certificate > > revocation checking or server identity checking. > > > > But it is not mandatory that during TLS handshake, UA performs > certificate > > revocation or an assertive answer is found about the revocation status > of > > the certificate. The reasons could be: > > > > 1. OCSP is disabled by default at the UA and the user has not > changed > > it. > > > > 2. OCSP checking is disabled by the user. > > > > 3. OCSP check is performed but no answer is obtained from the OCS= P > > server within the stipulated timeout. > > > > So it is very much possible that the UA accepts the PKP header from th= e > > host without verifying the revocation status of the host certificate > used > > in TLS handshake. > > > > In the case of the host losing its private key to an attacker, the > > attacker > > may be able to block the host permanently from connecting to the UA, a= s > > explained below. The host=92s CA would have revoked the certificate bu= t > the > > unreliability in revocation checking creates a vulnerability. > > > > Suppose an attacker is in possession of the private key of the host an= d > > the > > host certificate is duly revoked by the issued CA. Attacker may succee= d > in > > diverting the UA to his server when UA tries to connect to the valid > host. > > Attacker may mount a DNS attack or a MIM attack to achieve this. Since > he > > posses the valid private key, the TLS connection will be successful. T= he > > only other thing he needs is that UA doesn=92t get to know the revocat= ion > > status of the certificate. Here, the attacker is able to make the UA > > accept > > whatever PKP headers sent in the HTTP response. > > > > Say, the attacker has two key pairs, KeyPair1 and Keypair2, and holds = a > > valid certificate for KeyPair1. > > > > He constructs a PKP header, > > > > Public-Key-Pins: max-age=3D (maximum possible value); > > > > pin-sha1=3D (pin corresponding to compromised key); > > > > pin-sha1=3D (pin corresponding to KeyPair1); > > > > When UA accepts this PKP header, effectively the attacker is able to > set a > > new backup pin. > > > > The attacker can set a new PKP header in subsequent connection. He can > use > > KeyPair1 in the TLS handshake. > > > > Public-Key-Pins: max-age=3D (maximum possible value); > > > > pin-sha1=3D (pin corresponding to KeyPair1); > > > > pin-sha1=3D (pin corresponding to KeyPair2); > > > > Now the UA sets both pins to be attacker=92s pins and the valid host i= s > > permanently blocked from connecting to the UA. > > > > To avoid this attack, shouldn=92t we mandate revocation checking when = PKP > > headers are accepted? > > > > > > Thanks, > > > > Vinod. > > This attack exists even if you're not in possession of the server's > private key - you may have obtained a fraudulently issued certificate for > a site that wasn't using HPKP already, an attack that's been discussed at > some length so far. > > If I understand your proposal correctly, you would see UAs establish an > SSL/TLS connection, send a request (which may include sensitive data that > is otherwise desired to be protected - such as cookies), and then on > receipt of the request, when the server sends back an HPKP header, perfor= m > a secondary revocation check? > > 1) What if the user has explicitly disabled revocation checking > 2) I'm assuming you mean "revocation checking in hard(est) fail(ure) > mode", since anything short of that would be pointless, given all the > attacks that trivially exist. > > If we think about the risk/benefits carefully - from the side of the > attacker, the site operator who deploys HPKP, the site operator that > doesn't deploy HPKP, and the user - I think the solution is much less > compelling. > > From the attacker: > - Strengths > * Attacker can DOS a site by deploying a malicious HPKP header > - Weaknesses > * Deploying an HPKP header would force revocation checking, potentially > revealing their attack. However, by simply *not deploying an HPKP > header*, their attack MAY not be noticed (even by clients who DO > revocation checking) > * It requires some form of privileged connection/MITM to deploy. An > attacker with such a position can equally DOS a site at lower layers in > the protocol. > - Questions: > * Whether or not the window of time that an attacker can DOS a site via > HPKP is less than, equal to, or greater than the window of time that an > attacker can DOS a site via lower-level protocol. This is the ongoing > max-age discussion. > > From the site operator who deploys HPKP: > - Strengths: > * None particular over HPKP > - Weaknesses: > * Users will pay significant additional latency costs when connecting to > a site, and a non-trivial percentage of users will outright fail. This is > (one of) the many reasons why administrators and user agents have > disabled revocation checking to begin with. > - Question: > * Whether the security advantages of HPKP and the attack(s) they guard > against (eg: misissuance) are worth the significant tradeoffs in > performance and reachability. > > From the site operator who doesn't deploy HPKP: > - Strengths: > * An attacker who attempts to deploy an HPKP header with a revoked > certificate will be prevented. > - Weaknesses: > * As noted, the attacker can simply choose not to deploy the HPKP header > and continue unimpeded. > > From the user's perspective: > - Strengths: > * None particular for the user (since, as noted above, sensitive > information will already be disclosed in the HTTP stream) > - Weaknesses: > * The increased unreliability (due to hard-fail) may condition users to > clear pinning data [on a per-site or global basis], as a "get things > working" last effort, thus undermining many of the security benefits of > pinning. > > > Because of this, it seems like it significantly disadvantages all sites > that opt-in to HPKP as a means of trying to mitigate the risk of a stolen > certificate. Sites that don't opt into HPKP are already at risk (as > noted), so this is only a mitigation for sites that are at risk. > > I'm not convinced of the security benefits of such a change. It certainly > seems reasonable to mention in the security considerations (if not > already...), and it seems useful to mention potential proposals to deal > with this issue - for example, pinning to a certificate that contains the > CA/Browser Forum's proposed OCSP must-staple OID, which has 'hard fail' > semantics - but I don't think HPKP itself should be the conveyance > mechanism for such policies. > > Have I missed something in my analysis? > > --f46d042186b9445aba04dbe7b9ce Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Thanks very much for the detailed analysis of the proposal.

I was mainly thinking of security problems introd= uced by HPKP scheme. So, i think, some of the problems you mentioned do not fall in that category. Those are general problems associated with lack of revocatio= n checking, like,

1.=A0=A0=A0=A0=A0 The first HTTP request is sent to the attacker anyway, revealing session cookies.

2.=A0=A0=A0=A0=A0 If the attacker does not employ HPKP headers, the attack will not be detected.

But HPKP introduces a few DOS attacks on the host= . These are:

1.=A0=A0=A0=A0=A0 attacker gets a fraudulently issued certificate for a host which is not using HPKP. He can add HPKP headers in the response= to block out the host.

2.=A0=A0=A0=A0=A0 attacker steals host=92s private key. This attack applies to hosts supporting HPKP and those who don=92t.

You generalize these attacks as DOS attacks. In t= he case of a typical DOS attack, once the host finds out the occurrence of the atta= ck, he can take remedial action and recover from the situation.

But in the above attacks, host gets permanently b= locked from connecting to the affected UA=92s and there is no way the host can unb= lock the UA. =A0Of course, the user can remove the pin for the host (how does he decide?), but any user action is always trick= y and introduces other security vulnerabilities.

Coming back to revocation checking for HPKP, it a= ddresses DOS attack(2). We don=92t have to mandate revocation check whenever HPKP he= aders are received but only in the following cases:

1.=A0=A0=A0=A0=A0 The host is not a pinned host and an HPKP header is received.

2.=A0=A0=A0=A0=A0 The host is a pinned host and the HPKP header contains a new pin set.

3.=A0=A0=A0=A0=A0 The host is a pinned host and the max age value is less than the remaining age(?). I don=92t think the attacker gets any be= nefit by extending the max age of the current pins.

We may stipulate that if revocation check doesn= =92t pass in the above cases, the HPKP headers will not be accepted.

I hope this modification alleviate the concern ex= pressed in =91From the site operator who deploys HPKP: weakness=92 section.

We may be able to provide some solution using OCS= P stapling as you suggested, that is something to explore.



On Fri,= May 3, 2013 at 2:43 AM, Ryan Sleevi <ryan-ietfhasmat@sleevi.com<= /a>> wrote:
On T= hu, May 2, 2013 2:50 am, vinod kumar wrote:
> =A0Hi,
>
> =A0I would like to discuss a possible vulnerability in Public Key Pinn= ing
> =A0scheme (http://datatracker.ietf.org/doc/draft-iet= f-websec-key-pinning/ ),
> =A0related to certificate revocation checking. I would appreciate if a= nybody
> =A0can review and verify my observations.
>
> =A0Section 2.6 the draft states that when the UA connects to a pinned = host,
> =A0it
> =A0must terminate the TLS connection, if there are any errors. The ref= erred
> =A0rfc, RFC 6797, clarifies that error could be related to certificate=
> =A0revocation checking or server identity checking.
>
> =A0But it is not mandatory that during TLS handshake, UA performs cert= ificate
> =A0revocation or an assertive answer is found about the revocation sta= tus of
> =A0the certificate. The reasons could be:
>
> =A01. =A0 =A0 =A0OCSP is disabled by default at the UA and the user ha= s not changed
> =A0it.
>
> =A02. =A0 =A0 =A0OCSP checking is disabled by the user.
>
> =A03. =A0 =A0 =A0OCSP check is performed but no answer is obtained fro= m the OCSP
> =A0server within the stipulated timeout.
>
> =A0So it is very much possible that the UA accepts the PKP header from= the
> =A0host without verifying the revocation status of the host certificat= e used
> =A0in TLS handshake.
>
> =A0In the case of the host losing its private key to an attacker, the<= br> > =A0attacker
> =A0may be able to block the host permanently from connecting to the UA= , as
> =A0explained below. The host=92s CA would have revoked the certificate= but the
> =A0unreliability in revocation checking creates a vulnerability.
>
> =A0Suppose an attacker is in possession of the private key of the host= and
> =A0the
> =A0host certificate is duly revoked by the issued CA. Attacker may suc= ceed in
> =A0diverting the UA to his server when UA tries to connect to the vali= d host.
> =A0Attacker may mount a DNS attack or a MIM attack to achieve this. Si= nce he
> =A0posses the valid private key, the TLS connection will be successful= . The
> =A0only other thing he needs is that UA doesn=92t get to know the revo= cation
> =A0status of the certificate. Here, the attacker is able to make the U= A
> =A0accept
> =A0whatever PKP headers sent in the HTTP response.
>
> =A0Say, the attacker has two key pairs, KeyPair1 and Keypair2, and hol= ds a
> =A0valid certificate for KeyPair1.
>
> =A0He constructs a PKP header,
>
> =A0Public-Key-Pins: max-age=3D (maximum possible value);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pin-sha1=3D (pin corresponding to comp= romised key);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pin-sha1=3D (pin corresponding to KeyP= air1);
>
> =A0When UA accepts this PKP header, effectively the attacker is able t= o set a
> =A0new backup pin.
>
> =A0The attacker can set a new PKP header in subsequent connection. He = can use
> =A0KeyPair1 in the TLS handshake.
>
> =A0Public-Key-Pins: max-age=3D (maximum possible value);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pin-sha1=3D (pin corresponding to KeyP= air1);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pin-sha1=3D (pin corresponding to KeyP= air2);
>
> =A0Now the UA sets both pins to be attacker=92s pins and the valid hos= t is
> =A0permanently blocked from connecting to the UA.
>
> =A0To avoid this attack, shouldn=92t we mandate revocation checking wh= en PKP
> =A0headers are accepted?
>
>
> =A0Thanks,
>
> =A0Vinod.

This attack exists even if you're not in possession of the = server's
private key - you may have obtained a fraudulently issued certificate for a site that wasn't using HPKP already, an attack that's been discus= sed at
some length so far.

If I understand your proposal correctly, you would see UAs establish an
SSL/TLS connection, send a request (which may include sensitive data that is otherwise desired to be protected - such as cookies), and then on
receipt of the request, when the server sends back an HPKP header, perform<= br> a secondary revocation check?

1) What if the user has explicitly disabled revocation checking
2) I'm assuming you mean "revocation checking in hard(est) fail(ur= e)
mode", since anything short of that would be pointless, given all the<= br> attacks that trivially exist.

If we think about the risk/benefits carefully - from the side of the
attacker, the site operator who deploys HPKP, the site operator that
doesn't deploy HPKP, and the user - I think the solution is much less compelling.

>From the attacker:
- Strengths
=A0* Attacker can DOS a site by deploying a malicious HPKP header
- Weaknesses
=A0* Deploying an HPKP header would force revocation checking, potentially<= br> revealing their attack. However, by simply *not deploying an HPKP
header*, their attack MAY not be noticed (even by clients who DO
revocation checking)
=A0* It requires some form of privileged connection/MITM to deploy. An
attacker with such a position can equally DOS a site at lower layers in
the protocol.
- Questions:
=A0* Whether or not the window of time that an attacker can DOS a site via<= br> HPKP is less than, equal to, or greater than the window of time that an
attacker can DOS a site via lower-level protocol. This is the ongoing
max-age discussion.

>From the site operator who deploys HPKP:
- Strengths:
=A0* None particular over HPKP
- Weaknesses:
=A0* Users will pay significant additional latency costs when connecting to=
a site, and a non-trivial percentage of users will outright fail. This is (one of) the many reasons why administrators and user agents have
disabled revocation checking to begin with.
- Question:
=A0* Whether the security advantages of HPKP and the attack(s) they guard against (eg: misissuance) are worth the significant tradeoffs in
performance and reachability.

>From the site operator who doesn't deploy HPKP:
- Strengths:
=A0* An attacker who attempts to deploy an HPKP header with a revoked
certificate will be prevented.
- Weaknesses:
=A0* As noted, the attacker can simply choose not to deploy the HPKP header=
and continue unimpeded.

>From the user's perspective:
- Strengths:
=A0* None particular for the user (since, as noted above, sensitive
information will already be disclosed in the HTTP stream)
- Weaknesses:
=A0* The increased unreliability (due to hard-fail) may condition users to<= br> clear pinning data [on a per-site or global basis], as a "get things working" last effort, thus undermining many of the security benefits o= f
pinning.


Because of this, it seems like it significantly disadvantages all sites
that opt-in to HPKP as a means of trying to mitigate the risk of a stolen certificate. Sites that don't opt into HPKP are already at risk (as
noted), so this is only a mitigation for sites that are at risk.

I'm not convinced of the security benefits of such a change. It certain= ly
seems reasonable to mention in the security considerations (if not
already...), and it seems useful to mention potential proposals to deal
with this issue - for example, pinning to a certificate that contains the CA/Browser Forum's proposed OCSP must-staple OID, which has 'hard f= ail'
semantics - but I don't think HPKP itself should be the conveyance
mechanism for such policies.

Have I missed something in my analysis?


--f46d042186b9445aba04dbe7b9ce-- From ynir@checkpoint.com Tue May 7 00:13:36 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 2422C21F8B65 for ; Tue, 7 May 2013 00:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 DvkxryFyIiZq for ; Tue, 7 May 2013 00:13:31 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EF3EB21F919A for ; Tue, 7 May 2013 00:13:30 -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 r477DSZq005558 for ; Tue, 7 May 2013 10:13:28 +0300 X-CheckPoint: {5188A810-5-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, 7 May 2013 10:13:28 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Consensus call: Issue #57 (max-max-age) Thread-Index: AQHOSvJfUWwKnsbs2U6hMAgGMyNIfA== Date: Tue, 7 May 2013 07:13:28 +0000 Message-ID: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.134] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11f7b738ec3014da93af32572ca8c3b9ef03467bb1 Content-Type: text/plain; charset="Windows-1252" Content-ID: <9A4162343691C641AC4EED8AAADE0A3B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [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, 07 May 2013 07:13:36 -0000 Hi folks We think it's time to move on with Key Pinning, as there haven't been subst= antial issues raised in months. The one outstanding contentious issue is t= he one in the subject: http://trac.tools.ietf.org/wg/websec/trac/ticket/57 We've heard the argument that allowing pins to exist for indefinitely long = can cause a site to be bricked for that period because of simple mistakes l= ike changing certificate vendor or changing ownership of the domain name. We've also heard the counter-argument that some domains are visited infrequ= ently, so short pins would do nothing for them. So here are some options. Please reply to this thread with with your prefer= ence. Arguments are good, but "+1" works as well. So=85 How should we handle the max-max-age issue: (1) No hard limits, but allow UAs to limit the pin time. Suggest a month (2) Set a hard limit of one month in the RFC. Longer pins are truncated. (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't bee= n observed for some time (like a month) (4) Adopt some gradual confidence-building scheme a-la-TACK. "None of the above" is possible, but MUST come with argument and proposed t= ext. Let's give this until Wednesday, 22-May. Thanks Tobias & Yoav From trevp@trevp.net Wed May 8 12:02:12 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 60FA021F9375 for ; Wed, 8 May 2013 12:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.357 X-Spam-Level: * X-Spam-Status: No, score=1.357 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, RCVD_IN_SORBS_DUL=0.877, 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 P+9nya0Zlb75 for ; Wed, 8 May 2013 12:02:07 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 595F221F8511 for ; Wed, 8 May 2013 12:01:53 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so2165334wgh.13 for ; Wed, 08 May 2013 12:01:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Wn3x1VmTapiQsuvFV/fLLbe8Xy0AmZMijqIjbV23tSA=; b=RwUemLc6C8tj7gg6ei6cqkS+B7+c4dznQ4LPB2OytF+zlfRnc731Qo2OPIgdCY+KGj Ij20FEyT2u6DeLG25qzom9+lGGxCwXWxJxLs66jDk6bvDnkmOc/oK0mUm4RHUcfF/NGb StSmBU20HIsANnwM8QqLhLGjx+QuGUQ/LgkH75Ep3qYqWO1uR9lHwT730Yi5d92Tz2q1 Qc+wf9s2zp4bpcwp9NfC9LRa2RO3lQEGxQ89fZqkJ9JmBNA7NyRfcEqB4F9dT3Rx4rjd 4TV5+86OsNfB85yp7QSMmq1SpfpFaTXFGMF6s8uJKmw4UV1J4pfnbdvAxBeQUiPfr00u HNvg== MIME-Version: 1.0 X-Received: by 10.180.76.230 with SMTP id n6mr24055506wiw.28.1368039712426; Wed, 08 May 2013 12:01:52 -0700 (PDT) Received: by 10.216.113.7 with HTTP; Wed, 8 May 2013 12:01:52 -0700 (PDT) X-Originating-IP: [64.134.226.20] In-Reply-To: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> Date: Wed, 8 May 2013 12:01:52 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d043c7d46191eb504dc3991ba X-Gm-Message-State: ALoCoQnILTOhfPDy3jj7kLPHMyxqPwma1O/apiUShAkC4nLj9LeBdxPYTsiShmm/Wql2dkqASof3 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: Wed, 08 May 2013 19:02:12 -0000 --f46d043c7d46191eb504dc3991ba Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 12:13 AM, Yoav Nir wrote: > > How should we handle the max-max-age issue: > (1) No hard limits, but allow UAs to limit the pin time. Suggest a month > (2) Set a hard limit of one month in the RFC. Longer pins are truncated. > (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't > been observed for some time (like a month) > (4) Adopt some gradual confidence-building scheme a-la-TACK. > Hi Yoav, I suggest this could be viewed as two separate questions: A) Should there be / what is the spec-mandated max pin lifetime? - (this is your 1/2/3) B) How are pin lifetimes set? - server assertion ("max-age") - confidence building (eg "pin activation") - some combination? something else? These questions are somewhat independent: you could have a spec-mandated max regardless of whether pin lifetimes are set from server assertions *or* confidence-building. Anyways, the first question has been discussed a bunch, and I think it's reasonable to try to get a consensus. My vote is #2, with "30 days". The second question hasn't been discussed much, and has some complexity. Maybe we should try to encourage more discussion / research of the options, before trying to pull out a consensus? Trevor --f46d043c7d46191eb504dc3991ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, May 7, 2013 at 12:13 AM, Yoav Nir <ynir@checkpoint.com> wrote:

How should we handle the max-max-age issue:
=A0(1) No hard limits, but allow UAs to limit the pin time. Suggest a month=
=A0(2) Set a hard limit of one month in the RFC. Longer pins are truncated.=
=A0(3) No hard limits, but allow the UA to skip hard-fail if a pin hasn'= ;t been observed for some time (like a month)
=A0(4) Adopt some gradual confidence-building scheme a-la-TACK.

Hi Yoav,

I suggest this c= ould be viewed as two separate questions:

=A0A) Sh= ould there be / what is the spec-mandated max pin lifetime?
=A0 =A0- (this is your 1/2/3)
=A0 =A0
=A0B) How ar= e pin lifetimes set?=A0
=A0 =A0- server assertion ("max-age&= quot;)
=A0 =A0- confidence building (eg "pin activation"= ;)
=A0 =A0- some combination? =A0something else?

These questions are somewhat independent: you could hav= e a spec-mandated max regardless of whether pin lifetimes are set from serv= er assertions *or* confidence-building.

Anyways, t= he first question has been discussed a bunch, and I think it's reasonab= le to try to get a consensus. =A0My vote is #2, with "30 days".

The second question hasn't been discussed much, and= has some complexity. =A0Maybe we should try to encourage more discussion /= research of the options, before trying to pull out a consensus?


Trevor

--f46d043c7d46191eb504dc3991ba-- From tom@ritter.vg Sat May 11 13:10:14 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 5F6BC21F8930 for ; Sat, 11 May 2013 13:10:14 -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 j+au268Xps74 for ; Sat, 11 May 2013 13:10:13 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7C821F8916 for ; Sat, 11 May 2013 13:10:13 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id s9so10004387iec.20 for ; Sat, 11 May 2013 13:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=qFW+GWysbxQr0RAD4cI/SJwwfDB0f3KAB7N8obnwzqw=; b=c3z7hBajoLrI6LU4I0Bi0JZKWBqi2Hcil68INKZyy6RjKf/LzVQdR2bYO8WOibdwQB 1VqEeWjLc1sGlD0Ow3CzILA+wLM0s73ZvBmNrQJeyUjBXqi1BnnnHlio/9s6tpop3FP4 NocEBBYMMbnIQM/eQnEhdFrLCwSYcad9MFSzY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=qFW+GWysbxQr0RAD4cI/SJwwfDB0f3KAB7N8obnwzqw=; b=jpUhIHp5VvpbPv6Z2iuSflFjyC+nPRGK4r0Tdg8pu/6x18jRwpBwj3Humz8KIBEnV7 oYXozYw5xKCBsv8cEB27GiBYvp7EbGWm9/9dioC1Ffu0U272X/ArL5txXAxLujExc4vi xdCNNuwObWR09LJJk7/livkJaVdAum3OgjS+s2hCmGZay+Hv4n944wQrOq/Fctwv4wuF lCvRkvamQGaMC5q37x+mUPo4NW/JvImh4wLqFGdFlrPTwKVBKeXYs4/hEKG5IJVcz6Vi 7+/i2Wwrko/0qQmjMMah6Gzm3dFYNRvCH665AGoHth/TQtMpD7vyNZ5r0h17hwWKkDSZ xh7g== X-Received: by 10.50.25.102 with SMTP id b6mr5788199igg.27.1368303012655; Sat, 11 May 2013 13:10:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.20.72 with HTTP; Sat, 11 May 2013 13:09:52 -0700 (PDT) In-Reply-To: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> From: Tom Ritter Date: Sat, 11 May 2013 16:09:52 -0400 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnoDY3Z4H02FrGScLRGHiA7HzqCqhpdcxuFPnwiHDvYaZNtXW0xqQCgAiog9vD3FZWNxaVo 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: Sat, 11 May 2013 20:10:14 -0000 On 7 May 2013 03:13, Yoav Nir wrote: > How should we handle the max-max-age issue: > (1) No hard limits, but allow UAs to limit the pin time. Suggest a month > (2) Set a hard limit of one month in the RFC. Longer pins are truncated. > (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month) > (4) Adopt some gradual confidence-building scheme a-la-TACK. > > "None of the above" is possible, but MUST come with argument and proposed text. None of the above: No hard limits, leave limiting the pin time unspecified, make no suggestion. I don't believe any text changes are necessary. I think UAs that are sufficiently worried about websites bricking themselves come up with creative solutions that work well for them, but may not be applicable to others. (Chrome's will (or would) expire hardcoded pins if there hasn't been a Chrome update in a month - they could do the same for max-ages.) I don't like the idea of suggesting that UAs unilaterally override a site's possible desire to pin for more than 1 month. -tom. From duerst@it.aoyama.ac.jp Sat May 11 17:41: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 2EB5E21F859D for ; Sat, 11 May 2013 17:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.044 X-Spam-Level: X-Spam-Status: No, score=-108.044 tagged_above=-999 required=5 tests=[AWL=-2.254, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5uuIXdmuSYm for ; Sat, 11 May 2013 17:41:31 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3A86E21F856D for ; Sat, 11 May 2013 17:41:30 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r4C0f8qS022366; Sun, 12 May 2013 09:41:09 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3e19_9bdf_a2df121c_ba9c_11e2_9b3b_001e6722eec2; Sun, 12 May 2013 09:41:07 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id A9837BF4AF; Sun, 12 May 2013 09:40:26 +0900 (JST) Message-ID: <518EE510.9060600@it.aoyama.ac.jp> Date: Sun, 12 May 2013 09:40:48 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tom Ritter References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sun, 12 May 2013 00:41:37 -0000 I agree with Tom Ritter, with one caveat: The spec should very clearly call out the issue (balance between too soon pin expiry and too long), rather than not mentioning it. I haven't found such language (i.e. guidance to UA implementers) in the document, but I might have looked in the wrong place (I looked at every piece of text that contained the three letters 'max'). Regards, Martin. On 2013/05/12 5:09, Tom Ritter wrote: > On 7 May 2013 03:13, Yoav Nir wrote: >> How should we handle the max-max-age issue: >> (1) No hard limits, but allow UAs to limit the pin time. Suggest a month >> (2) Set a hard limit of one month in the RFC. Longer pins are truncated. >> (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month) >> (4) Adopt some gradual confidence-building scheme a-la-TACK. >> >> "None of the above" is possible, but MUST come with argument and proposed text. > > > None of the above: No hard limits, leave limiting the pin time > unspecified, make no suggestion. I don't believe any text changes are > necessary. > > I think UAs that are sufficiently worried about websites bricking > themselves come up with creative solutions that work well for them, > but may not be applicable to others. (Chrome's will (or would) expire > hardcoded pins if there hasn't been a Chrome update in a month - they > could do the same for max-ages.) I don't like the idea of suggesting > that UAs unilaterally override a site's possible desire to pin for > more than 1 month. > > -tom. > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From ynir@checkpoint.com Sun May 12 04:57:36 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 1557521F8E49 for ; Sun, 12 May 2013 04:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.343 X-Spam-Level: X-Spam-Status: No, score=-11.343 tagged_above=-999 required=5 tests=[AWL=0.956, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, 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 5GXFtjmihi8w for ; Sun, 12 May 2013 04:57:25 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 08EA221F8DA6 for ; Sun, 12 May 2013 04:57:24 -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 r4CBvAV9015411; Sun, 12 May 2013 14:57:15 +0300 X-CheckPoint: {518F81CB-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, 12 May 2013 14:57:10 +0300 From: Yoav Nir To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= Thread-Topic: [websec] Consensus call: Issue #57 (max-max-age) Thread-Index: AQHOSvJfUWwKnsbs2U6hMAgGMyNIfJkAPs4AgABLswCAAL0DAA== Date: Sun, 12 May 2013 11:57:09 +0000 Message-ID: <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> In-Reply-To: <518EE510.9060600@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.45] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11a43d25081cbb663ef954b02e26dc18827b642b40 Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sun, 12 May 2013 11:57:36 -0000 Hi Martin Such guidance in the spec is relevant for the rightful domain owners. Suppo= se an attacker got some CA to issue a bad certificate for facebook.com. The= attacker now sets up this certificate on some public proxy, and sets a pin= for 20 years. Within days the attack is discovered, the certificate revoke= d and the fake website taken down. But the user-agents that received this p= in are blocked from reaching facebook. A limit would help by getting them o= ff of facebook for just 1 month. Also, if a domain name is sold or transferred to another entity, a long-liv= ed pin could mean that the new owner can't put a website there. I'm not saying these are compelling arguments to limit pins in the UA, but = they should be considered. Yoav On May 12, 2013, at 3:40 AM, Martin J. D=FCrst wro= te: > I agree with Tom Ritter, with one caveat: The spec should very clearly ca= ll out the issue (balance between too soon pin expiry and too long), rather= than not mentioning it. I haven't found such language (i.e. guidance to UA= implementers) in the document, but I might have looked in the wrong place = (I looked at every piece of text that contained the three letters 'max'). >=20 > Regards, Martin. >=20 > On 2013/05/12 5:09, Tom Ritter wrote: >> On 7 May 2013 03:13, Yoav Nir wrote: >>> How should we handle the max-max-age issue: >>> (1) No hard limits, but allow UAs to limit the pin time. Suggest a mon= th >>> (2) Set a hard limit of one month in the RFC. Longer pins are truncate= d. >>> (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't= been observed for some time (like a month) >>> (4) Adopt some gradual confidence-building scheme a-la-TACK. >>>=20 >>> "None of the above" is possible, but MUST come with argument and propos= ed text. >>=20 >>=20 >> None of the above: No hard limits, leave limiting the pin time >> unspecified, make no suggestion. I don't believe any text changes are >> necessary. >>=20 >> I think UAs that are sufficiently worried about websites bricking >> themselves come up with creative solutions that work well for them, >> but may not be applicable to others. (Chrome's will (or would) expire >> hardcoded pins if there hasn't been a Chrome update in a month - they >> could do the same for max-ages.) I don't like the idea of suggesting >> that UAs unilaterally override a site's possible desire to pin for >> more than 1 month. >>=20 >> -tom. From hallam@gmail.com Tue May 14 18:36: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 0A42321F8B2B for ; Tue, 14 May 2013 18:36:38 -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 u05Efy9ffOOl for ; Tue, 14 May 2013 18:36:37 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A209321F8651 for ; Tue, 14 May 2013 18:36:36 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q57so1053915wes.23 for ; Tue, 14 May 2013 18:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=2rQKeCVlDDU+ABfMMVC7ZmExfsR240wMwRG+hrqP8Qk=; b=N1MIc+IWW8WpmoAIFJ1Pmk1dO7XD9a8mCe3LGeCCIa6OamKAh0ISSB9yyJGY8OTKVm L3/jSXgxeOFoRCNniIf7ulKqOWJT7MGTefoJLAATgnYqA6iWYY2dD0mBLWc0HcKIgfci iGuPbPd9wY1CXjOkLVmJdq3JuA3AK7Z1P1H7jUyxtoWMxr37F/dy6euWesI+5iymHFdc 0yl/3D3XDA1bd7lNexTqI4XM4XIK/YJGB3j5qPSpC3ZzsSz5YAK+nobNEIyJ9E4XfSZh J0NXFpaxSIOpv4w8tmoaNkV0KA5ha3BpKO6mPcm1SNt2Y3ZvVE6VlintaQl/KzINd/vv D4QA== MIME-Version: 1.0 X-Received: by 10.194.243.170 with SMTP id wz10mr678664wjc.53.1368581795800; Tue, 14 May 2013 18:36:35 -0700 (PDT) Received: by 10.194.162.8 with HTTP; Tue, 14 May 2013 18:36:35 -0700 (PDT) Date: Tue, 14 May 2013 21:36:35 -0400 Message-ID: From: Phillip Hallam-Baker To: websec Content-Type: multipart/alternative; boundary=089e0149411ac8eaef04dcb7c71a Subject: [websec] Session continuation mechanism -01 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, 15 May 2013 01:36:38 -0000 --089e0149411ac8eaef04dcb7c71a Content-Type: text/plain; charset=ISO-8859-1 I have just submitted an updated version of the session continuation draft. http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt I didn't bring the first version to the list attention as I was not convinced all the parts really worked. I have since re-engineered the replay prevention mechanism and I think the result is more sensible. There is code, but this version is not tracking it (yet). I modified the examples to get the draft out the door so don't go checking it :-) The basic idea here is that this is a more or less drop in replacement for HTTP cookies but with much better security properties. To signal that it can accept session continuation in place of cookies, a client adds an Accept-Session header to a request. If the server accepts the offer of using session management it returns a response with a Set-Session header. After the context is set up, the client and server both add Session headers to request and response messages. The main change is on replay attack prevention which I now think needs to be different for requests and responses. Response replay attack prevention is easy. Just put a nonce in the request and the server returns in in the response. Problem solved. No need to keep any state or muck about with clocks. Request replay attack is trickier and I don't think we even want to try to do the job in HTTP, certainly not the whole job. If people want really solid request replay attack prevention for a Web service then they should write the code into their Web Service because HTTP does not have enough visibility into their transaction to know when the nonces should be there or not. The same mechanism could be extended to cover public key techniques (digital signatures). -- Website: http://hallambaker.com/ --089e0149411ac8eaef04dcb7c71a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have just submitted an updated version of the session co= ntinuation draft.


I didn't bring the first version to the= list attention as I was not convinced all the parts really worked. I have = since re-engineered the replay prevention mechanism and I think the result = is more sensible.

There is code, but this version is not trac= king it (yet). I modified the examples to get the draft out the door so don= 't go checking it :-)


The basic idea here is that this is a more or less drop in repla= cement for HTTP cookies but with much better security properties. To signal= that it can accept session continuation in place of cookies, a client adds= an Accept-Session header to a request. If the server accepts the offer of = using session management it returns a response with a Set-Session header.

After the context is set up, the client and= server both add Session headers to request and response messages.


The main change is on rep= lay attack prevention which I now think needs to be different for requests = and responses.

Response replay attack prevention is easy. = Just put a nonce in the request and the server returns in in the response. = Problem solved. No need to keep any state or muck about with clocks.

Request replay attack is trickier and I don= 't think we even want to try to do the job in HTTP, certainly not the w= hole job. If people want really solid request replay attack prevention for = a Web service then they should write the code into their Web Service becaus= e HTTP does not have enough visibility into their transaction to know when = the nonces should be there or not.


The same mechanism cou= ld be extended to cover public key techniques (digital signatures).

--
Website: http= ://hallambaker.com/
--089e0149411ac8eaef04dcb7c71a-- From tobias.gondrom@gondrom.org Thu May 16 00:53:49 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 BFCF521F8797 for ; Thu, 16 May 2013 00:53:49 -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 PhbJcc2kc1tw for ; Thu, 16 May 2013 00:53:45 -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 01F3421F859D for ; Thu, 16 May 2013 00:53:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=EHkrcF0eZs6rIdIxur3vfck//ixGgkq43ewBdtPcNTEnEFhoQ7tPtRWZkIgI5A4bfcSfUNPnBF47FzA/BVcK9+IM1/N70D/fX6q8CzTC+WxSIa0mTlzkZQPfIFmQsloW; 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 15767 invoked from network); 16 May 2013 09:53:43 +0200 Received: from 188-223-226-249.zone14.bethere.co.uk (HELO ?192.168.1.80?) (188.223.226.249) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 May 2013 09:53:43 +0200 Message-ID: <51949087.9020307@gondrom.org> Date: Thu, 16 May 2013 08:53:43 +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: websec@ietf.org References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 16 May 2013 07:53:49 -0000 I agree with Tom. Tobias On 11/05/13 21:09, Tom Ritter wrote: > On 7 May 2013 03:13, Yoav Nir wrote: >> How should we handle the max-max-age issue: >> (1) No hard limits, but allow UAs to limit the pin time. Suggest a month >> (2) Set a hard limit of one month in the RFC. Longer pins are truncated. >> (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month) >> (4) Adopt some gradual confidence-building scheme a-la-TACK. >> >> "None of the above" is possible, but MUST come with argument and proposed text. > > None of the above: No hard limits, leave limiting the pin time > unspecified, make no suggestion. I don't believe any text changes are > necessary. > > I think UAs that are sufficiently worried about websites bricking > themselves come up with creative solutions that work well for them, > but may not be applicable to others. (Chrome's will (or would) expire > hardcoded pins if there hasn't been a Chrome update in a month - they > could do the same for max-ages.) I don't like the idea of suggesting > that UAs unilaterally override a site's possible desire to pin for > more than 1 month. > > -tom. > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Thu May 16 00:58: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 8CF8A21F854D for ; Thu, 16 May 2013 00:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.362 X-Spam-Level: X-Spam-Status: No, score=-96.362 tagged_above=-999 required=5 tests=[AWL=1.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, GB_I_LETTER=-2, 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 62FimI4wMhH8 for ; Thu, 16 May 2013 00:58:04 -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 C333F21F901D for ; Thu, 16 May 2013 00:58:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Ap3Gfyf5dqnkhPq5l4W9waj2j/1s114eIGLQr3apNu7exlACdeaazNN5NoMRAlDNX1JlWSIt3QF7jLQwl9JIhdr0MTKD+IJ+j2U7CFhmifB+JW868k/Gu5WepWUSb6YI; 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 15797 invoked from network); 16 May 2013 09:58:02 +0200 Received: from 188-223-226-249.zone14.bethere.co.uk (HELO ?192.168.1.80?) (188.223.226.249) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 May 2013 09:58:02 +0200 Message-ID: <5194918A.7030300@gondrom.org> Date: Thu, 16 May 2013 08:58:02 +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: websec@ietf.org References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> In-Reply-To: <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Thu, 16 May 2013 07:58:08 -0000 Hi all, as mentioned before: I believe a time limit of 1 month is too short considering that some of the high profile use cases (banks, etc.) may only have monthly or bi-monthly usage. In which case the key pin would regularly expire before people return to the site and the protection is null. And regarding some of the concerns of pro-longed malicious bricking by an attacker after an attack has been resolved: Two scenarios: 1. I believe if we have a time limit of more than 1 month we need a different mechanism (e.g. user actively flushing the key cache) anyway. 2. in the case of high frequency sites (like you mentioned Facebook), imagine even a 1 month brick time would already be considered unacceptable too long by most users (in fact probably everything above a few hours would be considered too long) and trigger user action to flush the cache. Best regards, Tobias On 12/05/13 12:57, Yoav Nir wrote: > Hi Martin > > Such guidance in the spec is relevant for the rightful domain owners. Suppose an attacker got some CA to issue a bad certificate for facebook.com. The attacker now sets up this certificate on some public proxy, and sets a pin for 20 years. Within days the attack is discovered, the certificate revoked and the fake website taken down. But the user-agents that received this pin are blocked from reaching facebook. A limit would help by getting them off of facebook for just 1 month. > > Also, if a domain name is sold or transferred to another entity, a long-lived pin could mean that the new owner can't put a website there. > > I'm not saying these are compelling arguments to limit pins in the UA, but they should be considered. > > Yoav > > On May 12, 2013, at 3:40 AM, Martin J. Dürst wrote: > >> I agree with Tom Ritter, with one caveat: The spec should very clearly call out the issue (balance between too soon pin expiry and too long), rather than not mentioning it. I haven't found such language (i.e. guidance to UA implementers) in the document, but I might have looked in the wrong place (I looked at every piece of text that contained the three letters 'max'). >> >> Regards, Martin. >> >> On 2013/05/12 5:09, Tom Ritter wrote: >>> On 7 May 2013 03:13, Yoav Nir wrote: >>>> How should we handle the max-max-age issue: >>>> (1) No hard limits, but allow UAs to limit the pin time. Suggest a month >>>> (2) Set a hard limit of one month in the RFC. Longer pins are truncated. >>>> (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month) >>>> (4) Adopt some gradual confidence-building scheme a-la-TACK. >>>> >>>> "None of the above" is possible, but MUST come with argument and proposed text. >>> >>> None of the above: No hard limits, leave limiting the pin time >>> unspecified, make no suggestion. I don't believe any text changes are >>> necessary. >>> >>> I think UAs that are sufficiently worried about websites bricking >>> themselves come up with creative solutions that work well for them, >>> but may not be applicable to others. (Chrome's will (or would) expire >>> hardcoded pins if there hasn't been a Chrome update in a month - they >>> could do the same for max-ages.) I don't like the idea of suggesting >>> that UAs unilaterally override a site's possible desire to pin for >>> more than 1 month. >>> >>> -tom. > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Sat May 18 10:40:48 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 6964321F8FF2 for ; Sat, 18 May 2013 10:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.357 X-Spam-Level: * X-Spam-Status: No, score=1.357 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, RCVD_IN_SORBS_DUL=0.877, 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 4DpiIox3sJpW for ; Sat, 18 May 2013 10:40:44 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DF43521F8FEB for ; Sat, 18 May 2013 10:40:43 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id u55so4049547wes.2 for ; Sat, 18 May 2013 10:40:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=fOH4Xq39TB+Rx3jq2NUd6QQAXfqoUlUntC+8jVk28Ws=; b=PI6fUK9ANFBk7MoDAu0VoeAlz72Yjhi5MdoZcb1rJfSmLy/0WK/ocCh/8NrTnbKpEd XKhdBwfOaHXpDk9bdjybXT7H7z3tF8nibWrEE7sMofq6xjk7Z5+HGj8xiw56ysxguuTD 1rpRH1U61uQwhAOHdmbsbXvnu1bfkmzbT40yldQWdE5L+NssKHSrWDCo8koJXJhbN54t IXc1CaaSJZhPeS+Egl9D255xsIPXq+7Us803wFUvuBJWMn/cB6xuOojpYPMWs5pH8Gch HXWjUc9oq1KcD856uyFLSzHzkWZuxaQRzdOTHhM7e8771T/znnPOkIbpNwvEgP5udS7p f3iA== MIME-Version: 1.0 X-Received: by 10.194.61.50 with SMTP id m18mr6519512wjr.49.1368898842902; Sat, 18 May 2013 10:40:42 -0700 (PDT) Received: by 10.217.110.129 with HTTP; Sat, 18 May 2013 10:40:42 -0700 (PDT) X-Originating-IP: [76.21.8.64] In-Reply-To: <5194918A.7030300@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> Date: Sat, 18 May 2013 10:40:42 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: multipart/alternative; boundary=047d7b66f8e743e78104dd0199d8 X-Gm-Message-State: ALoCoQmAW+5go2m5zaWCxb5VeaNoyzT6Nh42AiRJyNep3lA1AnpnIJ9heq/z7a+K/g/DnfUhWVTE 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: Sat, 18 May 2013 17:40:48 -0000 --047d7b66f8e743e78104dd0199d8 Content-Type: text/plain; charset=ISO-8859-1 Hi Tobias, all, I think Tobias gives a fair summary of the arguments against a 30-day spec limit. Let me summarize the opposing arguments: On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom wrote: > > as mentioned before: I believe a time limit of 1 month is too short > considering that some of the high profile use cases (banks, etc.) may > only have monthly or bi-monthly usage. In which case the key pin would > regularly expire before people return to the site and the protection is > null. > You're assuming that pin assertions (like HPKP headers) are only processed by individual browsers. I hope pin assertions will *also* be processed by web crawlers to create pin lists which are made available to browsers (via preloaded lists, secure links, online lookups, etc.) In that case, having pins last a month (instead of shorter) keeps the frequency of re-crawling sites and re-downloading pin lists manageable. Longer pins wouldn't be a big improvement. > And regarding some of the concerns of pro-longed malicious bricking by > an attacker after an attack has been resolved: > Two scenarios: > 1. I believe if we have a time limit of more than 1 month we need a > different mechanism (e.g. user actively flushing the key cache) anyway. > 2. in the case of high frequency sites (like you mentioned Facebook), > imagine even a 1 month brick time would already be considered > unacceptable too long by most users (in fact probably everything above a > few hours would be considered too long) and trigger user action to flush > the cache. > Agreed that a 30-day limit is not, by itself, sufficient mitigation against "malicious bricking by an attacker after an attack". I suspect pinning will need several additional mechanisms to prevent, limit, and recover from such attacks. "Pin activation" is one mechanism I think is particularly helpful, for this case. A 30-day spec limit is more important for other reasons: 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, etc.) 2) Preventing long-term lock-in. E.g. you are pinned to CA keys which you lose trust in and suspect might be participating in MITM attacks; you are not bricked, but you are unable to change to a different CA and assert new CA pins until the old pins expire. 3) Pruning the amount of pin history you must keep your site consistent with (Do you remember what pins you or the previous domain owner asserted 6 month ago? 6 years ago? ever? They might still be out there, waiting to trip you up). In each of these cases, the site has a decision to make: 1) When can the site start using its new domain name? 2) When can the site change pinned keys? 3) What certificate chains are consistent with extant pins? Having a mandated 30-day limit makes these questions easier: 1) The site can always use a new domain name 30 days after acquiring it. 2) The site can always change pinned keys 30 days after last asserting the pin. 3) The site only has to consider pin assertions from the last 30 days. If browsers can take "creative" approaches to pin limits, per Tom Ritter [1], it's harder for sites to make these decisions. Sites would need to know what algorithms / parameters every browser is using and has used in the past. And if some browsers made bad decisions and store excessively long pins, the site will have to decide whether it's OK to make changes even if some users will have problems. Anyways, I think making things safe and simple for site operators is more important than browser creativity, or trying to maximize pinning's security benefits. That's why I still prefer a spec-mandated limit. And I think 30 days strikes a good balance between security benefits and safety, and is easy to remember and explain. Trevor [1] http://www.ietf.org/mail-archive/web/websec/current/msg01597.html --047d7b66f8e743e78104dd0199d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Tobias, all,

I think = Tobias gives a fair summary of the arguments against a 30-day spec limit. = =A0Let me summarize the opposing arguments:
<= br>
On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom= <tobias.gondrom@gondrom.org> wrote:

as mentioned before: I believe a time limit of 1 month is too short
considering that some of the high profile use cases (banks, etc.) may
only have monthly or bi-monthly usage. In which case the key pin would
regularly expire before people return to the site and the protection is
null.

You're assuming that pin= assertions (like HPKP headers) are only processed by individual browsers.= =A0

I hope pin assertions will *also* be processed= by web crawlers to create pin lists which are made available to browsers (= via preloaded lists, secure links, online lookups, etc.)

In that case, having pins last a month (instead of shor= ter) keeps the frequency of re-crawling sites and re-downloading pin lists = manageable. =A0Longer pins wouldn't be a big improvement.

=A0
And regarding some of the concerns of pro-longed malicious bricking by
an attacker after an attack has been resolved:
Two scenarios:
1. I believe if we have a time limit of more than 1 month we need a
different mechanism (e.g. user actively flushing the key cache) anyway.
2. in the case of high frequency sites (like you mentioned Facebook),
imagine even a 1 month brick time would already be considered
unacceptable too long by most users (in fact probably everything above a few hours would be considered too long) and trigger user action to flush the cache.

Agreed that a 30-= day limit is not, by itself, sufficient mitigation against "malicious = bricking by an attacker after an attack". =A0I suspect pinning will ne= ed several additional mechanisms to prevent, limit, and recover from such a= ttacks. =A0"Pin activation" is one mechanism I think is particula= rly helpful, for this case.

A 30-day spec limit is more important for other reasons= :
=A01) Domain name transfers (sales, disputes, reclaiming hijack= ed domains, etc.)
=A02) Preventing long-term lock-in. =A0E.g. you= are pinned to CA keys which you lose trust in and suspect might be partici= pating in MITM attacks; you are not bricked, but you are unable to change t= o a different CA and assert new CA pins until the old pins expire.
=A03) Pruning the amount of pin history you must keep your site consis= tent with (Do you remember what pins you or the previous domain owner asser= ted 6 month ago? 6 years ago? ever? =A0They might still be out there, waiti= ng to trip you up).
=A0
In each of these cases, the site has a decision to make:=
=A01) When can the site start using its new domain name?
=A02) When can the site change pinned keys?
=A03) What certifi= cate chains are consistent with extant pins?
=A0
Having a mandated 30-day limit makes these questions eas= ier:
=A01) The site can always use a new domain name 30 days afte= r acquiring it.
=A02) The site can always change pinned keys 30 d= ays after last asserting the pin.
=A03) The site only has to consider pin assertions from the last 30 da= ys.

If browsers can take "creative" appr= oaches to pin limits, per Tom Ritter [1], it's harder for sites to make= these decisions. =A0Sites would need to know what algorithms / parameters = every browser is using and has used in the past. =A0And if some browsers ma= de bad decisions and store excessively long pins, the site will have to dec= ide whether it's OK to make changes even if some users will have proble= ms.


Anyways, I think making things safe and = simple for site operators is more important than browser creativity, or try= ing to maximize pinning's security benefits. =A0That's why I still = prefer a spec-mandated limit. =A0And I think 30 days strikes a good balance= between security benefits and safety, and is easy to remember and explain.=


Trevor

--047d7b66f8e743e78104dd0199d8-- From ynir@checkpoint.com Tue May 21 15:26:25 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 8AD8F1F0D3A for ; Tue, 21 May 2013 15:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=0.173, 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 vl9-xK9jCT3S for ; Tue, 21 May 2013 15:26:20 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1D21F9377 for ; Tue, 21 May 2013 15:26:19 -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 r4LMQFSp021745; Wed, 22 May 2013 01:26:15 +0300 X-CheckPoint: {519BF241-1-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; Wed, 22 May 2013 01:26:14 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] Consensus call: Issue #57 (max-max-age) Thread-Index: AQHOSvJfUWwKnsbs2U6hMAgGMyNIfJkAPs4AgABLswCAAL0DAIAGBnoAgAPHdQCABQbDAA== Date: Tue, 21 May 2013 22:26:14 +0000 Message-ID: <1A1F4108-B0F3-4742-9DC5-2D8E1E56D7E1@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> 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.126] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11698b2c2cfe9a6b863c3d911ad604b1399b2bf58a Content-Type: multipart/alternative; boundary="_000_1A1F4108B0F347429DC52D8E1E56D7E1checkpointcom_" MIME-Version: 1.0 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, 21 May 2013 22:26:25 -0000 --_000_1A1F4108B0F347429DC52D8E1E56D7E1checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Trevor The suggestion that web spiders also note pins is interesting, but it's not= mentioned in the draft at all. So I believe that we have to take the draft= at face value, that it is user agents that are supposed to note pins. BTW:= assuming that relatively few sites have pins, it is also possible for the = browser itself to load pages in the background to refresh the list of pins.= Either way, we have to assume that the pin is noted by a user agent and is= noted again only when the user clicks a link or types in the address again= . I don't think we want to require anything else. I do agree that a spider or the browser itself can periodically check on pi= ns. You go on to note three cases where limiting the max-age may be beneficial: 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, et= c.) 2) Preventing long-term lock-in. E.g. you are pinned to CA keys which you= lose trust in and suspect might be participating in MITM attacks; you are = not bricked, but you are unable to change to a different CA and assert new = CA pins until the old pins expire. 3) Pruning the amount of pin history you must keep your site consistent wi= th (Do you remember what pins you or the previous domain owner asserted 6 m= onth ago? 6 years ago? ever? They might still be out there, waiting to tri= p you up). #2 and #3 make sense, but they only make sense as reasons to set max-age to= a relatively short value. It may be good to incorporate this as advice to = the administrator as to what to set max-age to. They are not a good reason,= IMO, to set a hard limit in the protocol. So we're left with #1. And I would add to that the case where an attacker m= anaged to get a valid-looking certificate for the domain (as in the diginot= ar case), and used the session to set a false pin with a long max-age. I agree that there's an issue here. I just think that it should be balanced= against the needs of infrequently accessed domains. Yoav On May 18, 2013, at 8:40 PM, Trevor Perrin > wrote: Hi Tobias, all, I think Tobias gives a fair summary of the arguments against a 30-day spec = limit. Let me summarize the opposing arguments: On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom > wrote: as mentioned before: I believe a time limit of 1 month is too short considering that some of the high profile use cases (banks, etc.) may only have monthly or bi-monthly usage. In which case the key pin would regularly expire before people return to the site and the protection is null. You're assuming that pin assertions (like HPKP headers) are only processed = by individual browsers. I hope pin assertions will *also* be processed by web crawlers to create pi= n lists which are made available to browsers (via preloaded lists, secure l= inks, online lookups, etc.) In that case, having pins last a month (instead of shorter) keeps the frequ= ency of re-crawling sites and re-downloading pin lists manageable. Longer = pins wouldn't be a big improvement. And regarding some of the concerns of pro-longed malicious bricking by an attacker after an attack has been resolved: Two scenarios: 1. I believe if we have a time limit of more than 1 month we need a different mechanism (e.g. user actively flushing the key cache) anyway. 2. in the case of high frequency sites (like you mentioned Facebook), imagine even a 1 month brick time would already be considered unacceptable too long by most users (in fact probably everything above a few hours would be considered too long) and trigger user action to flush the cache. Agreed that a 30-day limit is not, by itself, sufficient mitigation against= "malicious bricking by an attacker after an attack". I suspect pinning wi= ll need several additional mechanisms to prevent, limit, and recover from s= uch attacks. "Pin activation" is one mechanism I think is particularly hel= pful, for this case. A 30-day spec limit is more important for other reasons: 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, et= c.) 2) Preventing long-term lock-in. E.g. you are pinned to CA keys which you= lose trust in and suspect might be participating in MITM attacks; you are = not bricked, but you are unable to change to a different CA and assert new = CA pins until the old pins expire. 3) Pruning the amount of pin history you must keep your site consistent wi= th (Do you remember what pins you or the previous domain owner asserted 6 m= onth ago? 6 years ago? ever? They might still be out there, waiting to tri= p you up). In each of these cases, the site has a decision to make: 1) When can the site start using its new domain name? 2) When can the site change pinned keys? 3) What certificate chains are consistent with extant pins? Having a mandated 30-day limit makes these questions easier: 1) The site can always use a new domain name 30 days after acquiring it. 2) The site can always change pinned keys 30 days after last asserting the= pin. 3) The site only has to consider pin assertions from the last 30 days. If browsers can take "creative" approaches to pin limits, per Tom Ritter [1= ], it's harder for sites to make these decisions. Sites would need to know= what algorithms / parameters every browser is using and has used in the pa= st. And if some browsers made bad decisions and store excessively long pin= s, the site will have to decide whether it's OK to make changes even if som= e users will have problems. Anyways, I think making things safe and simple for site operators is more i= mportant than browser creativity, or trying to maximize pinning's security = benefits. That's why I still prefer a spec-mandated limit. And I think 30= days strikes a good balance between security benefits and safety, and is e= asy to remember and explain. Trevor [1] http://www.ietf.org/mail-archive/web/websec/current/msg01597.html Email secured by Check Point _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec --_000_1A1F4108B0F347429DC52D8E1E56D7E1checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <845557B58DA2E64BB47F13FE9451F66B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi Trevor

<no hats>

The suggestion that web spiders also note pins is interesting, but it'= s not mentioned in the draft at all. So I believe that we have to take the = draft at face value, that it is user agents that are supposed to note pins.= BTW: assuming that relatively few sites have pins, it is also possible for the browser itself to load pages = in the background to refresh the list of pins. Either way, we have to assum= e that the pin is noted by a user agent and is noted again only when the us= er clicks a link or types in the address again. I don't think we want to require anything else.

I do agree that a spider or the browser itself can periodically check = on pins.

You go on to note three cases where limiting the max-age may be benefi= cial:
 1) Domain name transfers (sales, disputes, reclaiming hijacked d= omains, etc.)
 2) Preventing long-term lock-in.  E.g. you are pinned to CA= keys which you lose trust in and suspect might be participating in MITM at= tacks; you are not bricked, but you are unable to change to a different CA = and assert new CA pins until the old pins expire.
 3) Pruning the amount of pin history you must keep your site con= sistent with (Do you remember what pins you or the previous domain owner as= serted 6 month ago? 6 years ago? ever?  They might still be out there,= waiting to trip you up).

#2 and #3 make sense, but they only make sense as reasons to set max-a= ge to a relatively short value. It may be good to incorporate this as advic= e to the administrator as to what to set max-age to. They are not a good re= ason, IMO, to set a hard limit in the protocol.

So we're left with #1. And I would add to that the case where an attac= ker managed to get a valid-looking certificate for the domain (as in the di= ginotar case), and used the session to set a false pin with a long max-age.=

I agree that there's an issue here. I just think that it should be bal= anced against the needs of infrequently accessed domains.

Yoav


On May 18, 2013, at 8:40 PM, Trevor Perrin <trevp@trevp.net> wrote:


Hi Tobias, all,

I think Tobias gives a fair summary of the arguments against a 30-day = spec limit.  Let me summarize the opposing arguments:


On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom= <tobias.= gondrom@gondrom.org> wrote:

as mentioned before: I believe a time limit of 1 month is too short
considering that some of the high profile use cases (banks, etc.) may
only have monthly or bi-monthly usage. In which case the key pin would
regularly expire before people return to the site and the protection is
null.

You're assuming that pin assertions (like HPKP headers) are only proce= ssed by individual browsers. 

I hope pin assertions will *also* be processed by web crawlers to crea= te pin lists which are made available to browsers (via preloaded lists, sec= ure links, online lookups, etc.)

In that case, having pins last a month (instead of shorter) keeps the = frequency of re-crawling sites and re-downloading pin lists manageable. &nb= sp;Longer pins wouldn't be a big improvement.

 
And regarding some of the concerns of pro-longed malicious bricking by
an attacker after an attack has been resolved:
Two scenarios:
1. I believe if we have a time limit of more than 1 month we need a
different mechanism (e.g. user actively flushing the key cache) anyway.
2. in the case of high frequency sites (like you mentioned Facebook),
imagine even a 1 month brick time would already be considered
unacceptable too long by most users (in fact probably everything above a few hours would be considered too long) and trigger user action to flush the cache.

Agreed that a 30-day limit is not, by itself, sufficient mitigation ag= ainst "malicious bricking by an attacker after an attack".  = I suspect pinning will need several additional mechanisms to prevent, limit= , and recover from such attacks.  "Pin activation" is one mechanism I think is particularly helpful, for this case.

A 30-day spec limit is more important for other reasons:
 1) Domain name transfers (sales, disputes, reclaiming hijacked d= omains, etc.)
 2) Preventing long-term lock-in.  E.g. you are pinned to CA= keys which you lose trust in and suspect might be participating in MITM at= tacks; you are not bricked, but you are unable to change to a different CA = and assert new CA pins until the old pins expire.
 3) Pruning the amount of pin history you must keep your site con= sistent with (Do you remember what pins you or the previous domain owner as= serted 6 month ago? 6 years ago? ever?  They might still be out there,= waiting to trip you up).
 
In each of these cases, the site has a decision to make:
 1) When can the site start using its new domain name?
 2) When can the site change pinned keys?
 3) What certificate chains are consistent with extant pins?
 
Having a mandated 30-day limit makes these questions easier:
 1) The site can always use a new domain name 30 days after acqui= ring it.
 2) The site can always change pinned keys 30 days after last ass= erting the pin.
 3) The site only has to consider pin assertions from the last 30= days.

If browsers can take "creative" approaches to pin limits, pe= r Tom Ritter [1], it's harder for sites to make these decisions.  Site= s would need to know what algorithms / parameters every browser is using an= d has used in the past.  And if some browsers made bad decisions and store excessively long pins, the site will have to decid= e whether it's OK to make changes even if some users will have problems.


Anyways, I think making things safe and simple for site operators is m= ore important than browser creativity, or trying to maximize pinning's secu= rity benefits.  That's why I still prefer a spec-mandated limit.  = ;And I think 30 days strikes a good balance between security benefits and safety, and is easy to remember and explain.=


Trevor





Email secured by Check Point

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

--_000_1A1F4108B0F347429DC52D8E1E56D7E1checkpointcom_-- From tobias.gondrom@gondrom.org Wed May 22 14:02: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 3CC8421F9673 for ; Wed, 22 May 2013 14:02:20 -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 wuQ0TvOvFHLb for ; Wed, 22 May 2013 14:02:15 -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 7131E21F964C for ; Wed, 22 May 2013 14:02:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=YS5EdMdUAm2DyY1tU980MfJTNGzbJMhusWbraCX+EQGMfR+nVGic3ttSDFaAvS/LL4c6FHMCch7eOCFg8L60uDRKTnAtA15iZMWD89eFYxxqNu9rUe5aB7AB5An45mWP; 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 4077 invoked from network); 22 May 2013 23:02:12 +0200 Received: from 188-222-102-61.zone13.bethere.co.uk (HELO ?192.168.1.86?) (188.222.102.61) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 May 2013 23:02:12 +0200 Message-ID: <519D3254.1040508@gondrom.org> Date: Wed, 22 May 2013 22:02:12 +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> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------060805060201080100030701" 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: Wed, 22 May 2013 21:02:20 -0000 This is a multi-part message in MIME format. --------------060805060201080100030701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Trevor, hi all, thanks for the thoughts. Maybe a few comments and a question inline. On 18/05/13 18:40, Trevor Perrin wrote: > > Hi Tobias, all, > > I think Tobias gives a fair summary of the arguments against a 30-day > spec limit. Let me summarize the opposing arguments: > > > On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom > > wrote: > > > as mentioned before: I believe a time limit of 1 month is too short > considering that some of the high profile use cases (banks, etc.) may > only have monthly or bi-monthly usage. In which case the key pin would > regularly expire before people return to the site and the > protection is > null. > > > You're assuming that pin assertions (like HPKP headers) are only > processed by individual browsers. > > I hope pin assertions will *also* be processed by web crawlers to > create pin lists which are made available to browsers (via preloaded > lists, secure links, online lookups, etc.) > > In that case, having pins last a month (instead of shorter) keeps the > frequency of re-crawling sites and re-downloading pin lists > manageable. Longer pins wouldn't be a big improvement.# The web crawler idea could be interesting as a solution to early pin expiry if we would have a hard limit in the RFC, but only if _all_ browsers will implement and use them. Which from my current understanding is not on the horizon. At least I have seen no such indications. Otherwise you get the varying implementations through "creative approaches" you are worried about down below (and which I don't like either). And maybe a question to go a step further: Would you agree that if we would do a 30-day hard limit as you propose, this would basically mean that all less frequent banking/paypal/... users MUST (or a very strong SHOULD) use such a web crawler to make sure that their pin has not expired before they come back? This would be a big problem in my eyes, as IMHO this assumption can not be guaranteed nor expected to be rolled out consistently. > > > And regarding some of the concerns of pro-longed malicious bricking by > an attacker after an attack has been resolved: > Two scenarios: > 1. I believe if we have a time limit of more than 1 month we need a > different mechanism (e.g. user actively flushing the key cache) > anyway. > 2. in the case of high frequency sites (like you mentioned Facebook), > imagine even a 1 month brick time would already be considered > unacceptable too long by most users (in fact probably everything > above a > few hours would be considered too long) and trigger user action to > flush > the cache. > > > Agreed that a 30-day limit is not, by itself, sufficient mitigation > against "malicious bricking by an attacker after an attack". I > suspect pinning will need several additional mechanisms to prevent, > limit, and recover from such attacks. "Pin activation" is one > mechanism I think is particularly helpful, for this case. > > A 30-day spec limit is more important for other reasons: > 1) Domain name transfers (sales, disputes, reclaiming hijacked > domains, etc.) > 2) Preventing long-term lock-in. E.g. you are pinned to CA keys > which you lose trust in and suspect might be participating in MITM > attacks; you are not bricked, but you are unable to change to a > different CA and assert new CA pins until the old pins expire. > 3) Pruning the amount of pin history you must keep your site > consistent with (Do you remember what pins you or the previous domain > owner asserted 6 month ago? 6 years ago? ever? They might still be > out there, waiting to trip you up). Hm, in my view case #2 and #3 are about your own pinning time frames and should be ok with recommendations, but would not require hard limits in the draft. And in fact as we have multiple pins in the header we have a migration path from A to B during that transition. Reading your cases, it feels to me #1 the malicious domain name transfer is the strongest case. Is that in your opinion as well? I am wondering how often that would happen? And whether we should not be solving this through other means? (e.g. flushing the cache, reseting this domain pin due to legal action or whatever?) Overall, I still think it would be better not to assert a hard time limit of 30 days in the doc. (and if at all a time limit would be there, it should be at least 60 days, to cover users who revisit sites once per month which I imagine many banking etc. users may do...). I would be very interested to also read from others on the mailing-list and the editors of the draft about their opinion on the web crawler, and the use cases? Best regards, Tobias --------------060805060201080100030701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
<hat="individual">

Hi Trevor, hi all,

thanks for the thoughts.
Maybe a few comments and a question inline.


On 18/05/13 18:40, Trevor Perrin wrote:

Hi Tobias, all,

I think Tobias gives a fair summary of the arguments against a 30-day spec limit.  Let me summarize the opposing arguments:


On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

as mentioned before: I believe a time limit of 1 month is too short
considering that some of the high profile use cases (banks, etc.) may
only have monthly or bi-monthly usage. In which case the key pin would
regularly expire before people return to the site and the protection is
null.

You're assuming that pin assertions (like HPKP headers) are only processed by individual browsers. 

I hope pin assertions will *also* be processed by web crawlers to create pin lists which are made available to browsers (via preloaded lists, secure links, online lookups, etc.)

In that case, having pins last a month (instead of shorter) keeps the frequency of re-crawling sites and re-downloading pin lists manageable.  Longer pins wouldn't be a big improvement.#

The web crawler idea could be interesting as a solution to early pin expiry if we would have a hard limit in the RFC, but only if _all_ browsers will implement and use them. Which from my current understanding is not on the horizon. At least I have seen no such indications. Otherwise you get the varying implementations through "creative approaches" you are worried about down below (and which I don't like either).

And maybe a question to go a step further:
Would you agree that if we would do a 30-day hard limit as you propose, this would basically mean that all less frequent banking/paypal/... users MUST (or a very strong SHOULD) use such a web crawler to make sure that their pin has not expired before they come back?
This would be a big problem in my eyes, as IMHO this assumption can not be guaranteed nor expected to be rolled out consistently.

 
And regarding some of the concerns of pro-longed malicious bricking by
an attacker after an attack has been resolved:
Two scenarios:
1. I believe if we have a time limit of more than 1 month we need a
different mechanism (e.g. user actively flushing the key cache) anyway.
2. in the case of high frequency sites (like you mentioned Facebook),
imagine even a 1 month brick time would already be considered
unacceptable too long by most users (in fact probably everything above a
few hours would be considered too long) and trigger user action to flush
the cache.

Agreed that a 30-day limit is not, by itself, sufficient mitigation against "malicious bricking by an attacker after an attack".  I suspect pinning will need several additional mechanisms to prevent, limit, and recover from such attacks.  "Pin activation" is one mechanism I think is particularly helpful, for this case.

A 30-day spec limit is more important for other reasons:
 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, etc.)
 2) Preventing long-term lock-in.  E.g. you are pinned to CA keys which you lose trust in and suspect might be participating in MITM attacks; you are not bricked, but you are unable to change to a different CA and assert new CA pins until the old pins expire.
 3) Pruning the amount of pin history you must keep your site consistent with (Do you remember what pins you or the previous domain owner asserted 6 month ago? 6 years ago? ever?  They might still be out there, waiting to trip you up).

Hm, in my view case #2 and #3 are about your own pinning time frames and should be ok with recommendations, but would not require hard limits in the draft. And in fact as we have multiple pins in the header we have a migration path from A to B during that transition.

Reading your cases, it feels to me #1 the malicious domain name transfer is the strongest case.
Is that in your opinion as well?
I am wondering how often that would happen? And whether we should not be solving this through other means? (e.g. flushing the cache, reseting this domain pin due to legal action or whatever?)

Overall, I still think it would be better not to assert a hard time limit of 30 days in the doc.

(and if at all a time limit would be there, it should be at least 60 days, to cover users who revisit sites once per month which I imagine many banking etc. users may do...).

I would be very interested to also read from others on the mailing-list and the editors of the draft about their opinion on the web crawler, and the use cases?

Best regards, Tobias

--------------060805060201080100030701-- From ynir@checkpoint.com Wed May 22 14:21: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 12B1011E810C for ; Wed, 22 May 2013 14:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.153, 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 hWnke1meIpSJ for ; Wed, 22 May 2013 14:21:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36F11E80A2 for ; Wed, 22 May 2013 14:21:49 -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 r4MLLktk032483; Thu, 23 May 2013 00:21:46 +0300 X-CheckPoint: {519D3498-7-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; Thu, 23 May 2013 00:21:45 +0300 From: Yoav Nir To: Tobias Gondrom Thread-Topic: [websec] Consensus call: Issue #57 (max-max-age) Thread-Index: AQHOSvJfUWwKnsbs2U6hMAgGMyNIfJkAPs4AgABLswCAAL0DAIAGBnoAgAPHdQCABoGgAIAABXaA Date: Wed, 22 May 2013 21:21:45 +0000 Message-ID: <7189D6F0-1917-419C-80F6-E8A3002642EA@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> In-Reply-To: <519D3254.1040508@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.64] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11282b60982c0b4e537b83d3e1349fc105548ac870 Content-Type: multipart/alternative; boundary="_000_7189D6F01917419C80F6E8A3002642EAcheckpointcom_" 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: Wed, 22 May 2013 21:21:57 -0000 --_000_7189D6F01917419C80F6E8A3002642EAcheckpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Tobias On May 23, 2013, at 12:02 AM, Tobias Gondrom > wrote: On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom > wrote: as mentioned before: I believe a time limit of 1 month is too short considering that some of the high profile use cases (banks, etc.) may only have monthly or bi-monthly usage. In which case the key pin would regularly expire before people return to the site and the protection is null. You're assuming that pin assertions (like HPKP headers) are only processed = by individual browsers. I hope pin assertions will *also* be processed by web crawlers to create pi= n lists which are made available to browsers (via preloaded lists, secure l= inks, online lookups, etc.) In that case, having pins last a month (instead of shorter) keeps the frequ= ency of re-crawling sites and re-downloading pin lists manageable. Longer = pins wouldn't be a big improvement.# The web crawler idea could be interesting as a solution to early pin expiry= if we would have a hard limit in the RFC, but only if _all_ browsers will = implement and use them. Which from my current understanding is not on the h= orizon. At least I have seen no such indications. Otherwise you get the var= ying implementations through "creative approaches" you are worried about do= wn below (and which I don't like either). And maybe a question to go a step further: Would you agree that if we would do a 30-day hard limit as you propose, thi= s would basically mean that all less frequent banking/paypal/... users MUST= (or a very strong SHOULD) use such a web crawler to make sure that their p= in has not expired before they come back? This would be a big problem in my eyes, as IMHO this assumption can not be = guaranteed nor expected to be rolled out consistently. There is an alternative to the web crawler (although the crawler would be b= etter). Your browser could refresh the pins in the background. If the pin i= s about to expire (say, in 7 days) and you have an Internet connection, the= browser can silently open a connection to the server, see that the SSL han= dshake fits the pin, and refresh the entry in the local pin database. This = won't scale very well if every site on the Internet has pins, but I don't r= eally expect anyone to note more than several tens of pins (banking sites, = some government, maybe things that accept credit cards). With less than 100= sites, you can make do with noting 3-4 pins per day, which shouldn't consu= me too much traffic. I guess browsers would stop refreshing pins if you don't visit the site for= a year. Yoav --_000_7189D6F01917419C80F6E8A3002642EAcheckpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Tobias

On May 23, 2013, at 12:02 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

<snip />

On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom= <tobias.gondrom@gondrom.org> wrote:

as mentioned before: I believe a time limit of 1 month is too short
considering that some of the high profile use cases (banks, etc.) may
only have monthly or bi-monthly usage. In which case the key pin would
regularly expire before people return to the site and the protection is
null.

You're assuming that pin assertions (like HPKP headers) are only proce= ssed by individual browsers. 

I hope pin assertions will *also* be processed by web crawlers to crea= te pin lists which are made available to browsers (via preloaded lists, sec= ure links, online lookups, etc.)

In that case, having pins last a month (instead of shorter) keeps the = frequency of re-crawling sites and re-downloading pin lists manageable. &nb= sp;Longer pins wouldn't be a big improvement.#

The web crawler idea could be interesting as a solution to early pin expiry= if we would have a hard limit in the RFC, but only if _all_ browsers will = implement and use them. Which from my current understanding is not on the h= orizon. At least I have seen no such indications. Otherwise you get the varying implementations through &q= uot;creative approaches" you are worried about down below (and which I= don't like either).

And maybe a question to go a step further:
Would you agree that if we would do a 30-day hard limit as you propose, thi= s would basically mean that all less frequent banking/paypal/... users MUST= (or a very strong SHOULD) use such a web crawler to make sure that their p= in has not expired before they come back?
This would be a big problem in my eyes, as IMHO this assumption can not be = guaranteed nor expected to be rolled out consistently.

There is an alternative to the web crawler (although the crawler would= be better). Your browser could refresh the pins in the background. If the = pin is about to expire (say, in 7 days) and you have an Internet connection= , the browser can silently open a connection to the server, see that the SSL handshake fits the pin, and r= efresh the entry in the local pin database. This won't scale very well if e= very site on the Internet has pins, but I don't really expect anyone to not= e more than several tens of pins (banking sites, some government, maybe things that accept credit cards). W= ith less than 100 sites, you can make do with noting 3-4 pins per day, whic= h shouldn't consume too much traffic.

I guess browsers would stop refreshing pins if you don't visit the sit= e for a year.

Yoav

--_000_7189D6F01917419C80F6E8A3002642EAcheckpointcom_-- From tobias.gondrom@gondrom.org Wed May 22 14:46: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 22DC511E813B for ; Wed, 22 May 2013 14:46:27 -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 q+d5clI3Hysi for ; Wed, 22 May 2013 14:46:22 -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 4623811E8123 for ; Wed, 22 May 2013 14:46:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=hf02zUNni89pDI6Mp2Y86JUtTWiMaBORlWZS2mk/Q25GjU9H4GakF/cvS0HTVN6iYcUgGHgZiYEFQeHQzu6ZJR3O/5lNbXVBMXWler3z8txOB5/gmZkUDpb4KJOfSUYC; 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 5288 invoked from network); 22 May 2013 23:46:19 +0200 Received: from 188-222-102-61.zone13.bethere.co.uk (HELO ?192.168.1.86?) (188.222.102.61) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 May 2013 23:46:19 +0200 Message-ID: <519D3CAB.80004@gondrom.org> Date: Wed, 22 May 2013 22:46: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: 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> <7189D6F0-1917-419C-80F6-E8A3002642EA@checkpoint.com> In-Reply-To: <7189D6F0-1917-419C-80F6-E8A3002642EA@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------030804070107000306000004" 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: Wed, 22 May 2013 21:46:27 -0000 This is a multi-part message in MIME format. --------------030804070107000306000004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/05/13 22:21, Yoav Nir wrote: > Hi, Tobias > > On May 23, 2013, at 12:02 AM, Tobias Gondrom > > wrote: > > > >>> On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom >>> > wrote: >>> >>> >>> as mentioned before: I believe a time limit of 1 month is too short >>> considering that some of the high profile use cases (banks, >>> etc.) may >>> only have monthly or bi-monthly usage. In which case the key pin >>> would >>> regularly expire before people return to the site and the >>> protection is >>> null. >>> >>> >>> You're assuming that pin assertions (like HPKP headers) are only >>> processed by individual browsers. >>> >>> I hope pin assertions will *also* be processed by web crawlers to >>> create pin lists which are made available to browsers (via preloaded >>> lists, secure links, online lookups, etc.) >>> >>> In that case, having pins last a month (instead of shorter) keeps >>> the frequency of re-crawling sites and re-downloading pin lists >>> manageable. Longer pins wouldn't be a big improvement.# >> >> The web crawler idea could be interesting as a solution to early pin >> expiry if we would have a hard limit in the RFC, but only if _all_ >> browsers will implement and use them. Which from my current >> understanding is not on the horizon. At least I have seen no such >> indications. Otherwise you get the varying implementations through >> "creative approaches" you are worried about down below (and which I >> don't like either). >> >> And maybe a question to go a step further: >> Would you agree that if we would do a 30-day hard limit as you >> propose, this would basically mean that all less frequent >> banking/paypal/... users MUST (or a very strong SHOULD) use such a >> web crawler to make sure that their pin has not expired before they >> come back? >> This would be a big problem in my eyes, as IMHO this assumption can >> not be guaranteed nor expected to be rolled out consistently. > > There is an alternative to the web crawler (although the crawler would > be better). Your browser could refresh the pins in the background. If > the pin is about to expire (say, in 7 days) and you have an Internet > connection, the browser can silently open a connection to the server, > see that the SSL handshake fits the pin, and refresh the entry in the > local pin database. This won't scale very well if every site on the > Internet has pins, but I don't really expect anyone to note more than > several tens of pins (banking sites, some government, maybe things > that accept credit cards). With less than 100 sites, you can make do > with noting 3-4 pins per day, which shouldn't consume too much traffic. Interesting idea. And could this maybe also solve Trevor's concerns? E.g. we could add to the spec some implementation advise, like "even if the user does not visit the pinned sites, the browser SHOULD attempt in the background to refresh recognized pins if they are about to expire or before 30 days have passed...." That way, pinning updates would come in earlier even though the visit is maybe only monthly. Could possibly solve Trevor's use cases #2 and #3? Note: I would still not want the 30 day hard limit in the spec, because I feel that this can give results that will be unexpected from a user point of view... Best regards, Tobias > > I guess browsers would stop refreshing pins if you don't visit the > site for a year. > > Yoav > --------------030804070107000306000004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/05/13 22:21, Yoav Nir wrote:
Hi, Tobias

On May 23, 2013, at 12:02 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

<snip />

On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

as mentioned before: I believe a time limit of 1 month is too short
considering that some of the high profile use cases (banks, etc.) may
only have monthly or bi-monthly usage. In which case the key pin would
regularly expire before people return to the site and the protection is
null.

You're assuming that pin assertions (like HPKP headers) are only processed by individual browsers. 

I hope pin assertions will *also* be processed by web crawlers to create pin lists which are made available to browsers (via preloaded lists, secure links, online lookups, etc.)

In that case, having pins last a month (instead of shorter) keeps the frequency of re-crawling sites and re-downloading pin lists manageable.  Longer pins wouldn't be a big improvement.#

The web crawler idea could be interesting as a solution to early pin expiry if we would have a hard limit in the RFC, but only if _all_ browsers will implement and use them. Which from my current understanding is not on the horizon. At least I have seen no such indications. Otherwise you get the varying implementations through "creative approaches" you are worried about down below (and which I don't like either).

And maybe a question to go a step further:
Would you agree that if we would do a 30-day hard limit as you propose, this would basically mean that all less frequent banking/paypal/... users MUST (or a very strong SHOULD) use such a web crawler to make sure that their pin has not expired before they come back?
This would be a big problem in my eyes, as IMHO this assumption can not be guaranteed nor expected to be rolled out consistently.

There is an alternative to the web crawler (although the crawler would be better). Your browser could refresh the pins in the background. If the pin is about to expire (say, in 7 days) and you have an Internet connection, the browser can silently open a connection to the server, see that the SSL handshake fits the pin, and refresh the entry in the local pin database. This won't scale very well if every site on the Internet has pins, but I don't really expect anyone to note more than several tens of pins (banking sites, some government, maybe things that accept credit cards). With less than 100 sites, you can make do with noting 3-4 pins per day, which shouldn't consume too much traffic.

Interesting idea.
And could this maybe also solve Trevor's concerns?

E.g. we could add to the spec some implementation advise, like "even if the user does not visit the pinned sites, the browser SHOULD attempt in the background to refresh recognized pins if they are about to expire or before 30 days have passed...."

That way, pinning updates would come in earlier even though the visit is maybe only monthly.
Could possibly solve Trevor's use cases #2 and #3?

Note: I would still not want the 30 day hard limit in the spec, because I feel that this can give results that will be unexpected from a user point of view...

Best regards, Tobias



I guess browsers would stop refreshing pins if you don't visit the site for a year.

Yoav


--------------030804070107000306000004-- From dkg@fifthhorseman.net Wed May 22 14:56: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 018B921F9193 for ; Wed, 22 May 2013 14:56:40 -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 cfnQGU5xo21o for ; Wed, 22 May 2013 14:56:34 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DC20821F9180 for ; Wed, 22 May 2013 14:56:33 -0700 (PDT) Received: from fifthhorseman.net (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id C533EF97F for ; Wed, 22 May 2013 17:56:30 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2F33A1FDE5; Wed, 22 May 2013 17:56:31 -0400 (EDT) From: Daniel Kahn Gillmor To: websec@ietf.org User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Wed, 22 May 2013 17:56:28 -0400 Message-ID: <87sj1e8yr7.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Subject: [websec] Strict-Transport-Security and mixed-content warnings 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, 22 May 2013 21:56:40 -0000 --=-=-= Content-Type: text/plain hi websec folks-- I am wondering what people think the proper intersection is between a web browser's mixed-content warnings and HSTS. For example, if https://example.net has asserted Strict-Transport-Security: max-age=15768000 but the homepage at https://example.net/ also contains should an HSTS-compatible browser show its standard mixed-content warning even though it knows to rewrite that img src to https://example.net/example.jpg ? My intuition is that this shouldn't trigger the browser's mixed-content warning, but chromium 26.0.1410.43 does show it, and https://code.google.com/p/chromium/issues/detail?id=122548#c26 suggests that palmer@ and rsleevi@ think that is the correct behavior because they want: > to signal to the site author of an error - for example, if users which > did not have HSTS visited. I'm not sure how the author is supposed to get this signal from the site visitor's browser, though -- perhaps the expectation is that site visitors will independently report the "broken lock" to the site administrator? I also note that firefox 21.0 (when security.mixed_content.block_display_content = true) doesn't show the media at all, and when security.mixed_content.block_display_content = false it shows the image but removes the lock from the address bar (which i think is the equivalent of the "mixed content warning" these days). Do other folks have any thoughts about the right thing is to do here? --dkg --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQJ8BAEBCgBmBQJRnT8MXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpces4QAMaxMxHdrZS6CEEXk1GYoqgB L26Iys0QTq8VwxyW220bU1bej6ke8juP5plHLRIxdjNDKcZqIJeX7mi6mmaFHm2d lmQ2nXWAWM9PkYtC6ZXKulkaVqXG5NNsM853ezx1t1BE/B6Bnn6dyh8673MLczz3 gJcaV900IQO/NhZZwHhUz8XlDx0imAPiJe3QErJbvPHUo7vO5oDn7XrOIWgQ3G8a 40ScZ8j4Qy3jl7HGLv566+DI7ruHNQ5qhLkgYAI+yNc0xeKz05T4vhC/X0ukWmmq KBDv6LYVTBk+VNafEGj2H3GHIzL146mOBmxiSNNQUVGOJOR6/5BRTGAQRA3J2LL0 6AdiAS4RFe/Zf0uaYLri8R/K9jPabnH4Zrkc7Om/WmTUt+Juu1mIeia9TfaAdKIa vMptAqZEn6iWVrTtCAiJ7cX3SaGsw3MKsSjH4doasf0n+IAcjKeMxr8O9khL/Efa mWN+edJB6FkypXpVAdtnlL09uzCh0Ui5Y84zwAPOyRLOff8G26eaVdQT+5fX7r1c +CdR5DEJUxYpwmmAbPxZjQ3O01660G1KozoKJJSYJrs5UFDlOUVVS9MErj+Cz1pA ukvgeoSujkkG8XuhxHxHClWT5SOXCodIFXZzAARZweaYPWcaerd3UF2QLtGWWh4f fjiFI1AH7CjUs3MYpVJ2 =i1Au -----END PGP SIGNATURE----- --=-=-=-- From trevp@trevp.net Wed May 22 15:29: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 6DDEA11E814C for ; Wed, 22 May 2013 15:29:39 -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 QrizYZ8I17to for ; Wed, 22 May 2013 15:29:35 -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 702B911E813A for ; Wed, 22 May 2013 15:29:33 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id u57so1646575wes.12 for ; Wed, 22 May 2013 15:29:33 -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=jF9vQYZwzofmYLqB2ED3OHpXVf7qSyv11l99eChfERQ=; b=LxeOtsmo2l8+tkE2Lq4031qn2LqgRAZN1l8lCS5xm+z5HoKwtDKDEE5JRkGOZg9I6Q KIBo2lqJzoJlVx8V3WiMmPoBdIYdF2EcRzhqdLzsdKiMcayKAvvaPR1EO317ebLFHHyd BPp9Lo1zerZ8K5k0xT5E03UvKAm2OkdQZ3st/Ms86cR5ORmy8dNPTre5jts3n8dLvRe5 Bhl79WgZW12SCIa5aICI5Rm5Nr2uAeYPERHZcqpgk1J9ojdFb8UVyxWr71pqg/Jq3I1c Q9zmcvflUvAzENpJAU56c1WHiqyhGBrIGT1w8SNNgxDR/r9aHmDiuUYjjsAOxd0LQHY/ hIzQ== MIME-Version: 1.0 X-Received: by 10.180.108.168 with SMTP id hl8mr19119310wib.23.1369261773008; Wed, 22 May 2013 15:29:33 -0700 (PDT) Received: by 10.217.110.129 with HTTP; Wed, 22 May 2013 15:29:32 -0700 (PDT) X-Originating-IP: [208.70.28.214] In-Reply-To: <1A1F4108-B0F3-4742-9DC5-2D8E1E56D7E1@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> <1A1F4108-B0F3-4742-9DC5-2D8E1E56D7E1@checkpoint.com> Date: Wed, 22 May 2013 15:29:32 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=e89a8f3ba2f395ca8304dd56198f X-Gm-Message-State: ALoCoQmbgi6FboM6rTiltLQB5faIX8sSok85dd3YtGJxHpJ2FKJyOOZA/wBPgK6UHVmqwrgAXe37 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: Wed, 22 May 2013 22:29:39 -0000 --e89a8f3ba2f395ca8304dd56198f Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav, On Tue, May 21, 2013 at 3:26 PM, Yoav Nir wrote: > Hi Trevor > > > > The suggestion that web spiders also note pins is interesting, but it's > not mentioned in the draft at all. > I think this possibility should be mentioned. The draft discusses "Preloaded Pin Lists", which are presumably conveyed to the UA from some 3rd party (eg browser vendor). It seems reasonable for such lists to be created or kept fresh by scanning web sites. I believe Mozilla is taking this approach to HSTS [1]. Besides preloaded lists, there's other proposals that could discover pins based on scans and then send fresh pins to clients (Convergence, S-Links, Omnibroker, etc.) So I think the draft should endorse the idea that pins might be discovered by one party, then used by a second party. If we agree this is a possible way to use server-asserted pins, then we shouldn't assume that a 30-day pin is always worthless to a UA who can't contact a site every 30 days. > So I believe that we have to take the draft at face value, that it is user > agents that are supposed to note pins. BTW: assuming that relatively few > sites have pins, it is also possible for the browser itself to load pages > in the background to refresh the list of pins. > Seems like a privacy risk to have the browser connecting back to pinned sites on some interval. Eg: you're at a coffee shop and your browser decides to refresh pins for your embarrasing hobby sites. Someone observes these queries via sniffer... If the global set of pins is small enough, the browser could periodically fetch the entire thing (or the most important 10,000 pins, say). I think that's a practical, simple example of using 3rd-party infrastructure. > Either way, we have to assume that the pin is noted by a user agent and is > noted again only when the user clicks a link or types in the address again. > I don't think we want to require anything else. > > I do agree that a spider or the browser itself can periodically check on > pins. > > You go on to note three cases where limiting the max-age may be > beneficial: > > 1) Domain name transfers (sales, disputes, reclaiming hijacked > domains, etc.) > 2) Preventing long-term lock-in. E.g. you are pinned to CA keys which > you lose trust in and suspect might be participating in MITM attacks; you > are not bricked, but you are unable to change to a different CA and assert > new CA pins until the old pins expire. > 3) Pruning the amount of pin history you must keep your site consistent > with (Do you remember what pins you or the previous domain owner asserted 6 > month ago? 6 years ago? ever? They might still be out there, waiting to > trip you up). > > > #2 and #3 make sense, but they only make sense as reasons to set max-age > to a relatively short value. It may be good to incorporate this as advice > to the administrator as to what to set max-age to. They are not a good > reason, IMO, to set a hard limit in the protocol. > Not sure I agree. #2 and #3 are consequences of long-lived bad pins (lock-in to keys/CAs; and uncertainty over what pins might have been asserted by previous sysadmins, domain owners, or attackers). But these bad pins could arise from site mistakes, attacks, or previous domain name owners, so asking sites to assert short-lived pins doesn't guarantee they won't happen. I'll try to break down the proposals for pin lifetimes: A) Sites assert short-lifetime pins B) UAs choose their own pin-lifetime limit C) Spec limit (A) doesn't help with site mistakes, domain name transfers, or attacks (disgruntled site administrator, hacker, or domain hijacker setting bad pins, etc). (B) doesn't give sites a guaranteed recovery period after which any bad pins will disappear. Let's say you acquire a new domain name, or you suspect the previous admin was sloppy with pins, or a hacker might have set bad pins. If UAs can do whatever they want, then you can't be sure there aren't bad pins hanging around somewhere, from *anything* that might have happened *anytime* in the past. Even if your domain seems to be working, there could be bad "report-only" pins that are reporting on your users, or that are locking you in to your current CA and which you might not discover until you actually try to change CAs (months or years later)... Anyways, a spec limit solves these problems - no matter what mistakes, ownership changes, or attacks a domain name suffers, the site has a hard guarantee that only the last 30 days of pin assertions matter. Trevor [1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ --e89a8f3ba2f395ca8304dd56198f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Yoav,
On Tue, May 21, 2013 at 3:26 PM, Yoav Nir <y= nir@checkpoint.com> wrote:
Hi Trevor

<no hats>

The suggestion that web spiders also note pins is interesting, but it&= #39;s not mentioned in the draft at all.

<= /div>
I think this possibility should be mentioned.

The draft discusses "Preloaded Pin Lists", which a= re presumably conveyed to the UA from some 3rd party (eg browser vendor). = =A0It seems reasonable for such lists to be created or kept fresh by scanni= ng web sites. =A0I believe Mozilla is taking this approach to HSTS [1].

Besides preloaded lists, there's other proposals th= at could discover pins based on scans and then send fresh pins to clients (= Convergence, S-Links, Omnibroker, etc.)

So I think= the draft should endorse the idea that pins might be discovered by one par= ty, then used by a second party. =A0

If we agree this is a possible way to use server-assert= ed pins, then we shouldn't assume that a 30-day pin is always worthless= to a UA who can't contact a site every 30 days.

=A0
So I believe that we have to take the draft at face value, that it is u= ser agents that are supposed to note pins. BTW: assuming that relatively fe= w sites have pins, it is also possible for the browser itself to load pages = in the background to refresh the list of pins.

Seems like a privacy risk to have the browser connect= ing back to pinned sites on some interval. =A0Eg: you're at a coffee sh= op and your browser decides to refresh pins for your embarrasing hobby site= s. =A0Someone observes these queries via sniffer...

If the global set of pins is small enough, = the browser could periodically fetch the entire thing (or the most importan= t 10,000 pins, say). =A0I think that's a practical, simple example of u= sing 3rd-party infrastructure.

=A0
Either way, we have to assume that the pin is noted by a user agent a= nd is noted again only when the user clicks a link or types in the address again. I don't think we want to require anything else.

I do agree that a spider or the browser itself can periodically check = on pins.

You go on to note three cases where limiting the max-age may be benefi= cial:
=A01) Domain name transfers (sales, disputes, reclaiming hijacked doma= ins, etc.)
=A02) Preventing long-term lock-in. =A0E.g. you are pinned to CA keys = which you lose trust in and suspect might be participating in MITM attacks;= you are not bricked, but you are unable to change to a different CA and as= sert new CA pins until the old pins expire.
=A03) Pruning the amount of pin history you must keep your site consis= tent with (Do you remember what pins you or the previous domain owner asser= ted 6 month ago? 6 years ago? ever? =A0They might still be out there, waiti= ng to trip you up).

#2 and #3 make sense, but they only make sense as reasons to set= max-age to a relatively short value. It may be good to incorporate this as= advice to the administrator as to what to set max-age to. They are not a g= ood reason, IMO, to set a hard limit in the protocol.

Not sure I= agree. =A0#2 and #3 are consequences of long-lived bad pins (lock-in to ke= ys/CAs; and uncertainty over what pins might have been asserted by previous= sysadmins, domain owners, or attackers).

But these bad pins could arise from site mi= stakes, attacks, or previous domain name owners, so asking sites to assert = short-lived pins doesn't guarantee they won't happen.

I'll try to break down the proposals for pin = lifetimes:

=A0A) Sites assert short-lifetime pins<= /div>
=A0B) UAs choose their own pin-lifetime limit
=A0C) Spe= c limit

(A) doesn't help with site mistakes, domain name tr= ansfers, or attacks (disgruntled site administrator, hacker, or domain hija= cker setting bad pins, etc).

(B) doesn't= give sites a guaranteed recovery period after which any bad pins will disa= ppear. =A0Let's say you acquire a new domain name, or you suspect the p= revious admin was sloppy with pins, or a hacker might have set bad pins. = =A0If UAs can do whatever they want, then you can't be sure there aren&= #39;t bad pins hanging around somewhere, from *anything* that might have ha= ppened *anytime* in the past. =A0Even if your domain seems to be working, t= here could be bad "report-only" pins that are reporting on your u= sers, or that are locking you in to your current CA and which you might not= discover until you actually try to change CAs (months or years later)...

Anyways, a spec limit solves these problems - no matter= what mistakes, ownership changes, or attacks a domain name suffers, the si= te has a hard guarantee that only the last 30 days of pin assertions matter= .


--e89a8f3ba2f395ca8304dd56198f-- From ryan-ietfhasmat@sleevi.com Wed May 22 15:45: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 1299F21F90DF for ; Wed, 22 May 2013 15:45:56 -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 hjWI6CAub7Ck for ; Wed, 22 May 2013 15:45:51 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0F02E21F90D2 for ; Wed, 22 May 2013 15:45:51 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id BD9DCBC032; Wed, 22 May 2013 15:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=X0fJHMcyqd5oX6QqVGe1Xzk2tmw=; b=m8uOyrNDwJvezx6po l2QJjeoTSfMDzkrC+ELCc+aatp0EPk7AH/CX2R6f32Z07rpcL6L2aH2+UroIAJIl 8/kTZ2t8u+incurckTOJENRWQ/R7bgSAemdcMfb90zNSJDLFg4hs7HzgtVYAOMg6 jYntBwCF4JZkH6kp9FFSffmflE= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 736A1BC031; Wed, 22 May 2013 15:45:50 -0700 (PDT) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 22 May 2013 15:45:50 -0700 Message-ID: <1da99e22e4f28c080510f136765a6bcb.squirrel@webmail.dreamhost.com> In-Reply-To: <519D3CAB.80004@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> <7189D6F0-1917-419C-80F6-E8A3002642EA@checkpoint.com> <519D3CAB.80004@gondrom.org> Date: Wed, 22 May 2013 15:45:50 -0700 From: "Ryan Sleevi" To: "Tobias Gondrom" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 22:45:56 -0000 On Wed, May 22, 2013 2:46 pm, Tobias Gondrom wrote: > On 22/05/13 22:21, Yoav Nir wrote: > > Hi, Tobias > > > > On May 23, 2013, at 12:02 AM, Tobias Gondrom > > > wrot= e: > > > > > > > >>> On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom > >>> > > >>> wrote: > >>> > >>> > >>> as mentioned before: I believe a time limit of 1 month is too > >>> short > >>> considering that some of the high profile use cases (banks, > >>> etc.) may > >>> only have monthly or bi-monthly usage. In which case the key pi= n > >>> would > >>> regularly expire before people return to the site and the > >>> protection is > >>> null. > >>> > >>> > >>> You're assuming that pin assertions (like HPKP headers) are only > >>> processed by individual browsers. > >>> > >>> I hope pin assertions will *also* be processed by web crawlers to > >>> create pin lists which are made available to browsers (via preloade= d > >>> lists, secure links, online lookups, etc.) > >>> > >>> In that case, having pins last a month (instead of shorter) keeps > >>> the frequency of re-crawling sites and re-downloading pin lists > >>> manageable. Longer pins wouldn't be a big improvement.# > >> > >> The web crawler idea could be interesting as a solution to early pin > >> expiry if we would have a hard limit in the RFC, but only if _all_ > >> browsers will implement and use them. Which from my current > >> understanding is not on the horizon. At least I have seen no such > >> indications. Otherwise you get the varying implementations through > >> "creative approaches" you are worried about down below (and which I > >> don't like either). > >> > >> And maybe a question to go a step further: > >> Would you agree that if we would do a 30-day hard limit as you > >> propose, this would basically mean that all less frequent > >> banking/paypal/... users MUST (or a very strong SHOULD) use such a > >> web crawler to make sure that their pin has not expired before they > >> come back? > >> This would be a big problem in my eyes, as IMHO this assumption can > >> not be guaranteed nor expected to be rolled out consistently. > > > > There is an alternative to the web crawler (although the crawler woul= d > > be better). Your browser could refresh the pins in the background. If > > the pin is about to expire (say, in 7 days) and you have an Internet > > connection, the browser can silently open a connection to the server, > > see that the SSL handshake fits the pin, and refresh the entry in the > > local pin database. This won't scale very well if every site on the > > Internet has pins, but I don't really expect anyone to note more than > > several tens of pins (banking sites, some government, maybe things > > that accept credit cards). With less than 100 sites, you can make do > > with noting 3-4 pins per day, which shouldn't consume too much traffi= c. > > Interesting idea. > And could this maybe also solve Trevor's concerns? > > E.g. we could add to the spec some implementation advise, like "even i= f > the user does not visit the pinned sites, the browser SHOULD attempt i= n > the background to refresh recognized pins if they are about to expire = or > before 30 days have passed...." > > That way, pinning updates would come in earlier even though the visit = is > maybe only monthly. > Could possibly solve Trevor's use cases #2 and #3? > > Note: I would still not want the 30 day hard limit in the spec, becaus= e > I feel that this can give results that will be unexpected from a user > point of view... > > Best regards, Tobias > Sorry for not chiming in sooner, but I don't think we'd consider a pollin= g based solution as being viable for implementation. We've certainly discussed these in-house and had discussions with other browser vendors, and I don't think anyone is too enthused with the idea. I can certainly understand and appreciate Trevor's concerns - and I haven't really had a chance to sit down and give them the considered response they deserve - but I did want to provide at least some feedback before we got too far out there onto the 'background polling' bandwagon. Cheers, Ryan From ryan-ietfhasmat@sleevi.com Wed May 22 15:53: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 6C4E611E816B for ; Wed, 22 May 2013 15:53:46 -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 aeh-fhSX2ORh for ; Wed, 22 May 2013 15:53:41 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 95E2511E814B for ; Wed, 22 May 2013 15:53:34 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 5783A318059; Wed, 22 May 2013 15:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=AzdUrmfuDMWSUaFN3m/3mzGRK08=; b=Dn97b+yfx2aoPcSy7 gFtf9MHgJo7G6euJxBN0Oj/JYr0Lf5cI2Ro8TLUO3i4BDIxksmv33HEG4BJk2mCn CUSUAZzhggP7NrwZygz5KEjCe4ZFPdfhG69E/QJgNnV7W3Vbw+Vv4m742Mu2C7pF BVafOw0wGuFBGBcjJedXcheJRE= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 0C86C318064; Wed, 22 May 2013 15:53:22 -0700 (PDT) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 22 May 2013 15:52:52 -0700 Message-ID: <5833d9ac9b80141674bece13781fee36.squirrel@webmail.dreamhost.com> In-Reply-To: <87sj1e8yr7.fsf@alice.fifthhorseman.net> References: <87sj1e8yr7.fsf@alice.fifthhorseman.net> Date: Wed, 22 May 2013 15:52:52 -0700 From: "Ryan Sleevi" To: "Daniel Kahn Gillmor" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security and mixed-content warnings X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 22:53:46 -0000 On Wed, May 22, 2013 2:56 pm, Daniel Kahn Gillmor wrote: > hi websec folks-- > > I am wondering what people think the proper intersection is between a > web browser's mixed-content warnings and HSTS. > > For example, if https://example.net has asserted > Strict-Transport-Security: max-age=3D15768000 but the homepage at > https://example.net/ also contains > > > > should an HSTS-compatible browser show its standard mixed-content > warning even though it knows to rewrite that img src to > https://example.net/example.jpg ? > > My intuition is that this shouldn't trigger the browser's mixed-conten= t > warning, but chromium 26.0.1410.43 does show it, and > > https://code.google.com/p/chromium/issues/detail?id=3D122548#c26 > > suggests that palmer@ and rsleevi@ think that is the correct behavior > because they want: > > > to signal to the site author of an error - for example, if users whic= h > > did not have HSTS visited. > > I'm not sure how the author is supposed to get this signal from the si= te > visitor's browser, though -- perhaps the expectation is that site > visitors will independently report the "broken lock" to the site > administrator? Yes. The view is that it's still a legitimate error for the site operator, in that any user without HSTS protections (or with expired HSTS) is still at risk. While HSTS may be providing protection to the user, the site itself is still configured to serve resources insecurely, thus we still surface it as user visible. > > I also note that firefox 21.0 (when > security.mixed_content.block_display_content =3D true) doesn't show th= e > media at all, and when security.mixed_content.block_display_content =3D > false it shows the image but removes the lock from the address bar > (which i think is the equivalent of the "mixed content warning" these > days). I believe the Firefox behaviour is an artifact of their current (partial) implementation of mixed content blocking. According to https://blog.mozilla.org/security/2013/05/16/mixed-content-blocking-in-fi= refox-aurora/ , future versions should distinguish between active and passive content, and thus more closely mirror the Chromium behaviour by default (namely, that it will block active content, but not passive content) > > Do other folks have any thoughts about the right thing is to do here? > ISTM that UI behaviours are largely outside the realm of what the IETF standardizes. That said, certainly feedback is welcomed on this, and I would love to se= e consistent handling (which, AFAIK, we will soon have). I'm just not sure if this is really a "spec issue". From trevp@trevp.net Wed May 22 16:09: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 2EEB511E814E for ; Wed, 22 May 2013 16:09:27 -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 CYfUA2Q8gdWd for ; Wed, 22 May 2013 16:09:20 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC711E814B for ; Wed, 22 May 2013 16:09:20 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so1705398wib.10 for ; Wed, 22 May 2013 16:09:19 -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=DbXphFPKjl8mzpi8CpMbCFEhQL3x6tMEMY7VIe1oJvM=; b=fzcydp/g/ohX0MMa1/SJOBSZXtq83pW4OPFvl9wXvWrog8p4BqiFaKh/eQIJKDz4++ d3w9GtthXH4BZ4LSCDw89AwtzPxQUfsl4VCFo6qiZ25DSGvLXSgQc+8Y49VtLD9a0OQt XNP1goYVHWvUl7oQCK2/P+DBOs41ugxhkVnEiBl/ecbhdgk14RMx1uYTklOjQjGivoJ+ Ig0G95kK/DQCjJ4YoIuvRzsXo1BTGuamkMX5HJeCXbX7136gqujULPMakGlKwUALe0u2 jQfEtdLTK1xSkKo3xAlNeNZ74/mfLSNkAHMrsJMLYESzdAcnq0W1uAAvLxbGOvnXWGBF Lsvg== MIME-Version: 1.0 X-Received: by 10.180.99.232 with SMTP id et8mr38229289wib.17.1369264159393; Wed, 22 May 2013 16:09:19 -0700 (PDT) Received: by 10.217.110.129 with HTTP; Wed, 22 May 2013 16:09:19 -0700 (PDT) X-Originating-IP: [208.70.28.214] In-Reply-To: <519D3254.1040508@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> Date: Wed, 22 May 2013 16:09:19 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: multipart/alternative; boundary=f46d041825acd31e7604dd56a7c7 X-Gm-Message-State: ALoCoQm01Q8h3qSt651GyWc1Q+sbTs63bOgxr9+hojLwe3Pl8A67llqEVLl2iJ5UfRCh9U7f5k4p 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: Wed, 22 May 2013 23:09:27 -0000 --f46d041825acd31e7604dd56a7c7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 2:02 PM, Tobias Gondrom wrote: > > And maybe a question to go a step further: > Would you agree that if we would do a 30-day hard limit as you propose, > this would basically mean that all less frequent banking/paypal/... users > MUST (or a very strong SHOULD) use such a web crawler to make sure that > their pin has not expired before they come back? > Pins created by the UA itself won't protect initial connections, or provide security when expired. These are inherent limits of UA-derived pins. So I don't think a spec-limit makes these problems dramatically worse, or requires new mandates for UAs. You could, however, note the deficiences of UA-derived pins in the Security Considerations, and say something something like: "Clients are advised to make use of 3rd-party trust infrastructure so that pins can be aggregated and shared. This will require additional protocols outside the scope of this document." > This would be a big problem in my eyes, as IMHO this assumption can not be > guaranteed nor expected to be rolled out consistently. > > > >> And regarding some of the concerns of pro-longed malicious bricking by >> an attacker after an attack has been resolved: >> Two scenarios: >> 1. I believe if we have a time limit of more than 1 month we need a >> different mechanism (e.g. user actively flushing the key cache) anyway. >> 2. in the case of high frequency sites (like you mentioned Facebook), >> imagine even a 1 month brick time would already be considered >> unacceptable too long by most users (in fact probably everything above a >> few hours would be considered too long) and trigger user action to flush >> the cache. >> > > Agreed that a 30-day limit is not, by itself, sufficient mitigation > against "malicious bricking by an attacker after an attack". I suspect > pinning will need several additional mechanisms to prevent, limit, and > recover from such attacks. "Pin activation" is one mechanism I think is > particularly helpful, for this case. > > A 30-day spec limit is more important for other reasons: > 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, > etc.) > 2) Preventing long-term lock-in. E.g. you are pinned to CA keys which > you lose trust in and suspect might be participating in MITM attacks; you > are not bricked, but you are unable to change to a different CA and assert > new CA pins until the old pins expire. > 3) Pruning the amount of pin history you must keep your site consistent > with (Do you remember what pins you or the previous domain owner asserted 6 > month ago? 6 years ago? ever? They might still be out there, waiting to > trip you up). > > > Hm, in my view case #2 and #3 are about your own pinning time frames and > should be ok with recommendations, but would not require hard limits in the > draft. And in fact as we have multiple pins in the header we have a > migration path from A to B during that transition. > Being able to assert multiple pins in the header doesn't avoid lock-in problems. In a lock-in scenario there could be extant pins in clients to the set of keys (X,Y,Z). Thus you *cannot* safely stop using one of keys (X,Y,Z) until those pins expire. Advertising new pins doesn't fix the problem, cause you can't be guaranteed of reaching all existing clients. > Reading your cases, it feels to me #1 the malicious domain name transfer > is the strongest case. > Is that in your opinion as well? > Not sure. Trevor --f46d041825acd31e7604dd56a7c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, May 22, 2013 at 2:02 PM, Tobias Gondrom <tobias.gondrom@g= ondrom.org> wrote:
=20 =20 =20

And maybe a question to go a step further:
Would you agree that if we would do a 30-day hard limit as you propose, this would basically mean that all less frequent banking/paypal/... users MUST (or a very strong SHOULD) use such a web crawler to make sure that their pin has not expired before they come back?

Pins created= by the UA itself won't protect initial connections, or provide securit= y when expired. =A0These are inherent limits of UA-derived pins. =A0So I do= n't think a spec-limit makes these problems dramatically worse, or requ= ires new mandates for UAs.

You could, however, note the deficiences of UA-derived = pins in the Security Considerations, and say something something like:=A0

"Clients are advised to make use of 3rd-party = trust infrastructure so that pins can be aggregated and shared. =A0This wil= l require additional protocols outside the scope of this document."

=A0
This would be a big problem in my eyes, as IMHO this assumption can not be guaranteed nor expected to be rolled out consistently.

=A0
And regarding some of the concerns of pro-longed malicious bricking by
an attacker after an attack has been resolved:
Two scenarios:
1. I believe if we have a time limit of more than 1 month we need a
different mechanism (e.g. user actively flushing the key cache) anyway.
2. in the case of high frequency sites (like you mentioned Facebook),
imagine even a 1 month brick time would already be considered
unacceptable too long by most users (in fact probably everything above a
few hours would be considered too long) and trigger user action to flush
the cache.

Agreed that a 30-day limit is not, by itself, sufficient mitigation against "malicious bricking by an attacker after an attack". =A0I suspect pinning w= ill need several additional mechanisms to prevent, limit, and recover from such attacks. =A0"Pin activation&qu= ot; is one mechanism I think is particularly helpful, for this case.

A 30-day spec limit is more important for other reasons:
=A01) Domain name transfers (sales, disputes, reclaiming hijacked domains, etc.)
=A02) Preventing long-term lock-in. =A0E.g. you are pinned to CA keys which you lose trust in and suspect might be participating in MITM attacks; you are not bricked, but you are unable to change to a different CA and assert new CA pins until the old pins expire.
=A03) Pruning the amount of pin history you must keep your site consistent with (Do you remember what pins you or the previous domain owner asserted 6 month ago? 6 years ago? ever? =A0They might still be out there, waiting to trip you up).

Hm, in my view case #2 and #3 are about your own pinning time frames and should be ok with recommendations, but would not require hard limits in the draft. And in fact as we have multiple pins in the header we have a migration path from A to B during that transition.

Being able to assert multiple = pins in the header doesn't avoid lock-in problems. =A0In a lock-in scen= ario there could be extant pins in clients to the set of keys (X,Y,Z). =A0T= hus you *cannot* safely stop using one of keys (X,Y,Z) until those pins exp= ire.

Advertising new pins doesn't fix the pr= oblem, cause you can't be guaranteed of reaching all existing clients.<= /div>

=A0
Reading your cases, it feels to me #1 the malicious domain name transfer is the strongest case.
Is that in your opinion as well?

=
Not sure.


Trevor
--f46d041825acd31e7604dd56a7c7-- From tanvi@mozilla.com Wed May 22 16:26:21 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 CCD5B21F90D2 for ; Wed, 22 May 2013 16:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 UyOqFBM1MB0a for ; Wed, 22 May 2013 16:26:16 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 440E921F90EE for ; Wed, 22 May 2013 16:26:15 -0700 (PDT) Received: from host-4-248.mv.mozilla.com (unknown [63.245.220.240]) (Authenticated sender: tvyas@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 785D7F242C; Wed, 22 May 2013 16:26:15 -0700 (PDT) Message-ID: <519D5417.2030402@mozilla.com> Date: Wed, 22 May 2013 16:26:15 -0700 From: Tanvi Vyas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ryan-ietfhasmat@sleevi.com References: <87sj1e8yr7.fsf@alice.fifthhorseman.net> <5833d9ac9b80141674bece13781fee36.squirrel@webmail.dreamhost.com> In-Reply-To: <5833d9ac9b80141674bece13781fee36.squirrel@webmail.dreamhost.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security and mixed-content warnings 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, 22 May 2013 23:26:21 -0000 Firefox's Mixed Content Blocker is enabled by default in Firefox 23+. It will block Mixed Active Content, but allow Mixed Passive Content (unless the user explicitly turns it off by setting security.mixed_content.block_display_content to true). If an HSTS site includes Mixed Active Content, we will block the content by default. As Ryan mentioned, a user without HSTS protections is still at risk. This is discussed in detail in this blog post: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/#Appendix. This has actually been a problem for our own mozilla sites, since many of them have set the HSTS header but haven't updated their content. We are working with them to update their websites and replace http:// links with their https:// equivalents. Note that our definitions of Mixed Active and Mixed Passive are slightly different than Chrome's and IE's. Some of these differences are also discussed in the blog post (https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23). Thanks! ~Tanvi On 5/22/13 3:52 PM, Ryan Sleevi wrote: > On Wed, May 22, 2013 2:56 pm, Daniel Kahn Gillmor wrote: >> hi websec folks-- >> >> I am wondering what people think the proper intersection is between a >> web browser's mixed-content warnings and HSTS. >> >> For example, if https://example.net has asserted >> Strict-Transport-Security: max-age=15768000 but the homepage at >> https://example.net/ also contains >> >> >> >> should an HSTS-compatible browser show its standard mixed-content >> warning even though it knows to rewrite that img src to >> https://example.net/example.jpg ? >> >> My intuition is that this shouldn't trigger the browser's mixed-content >> warning, but chromium 26.0.1410.43 does show it, and >> >> https://code.google.com/p/chromium/issues/detail?id=122548#c26 >> >> suggests that palmer@ and rsleevi@ think that is the correct behavior >> because they want: >> >>> to signal to the site author of an error - for example, if users which >>> did not have HSTS visited. >> I'm not sure how the author is supposed to get this signal from the site >> visitor's browser, though -- perhaps the expectation is that site >> visitors will independently report the "broken lock" to the site >> administrator? > Yes. > > The view is that it's still a legitimate error for the site operator, in > that any user without HSTS protections (or with expired HSTS) is still at > risk. While HSTS may be providing protection to the user, the site itself > is still configured to serve resources insecurely, thus we still surface > it as user visible. > > >> I also note that firefox 21.0 (when >> security.mixed_content.block_display_content = true) doesn't show the >> media at all, and when security.mixed_content.block_display_content = >> false it shows the image but removes the lock from the address bar >> (which i think is the equivalent of the "mixed content warning" these >> days). > I believe the Firefox behaviour is an artifact of their current (partial) > implementation of mixed content blocking. According to > https://blog.mozilla.org/security/2013/05/16/mixed-content-blocking-in-firefox-aurora/ > , future versions should distinguish between active and passive content, > and thus more closely mirror the Chromium behaviour by default (namely, > that it will block active content, but not passive content) > >> Do other folks have any thoughts about the right thing is to do here? >> > ISTM that UI behaviours are largely outside the realm of what the IETF > standardizes. > > That said, certainly feedback is welcomed on this, and I would love to see > consistent handling (which, AFAIK, we will soon have). I'm just not sure > if this is really a "spec issue". > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From palmer@google.com Wed May 22 17:14: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 354C211E816F for ; Wed, 22 May 2013 17:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 WxlDtxvQ6qYG for ; Wed, 22 May 2013 17:14:51 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 43FE921F8FE8 for ; Wed, 22 May 2013 17:14:51 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id p13so405974vbe.40 for ; Wed, 22 May 2013 17:14:50 -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 :content-type; bh=cxm9sHQCQKZsA0k+DcyfYxtoc0pq5qF/3i+U93snw/A=; b=SRGO3PlSRyaGm+t8nkHfyX4TqUYhisTtMiKsite15JUHYpTwnSUnazsSfgM2Ta8WHH vkKOwWCZS8yK0N4vZetfvbWr8ZxV3advgkp/XfG12lk1qixFAZ+4guNJ+8E5Pxmdj5Di 82aXZbDGROM8Nwfwx02UjDO1ptyeiZq+BhoBS0xG3s7WY6j5Fsr5WlUmoHgwae74iOnK PH1CMqtsNvC2cr1mYpovZu/2Ijgp9Vk6FX2N6j2ZLSuMwPHOBnm0CPxfatJ6/8bFtfOP nvO647itKJVXt0dSO18F+Lg4IWLyOiwcyDzGksTjwVjSdj71c6CtVRjke5JfYln2h+sF nXhg== 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 :content-type:x-gm-message-state; bh=cxm9sHQCQKZsA0k+DcyfYxtoc0pq5qF/3i+U93snw/A=; b=XcdLCY8T+h6RxhWvJoph58nDbMR/m0EOrrHzBrWqjwW5arD2rwEpNJvnLhS9tIdlSp fOVYpcofMILumJKpYV+g0d1IlKki3PuP8kMKLdNZIoTs4hLmwJrbhfzf2mkPUQiMI5kp 1zqoTIr63zsxdj3WmRfsWvfbAplyNdgHoxltkK9pPnihn2n7V/wsQPqNWp4y/HLyZ5Pc Ut/SEKB2Hr6dW4HO1SL/gkdRbZsy0njCouFihtW16+nOm6v0tGHuOID5CsgGtYZbtusf W/lK6uQBBUMII6jnuMGgbNMmOT85g/Y4DfIXn2wCT2X75e5B2m7JiSFkCGxfSILmFmuF dQhQ== MIME-Version: 1.0 X-Received: by 10.52.28.171 with SMTP id c11mr582460vdh.18.1369268090537; Wed, 22 May 2013 17:14:50 -0700 (PDT) Received: by 10.220.61.131 with HTTP; Wed, 22 May 2013 17:14:50 -0700 (PDT) In-Reply-To: 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> Date: Wed, 22 May 2013 17:14:50 -0700 Message-ID: From: Chris Palmer To: IETF WebSec WG Content-Type: multipart/alternative; boundary=20cf30780ae023a37604dd5792d8 X-Gm-Message-State: ALoCoQkUIOOnrIMpcnN8jiJaaHyZ0N2qQGM6WdnnbzCM564dF8X7P5VSnZUUHhmyiKQ4/gdYkJLOHKXv6Hw4wZgviigiLv2popdY7t3T/IAGZSZ4vcVluX652aqkNwrEp0dXG8dl1CJ1q9n7bUEzwVXk9cqG1IYSWtB9BnESPzELN3pWD6Tsrm3L7cgsQ+x6GfOVb5Ieo7K7 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: Thu, 23 May 2013 00:14:55 -0000 --20cf30780ae023a37604dd5792d8 Content-Type: text/plain; charset=UTF-8 Hi all, Looks like these are the options: 1. No hard limits, but allow UAs to limit the pin time. Suggest a month 2. Set a hard limit of one month in the RFC. Longer pins are truncated. 3. No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month) 4. Adopt some gradual confidence-building scheme a-la-TACK. 5. No hard limits, leave limiting the pin time unspecified, make no suggestion. (4) is a key differentiator for TACK, and I want to let TACK be TACK and HPKP be HPKP. I consider both to be experimental features, and having two very different proposals maximizes our experimentation coverage. Any of (1, 2, 3, 5) is more or less fine by me; I'll go along with the consensus. I see them as being on a spectrum of "fixity" or "definedness": least fixed . . . most fixed 5 3 1 2 Perhaps in this time of experimentation, less fixed is better. Maybe we can learn more about how well/not well pinning works, and then publish a new version of the specification in the future. I posit that browsers will have strong incentives to fail open after some reasonable max-max-age, even if the spec does not mandate it. (For example, Chrome stops enforcing pinning completely if it recognizes that its own build date is more than 10 weeks in the past: a browser that old is definitely an indicator of some kind of problem, and we want users to be able to recover.) So, not mandating a limit is not as dangerous as it may seem, as a practical matter. However, Trevor compellingly argues: """Anyways, I think making things safe and simple for site operators is more important than browser creativity, or trying to maximize pinning's security benefits. That's why I still prefer a spec-mandated limit. And I think 30 days strikes a good balance between security benefits and safety, and is easy to remember and explain.""" I am less compelled by the argument that rarely-visited sites will get no protection from pinning if the max-max-age is as low as 30 days, if the fail-open behavior is to provide the user a warning/notice/choice: Hey, you haven't visited yourbank.com recently enough for us to be highly confident that it's the real yourbank.com. Everything else checks out, so we still have good confidence. [ I'm OK with good confidence, proceed anyway ] [ Oops, go back ] So, my vote is for (3). --20cf30780ae023a37604dd5792d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Looks like these are the = options:

1. No hard limits, but allow UAs to = limit the pin time. Suggest a month

2. Set a hard = limit of one month in the RFC. Longer pins are truncated.

3. No hard limits, but allow the UA to skip hard-fail i= f a pin hasn't been observed for some time (like a month)
4. Adopt some gradual confidence-building scheme a-la-TACK.

5.=C2=A0No hard limits, leave limiting the pin time=C2=A0= unspecified, ma= ke no suggestion.

(4) is a key differentiator for TACK, and I want to let= TACK be TACK and HPKP be HPKP. I consider both to be experimental features= , and having two very different proposals maximizes our experimentation cov= erage.

Any of (1, 2, 3, 5) is more or less fine by me; I'l= l go along with the consensus. I see them as being on a spectrum of "f= ixity" or "definedness":

least fixe= d . . . most fixed
5 =C2=A0 =C2=A0 =C2=A0 =C2=A03 =C2=A0 =C2=A0 =C2=A0 =C2=A01 =C2=A0 =C2= =A0 =C2=A0 =C2=A02

Perhaps in this time of experim= entation, less fixed is better. Maybe we can learn more about how well/not = well pinning works, and then publish a new version of the specification in = the future.

I posit that browsers will have strong incentives to fa= il open after some reasonable max-max-age, even if the spec does not mandat= e it. (For example, Chrome stops enforcing pinning completely if it recogni= zes that its own build date is more than 10 weeks in the past: a browser th= at old is definitely an indicator of some kind of problem, and we want user= s to be able to recover.) So, not mandating a limit is not as dangerous as = it may seem, as a practical matter.

However, Trevor compellingly argues: """= Anyways, I think making things safe and simple for site operators is more i= mportant than browser creativity, or trying to maximize pinning's secur= ity benefits. =C2=A0That's why I still prefer a spec-mandated limit. An= d I think 30 days strikes a good balance between security benefits and safe= ty, and is easy to remember and explain."""

I am less compelled by the argument that ra= rely-visited sites will get no protection from pinning if the max-max-age i= s as low as 30 days, if the fail-open behavior is to provide the user a war= ning/notice/choice:

=C2=A0 =C2=A0 Hey, you haven't visited = yourbank.com recently enough for us to = be highly
=C2=A0 =C2=A0 confident that it's the real yourbank.com. Everything else checks out,= so
=C2=A0 =C2=A0 we still have good confidence.
=C2=A0 =C2=A0 [ I'm OK with good confidence, proceed = anyway ] =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Oops, go back ]

<= /div>
So, my vote is for (3).
--20cf30780ae023a37604dd5792d8-- From dveditz@mozilla.com Wed May 22 19:43:29 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 493B521F8E3C for ; Wed, 22 May 2013 19:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 E2dH74+YogNm for ; Wed, 22 May 2013 19:43:23 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 74DD221F8F24 for ; Wed, 22 May 2013 19:43:23 -0700 (PDT) Received: from [192.168.7.27] (c-76-102-4-44.hsd1.ca.comcast.net [76.102.4.44]) (Authenticated sender: dveditz@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C6194F230D for ; Wed, 22 May 2013 19:43:19 -0700 (PDT) Message-ID: <519D8244.6050209@mozilla.com> Date: Wed, 22 May 2013 19:43:16 -0700 From: Daniel Veditz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: websec@ietf.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> <1A1F4108-B0F3-4742-9DC5-2D8E1E56D7E1@checkpoint.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040902060007050504080907" 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: Thu, 23 May 2013 02:43:29 -0000 This is a cryptographically signed message in MIME format. --------------ms040902060007050504080907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 5/22/2013 3:29 PM, Trevor Perrin wrote: > The draft discusses "Preloaded Pin Lists", which are presumably conveye= d > to the UA from some 3rd party (eg browser vendor). It seems reasonable= > for such lists to be created or kept fresh by scanning web sites. I > believe Mozilla is taking this approach to HSTS [1]. Note that Mozilla currently requires sites to specify an HSTS pinning=20 time of at least 18 WEEKS to be included in the pre-load list. There was = concern that sites with shorter pins could have stopped using HSTS by=20 time that version of the browser shipped. I personally think that's a=20 little strict, but even if we relaxed the requirement to the length of a = Beta cycle that's still a longer period of time (6 weeks) than the=20 maximum 30 days you're suggesting. This has no direct bearing of whether 30 days is a reasonable max=20 pinning length, but I doubt Mozilla would ship a pre-loaded list if the=20 lifetime was so short that pins would have expired by time the user gets = it. -Dan Veditz --------------ms040902060007050504080907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKSTCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFJzCCBA+gAwIBAgIQUyil4+4bA9FJ9YcCRI4lwDANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzAy MTEwMDAwMDBaFw0xNDAyMTEyMzU5NTlaMCQxIjAgBgkqhkiG9w0BCQEWE2R2ZWRpdHpAbW96 aWxsYS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTnsC1EsBKllnFfIOa Zq4Zc4FTmw35nhWt6Z+VZKhmcuBKcDc/pBdwSQAmYMz5bNNJwJVaCAMtQgY7MRqoDJ64rdII ktmupz8r5DU3jFPi1V7aLd3hI4ykYu2LF/FR47frBTCw9UpbgHwEuTucRoSU3UHbYoL4uYO4 tPJTD4a5Kduy/qsKPq/3FyblLbODcCGgrGXaXJfDrf5MeJfKj1VULfSbLGceWLg23w4Fxzpi L7bgtFVU85HT2MSAbpCvfuIz1tUKgHvPF7hzmzuqCJS2GL3zycpVlNoV+Afs9WGlE8rWKxzO dn/bLonL3pjuFdzS4ovAGMb0YUPzjVTIk7WzAgMBAAGjggHjMIIB3zAfBgNVHSMEGDAWgBR6 E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQU+joXtDpPHfhG6IY+xRSsQcCOS8QwDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQB sjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBO MEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNh dGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKG Rmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv bTAeBgNVHREEFzAVgRNkdmVkaXR6QG1vemlsbGEuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCK RmxKBaAFBoAXt3WiWLvt/WHlf1LmbV9DhPEkltWgnEu2gXEp0jhwpGUM4IonDoTwl0A+YAMJ AIRBxvMWq2ZbIEaDnC5a/9jQEgfkZNmGIOde1P9baeC16ULdF9CU/BCmFR2w48IJPtMExyIj bZVDVdTe87pG2IQ5E3RZfXdmHP3HQOC3eRc1O0zf7rwu6cgUDzPZ3YJ3GGitv+dtQPclu9df Yv/atYMj81y0WqEyV3vWy/rMSgZvwnqnQATQId9jNAZbKoW2KyGWGijpwljdsA5jkM42nAfC w0Eq9Oz84FdFtCExNUcfCDuEkhNN0Va8cQpsh+rbQv7Jd6H/dl0fMYIEGTCCBBUCAQEwgagw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEFMopePuGwPRSfWH AkSOJcAwCQYFKw4DAhoFAKCCAkUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTMwNTIzMDI0MzE2WjAjBgkqhkiG9w0BCQQxFgQUGGMk8TQXn+P+LT02ACVy R8X8560wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhBTKKXj7hsD0Un1hwJEjiXAMIG7BgsqhkiG9w0BCRACCzGBq6CB qDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9E TyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQUyil4+4bA9FJ 9YcCRI4lwDANBgkqhkiG9w0BAQEFAASCAQAJoQhONVOTJiY4vmfICVtwjc5OWt0Aci3paCpM kOjQ/VR+PvQIgDb1CLN0sr9Oi/MAJwAzNAo9uKhcNUYchDT+fObbeFNhuSu6gpgrfNAuA8pb xK3Vvl5mZSiOXVLVWAlADq5zFtign3lWMSeAQBFlNGGuyUmnY5nxc3FocnOnVDX+YKftcWt2 a7OpiLkOW+SXJk8K+cJLeDwyHPeM1Yhpeb98QDr7RjfUACrQAynB0gJSxIGGx/eNmfvsR7e7 tPeMh2xW9tdJFMNvVAm5Dj7bDyPD9f6LC8fVdCJTJQfk6a6PhEPucmzR9RYs0Tmenq2EYXvs jJ9FA8i/rx/9lHP3AAAAAAAA --------------ms040902060007050504080907-- From dkg@fifthhorseman.net Wed May 22 20:27:16 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 F247B11E8145 for ; Wed, 22 May 2013 20:27:15 -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 ppcAEfSiom6w for ; Wed, 22 May 2013 20:27:11 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3221F8F32 for ; Wed, 22 May 2013 20:27:10 -0700 (PDT) Received: from [192.168.13.158] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 82466F97F; Wed, 22 May 2013 23:27:07 -0400 (EDT) Message-ID: <519D8C88.6070104@fifthhorseman.net> Date: Wed, 22 May 2013 23:27:04 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: ryan-ietfhasmat@sleevi.com References: <87sj1e8yr7.fsf@alice.fifthhorseman.net> <5833d9ac9b80141674bece13781fee36.squirrel@webmail.dreamhost.com> In-Reply-To: <5833d9ac9b80141674bece13781fee36.squirrel@webmail.dreamhost.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2MIRCLTLFBPBNNGUQAAHM" Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security and mixed-content warnings 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, 23 May 2013 03:27:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MIRCLTLFBPBNNGUQAAHM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/22/2013 06:52 PM, Ryan Sleevi wrote: > The view is that it's still a legitimate error for the site operator, i= n > that any user without HSTS protections (or with expired HSTS) is still = at > risk. While HSTS may be providing protection to the user, the site itse= lf > is still configured to serve resources insecurely, thus we still surfac= e > it as user visible. It is an error for the site operator, certainly. But for a given user, with a browser that supports HSTS, which has received the header during the main page load (so it is clearly not expired), and trying to fetch content from the origin site itself (that happens to be mistakenly linked with http:// instead of https://): in this scenario it is not a security vulnerability for this user. My expectation as someone who browses the web is the browser UI feeback info is telling me things about *this connection right now*. If i want to get feedback about how the site is (mis)configured in ways that are not actively harming my connection at the moment, i expect that to be functionality provided by an extension or a web-developer-specific settin= g. For example, if i'm visiting a web page that is not valid HTML, but my browser can do a passable rendering of it, i don't expect my browser to choke or provide a warning label that says "invalid HTML! some other browsers might not be able to render this properly!" (though maybe that would be nice?) What about sites that are using 768-bit RSA keys -- some TLS stacks might reject those too, even if this one does not; should the browser show a warning? What about "transvalid" certs, which are only valid because we were able to find their intermediary CA in our cache of previously-seen CAs? There are lots of potential "your current connection is only safe because of this quirky combination of your browser, the page you're currently viewing, and your browsing history..." scenarios. Why should HSTS+mixed-content be singled out for special display to the user? I would expect that site administrators don't want their visitors to see indicators of security failure when they are using tools that are specifically designed to be able to prevent the security failure in question from happening. Site administrators should *also* be happy to have a mechanism to get reports about possible breakage on non-STS-compatible browsers, but i don't think they would want that mechanism to be complaints from scared users of STS-compatible browsers who actually don't have a problem. > ISTM that UI behaviours are largely outside the realm of what the IETF > standardizes. Some IETF specs do mandate certain UI (e.g. https://tools.ietf.org/html/rfc6797#section-12.1 specifies "no user recourse"), so i hope it's not too far outside the scope of the WG to talk about this here. But mainly i was asking about this here because i expect folks in this WG to have thought about these issues and to be able to explain where they're coming from (and even be interested in working toward rough consensus). That already is happening, so i don't think this is a terrible venue for the discussion :) Regards, --dkg ------enig2MIRCLTLFBPBNNGUQAAHM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRnYyIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcf4EQAIE0W/xo5+aNpVW95Z5DQI73 PAJkkzDUE1rhBzlSdQs5Gm9bJ6G7QplUVeihTtBrff4q6+wZYgw59sJLYCu/EGd5 KruwxaSNML5h3jSroTfQZAKAxCjDHpX0UIikGMXLovdVl9YPxORtcH4tCmM/anmY IVpo+gEggp9vKE7FY3afxi1q2QW6daA7vCxDuKK9l5QqGr3bj7CJVGxoXxpzHcUX XPWNO2QTdQFJTlTCh3R5Z6RegaSx3miwhTDMbTjGo9diAzHDT4aAH+XoXJUWVSvJ KacFnTonk7i4nHAiHDbRc0iarJXTWScln/SsIMjgiKjE8VJTRjwsPigqLTJMWG7b LBCJbopFUpr4lxiy+OX3YlOz4ZqLpBd9332gnzESSmC87WX9RN0iG9EhtnfwWKDd L8VEp5+BHY3S8D3iegQVzVb2hwOs4ze4mROo4mCohkj5rmThUbGRKzY9TuXMI4Vf 3AHKCPwWg6O12fXl4pdpp22CNTL7qD18fcyfkvjOGrdKrittc3cY6ymeVauZ5r+a e84wK1xAeDEAIBYk3PsQRY54F89eu4DKVQ2JZaUIKUCc0mR8a34hDLvRpglavPFt HBui2g18SfbsrbR9ZMJTjiByCUvkBYviYVO7fWu3fGVwEu7GHK8BVOBxaht/3mvv HoL/V8Dyh0TozL3Zo3Ql =0kip -----END PGP SIGNATURE----- ------enig2MIRCLTLFBPBNNGUQAAHM-- From trevp@trevp.net Thu May 23 08:18: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 7DA7111E8119 for ; Thu, 23 May 2013 08:18:03 -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 WtED2S2UujcW for ; Thu, 23 May 2013 08:17:59 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C2FED11E8132 for ; Thu, 23 May 2013 08:17:58 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id t60so1185963wes.25 for ; Thu, 23 May 2013 08:17:57 -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=FPGaL+yODO0ncatUxv+Z75w9JSeJBfkQDc3z1Y3DC14=; b=Ut0EpQnOOUK/xrTUQOxEs9CqiTMyvvQE28bpxkaxGZJ/Db7AL7AdN82a0FTDeriP9+ HbRY33jRB2vagSI1OnP075tM579Nrey0f1KqnnP82WvanuuhjZA4K9EdI6EbJe9MuVxu Ysxe9VFzXPPRNiNqih/jyrncnRlHuxUswb4ruHDVPdzj8kb0z3WEvTeTMawCqztuRzuQ mDntQB8BtMi0fT/8Pgg6Ere0XY+WmG5ke5KsnwIO7Hblt+C1i4JN3hyOjNvtFWOem52f yEqQwH+ydlEoJiVJui6Y+ZuGz9YzM1QEP78bsoGGc50apfhfnjg/cljzpASjAv9MIb/f A6kg== MIME-Version: 1.0 X-Received: by 10.181.13.169 with SMTP id ez9mr25444707wid.8.1369322277616; Thu, 23 May 2013 08:17:57 -0700 (PDT) Received: by 10.217.110.129 with HTTP; Thu, 23 May 2013 08:17:57 -0700 (PDT) X-Originating-IP: [166.137.187.135] In-Reply-To: <519D8244.6050209@mozilla.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> <1A1F4108-B0F3-4742-9DC5-2D8E1E56D7E1@checkpoint.com> <519D8244.6050209@mozilla.com> Date: Thu, 23 May 2013 08:17:57 -0700 Message-ID: From: Trevor Perrin To: Daniel Veditz Content-Type: multipart/alternative; boundary=f46d0438eb9ff0d8eb04dd642f42 X-Gm-Message-State: ALoCoQlre/n/uLkLZ7weVTDtilHjkGuStFeG8IIqKdAYrWe4I/knDQE/6gImsay5gIUx8nXdTwFt 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: Thu, 23 May 2013 15:18:03 -0000 --f46d0438eb9ff0d8eb04dd642f42 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 7:43 PM, Daniel Veditz wrote: > On 5/22/2013 3:29 PM, Trevor Perrin wrote: > >> The draft discusses "Preloaded Pin Lists", which are presumably conveyed >> to the UA from some 3rd party (eg browser vendor). It seems reasonable >> for such lists to be created or kept fresh by scanning web sites. I >> believe Mozilla is taking this approach to HSTS [1]. >> > > Note that Mozilla currently requires sites to specify an HSTS pinning time > of at least 18 WEEKS to be included in the pre-load list. There was concern > that sites with shorter pins could have stopped using HSTS by time that > version of the browser shipped. I personally think that's a little strict, > but even if we relaxed the requirement to the length of a Beta cycle that's > still a longer period of time (6 weeks) than the maximum 30 days you're > suggesting. > Hi Daniel, That seems like a downside of compiling preloads into browser binaries, as done by Chrome and Firefox. But it looks like Google and Mozilla have both considered having the browser query a service to update a local list. That seems like a better approach, since it would eliminate this problem of shipping a build with pin information that is several weeks stale, and can only be updated with a new browser binary. https://code.google.com/p/chromium/issues/detail?id=175207 "As both the pinning list grows, and our desire to have a consistent pinning list across all versions of Chromium, we should look to move the static pin database into a module that may be updated independently of the main Chromium binary." https://wiki.mozilla.org/Privacy/Features/HSTS_Preload_List "There are two ways to accomplish this: 1. Hard-code the list in each shipping version of Firefox 2. Stand up a service (like blocklist ping) that serves the list upon request." Trevor --f46d0438eb9ff0d8eb04dd642f42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 7:43 PM, Daniel Veditz <dvedi= tz@mozilla.com> wrote:
On 5/22/2013 3:29 PM, Trevor Perrin wrot= e:
The draft discusses "Preloaded Pin Lists", which are presumably c= onveyed
to the UA from some 3rd party (eg browser vendor). =A0It seems reasonable for such lists to be created or kept fresh by scanning web sites. =A0I
believe Mozilla is taking this approach to HSTS [1].

Note that Mozilla currently requires sites to specify an HSTS pinning time = of at least 18 WEEKS to be included in the pre-load list. There was concern= that sites with shorter pins could have stopped using HSTS by time that ve= rsion of the browser shipped. I personally think that's a little strict= , but even if we relaxed the requirement to the length of a Beta cycle that= 's still a longer period of time (6 weeks) than the maximum 30 days you= 're suggesting.


Hi Daniel,
<= br>
That seems like a downside of compiling preloads into browser= binaries, as done by Chrome and Firefox. =A0

But = it looks like Google and Mozilla have both considered having the browser qu= ery a service to update a local list. =A0That seems like a better approach,= since it would eliminate this problem of shipping a build with pin informa= tion that is several weeks stale, and can only be updated with a new browse= r binary.

"As both the pinning list grows, and our desire to h= ave a consistent pinning list across all versions of Chromium, we should lo= ok to move the static pin database into a module that may be updated indepe= ndently of the main Chromium binary."

"There are two ways to accomplish this:
1. H= ard-code the list in each shipping version of Firefox
2. Stand up a service (like blocklist ping) that serves the list upon = request."


Trevor

--f46d0438eb9ff0d8eb04dd642f42-- From trac+websec@trac.tools.ietf.org Fri May 24 16:41:49 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 B24BD21F8CA5 for ; Fri, 24 May 2013 16:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 PBg6me-dYzbW for ; Fri, 24 May 2013 16:41:49 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EDA3E11E80D2 for ; Fri, 24 May 2013 16:41:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:36711 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ug1cB-0000uF-0Z; Sat, 25 May 2013 01:41:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "websec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: palmer@google.com X-Trac-Project: websec Date: Fri, 24 May 2013 23:41:38 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/55#comment:3 Message-ID: <073.f62391cb0cf5d9ebda966c81e774dd78@trac.tools.ietf.org> References: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [websec] #55: Clarify that the newest pinning information takes precedence X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 23:41:49 -0000 #55: Clarify that the newest pinning information takes precedence Changes (by palmer@google.com): * status: assigned => closed * resolution: => fixed Comment: Per discussion on the list, adopted Sleevi's text but changed "evict" to "ignore". https://code.google.com/p/key-pinning- draft/source/diff?spec=svnfc4bef2ce138d467182832a362831b6d63ea9cdc&r=fc4bef2ce138d467182832a362831b6d63ea9cdc&format=side&path =/draft-ietf-websec-key-pinning.xml -- -------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Fri May 24 18:32:59 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 138A821F9349 for ; Fri, 24 May 2013 18:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 slcBNrhMGOoD for ; Fri, 24 May 2013 18:32:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEBE21F92F0 for ; Fri, 24 May 2013 18:32:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:44126 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ug3Lt-0001AW-27; Sat, 25 May 2013 03:32:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "websec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: palmer@google.com X-Trac-Project: websec Date: Sat, 25 May 2013 01:32:57 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/56#comment:4 Message-ID: <073.784fdfee212774401579f342d657a38b@trac.tools.ietf.org> References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 01:32:59 -0000 #56: Specify includeSubdomains directive for HPKP Changes (by palmer@google.com): * status: assigned => closed * resolution: => fixed Comment: There seems to be consensus that this is done. -- -------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: fixed Keywords: includeSubdomains | -------------------------------+-------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Fri May 24 18:41: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 BAFE021F942D for ; Fri, 24 May 2013 18:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 1bBGiJV1zQSQ for ; Fri, 24 May 2013 18:41:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EF1EF21F9428 for ; Fri, 24 May 2013 18:41:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:44431 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ug3Tv-0003QI-BE; Sat, 25 May 2013 03:41:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "websec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: palmer@google.com X-Trac-Project: websec Date: Sat, 25 May 2013 01:41:15 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/websec/trac/ticket/53#comment:2 Message-ID: <073.7596c49c42f63bc38fe20a2ed8c59450@trac.tools.ietf.org> References: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [websec] #53: Clarify status of pin validation when used with private trust anchors X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 01:41:17 -0000 #53: Clarify status of pin validation when used with private trust anchors Comment (by palmer@google.com): The current draft has this text: 578 If the connection has no errors, then the UA will determine whether to 579 apply a new, additional correctness check: Pin Validation. A UA SHOULD 580 perform Pin Validation whenever connecting to a Known Pinned Host, but MAY 581 allow Pin Validation to be disabled for Hosts according to local policy. For 582 example, a UA may disable Pin Validation for Pinned Hosts whose validated 583 certificate chain terminates at a user-defined trust anchor, rather than a 584 trust anchor built-in to the UA. However, if the Pinned Host Metadata 585 indicates that the Pinned Host is operating in "strict mode" (see 586 ), then the UA MUST perform Pin Validation. I believe this is the result of previous consensus. Is that correct, and can I therefore close this issue? -- -------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------- Ticket URL: websec From tobias.gondrom@gondrom.org Tue May 28 04:35: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 5399521F8930 for ; Tue, 28 May 2013 04:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.873 X-Spam-Level: X-Spam-Status: No, score=-93.873 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 oQ7RmT22yafV for ; Tue, 28 May 2013 04:35:52 -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 DB2C821F885A for ; Tue, 28 May 2013 04:35:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=FxLP7PozMu7kzUq2jC32yPTLlcLmhBM1rykxsHLP8G/vyb/Y4fVchKV91sSy305U2m5aDH24oJOw5mYbft0ehN2Hc2aPU/kz55xRTwQ8rfNianXQms0SaW85/NxGQcPk; 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 11421 invoked from network); 28 May 2013 13:35:49 +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); 28 May 2013 13:35:49 +0200 Message-ID: <51A49695.9080200@gondrom.org> Date: Tue, 28 May 2013 12:35:49 +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: websec@ietf.org References: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> <073.7596c49c42f63bc38fe20a2ed8c59450@trac.tools.ietf.org> In-Reply-To: <073.7596c49c42f63bc38fe20a2ed8c59450@trac.tools.ietf.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] #53: Clarify status of pin validation when used with private trust anchors 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, 28 May 2013 11:35:57 -0000 Hi Chris, I think so. (but am not 100% sure.) Any other comments on this issue before we close it? Thanks, Tobias On 25/05/13 02:41, websec issue tracker wrote: > #53: Clarify status of pin validation when used with private trust anchors > > > Comment (by palmer@google.com): > > The current draft has this text: > > 578 If the connection has no errors, then the UA will determine > whether to > 579 apply a new, additional correctness check: Pin Validation. A UA > SHOULD > 580 perform Pin Validation whenever connecting to a Known Pinned Host, > but MAY > 581 allow Pin Validation to be disabled for Hosts according to local > policy. For > 582 example, a UA may disable Pin Validation for Pinned Hosts whose > validated > 583 certificate chain terminates at a user-defined trust anchor, rather > than a > 584 trust anchor built-in to the UA. However, if the Pinned Host Metadata > 585 indicates that the Pinned Host is operating in "strict mode" (see > 586 ), then the UA MUST perform Pin > Validation. > > I believe this is the result of previous consensus. Is that correct, and > can I therefore close this issue? > From tobias.gondrom@gondrom.org Tue May 28 04:52:13 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 8C93521F96D6 for ; Tue, 28 May 2013 04:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.318 X-Spam-Level: X-Spam-Status: No, score=-93.318 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, 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 MUFjZh8chLMI for ; Tue, 28 May 2013 04:52:06 -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 24ACD21F96C9 for ; Tue, 28 May 2013 04:51:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=A8VVHoVR59ETSRyjcS6El4meBK+e5g8n049T5wZ5ShHulfiEuUN0CW/+5WzZY5IO3JRvvMQaRzfIUxbxrMW9q/QccX9/srcdMvwNDF1YDHIQMRItyBuv1PHzJ5pxjlAs; 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 11539 invoked from network); 28 May 2013 13:51:56 +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); 28 May 2013 13:51:56 +0200 Message-ID: <51A49A5C.5080002@gondrom.org> Date: Tue, 28 May 2013 12:51:56 +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: websec@ietf.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> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 28 May 2013 11:52:13 -0000 Hi Chris, It seems like the majority of the WG would not share my concerns. So I will shut up soon. ;-) Maybe two remarks: 1. user choice is a bad idea when it comes to security. Just remember the many SSL cert "click to proceed anyway pop-up windows/issues..." In most cases the user is not qualified to fully understand the consequences of his choice. And also if he is faced with the choice "no access" or "access", he/she will probably go for "access anyway". We have trained them that way the last few years. So I rather want to avoid a user choice as much as possible. 2. as you seem to advocate a hard limit of 30 days. Could you think of browsers refreshing their PINs before expiry automatically? (i.e. without the user actually visiting the site?) And question to all: would this open Pandora's box in terms of privacy etc. as we would leak the list of pinned sites to servers in the middle? Best regards, Tobias On 23/05/13 01:14, Chris Palmer wrote: > Hi all, > > Looks like these are the options: > > 1. No hard limits, but allow UAs to limit the pin time. Suggest a month > > 2. Set a hard limit of one month in the RFC. Longer pins are truncated. > > 3. No hard limits, but allow the UA to skip hard-fail if a pin hasn't > been observed for some time (like a month) > > 4. Adopt some gradual confidence-building scheme a-la-TACK. > > 5. No hard limits, leave limiting the pin time unspecified, make no > suggestion. > > (4) is a key differentiator for TACK, and I want to let TACK be TACK > and HPKP be HPKP. I consider both to be experimental features, and > having two very different proposals maximizes our experimentation > coverage. > > Any of (1, 2, 3, 5) is more or less fine by me; I'll go along with the > consensus. I see them as being on a spectrum of "fixity" or "definedness": > > least fixed . . . most fixed > 5 3 1 2 > > Perhaps in this time of experimentation, less fixed is better. Maybe > we can learn more about how well/not well pinning works, and then > publish a new version of the specification in the future. > > I posit that browsers will have strong incentives to fail open after > some reasonable max-max-age, even if the spec does not mandate it. > (For example, Chrome stops enforcing pinning completely if it > recognizes that its own build date is more than 10 weeks in the past: > a browser that old is definitely an indicator of some kind of problem, > and we want users to be able to recover.) So, not mandating a limit is > not as dangerous as it may seem, as a practical matter. > > However, Trevor compellingly argues: """Anyways, I think making things > safe and simple for site operators is more important than browser > creativity, or trying to maximize pinning's security benefits. That's > why I still prefer a spec-mandated limit. And I think 30 days strikes > a good balance between security benefits and safety, and is easy to > remember and explain.""" > > I am less compelled by the argument that rarely-visited sites will get > no protection from pinning if the max-max-age is as low as 30 days, if > the fail-open behavior is to provide the user a warning/notice/choice: > > Hey, you haven't visited yourbank.com > recently enough for us to be highly > confident that it's the real yourbank.com . > Everything else checks out, so > we still have good confidence. > > [ I'm OK with good confidence, proceed anyway ] [ Oops, go > back ] > > So, my vote is for (3). > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Tue May 28 04:54:00 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 7B26721F96DF for ; Tue, 28 May 2013 04:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.133 X-Spam-Level: X-Spam-Status: No, score=-93.133 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_40=-0.185, 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 Ws7-Qkhtn8Oo for ; Tue, 28 May 2013 04:53:52 -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 453C921F96DE for ; Tue, 28 May 2013 04:53:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=u8EPv5bU4o+xPzkuQf2Jokymo1yvSpsG1/ImZXUxMMFVGIds1505UDVeo/7TjorrThF3xKqrMy2pyh6flL3JPzgdBrDAesg9v6bI53mZLHv2RRBDoxsJ1dzdYwpgWtWb; 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 11559 invoked from network); 28 May 2013 13:53:47 +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); 28 May 2013 13:53:47 +0200 Message-ID: <51A49ACA.3070103@gondrom.org> Date: Tue, 28 May 2013 12:53:46 +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: websec@ietf.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> <1A1F4108-B0F3-4742-9DC5-2D8E1E56D7E1@checkpoint.com> <519D8244.6050209@mozilla.com> In-Reply-To: <519D8244.6050209@mozilla.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 28 May 2013 11:54:00 -0000 Hi Dan, thank you for the info. And a good point. Tobias On 23/05/13 03:43, Daniel Veditz wrote: > On 5/22/2013 3:29 PM, Trevor Perrin wrote: >> The draft discusses "Preloaded Pin Lists", which are presumably conveyed >> to the UA from some 3rd party (eg browser vendor). It seems reasonable >> for such lists to be created or kept fresh by scanning web sites. I >> believe Mozilla is taking this approach to HSTS [1]. > > Note that Mozilla currently requires sites to specify an HSTS pinning > time of at least 18 WEEKS to be included in the pre-load list. There > was concern that sites with shorter pins could have stopped using HSTS > by time that version of the browser shipped. I personally think that's > a little strict, but even if we relaxed the requirement to the length > of a Beta cycle that's still a longer period of time (6 weeks) than > the maximum 30 days you're suggesting. > > This has no direct bearing of whether 30 days is a reasonable max > pinning length, but I doubt Mozilla would ship a pre-loaded list if > the lifetime was so short that pins would have expired by time the > user gets it. > > -Dan Veditz > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ynir@checkpoint.com Tue May 28 05:12: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 9619921F96E4 for ; Tue, 28 May 2013 05:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 3r0oMHznWFAq for ; Tue, 28 May 2013 05:12:06 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 887BF21F96A3 for ; Tue, 28 May 2013 05:12:05 -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 r4SCBuLV030484; Tue, 28 May 2013 15:11:56 +0300 X-CheckPoint: {51A49C71-A-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, 28 May 2013 15:11:56 +0300 From: Yoav Nir To: Tobias Gondrom Thread-Topic: [websec] #53: Clarify status of pin validation when used with private trust anchors Thread-Index: Ac2rKh9d18aqpJuvSdOlKuUlnfYpBCtpaz6AAKujpoAAAULDgA== Date: Tue, 28 May 2013 12:11:54 +0000 Message-ID: <9E7A30FE-E598-4A73-96DA-CC865E4A8C8D@checkpoint.com> References: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> <073.7596c49c42f63bc38fe20a2ed8c59450@trac.tools.ietf.org> <51A49695.9080200@gondrom.org> In-Reply-To: <51A49695.9080200@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.225] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 111777f398bfe71dec04e8c4fe3787a73204f590e7 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] #53: Clarify status of pin validation when used with private trust anchors 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, 28 May 2013 12:12:10 -0000 I agree. I think that this non-strict behavior is something that UAs will i= mplement anyway, because otherwise the UA doesn't work in any place that ha= s a "next generation firewall" (which is pretty much any firewall these day= s) And if they did stick to only strict behavior, pretty much none of the pote= ntial servers would use HPKP.=20 I agree that this text represents a middle ground that allows both UAs and = servers to deploy the protocol. so, +1. Yoav (with no hats, except maybe a next-generation firewall vendor hat) On May 28, 2013, at 2:35 PM, Tobias Gondrom wr= ote: > Hi Chris, >=20 > I think so. (but am not 100% sure.) > Any other comments on this issue before we close it? >=20 > Thanks, Tobias >=20 >=20 > On 25/05/13 02:41, websec issue tracker wrote: >> #53: Clarify status of pin validation when used with private trust ancho= rs >>=20 >>=20 >> Comment (by palmer@google.com): >>=20 >> The current draft has this text: >>=20 >> 578 If the connection has no errors, then the UA will determine >> whether to >> 579 apply a new, additional correctness check: Pin Validation. A UA >> SHOULD >> 580 perform Pin Validation whenever connecting to a Known Pinned Host, >> but MAY >> 581 allow Pin Validation to be disabled for Hosts according to local >> policy. For >> 582 example, a UA may disable Pin Validation for Pinned Hosts whose >> validated >> 583 certificate chain terminates at a user-defined trust anchor, rather >> than a >> 584 trust anchor built-in to the UA. However, if the Pinned Host Metada= ta >> 585 indicates that the Pinned Host is operating in "strict mode" (see >> 586 ), then the UA MUST perform Pin >> Validation. >>=20 >> I believe this is the result of previous consensus. Is that correct, and >> can I therefore close this issue? >>=20 >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From palmer@google.com Tue May 28 15:33: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 A004621F89FF for ; Tue, 28 May 2013 15:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 vJCFPmH0Vq1G for ; Tue, 28 May 2013 15:33:58 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 78ECE21F8A6B for ; Tue, 28 May 2013 15:33:57 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id p13so4416390vbe.40 for ; Tue, 28 May 2013 15:33:56 -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=OnBp/lUo6voBKl1Fh7jBmFTQIm/xfw2cFgjxt8xpexU=; b=K8tZwt27zccuIvVo1uh0y2SVEqNB088zDBROQA6/FbLHF05iM1u6+v8sOI3yiKJKQx lnSd2pcjHZcnLqnqn/c2bDqaD4MJMnSpTVaahlyK+gBqtknsJzSWXHEALq4ajHg8Lgm+ mySXTPcHw+T/dQB7UB5mxYIkd102hoSO0XXADcdTYSDNt1rUzxUnglP4mY2gdCVh091K ftlxL5jIkw5h26FBGo+YbuuBvT48JNDX4Ame0B0qFquuYXJEKRusZTuEjfYy/6bwLVst SZ57cw33yDuGlAwKc/hSCAT/Jw8psmnqPslU9T4nesFnHozh744mnlK5oUd55bB+2iQU AjLw== 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=OnBp/lUo6voBKl1Fh7jBmFTQIm/xfw2cFgjxt8xpexU=; b=EGwm4JSAm0Z4Nw+UQUZfUeeyXr3NPYqpX5VntVOeU7XDkCHvTmu62PwkeAvqwZFhsI 0kEqWxDlRyAvO3dmhNtGIcotCwzOX3Ta3oJXGGsxS+aK46oopJmuZM4M70pbm4Ct+hB8 Jy28o8ZCSe/H4IAi8jn+10JBfiGgNO5KJezhOjNzL/wnf1cZKCyzSEi4CikfK3WciThG JYQ6ae+fVtaaTWXqrb8KPE02E+jeEZ4jVUvirNDVBvqJhs2HOHE9ikTQmMtytfuMYKvM Dww4PtJjs+c0u4sQARWhBHngcLhKEebodgL/T39PDYadwg8qHrptGS3xEmkVfF4EmKWK cCZg== MIME-Version: 1.0 X-Received: by 10.58.173.36 with SMTP id bh4mr19439320vec.9.1369780436739; Tue, 28 May 2013 15:33:56 -0700 (PDT) Received: by 10.220.75.138 with HTTP; Tue, 28 May 2013 15:33:56 -0700 (PDT) In-Reply-To: <9E7A30FE-E598-4A73-96DA-CC865E4A8C8D@checkpoint.com> References: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> <073.7596c49c42f63bc38fe20a2ed8c59450@trac.tools.ietf.org> <51A49695.9080200@gondrom.org> <9E7A30FE-E598-4A73-96DA-CC865E4A8C8D@checkpoint.com> Date: Tue, 28 May 2013 15:33:56 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b5da8135a3c5104ddcedc20 X-Gm-Message-State: ALoCoQlyOfMvoMOtKPppWCdD0NuyoX78qXeWEq0zEvjct+jisVaDDt1LYq80KZHACCFgWb1wrg3qqMjXxNO1dB9E4z2jNUF3JZikjQ2KfOn3ePVt4rdYn4BFUGg6ct6cYabzCyH3WjmlWF8fdgOd7/r1U3wsj3KgxwQrIRCrjt9MpWZOugnghRgVmbI/ETyK2QAavbkB6EKS Cc: "" Subject: Re: [websec] #53: Clarify status of pin validation when used with private trust anchors 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, 28 May 2013 22:33:58 -0000 --047d7b5da8135a3c5104ddcedc20 Content-Type: text/plain; charset=UTF-8 Thanks everyone. Closing it out. On Tue, May 28, 2013 at 5:11 AM, Yoav Nir wrote: > I agree. I think that this non-strict behavior is something that UAs will > implement anyway, because otherwise the UA doesn't work in any place that > has a "next generation firewall" (which is pretty much any firewall these > days) > > And if they did stick to only strict behavior, pretty much none of the > potential servers would use HPKP. > > I agree that this text represents a middle ground that allows both UAs and > servers to deploy the protocol. > > so, +1. > > Yoav > (with no hats, except maybe a next-generation firewall vendor hat) > > On May 28, 2013, at 2:35 PM, Tobias Gondrom > wrote: > > > Hi Chris, > > > > I think so. (but am not 100% sure.) > > Any other comments on this issue before we close it? > > > > Thanks, Tobias > > > > > > On 25/05/13 02:41, websec issue tracker wrote: > >> #53: Clarify status of pin validation when used with private trust > anchors > >> > >> > >> Comment (by palmer@google.com): > >> > >> The current draft has this text: > >> > >> 578 If the connection has no errors, then the UA will determine > >> whether to > >> 579 apply a new, additional correctness check: Pin Validation. A UA > >> SHOULD > >> 580 perform Pin Validation whenever connecting to a Known Pinned Host, > >> but MAY > >> 581 allow Pin Validation to be disabled for Hosts according to local > >> policy. For > >> 582 example, a UA may disable Pin Validation for Pinned Hosts whose > >> validated > >> 583 certificate chain terminates at a user-defined trust anchor, rather > >> than a > >> 584 trust anchor built-in to the UA. However, if the Pinned Host > Metadata > >> 585 indicates that the Pinned Host is operating in "strict mode" (see > >> 586 ), then the UA MUST perform Pin > >> Validation. > >> > >> I believe this is the result of previous consensus. Is that correct, and > >> can I therefore close this issue? > >> > > > > _______________________________________________ > > 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 > --047d7b5da8135a3c5104ddcedc20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks everyone. Closing it out.


On Tue, May 28, 2013 at 5:11 AM, = Yoav Nir <ynir@checkpoint.com> wrote:
I agree. I think that this non-strict behavi= or is something that UAs will implement anyway, because otherwise the UA do= esn't work in any place that has a "next generation firewall"= (which is pretty much any firewall these days)

And if they did stick to only strict behavior, pretty much none of the pote= ntial servers would use HPKP.

I agree that this text represents a middle ground that allows both UAs and = servers to deploy the protocol.

so, +1.

Yoav
(with no hats, except maybe a next-generation firewall vendor hat)

On May 28, 2013, at 2:35 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

> Hi Chris,
>
> I think so. (but am not 100% sure.)
> Any other comments on this issue before we close it?
>
> Thanks, Tobias
>
>
> On 25/05/13 02:41, websec issue tracker wrote:
>> #53: Clarify status of pin validation when used with private trust= anchors
>>
>>
>> Comment (by palmer@google.com= ):
>>
>> The current draft has this text:
>>
>> =C2=A0578 <t>If the connection has no errors, then the UA wi= ll determine
>> whether to
>> =C2=A0579 apply a new, additional correctness check: Pin Validatio= n. A UA
>> SHOULD
>> =C2=A0580 perform Pin Validation whenever connecting to a Known Pi= nned Host,
>> but MAY
>> =C2=A0581 allow Pin Validation to be disabled for Hosts according = to local
>> policy. For
>> =C2=A0582 example, a UA may disable Pin Validation for Pinned Host= s whose
>> validated
>> =C2=A0583 certificate chain terminates at a user-defined trust anc= hor, rather
>> than a
>> =C2=A0584 trust anchor built-in to the UA. However, if the Pinned = Host Metadata
>> =C2=A0585 indicates that the Pinned Host is operating in "str= ict mode" (see
>> =C2=A0586 <xref target=3D"strict"/>), then the UA = MUST perform Pin
>> Validation.</t>
>>
>> I believe this is the result of previous consensus. Is that correc= t, and
>> can I therefore close this issue?
>>
>
> _______________________________________________
> 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

--047d7b5da8135a3c5104ddcedc20-- From trac+websec@trac.tools.ietf.org Tue May 28 15:35:13 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 04B9621F8A0B for ; Tue, 28 May 2013 15:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Lr2OXJgTIcPH for ; Tue, 28 May 2013 15:35:12 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3239E21F89FF for ; Tue, 28 May 2013 15:35:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:47529 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UhSU2-0002Sv-Ig; Wed, 29 May 2013 00:35:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "websec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: palmer@google.com X-Trac-Project: websec Date: Tue, 28 May 2013 22:35:10 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/53#comment:3 Message-ID: <073.be1abe3d5c63611e600f8c83ee3216c2@trac.tools.ietf.org> References: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [websec] #53: Clarify status of pin validation when used with private trust anchors X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 22:35:13 -0000 #53: Clarify status of pin validation when used with private trust anchors Changes (by palmer@google.com): * status: assigned => closed * resolution: => fixed -- -------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------- Ticket URL: websec From palmer@google.com Tue May 28 17:23:54 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 A4A9D11E80BA for ; Tue, 28 May 2013 17:23:54 -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.001, 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 U4Rq0SL8bvHr for ; Tue, 28 May 2013 17:23:54 -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 E4EE111E80A4 for ; Tue, 28 May 2013 17:23:48 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so2061473veb.13 for ; Tue, 28 May 2013 17:23:48 -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=OA5vk52GsDE4rChTVfh4kLjcvXIA5kc39K5vz8Ehic4=; b=f6ouJUTQLTM1TaIg/wrCWf0MdPOp5o/3SBPsoogyQ8llQNY2FS5xLJ5NmqB61S1wrk 8DLLlsurHNsvDmdZ5CeLNGVY3YQkY415nE738o9Xy8nhIIzA+CNdYOocSittDDqt9rFm QPVS7j87oco1bds+J6lZzF2ISC8JJTQ2IhfnYJkoT13PZBexx5pKUn5ruRhHtX4F5v5Y L7tuvVyt5ki4X/ZsBH8mpNsnwDjOn7fvAUQAXSCTO/1Nigro5O+9seh8IUoYv70B95/J 7tb/KP5YdqrAisdkpfY/ps4MWkwvSVhyL9R3qObISzYoV8rHyY8eL0gqzrl9HiOWnRku z1BA== 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=OA5vk52GsDE4rChTVfh4kLjcvXIA5kc39K5vz8Ehic4=; b=I5mZgyGwomIvLPNZg5d3lkXS/WZx2mFiTjMBjTEEJrAg3y2IRInfUPwM34w6lYWecq 5f3LxDC98lUieFYeNGx39ep/hFRq6QZ2F4riDAiwqpgxxOrRk4ZBo5yCJsrWCb1cqPpL w8rXGYHyxIIynagGrfowD6eC5h/CNyj88qjpHpf2O/GvHhIx6VPeYCgOgfhxweZXTuV7 or8x8VW8Ec86YlwTAVNP+jwS4yYR27vK2wSEqlFQLYJuGQDrcM/zAOorHpRFXnVfVLdx 7dsMKHoaN/s50ZkBPaBfgUtod/jm1U+vEK3z+auykanV1c5nU6BUQ4OQpSJss/UtWi1Y 4VtQ== MIME-Version: 1.0 X-Received: by 10.220.192.3 with SMTP id do3mr180655vcb.16.1369787028333; Tue, 28 May 2013 17:23:48 -0700 (PDT) Received: by 10.220.75.138 with HTTP; Tue, 28 May 2013 17:23:48 -0700 (PDT) In-Reply-To: <51A49A5C.5080002@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> Date: Tue, 28 May 2013 17:23:48 -0700 Message-ID: From: Chris Palmer To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQndc2lxyyu9ISHQe1e11HjB0zi9n6JlslMJP6fE+YiHPEvSvJl9FFkV/VoFsWRTP6iN2GfMZasT+/CGHtMH7/zXNbhKZrOACbi1RcPV8FuVMAiAwjKOHKGwZpMs6eteD/9ZTpl9ZynT473K+OGGEqy6p6Fj3L4WWlvuUx2NIY3DDuP3y+qaLR5OdJrgA/0bU+75eXju 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: Wed, 29 May 2013 00:23:54 -0000 On Tue, May 28, 2013 at 4:51 AM, Tobias Gondrom wrote: > It seems like the majority of the WG would not share my concerns. So I > will shut up soon. ;-) Thanks for raising your concerns, and for sticking the conversation and with pinning in general! > 1. user choice is a bad idea when it comes to security. > Just remember the many SSL cert "click to proceed anyway pop-up > windows/issues..." > In most cases the user is not qualified to fully understand the > consequences of his choice. Yes. But, in this case, the choice is between status-quo HTTPS and extra-happy pinned HTTPS. That's a very different proposition than clearly-broken HTTPS vs. status-quo HTTPS, for example. Also, failing closed would probably be a deal-breaker for deployment, at least at this time. Finally, for sites that people use regularly =E2=80=94 Facebook, Gmail, Twitter =E2=80=94 users will still get good protection. Arguably, th= ese are the sites that are mature and most likely to be able to deploy pinning; it's the banks and other occasionally-visited sites that should probably stick to Report-Only mode anyway, because they are less mature *as web technology companies*. Thus I would argue that, at least for now, the sites that would most likely fail open due to limit son the max-max-age are sites that should fail open anyway, for other reasons. However, that's a bit of a tangent. As it is, many sites that really need pinning protection can get it under this I-D, and others can gain nice information from Report-Only mode, and others do no worse than the status quo. > 2. as you seem to advocate a hard limit of 30 days. Not exactly; I find Trevor's call for simple clarity compelling, but I also like a browser-determined limit past which we fail open (for the reasons described above). I could happily go either way, which doesn't really help, I realize. :) Ryan and I can just make a call one way or the other and write it up, is that OK? > Could you think of > browsers refreshing their PINs before expiry automatically? (i.e. > without the user actually visiting the site?) > And question to all: would this open Pandora's box in terms of privacy > etc. as we would leak the list of pinned sites to servers in the middle? Right, exactly. I don't want to have browsers unilaterally leaking information by proactively pre-scanning particular sites. However, an oft-updated master list, like Chrome's CRLSets but for pins culled by crawling sites and looking for pin updates, might be workable. But I'd consider that a nice-to-have that is out of the I-D's immediate scope. From ynir@checkpoint.com Tue May 28 22:17: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 DFD2721F8FBE for ; Tue, 28 May 2013 22:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 xOgowN6uLNbi for ; Tue, 28 May 2013 22:17:03 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 98E1421F8FB6 for ; Tue, 28 May 2013 22:17:02 -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 r4T5GvZ9018196; Wed, 29 May 2013 08:16:57 +0300 X-CheckPoint: {51A58CA5-1-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; Wed, 29 May 2013 08:16:57 +0300 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] Consensus call: Issue #57 (max-max-age) Thread-Index: AQHOSvJfUWwKnsbs2U6hMAgGMyNIfJkAPs4AgABLswCAAL0DAIAGBnoAgAPHdQCABoGgAIAAI4SAgAASTgCACJ5sAIAA0hIAgABR5YA= Date: Wed, 29 May 2013 05:16:56 +0000 Message-ID: <7AD36561-65B4-448C-A371-907B12B75AF1@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> 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.252] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 119a6a2990122ce2bb8fcaac746069fe100843e326 Content-Type: text/plain; charset="Windows-1252" Content-ID: <9AE9DF4CED856C41957D0582B7ACE924@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 29 May 2013 05:17:09 -0000 Hi Chris (again, no hats) On May 29, 2013, at 3:23 AM, Chris Palmer wrote: >> 1. user choice is a bad idea when it comes to security. >> Just remember the many SSL cert "click to proceed anyway pop-up >> windows/issues..." >> In most cases the user is not qualified to fully understand the >> consequences of his choice. >=20 > Yes. But, in this case, the choice is between status-quo HTTPS and > extra-happy pinned HTTPS. That's a very different proposition than > clearly-broken HTTPS vs. status-quo HTTPS, for example. Also, failing > closed would probably be a deal-breaker for deployment, at least at > this time. Finally, for sites that people use regularly =97 Facebook, > Gmail, Twitter =97 users will still get good protection. Arguably, these > are the sites that are mature and most likely to be able to deploy > pinning; People having multiple devices kind of screws this up. People may use the s= ame site every day, but they might not use the same site from the same devi= ce every day. So if someone uses mostly a phone to access facebook, they ma= y go a whole month without accessing it from their desktop or laptop. Limit= ing pins to 30 days means your less-used devices, which may be on a totally= different network than your phone, are not protected. > it's the banks and other occasionally-visited sites that > should probably stick to Report-Only mode anyway, because they are > less mature *as web technology companies*. Thus I would argue that, at > least for now, the sites that would most likely fail open due to limit > son the max-max-age are sites that should fail open anyway, for other > reasons. Disagree on that. Banks and other financial institutions are not web techno= logy companies, but they deal with real money and they have real money with= which to buy such expertise. It's no coincidence that banks were very earl= y adopters of anti-XSS and anti-CSRF measures, and it's no coincidence that= one of this group's biggest contributors works for Paypal, which is no les= s a financial institution than any bank or credit card companies. If we can= 't help protect the transactions that involve money, what's the point? > However, that's a bit of a tangent. As it is, many sites that really > need pinning protection can get it under this I-D, and others can gain > nice information from Report-Only mode, and others do no worse than > the status quo. >=20 >> 2. as you seem to advocate a hard limit of 30 days. >=20 > Not exactly; I find Trevor's call for simple clarity compelling, but I > also like a browser-determined limit past which we fail open (for the > reasons described above). I could happily go either way, which doesn't > really help, I realize. :) Ryan and I can just make a call one way or > the other and write it up, is that OK? By "fail open", do you mean fail with a warning to the user, or just silent= ly ignore the pin? If it's the latter, than letting each implementation ch= oose a max-max-age does not address Trevor's concerns. If some site sent a = pin with max-age of 10 years, they can fix the pin that they send, but they= have to assume that for the next 10 years some browsers out there have rec= orded the way-too-long pin. Maybe this means that they can't switch root CA= s. If you set max-max-age in the RFC to 30 days, they can know that all tho= se browsers will have lost the pin after a month. If you let every UA choos= e their own max-max-age, they have to assume the maximum, and hope that the= y even know the maximum. They might think that taking the maximum among Chr= ome, Firefox, IE, Safari and Opera gets them there. They might not have eve= r heard of a browser called OmniWeb for Mac (just using an obscure one as a= n example). But if OmniWeb sets no limits on pins and they change CAs after= 1 year, they are going to get a whole bunch of support calls from people u= sing a browser they've never heard of. So I think we should either set no limits, or set hard limits. >> Could you think of >> browsers refreshing their PINs before expiry automatically? (i.e. >> without the user actually visiting the site?) >> And question to all: would this open Pandora's box in terms of privacy >> etc. as we would leak the list of pinned sites to servers in the middle? >=20 > Right, exactly. I don't want to have browsers unilaterally leaking > information by proactively pre-scanning particular sites. However, an > oft-updated master list, like Chrome's CRLSets but for pins culled by > crawling sites and looking for pin updates, might be workable. But I'd > consider that a nice-to-have that is out of the I-D's immediate scope. I agree that we can't mandate that each UA has access to the results of som= e web crawler looking for pins. Yoav= From tobias.gondrom@gondrom.org Wed May 29 08:04: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 2718121F9397 for ; Wed, 29 May 2013 08:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.278 X-Spam-Level: X-Spam-Status: No, score=-94.278 tagged_above=-999 required=5 tests=[AWL=1.084, 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 CiDyOiWuGRk2 for ; Wed, 29 May 2013 08:04:32 -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 C090E21F9307 for ; Wed, 29 May 2013 08:04:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=bIHuxWn6ZtaskiO/YUJpuRxOZ36fzOZDdeXGu8+0CI+gpWHpOF/DdX1zbSW1UBnTdzUli8G2NU4qWGiaic4y2qTM5e0NebnzXaUVmnJjO98xUE6mLP5yopooLSk+sk0F; 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 20407 invoked from network); 29 May 2013 17:04:27 +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); 29 May 2013 17:04:26 +0200 Message-ID: <51A618FA.9070209@gondrom.org> Date: Wed, 29 May 2013 16:04:26 +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: palmer@google.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: <7AD36561-65B4-448C-A371-907B12B75AF1@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Wed, 29 May 2013 15:04:37 -0000 Hi Chris, (also no hats) thanks for the clarification. If either "no-limit" and "hard-limit" would both be ok for you (and others), then I would be strongly in favor of "no-limit". (note: I recognise that the side effect of "no-limit" is that domain squatters can brick a site for a longer time after the domain had been handed over. But actually considering that we plan to do some pre-caching deployment in browsers anyway, the browsers might also be the solution for this problem. Like doing a "clear pin cache for domain xyz" in case of really malicious pin bricking.) Best regards, Tobias On 29/05/13 06:16, Yoav Nir wrote: > Hi Chris > > (again, no hats) > > On May 29, 2013, at 3:23 AM, Chris Palmer wrote: > >>> 1. user choice is a bad idea when it comes to security. >>> Just remember the many SSL cert "click to proceed anyway pop-up >>> windows/issues..." >>> In most cases the user is not qualified to fully understand the >>> consequences of his choice. >> Yes. But, in this case, the choice is between status-quo HTTPS and >> extra-happy pinned HTTPS. That's a very different proposition than >> clearly-broken HTTPS vs. status-quo HTTPS, for example. Also, failing >> closed would probably be a deal-breaker for deployment, at least at >> this time. Finally, for sites that people use regularly =97 Facebook, >> Gmail, Twitter =97 users will still get good protection. Arguably, the= se >> are the sites that are mature and most likely to be able to deploy >> pinning; > People having multiple devices kind of screws this up. People may use t= he same site every day, but they might not use the same site from the sam= e device every day. So if someone uses mostly a phone to access facebook,= they may go a whole month without accessing it from their desktop or lap= top. Limiting pins to 30 days means your less-used devices, which may be = on a totally different network than your phone, are not protected. > >> it's the banks and other occasionally-visited sites that >> should probably stick to Report-Only mode anyway, because they are >> less mature *as web technology companies*. Thus I would argue that, at= >> least for now, the sites that would most likely fail open due to limit= >> son the max-max-age are sites that should fail open anyway, for other >> reasons. > Disagree on that. Banks and other financial institutions are not web te= chnology companies, but they deal with real money and they have real mone= y with which to buy such expertise. It's no coincidence that banks were v= ery early adopters of anti-XSS and anti-CSRF measures, and it's no coinci= dence that one of this group's biggest contributors works for Paypal, whi= ch is no less a financial institution than any bank or credit card compan= ies. If we can't help protect the transactions that involve money, what's= the point? > >> However, that's a bit of a tangent. As it is, many sites that really >> need pinning protection can get it under this I-D, and others can gain= >> nice information from Report-Only mode, and others do no worse than >> the status quo. >> >>> 2. as you seem to advocate a hard limit of 30 days. >> Not exactly; I find Trevor's call for simple clarity compelling, but I= >> also like a browser-determined limit past which we fail open (for the >> reasons described above). I could happily go either way, which doesn't= >> really help, I realize. :) Ryan and I can just make a call one way or >> the other and write it up, is that OK? > By "fail open", do you mean fail with a warning to the user, or just si= lently ignore the pin? If it's the latter, than letting each implementat= ion choose a max-max-age does not address Trevor's concerns. If some site= sent a pin with max-age of 10 years, they can fix the pin that they send= , but they have to assume that for the next 10 years some browsers out th= ere have recorded the way-too-long pin. Maybe this means that they can't = switch root CAs. If you set max-max-age in the RFC to 30 days, they can k= now that all those browsers will have lost the pin after a month. If you = let every UA choose their own max-max-age, they have to assume the maximu= m, and hope that they even know the maximum. They might think that taking= the maximum among Chrome, Firefox, IE, Safari and Opera gets them there.= They might not have ever heard of a browser called OmniWeb for Mac (just= using an obscure one as an example). But if OmniWeb sets no limits on pi= ns and they change CAs after 1 year, they are going to get a whole bunch = of support calls from people using a browser they've never heard of. > > So I think we should either set no limits, or set hard limits. > >>> Could you think of >>> browsers refreshing their PINs before expiry automatically? (i.e. >>> without the user actually visiting the site?) >>> And question to all: would this open Pandora's box in terms of privac= y >>> etc. as we would leak the list of pinned sites to servers in the midd= le? >> Right, exactly. I don't want to have browsers unilaterally leaking >> information by proactively pre-scanning particular sites. However, an >> oft-updated master list, like Chrome's CRLSets but for pins culled by >> crawling sites and looking for pin updates, might be workable. But I'd= >> consider that a nice-to-have that is out of the I-D's immediate scope.= > I agree that we can't mandate that each UA has access to the results of= some web crawler looking for pins. > > Yoav From palmer@google.com Wed May 29 17:29: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 33A1B21F9206 for ; Wed, 29 May 2013 17:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 z56QJNsRtWmY for ; Wed, 29 May 2013 17:29:36 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9103821F910D for ; Wed, 29 May 2013 17:29:36 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ha11so6772711vcb.7 for ; Wed, 29 May 2013 17: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=Q7th7ZyA/xziN4PSaG2MEz5n6YZSbcAO1ZtnM9TllWc=; b=hVMW1sjvOSk8+6oNDK35a1EP+QOWOzS30ZJaOiKzJkrw+KC/qKOEWzYSXgwNo9r/4E rgkHMPjFVnZPrDqM0x1lEnYzTWmipY+wq2XuwPmM+7FgOnAZE/SVkb3h705njOvM86Ao +zW9uPEJ31p6x8G6X3IIogk1Zio+XG+RjC7N++pLw+82AGejMBwXSmb/OBYekrmnov/y oW2+c6m2yi5mZUeQuPF6ehOeRlPCIbxKikHzjLEH68w6XAumyU1cOUZd52Pzn1KHFGjl +oUDYaOUPY7CWRc36KjSWKABBa3rb95Uxdkoha5TOHHndjF/fre1NgZLzGyG8qZKcA6L DbZw== 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=Q7th7ZyA/xziN4PSaG2MEz5n6YZSbcAO1ZtnM9TllWc=; b=XgvBkdsk5dlGrBiGZGDT99ofJdQ4u6qZojvS3L6uOh81/qYrkUySqf1wWhvmW652cQ mSA3Oe9SrxsgGt7DQQsgBYsG0cbMbrnmZWdiw7rMG8MyjA3VtIPukCLY3APjcjJvYYOK ZtKld3RrzyfHv9gvDaI5xqi2ovwwuotZW4vijrpHGW4jpnasd38SV57/uwFk4b33nfm/ ex9D4idlNHrqbJ1amBwwc4Q2+jmbJuip2YwCD6+dvfwfC/AYCbRxYHmGtMArPRahVeJl IV57j0Id4bWm3sH0GOvpRDgd5MwlZngVgWrX+kShccqRkFsvfQ+jBIXfPdt59lliG8Vs R89A== MIME-Version: 1.0 X-Received: by 10.52.67.1 with SMTP id j1mr2778344vdt.84.1369873775960; Wed, 29 May 2013 17:29:35 -0700 (PDT) Received: by 10.220.217.66 with HTTP; Wed, 29 May 2013 17:29:35 -0700 (PDT) In-Reply-To: <7AD36561-65B4-448C-A371-907B12B75AF1@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> Date: Wed, 29 May 2013 17:29:35 -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: ALoCoQnLLSwl820Uu1yQrK+TW45pLE2bzGrLquWoN0KQ1Ope2/oFiWoHCltQWSRw8FT7uW7OcBYFED7lSrRqjyDkcwKDtg2aUgmI3kJdcui46nI8rXxOlFs4Wsoh930twYthWmMYrWtxAM3RnM0FaOZ6mH3DO+Rx0O3BOjb5RVJ0Q1/4OrRz7hbmzoEbjC+TPRV0Sd/KS2Jj 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: Thu, 30 May 2013 00:29:42 -0000 On Tue, May 28, 2013 at 10:16 PM, Yoav Nir wrote: > Disagree on that. Banks and other financial institutions are not web tech= nology companies, but they deal with real money and they have real money wi= th which to buy such expertise. It's no coincidence that banks were very ea= rly adopters of anti-XSS and anti-CSRF measures, and it's no coincidence th= at one of this group's biggest contributors works for Paypal, which is no l= ess a financial institution than any bank or credit card companies. If we c= an't help protect the transactions that involve money, what's the point? Money is not the only important thing to protect. If HPKP "merely" protected email or personal messages or social networks, that would still be pretty awesome =E2=80=94 because people often use those systems fo= r things at least as important as money. (E.g. political speech.) Yes, of course I want to also protect people's interactions with their financial institutions. >> Not exactly; I find Trevor's call for simple clarity compelling, but I >> also like a browser-determined limit past which we fail open (for the >> reasons described above). I could happily go either way, which doesn't >> really help, I realize. :) Ryan and I can just make a call one way or >> the other and write it up, is that OK? > > By "fail open", do you mean fail with a warning to the user, or just sile= ntly ignore the pin? Fail with a warning to the user, as described earlier. > So I think we should either set no limits, or set hard limits. I see in a subsequent email, Tobias says: """If either "no-limit" and "hard-limit" would both be ok for you (and others), then I would be strongly in favor of "no-limit".""" I'll go for no-mandated-limit with suggested-limit. Other votes?