From trac+websec@trac.tools.ietf.org Sun Sep 15 07:06:01 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 DEA7E21E8051 for ; Sun, 15 Sep 2013 07:06:01 -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 8scBgXblB8kf for ; Sun, 15 Sep 2013 07:06:01 -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 2025621E8095 for ; Sun, 15 Sep 2013 07:05:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:51718 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VLCxQ-0007ja-GL; Sun, 15 Sep 2013 16:05:48 +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: draft-ietf-websec-key-pinning@tools.ietf.org, ynir@checkpoint.com X-Trac-Project: websec Date: Sun, 15 Sep 2013 14:05:48 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/58#comment:1 Message-ID: <075.ba22f961c54a172374aeacef8932ea1d@trac.tools.ietf.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-key-pinning@tools.ietf.org, ynir@checkpoint.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 Resent-To: cevans@google.com, palmer@google.com, sleevi@google.com Resent-Message-Id: <20130915140555.2025621E8095@ietfa.amsl.com> Resent-Date: Sun, 15 Sep 2013 07:05:51 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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: Sun, 15 Sep 2013 14:06:02 -0000 #58: Should we pin only SPKI, or also names Changes (by ynir@checkpoint.com): * status: new => closed * resolution: => wontfix Comment: In the end we decided to leave this for a future extension, as we don't currently have a good framework for mapping names to keys -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-key- ynir@checkpoint.com | pinning@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: In WG Last | Resolution: wontfix Call | Keywords: HPKP | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sun Sep 15 07:12:06 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1CC11E8128 for ; Sun, 15 Sep 2013 07:12:06 -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 XyjFJPadULaT for ; Sun, 15 Sep 2013 07:12:05 -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 9C34C11E8125 for ; Sun, 15 Sep 2013 07:12:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:52069 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VLD3T-0008Nq-Ey; Sun, 15 Sep 2013 16:12:03 +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: draft-ietf-websec-key-pinning@tools.ietf.org, ynir@checkpoint.com X-Trac-Project: websec Date: Sun, 15 Sep 2013 14:12:03 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/60#comment:1 Message-ID: <075.33add479730d92a4f8261bc2d2539a10@trac.tools.ietf.org> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-key-pinning@tools.ietf.org, ynir@checkpoint.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 Resent-To: cevans@google.com, palmer@google.com, sleevi@google.com Resent-Message-Id: <20130915141205.9C34C11E8125@ietfa.amsl.com> Resent-Date: Sun, 15 Sep 2013 07:12:05 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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: Sun, 15 Sep 2013 14:12:06 -0000 #60: Well Known URIs vs Response Headers Changes (by ynir@checkpoint.com): * status: new => closed * resolution: => wontfix Comment: Although we accept that this will be hard to change in the future, the browser developers on the list argued that the disadvantages would outweigh the advantages. Specifically: * Sending the HPKP header in every request is not a big deal, and * Having to do the fetching of the policy resource out of band is complicated With no consensus to change, we decided to keep the current design. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-key- ynir@checkpoint.com | pinning@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: In WG Last | Resolution: wontfix Call | Keywords: HPKP | RFC5785 | -------------------------+------------------------------------------------- Ticket URL: websec From hallam@gmail.com Tue Sep 17 09:06:52 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC8821F9DF1 for ; Tue, 17 Sep 2013 09:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_05=-1.11, 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 DVx5uX4argDy for ; Tue, 17 Sep 2013 09:06:51 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3624921F9D23 for ; Tue, 17 Sep 2013 09:06:51 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so5505823lbi.4 for ; Tue, 17 Sep 2013 09:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0PJ/LpFna0iJwmwYll5UJu2ImNxV28yDAnCPFPhcqGo=; b=bCSS6QCv6f2ZosuMctcArh3egLdWIvgufDT0OiNrGQ0/c+GEOsecv3bpWc3cbvmoQp BVlr3Gxzi/wenLElxK6tDx2/Jxu39ITo7lkVXrfT04+wM+yccUHNLV0zxyzKNFH798Ix 5IUNoxZUM+g66b5yjmVzEgdyWxlRKhF0wXGkSjrZdKIDQuibk5c96aCp+W5yokgqRyc3 Sws08rj9kslUofdO0dIlabcpgBUkWEnDxbXH0cD5fuIqlGMS/x5XbPl1BtespYqX4F/L eEyguxQufJtDYGMZ7ZC4jL+XvFuYuvP8XgfQr+MKdRD7LHjm6TzZuqzYAI4+179KYC5m X6IQ== MIME-Version: 1.0 X-Received: by 10.152.121.3 with SMTP id lg3mr2279082lab.33.1379434008981; Tue, 17 Sep 2013 09:06:48 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Tue, 17 Sep 2013 09:06:48 -0700 (PDT) In-Reply-To: <521BD634.4070700@gondrom.org> References: <521BD634.4070700@gondrom.org> Date: Tue, 17 Sep 2013 12:06:48 -0400 Message-ID: From: Phillip Hallam-Baker To: Tobias Gondrom Content-Type: multipart/alternative; boundary=089e0112d16418b8a904e69682d0 Cc: websec Subject: Re: [websec] Resuming the cookie discussion 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, 17 Sep 2013 16:06:52 -0000 --089e0112d16418b8a904e69682d0 Content-Type: text/plain; charset=ISO-8859-1 In the light of PRISM we rediscovered the benefit of Forward Secrecy. Forward Secrecy isn't a perfect defense and if TLS works completely as we believe it to then it is an unnecessary one. But we know that TLS with Forward secrecy is worth having because it increases the work factor to the attacker by several orders of magnitude. Instead of breaking the server public key the attacker now needs to break one key per cryptographic session. Reinforcing Cookies is a similar proposition, TLS should be enough to secure the cookies but if we can reduce the window of vulnerability to an attacker from allowing them to compromise any exchange to only being vulnerable on the first then we vastly increase the work factor. The part that I now consider to be insufficiently thought out in the proposal is that it assumes that the only parties involved are the client and the server. This is not the case. There is also an application layer within the server and changing that would be painful. So I am now thinking of a scheme where the client and the server can conspire to encrypt and authenticate the cookies such that the applications on the server are unaware this is happening (as per TLS and socket security) The handshake I am thinking of is Client: 'I do this new thing, here are some crypto params' Server: 'why yes, here is the encrypted cookie data and the information to calculate the secret' Client: here is your encrypted cookie, re-encrypted under the secret, the MAC Bind to the TLS session naturally, also include forward secrecy. --089e0112d16418b8a904e69682d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the light of PRISM we rediscovered the benefit of Forwa= rd Secrecy.=A0

Forward Secrecy isn't a perfect defen= se and if TLS works completely as we believe it to then it is an unnecessar= y one. But we know that TLS with Forward secrecy is worth having because it= increases the work factor to the attacker by several orders of magnitude. = Instead of breaking the server public key the attacker now needs to break o= ne key per cryptographic session.

Reinforcing Cookies is a similar proposition, TLS shoul= d be enough to secure the cookies but if we can reduce the window of vulner= ability to an attacker from allowing them to compromise any exchange to onl= y being vulnerable on the first then we vastly increase the work factor.


The part that I now consider to be insuf= ficiently thought out in the proposal is that it assumes that the only part= ies involved are the client and the server. This is not the case. There is = also an application layer within the server and changing that would be pain= ful.


So I am now thinking of a scheme where t= he client and the server can conspire to encrypt and authenticate the cooki= es such that the applications on the server are unaware this is happening (= as per TLS and socket security)


The handshake I am thinking of is
<= div>
Client: =A0'I do this new thing, here are some crypt= o params'
Server: 'why yes, here is the encrypted cookie = data and the information to calculate the secret'

Client: here is your encrypted cookie, re-encrypted und= er the secret, the MAC


Bind to the = TLS session naturally, also include forward secrecy.

--089e0112d16418b8a904e69682d0--