From hallam@gmail.com Tue Jul 2 06:52: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 9D16021F9E6C for ; Tue, 2 Jul 2013 06:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_20=-0.74, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 iEI9ZNGOASUW for ; Tue, 2 Jul 2013 06:52:49 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9875421F9E5F for ; Tue, 2 Jul 2013 06:52:48 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so3391823lbh.35 for ; Tue, 02 Jul 2013 06:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wQswIOQPuyuL6nTF9g/qBg1Zo1I7dvMUT1ME9/HXO4E=; b=sVnRkwTW0HDJP2i1E/Sauu4dddiHwJoLqIfBqKLzsBiaVcEgUOrmA4tv2Tj0HfLICP nSfsS51hpb7G3ni5kukHql6hcroIDS6qzPesFFmQAVMeUO5i8tvk0Y0EHfcdEYXtsujK sb42yNDSq3IQsv0eaoT4NzB0cr4DnGraEHIWt2wyl3NIROBz7ub8c0qCJFgjyrbYoZWU oX5DXOf1tC1Jf4KNQDy5qSz/5BqezwPEnsgrSrMS/VCK2GuVhyCm6vEoAk7BNtnBVZ3W q4NJHELOXZ0y13FQ+ze2/cbzXR7IqUXICmDovTxeRMVLdVAWx8d+OarTjNNTYdVMSbx9 e+Qg== MIME-Version: 1.0 X-Received: by 10.112.51.99 with SMTP id j3mr13725475lbo.82.1372773167458; Tue, 02 Jul 2013 06:52:47 -0700 (PDT) Received: by 10.112.77.8 with HTTP; Tue, 2 Jul 2013 06:52:47 -0700 (PDT) Date: Tue, 2 Jul 2013 09:52:47 -0400 Message-ID: From: Phillip Hallam-Baker To: websec Content-Type: multipart/alternative; boundary=001a1133b7da0100db04e087a941 Subject: [websec] CRIME II alleged at Black Hat 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, 02 Jul 2013 13:52:49 -0000 --001a1133b7da0100db04e087a941 Content-Type: text/plain; charset=ISO-8859-1 http://www.darkreading.com/vulnerability/https-side-channel-attack-a-tool-for-enc/240157583 We do not have the details yet. But it seems like this will be yet another variant of the 'in the browser' adaptive plaintext attack against SSL enabling cookie stealing. There are two problems we need to fix: 1) Whatever the latest SSL issue is. 2) Stop using bearer tokens for authentication. I anticipated this attack (it is the third time round after all) which is why I wrote the session ID scheme as a drop in replacement for cookies. In the short term sites would have to support both schemes as a transitional measure but given the current transition to HTML5 it is entirely likely that some sites can force a transition sooner. http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt -- Website: http://hallambaker.com/ --001a1133b7da0100db04e087a941 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
http://www.darkr= eading.com/vulnerability/https-side-channel-attack-a-tool-for-enc/240157583=

We do not have the details yet. But it seems like this will = be yet another variant of the 'in the browser' adaptive plaintext a= ttack against SSL enabling cookie stealing.

There = are two problems we need to fix:

1) Whatever the latest SSL issue is.

2) Stop using bearer tokens for authentication.

=

I anticipated this attack (it is the third time r= ound after all) which is why I wrote the session ID scheme as a drop in rep= lacement for cookies. In the short term sites would have to support both sc= hemes as a transitional measure but given the current transition to HTML5 i= t is entirely likely that some sites can force a transition sooner.

--001a1133b7da0100db04e087a941-- From tom@ritter.vg Tue Jul 2 07:00:19 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFD621F9ECF for ; Tue, 2 Jul 2013 07:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 k0XWAODIfYHt for ; Tue, 2 Jul 2013 07:00:19 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EE1BB21F9EB7 for ; Tue, 2 Jul 2013 07:00:17 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp12so6291663pab.21 for ; Tue, 02 Jul 2013 07:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u/vsZYsR7gmweJ5OPnRVvfp9Hn5a4BDCQk3uENuVsP4=; b=GqFvojq2ytXAfJm5zq5MuqGLdc4O/caroNBmlHnQr3XaYFAqLbIasr4xMKktvXt4Bo 5Q6Bk6Aej7YhVHY/NuxFAGqNH95EoBCd5vrhEBxdRZkPS+DAXOoXBKWVOVNY/WVD80+l 8zVk3e2czS4JWxoavDVqRNfdpgXtzIPRn70Q0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=u/vsZYsR7gmweJ5OPnRVvfp9Hn5a4BDCQk3uENuVsP4=; b=pWKKrxJZ5Fz4xg8ODfRAmyRSeioeSXZV/sJ2y4IsqVnZdrDH+HReqH9q6Y9WyB+QrI m6YV+FZdNyfXnZtH+jrXKQFYdGCgsIYDVwThJuLlC9oVAeg6VBIqHd6TGROev9u6CLRm Mvxz8e9MgtxW+dg86kEMYVohhu7qiIKWBofB7vnTzF9vwGkFm5N0wF7iD5PJxVoxP5+T doKVrS32e7kk0l6B6blvgZMlbbyIEyq8F/9vZm+Ai6rwtSoGue2QY7AHX24AqgwSA8xy zvTSlNQI9HUYRBGU0cCwLgZIR94kPquf/72qUMyUTtQDjaYqfOlCbIYWZQmhJNDUm7LF pz3A== X-Received: by 10.68.198.65 with SMTP id ja1mr29369675pbc.175.1372773616168; Tue, 02 Jul 2013 07:00:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.72.134 with HTTP; Tue, 2 Jul 2013 06:59:56 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Tue, 2 Jul 2013 09:59:56 -0400 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkUfoyX3ASPPYOzcA+SH7qu47MrfbeDIsOTDLBwaMTNuyZH6ikcxrNe9XhriQJreYlPTBb5 Cc: websec Subject: Re: [websec] CRIME II alleged at Black Hat 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, 02 Jul 2013 14:00:20 -0000 On 2 July 2013 09:52, Phillip Hallam-Baker wrote: > http://www.darkreading.com/vulnerability/https-side-channel-attack-a-tool-for-enc/240157583 > > We do not have the details yet. But it seems like this will be yet another > variant of the 'in the browser' adaptive plaintext attack against SSL > enabling cookie stealing. Reading from what they're targeting: "could make it possible for targeted attackers to dig up secrets like session identifiers, CSRF tokens, OAuth tokens, and ViewState hidden fields " - I'm 90% certain this is an attack on HTTP compression. CSRF tokens and ViewState are in the HTTP response body. Session IDs and OAuth tokens *may* be in the body in some cases. -tom From hannes.tschofenig@gmx.net Tue Jul 2 07:38: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 8D8F821F9EE1 for ; Tue, 2 Jul 2013 07:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.359 X-Spam-Level: X-Spam-Status: No, score=-101.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 5JOGwhie6XKO for ; Tue, 2 Jul 2013 07:38:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4140821F9EEE for ; Tue, 2 Jul 2013 07:38:54 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MN7F0-1Urqvl1nYW-006eX3 for ; Tue, 02 Jul 2013 16:38:53 +0200 Received: (qmail invoked by alias); 02 Jul 2013 14:38:53 -0000 Received: from 80-248-243-11.cust.suomicom.fi (EHLO [192.168.1.37]) [80.248.243.11] by mail.gmx.net (mp027) with SMTP; 02 Jul 2013 16:38:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+PQtd4wI+PLjunm8Cod1jUAtF+8e5uRLlY/BQkRk 2M9yqeHURrr+oV Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 2 Jul 2013 17:38:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: websec Subject: Re: [websec] CRIME II alleged at Black Hat 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, 02 Jul 2013 14:38:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [I posted this mail also the CA Browser Forum list but it is read-only = for non-members only. So, I post it here.] Hi Phil,=20 I am always a bit reluctant when I hear about these types of attacks. In = many cases, they are very basic and make various assumptions. In the = OAuth working group we had looked into various attacks and many of them = turned out to be an implementation flaw: someone tried to make some = short-cuts and then had to pay the price for it. The most recent example = was Facebook earlier this year.=20 So, I am looking forward to see the details of this attack.=20 If you know the speakers maybe it is possible to get in touch with them = upfront.=20 Just saying move away from bearer tokens is certainly simplistic for a = number of reasons.=20 Ciao Hannes On Jul 2, 2013, at 4:52 PM, Phillip Hallam-Baker wrote: > = http://www.darkreading.com/vulnerability/https-side-channel-attack-a-tool-= for-enc/240157583 >=20 > We do not have the details yet. But it seems like this will be yet = another variant of the 'in the browser' adaptive plaintext attack = against SSL enabling cookie stealing. >=20 > There are two problems we need to fix: >=20 > 1) Whatever the latest SSL issue is. >=20 > 2) Stop using bearer tokens for authentication. >=20 >=20 > I anticipated this attack (it is the third time round after all) which = is why I wrote the session ID scheme as a drop in replacement for = cookies. In the short term sites would have to support both schemes as a = transitional measure but given the current transition to HTML5 it is = entirely likely that some sites can force a transition sooner. >=20 > http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR0uX7AAoJEGhJURNOOiAtn2kH/1EVIvEm07+TG0BHqYuRuuzz 9JsWp4CdECuH3H4Zj+B3a5wrY6XsUxxmTaceC94S82YuV0jy/8wS8vBeeIuF2PU/ FUwTFDoJ8zVdRtPNNRsbLTwc7n/Jg8Hz477wb4CXllfgcqci4ADuihJW6WkaiqNX l/4h0mqIfFOeQ3q7km5BZuZrrD/UbxM4r231tJRxhJL5QKyH8I3e63gtUlBMwW0g nONH3NdoCGoXLiQT9E6YAzCzFQBbb1+UsJbkQ+N8kW+2GtOVdf5caxX6EtuThYuW 68MGKhDbFQZk1dSwLvxzX6sgak020h7o6DJJDlBJLG/jlPlF3KESYmV6LXSaIRo=3D =3DRS6A -----END PGP SIGNATURE----- From nico@cryptonector.com Sun Jul 7 17:22:05 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 DCEB521F9F00 for ; Sun, 7 Jul 2013 17:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 xBFRhqkUGYEu for ; Sun, 7 Jul 2013 17:22:01 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2087721F9CE9 for ; Sun, 7 Jul 2013 17:22:00 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 8B087594061 for ; Sun, 7 Jul 2013 17:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=DP17sGQhNKMnsXjcjiiv /xuTQWc=; b=S5aoUroVZkM6q5iyqaa+hytuHfGm27T371oi0j3igWbezcwVYvvB R60OMV4Z/LLxm9W9g2mGq989Rhmk/hal0ExKLWwpbQME+pKmfY6fHbdhDOTNYZUz cbKUdww3IzTGQ/+JKXf4oRiEgUQDMWFhr1lQmwgEj+6Ey/PxYQIPvMo= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 1ED1F59405E for ; Sun, 7 Jul 2013 17:21:58 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so3245324wev.14 for ; Sun, 07 Jul 2013 17:21:57 -0700 (PDT) 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; bh=la7lPS8XLmFLQrRl3MWDeiztV4/mTwfOTrrB3T1tMes=; b=VMyQD9cTboUgCtDP/J1zOwBxFunz8uyGgzBZeg2+tJ0HjiCVFDfWSpgCER5pKtq7Sw ynR+UC+2KRU97KIE2sJXgCDxroL/havNc8WepSga3qfFj4J2GdgF4BuY9Lufm/WWahBy dWqvLE4XoCz+xV+12YIufY2EZG0gEfiGhNbBFO1VBvJyjRYE73nTOAZvRNuxPsgE2muK 56Gwi/I70blRAHO+Tfwb+ZKH0Gs2im70jSm6sDIk9CtkvR6z4/S5+3BXoFAvAzR14VvA 4kFkgOxWZGwU5PEICTfwuGqV/NYrg1t0fqUXyy14WuqiBWttbmpBixc1iSOX8O6QDDG2 M3fw== MIME-Version: 1.0 X-Received: by 10.194.7.137 with SMTP id j9mr11101844wja.11.1373242917280; Sun, 07 Jul 2013 17:21:57 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Sun, 7 Jul 2013 17:21:57 -0700 (PDT) In-Reply-To: <516F14E1.5040503@digitalbazaar.com> References: <516F14E1.5040503@digitalbazaar.com> Date: Sun, 7 Jul 2013 19:21:57 -0500 Message-ID: From: Nico Williams To: Manu Sporny Content-Type: text/plain; charset=UTF-8 Cc: websec@ietf.org, ietf-http-wg@w3.org, Web Payments CG Subject: Re: [websec] Web Keys and HTTP Signatures X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 00:22:06 -0000 In the IETF Websec WG we call the use of MACs to bind requests (and responses) to sessions: "session continuation". There have been... many specific proposals and even deployed protocols, like yours. We really do need a standard method for session continuation. Session continuation is predicated on having a session key already exchanged, possibly by an authentication mechanism. We'd like to separate the two things: session continuation on the one hand, and key exchange (and authentication) on the other. If your protocol is mature enough it might well be the one we should adopt. I urge you to subscribe to websec@ietf.org and help us :) Nico -- From internet-drafts@ietf.org Sun Jul 7 22:26: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 84CEE21F9FEA; Sun, 7 Jul 2013 22:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR4lvI4KtTbe; Sun, 7 Jul 2013 22:26:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEE321F9DD3; Sun, 7 Jul 2013 22:26:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> Date: Sun, 07 Jul 2013 22:26:54 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-session-continue-prob-00.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 05:26:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : Hypertext Transport Protocol (HTTP) Session Continuation= : Problem Statement Author(s) : Nicolas Williams Filename : draft-ietf-websec-session-continue-prob-00.txt Pages : 13 Date : 2013-07-07 Abstract: One of the most often talked about problems in web security is "cookies". Web cookies are a method of associating requests with "sessions" that may have been authenticated somehow. Cookies are a form of bearer token that leave much to be desired. This document describes the session "continuation" problem for the HyperText Transport Protocol (HTTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-session-continue-prob There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-session-continue-prob-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Sun Jul 7 22:38: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 C0B2D11E8186 for ; Sun, 7 Jul 2013 22:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQm-lQdsrfTz for ; Sun, 7 Jul 2013 22:38:04 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1E11E8188 for ; Sun, 7 Jul 2013 22:38:02 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r685bmGe006168 for ; Mon, 8 Jul 2013 08:38:01 +0300 X-CheckPoint: {51DA502B-2B-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 8 Jul 2013 08:37:53 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Call for adoption: draft-ietf-websec-session-continue-prob-00 Thread-Index: AQHOe51K2fjJqAHy/0+f/EfC93Qceg== Date: Mon, 8 Jul 2013 05:37:52 +0000 Message-ID: <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> In-Reply-To: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.110] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11224829e3e7ac92b6e03f1d303ddc61f0acb0259e Content-Type: text/plain; charset="us-ascii" Content-ID: <5A8E0AED1B01194E93E0D614EBF14511@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 05:38:09 -0000 Hi all This has been submitted with a websec filename, but note that this is not (= yet) on our charter. At the Orlando meeting, we discussed some of the security issues with keepi= ng HTTP sessions using cookies. There was consensus in the room that this i= s a problem that needs solving. Nicolas Williams, Phillip Hallam-Baker, and= Yaron Sheffer volunteered to write a problem statement, and this is it. Th= e message we got from our AD is that first we should show that the working = group has the time and energy to work on solving this problem, and then we = can add this to our charter. So please have a look and this document, and answer the following: - Is this a good starting point for the problem statement? - Will you be willing to review the problem statement? - Will you be willing to read multiple solution proposals to help the work= ing group choose? - Will you be willing to review the solution document? We will have a chance to discuss this in Berlin, but it would be great if w= e have a rough measure of how much energy we have. Thanks Tobias and Yoav On Jul 8, 2013, at 8:26 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Security Working Group of the IETF. >=20 > Title : Hypertext Transport Protocol (HTTP) Session Continuati= on: Problem Statement > Author(s) : Nicolas Williams > Filename : draft-ietf-websec-session-continue-prob-00.txt > Pages : 13 > Date : 2013-07-07 >=20 > Abstract: > One of the most often talked about problems in web security is > "cookies". Web cookies are a method of associating requests with > "sessions" that may have been authenticated somehow. Cookies are a > form of bearer token that leave much to be desired. This document > describes the session "continuation" problem for the HyperText > Transport Protocol (HTTP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-websec-session-continue-prob >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-websec-session-continue-prob-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Sun Jul 7 22:40:51 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2749811E8186 for ; Sun, 7 Jul 2013 22:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 CutY8LoWoEU2 for ; Sun, 7 Jul 2013 22:40:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B13CA21F9BBD for ; Sun, 7 Jul 2013 22:40:45 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r685ecCl007369 for ; Mon, 8 Jul 2013 08:40:38 +0300 X-CheckPoint: {51DA50D6-B-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 8 Jul 2013 08:40:38 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 Thread-Index: AQHOe52s+b7dZBBWJUWpKSg43MuMrw== Date: Mon, 8 Jul 2013 05:40:37 +0000 Message-ID: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> In-Reply-To: <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.110] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11fcb890ab2dcc8d94b00a64c525bcdec82e97109b Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 05:40:51 -0000 And I'll start the ball rolling, buy answering yes (with no hats) to all qu= estions. On Jul 8, 2013, at 8:37 AM, Yoav Nir wrote: > Hi all >=20 > This has been submitted with a websec filename, but note that this is not= (yet) on our charter. >=20 > At the Orlando meeting, we discussed some of the security issues with kee= ping HTTP sessions using cookies. There was consensus in the room that this= is a problem that needs solving. Nicolas Williams, Phillip Hallam-Baker, a= nd Yaron Sheffer volunteered to write a problem statement, and this is it. = The message we got from our AD is that first we should show that the workin= g group has the time and energy to work on solving this problem, and then w= e can add this to our charter. >=20 > So please have a look and this document, and answer the following: > - Is this a good starting point for the problem statement? > - Will you be willing to review the problem statement? > - Will you be willing to read multiple solution proposals to help the wor= king group choose? > - Will you be willing to review the solution document? >=20 > We will have a chance to discuss this in Berlin, but it would be great if= we have a rough measure of how much energy we have. >=20 > Thanks >=20 > Tobias and Yoav >=20 > On Jul 8, 2013, at 8:26 AM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Web Security Working Group of the IETF. >>=20 >> Title : Hypertext Transport Protocol (HTTP) Session Continuat= ion: Problem Statement >> Author(s) : Nicolas Williams >> Filename : draft-ietf-websec-session-continue-prob-00.txt >> Pages : 13 >> Date : 2013-07-07 >>=20 >> Abstract: >> One of the most often talked about problems in web security is >> "cookies". Web cookies are a method of associating requests with >> "sessions" that may have been authenticated somehow. Cookies are a >> form of bearer token that leave much to be desired. This document >> describes the session "continuation" problem for the HyperText >> Transport Protocol (HTTP). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-websec-session-continue-prob >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-websec-session-continue-prob-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Email secured by Check Point From alexey.melnikov@isode.com Mon Jul 8 10:11: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 611E421F9D49 for ; Mon, 8 Jul 2013 10:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MANGLED_LIST=2.3, 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 28+ldkSzBOJd for ; Mon, 8 Jul 2013 10:11:47 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEA921F9D46 for ; Mon, 8 Jul 2013 10:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1373303505; d=isode.com; s=selector; i=@isode.com; bh=JUr/ystuNnQu83LuzSg9RI280+zHO/NNNwgA2C1ojEg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gYPAAVIWZNxaYIywBNztcxPI+VgMBHeP1S518HDNEuZqiuJPSvwYI2h35/sDZXJxCCmQx4 jrt9lTSw4cOrX2fEpAAbWMq0cRzRMf6N+oincBS7QHUji+kptbpBEAX3AchM88OORiaWsJ zKVz7EwpqgXPXxX44P//yCHTR7aldEg=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 8 Jul 2013 18:11:45 +0100 Message-ID: <51DAF2DA.8050708@isode.com> Date: Mon, 08 Jul 2013 18:11:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: IETF WebSec WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Review of draft-ietf-websec-key-pinning-06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:11:48 -0000 In 2.1, 1st para: use of SHOULD is not needed. This is already an extension. What is the point of violating the SHOULD? It seems to be the same as not supporting the extension. End of section 2.1: base-64 needs a Normative reference. 2.1.3: next to the last paragraph: "MAY fail to report" is not a proper use of RFC 2119 keyword, as this is not an implementation choice. Just use lowercase "may" here. sha-1 and sha-256 need Normative references. In 2.5: the 3rd para from the end: how is this different from the 4th para? It seems to specify a weaker requirement. Typo: max.age JSON (Section 3) needs a Normative reference. Section 5 (IANA) contradicts section 2.1. So actually there are IANA Considerations. You should mark Section 8 as requiring removal by RFC-Editor, as this section is not useful in the final document (RFC). From palmer@google.com Mon Jul 8 16:29: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 9890E21F9B9B for ; Mon, 8 Jul 2013 16:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, MANGLED_LIST=2.3, 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 x6OeSuk-9t4Q for ; Mon, 8 Jul 2013 16:29:49 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05311E80E1 for ; Mon, 8 Jul 2013 16:29:49 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id gd11so3825559vcb.30 for ; Mon, 08 Jul 2013 16:29: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; bh=bCoqoH2QnW5n74N/sD9jGXkajoxB7vr91LWoFf0gXso=; b=UVUgJyXa12zNBuHP5mW4xfTpMNj6x3QP4wERu7I70m1AE7TR0luCczWVSOovD5LVdk gdIVm8c4oHJMsWNQGDd0JdpGga07YcbLE7Dvam/4tuaVyqeMC3eEM87/Ll/2j68rY+Nv sNeH8PmimXjLGcoaYcCyO7vdfMmjfKUZETgeataBz/sFLFGjf7XgC+1ZOUPrxF16emW+ WbQYD2txsOSqHrxUmiagw/2xDECr3R+aUoDhtrVVyeM84PcPWxgFFCuVPxesDLOYbcNU xJWBfcQFJnml/DhgD4xf8qlE2bDqnOmBPN6tyXeViAb4cXR/ItM3W6VR2u+JtYHS7KDM 08YQ== 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=bCoqoH2QnW5n74N/sD9jGXkajoxB7vr91LWoFf0gXso=; b=RnKo757a9TPa5wmtrxMakwVoYyg9lnTBTIwNyfflHcrG6GoupkksnWnaQwDNF4OZ7W +NNBNwyo2wOo88S/F+BP5MtSsIbnNjR8HAvHusU0CBGczgByDwc1nBzxRzpQDC/4mL1G Ow/XEgY+ySi1rCCbDUTl5R32IcSUw8V0hOADvYb4mxfKuaWshOQ+0jSmI0cI54780rl+ RwNmgcFbUVSY/rCCV4T5kyGMT1JTR2hCMpLgxiMCGt92LCjYJ4ee9oCeydAlvKckxHfk hq+juyaVR1Z1HlLHY4uRdalRpv1M8H19Jkqw5aGs5IhipO46JSrOI/nBZkVzUBScBXFs AYZA== MIME-Version: 1.0 X-Received: by 10.220.66.136 with SMTP id n8mr15168357vci.49.1373326188400; Mon, 08 Jul 2013 16:29:48 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Mon, 8 Jul 2013 16:29:48 -0700 (PDT) In-Reply-To: <51DAF2DA.8050708@isode.com> References: <51DAF2DA.8050708@isode.com> Date: Mon, 8 Jul 2013 16:29:48 -0700 Message-ID: From: Chris Palmer To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnDBwM1QkZAloxiKsC9w4wMefhnw43d8uzv7kPCAFyKuWL7+rWusDCXPb5+kFo5co/5Ua8qn4xclV19fGypY/R1GxSGY2TYff89Ku8wVIGW4bfM/CiwErb12OtZ7Rl6RF6kBc3SOwo5ZHpVJV2YUx98NykZHCQkP0jt1ewl9JtT3yX00493hJVzHpICOTdfivKBdeqI Cc: IETF WebSec WG Subject: Re: [websec] Review of draft-ietf-websec-key-pinning-06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 23:29:49 -0000 Thanks, Alexey! I will soon upload a version -07 that addresses most of your points and which also adds a Privacy Considerations section as requested by previous commenters. Notes and questions below: On Mon, Jul 8, 2013 at 10:11 AM, Alexey Melnikov wrote: > In 2.1, 1st para: use of SHOULD is not needed. This is already an extension. > What is the point of violating the SHOULD? It seems to be the same as not > supporting the extension. Lowercased to "should". > End of section 2.1: base-64 needs a Normative reference. Added and cited. > 2.1.3: next to the last paragraph: "MAY fail to report" is not a proper use > of RFC 2119 keyword, as this is not an implementation choice. Just use > lowercase "may" here. Done. > sha-1 and sha-256 need Normative references. Added and cited. > In 2.5: the 3rd para from the end: how is this different from the 4th para? > It seems to specify a weaker requirement. Can you say which paragraphs explicitly? I'm having a hard time figuring out which ones you mean. Thanks. > Typo: max.age Fixed. > JSON (Section 3) needs a Normative reference. Added and cited. > Section 5 (IANA) contradicts section 2.1. So actually there are IANA > Considerations. Added a comment in Section 5 to that effect. > You should mark Section 8 as requiring removal by RFC-Editor, as this > section is not useful in the final document (RFC). At least some RFCs do have Acknowledgements sections? Is there a standard way of telling the RFC-Editor to remove the section? From internet-drafts@ietf.org Mon Jul 8 16:39:31 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9ACD21F9B94; Mon, 8 Jul 2013 16:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+teUJWQuK8f; Mon, 8 Jul 2013 16:39:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CFF21F9A31; Mon, 8 Jul 2013 16:39:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708233930.18502.4410.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 16:39:30 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-07.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 23:39:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-07.txt Pages : 23 Date : 2013-07-08 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jbonneau@gmail.com Mon Jul 8 21:24: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 879E921F9BA6 for ; Mon, 8 Jul 2013 21:24: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, 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 8WB57uiyjyDL for ; Mon, 8 Jul 2013 21:24:08 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6F921F9B9C for ; Mon, 8 Jul 2013 21:24:07 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id o13so6176483qaj.10 for ; Mon, 08 Jul 2013 21:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ytY4t3U9FS9n2U4TrHa+wodQXVhef3t9rIcoh/JQc8Y=; b=NJwjBphT4PKQbYYlEcrW8Xb4aXeEYZkmmdnpKqv60mDUyoQ8oUvLa667isMZhV3V7W X099ZUcSdvE0QDT3i/jBRLmeu6B9F8ioygAn/vAVW7qgOdJVPLRuxo9Q2K5g9d+4S+Eh dIAAh1RoLc6Aj1KI/NmbJ8FgjudrJuO9f1rgEnVIAeNiAk8oXzBm62TgViraWg6JwxL9 IyAELiZhFcku4BL2RrIMgYa01Wn0AgNZ/HJcKFp8dAq5MBxvNdXDGBC9kXWMqfZFf5Mm YvSYRnyf8NZaVoR4GgrB4ik5KaFJ4kE3MjcNWZ2qonDruR1+cjv/aSE9OXDvqhhvW4Em Upow== X-Received: by 10.224.172.198 with SMTP id m6mr21637426qaz.44.1373343846316; Mon, 08 Jul 2013 21:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.120.199 with HTTP; Mon, 8 Jul 2013 21:23:46 -0700 (PDT) In-Reply-To: <51C7F08F.2090205@gondrom.org> References: <51C7F08F.2090205@gondrom.org> From: Joseph Bonneau Date: Tue, 9 Jul 2013 00:23:46 -0400 Message-ID: To: Tobias Gondrom , websec@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d8c7f1d450f04e10c889a Subject: Re: [websec] HPKP and privacy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 04:24:09 -0000 --047d7b5d8c7f1d450f04e10c889a Content-Type: text/plain; charset=UTF-8 There is now a section on privacy considerations in the new draft ( http://tools.ietf.org/html/draft-ietf-websec-key-pinning-07#section-5). The text does a nice job explaining the N-pinned-subdomains-as-supercookie attack, and also using report-uri as a tracking mechanism. There is no advice to implementers, however. Is there a reason not to make explicit that user agents SHOULD remove pins for privacy reasons, something along the lines of the text I suggested previously: > Thinking of (a) and (b) is it worth adding a section to the spec on > privacy considerations? The high points would be that (a) Browsers SHOULD > remove dynamic pins for a domain whenever users request deletion of other > browser-history state for that domain, such as a "clear history" request or > the end of a private browsing session. (b) Browsers MAY decline to note > pins for privacy reasons for third-party domains while browsing, similar to > third-party cookie policies. > > Cheers, Joe --047d7b5d8c7f1d450f04e10c889a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is now a section on privacy considerations in the new draft (http://tools.ietf.org/html/draft-ietf-websec-key-pinning-= 07#section-5). The text does a nice job explaining the N-pinned-subdoma= ins-as-supercookie attack, and also using report-uri as a tracking mechanis= m.

There is no advice to implementers, however. Is there a reas= on not to make explicit that user agents SHOULD remove pins for privacy rea= sons, something along the lines of the text I suggested previously:
Thinking of (a) and (b) is it worth adding a section to the spec on privacy considerations? The high points would be that (a) Browsers SHOULD remove dynamic pins for a domain whenever users request deletion of other browser-history state for that domain, such as a "clear history" request or the end of a private browsing session. (b) Browsers MAY decline to note pins for privacy reasons for third-party domains while browsing, similar to third-party cookie policies.=C2=A0
Cheers,

Joe
--047d7b5d8c7f1d450f04e10c889a-- From ynir@checkpoint.com Mon Jul 8 21:57: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 CDEC421F9CF3 for ; Mon, 8 Jul 2013 21:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 UdW5IyWbwPMV for ; Mon, 8 Jul 2013 21:57:19 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8121F9CEC for ; Mon, 8 Jul 2013 21:57:18 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r694vGKK007719; Tue, 9 Jul 2013 07:57:16 +0300 X-CheckPoint: {51DB982B-1-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Tue, 9 Jul 2013 07:57:15 +0300 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] Review of draft-ietf-websec-key-pinning-06 Thread-Index: AQHOe/5Awc18hwEkn0CDNhvqUptgEJlbO8sAgABbfgA= Date: Tue, 9 Jul 2013 04:57:15 +0000 Message-ID: <1F476385-849E-41F0-9B8C-A69A9C36FA71@checkpoint.com> References: <51DAF2DA.8050708@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.208] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11c11bfe0cb7a57dde1b583c2a8a556c4ce2d2ac31 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Review of draft-ietf-websec-key-pinning-06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 04:57:27 -0000 On Jul 9, 2013, at 2:29 AM, Chris Palmer wrote: >=20 >> In 2.5: the 3rd para from the end: how is this different from the 4th pa= ra? >> It seems to specify a weaker requirement. >=20 > Can you say which paragraphs explicitly? I'm having a hard time > figuring out which ones you mean. Thanks. 3rd Para: "If the Public-Key-Pins response header field does not meet all t= hree of these criteria, the UA MUST NOT note the host as a Pinned Host." 4th Para: "The UA MUST ignore Public-Key-Pins response header fields receiv= ed on connections that do not meet the first criterion." >=20 >> You should mark Section 8 as requiring removal by RFC-Editor, as this >> section is not useful in the final document (RFC). >=20 > At least some RFCs do have Acknowledgements sections? >=20 > Is there a standard way of telling the RFC-Editor to remove the section? The standard way is to add a sentence like: [RFC EDITOR: PLEASE REMOVE THIS SECTION] And don't worry, just before the RFC is published, you get to review that t= he RFC editor made all the right changes. And I think Alexey meant section 9 ("What's changed") rather than section 8= . RFCs do have acknowledgement sections. Hope this helps Yoav= From alexey.melnikov@isode.com Tue Jul 9 01:09:41 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 7DB5F21F9EF4 for ; Tue, 9 Jul 2013 01:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 u9UeOCGGazvZ for ; Tue, 9 Jul 2013 01:09:36 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id AE09F21F9EEF for ; Tue, 9 Jul 2013 01:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1373357369; d=isode.com; s=selector; i=@isode.com; bh=f04kyx+apYceBWnecWAPahHmTNIbcLm3DMN0PaGRAx4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vsPPyV3xhhOrjx12oHNPh3R6oPu2kO3IvpREyW7wQ7WnQ30vc5MxwKtIL2nXzVNGdeXDxX DT+w0NrYbrXVsS41Go2qsjOKhBa/zK4aM2j0Dz37Y8Lu9CqkdLlq2bBAd2ne9Z90mpWJwB wereduFgJY0FYxrjVYKUZ7Bf5HWLljY=; Received: from [10.210.28.155] ((unknown) [212.183.128.178]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 9 Jul 2013 09:09:29 +0100 X-SMTP-Protocol-Errors: NORDNS References: <51DAF2DA.8050708@isode.com> <1F476385-849E-41F0-9B8C-A69A9C36FA71@checkpoint.com> In-Reply-To: <1F476385-849E-41F0-9B8C-A69A9C36FA71@checkpoint.com> Message-Id: <8C30B0D0-360D-4188-8758-1C1E285B53C2@isode.com> X-Mailer: iPhone Mail (10A523) From: Alexey Melnikov Date: Tue, 9 Jul 2013 09:09:52 +0100 To: Yoav Nir MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Review of draft-ietf-websec-key-pinning-06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 08:09:41 -0000 On 9 Jul 2013, at 05:57, Yoav Nir wrote: > On Jul 9, 2013, at 2:29 AM, Chris Palmer wrote: >>> You should mark Section 8 as requiring removal by RFC-Editor, as this >>> section is not useful in the final document (RFC). >>=20 >> At least some RFCs do have Acknowledgements sections? >>=20 >> Is there a standard way of telling the RFC-Editor to remove the section? >=20 > The standard way is to add a sentence like: > [RFC EDITOR: PLEASE REMOVE THIS SECTION] >=20 > And don't worry, just before the RFC is published, you get to review that t= he RFC editor made all the right changes. >=20 > And I think Alexey meant section 9 ("What's changed") Oh yes, you are correct. > rather than section 8. RFCs do have acknowledgement sections. From tom@ritter.vg Tue Jul 9 06: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 8FAF411E812A for ; Tue, 9 Jul 2013 06:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=0.929, 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 14cqiW9IiSfT for ; Tue, 9 Jul 2013 06:29:41 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id C3AAB11E8128 for ; Tue, 9 Jul 2013 06:29:41 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id 14so5244887pdj.26 for ; Tue, 09 Jul 2013 06:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0XnKwsw6in4a7QJOkZ70fGlEa72x+aVqmeXX7HUkpZo=; b=RGg/6iN6gDlOfW0zcnKT1nl48JyIAcDK5eZb8dSCCbgbfnYseD46NbwUJgDTW2hiR1 wn+es1vu0a85eVkphQ1kbf9+ok+uhl8J2LaVG2otgF2T/xGgZhG9BNuA8eBeGOTn2FvG wnnKp0rX1c1L3Ey4LPXDWz9G/h/NBijOWo1Nc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=0XnKwsw6in4a7QJOkZ70fGlEa72x+aVqmeXX7HUkpZo=; b=SL9+UQt18s1pECiWbPvCy2A0gXb/fp5l/S4JePp8HhAWh8iKxpUg+b4y7/0XSGMvzN T9mKzBsJDxOU2zU7o7rnAoPTdPL51mrCYzlxuz9bN7OYryEL9QXQVqHTcC4xNB3UoYBh dywD7wCtoFZOhL0EpBi11V1uV1Zq6BdihIcqz1jgRI9qr0xcR7375m1mmc2R6Uf90T2+ orO15oUEZHb8royVQLGBhKvJW0E1LbDFiE6X+CtMNL6pEwy2HN0tPaVhKSFwy+iXFajs wbrGZyJMhfHMuBEMnqfRw65wIyvQDcNHQxusxCEmHdwkVF2t+avg42FgU1sBUmSQEKTU FTsQ== X-Received: by 10.68.252.194 with SMTP id zu2mr26385312pbc.58.1373376581122; Tue, 09 Jul 2013 06:29:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.72.134 with HTTP; Tue, 9 Jul 2013 06:29:21 -0700 (PDT) In-Reply-To: References: <51C7F08F.2090205@gondrom.org> From: Tom Ritter Date: Tue, 9 Jul 2013 09:29:21 -0400 Message-ID: To: Joseph Bonneau Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlRroiw560U6tmOGz8e9mOnCB41tjcW2GA8iTFjPDmb+y0ExLDt0bobHGFtV6htfKYjCdT6 Cc: websec@ietf.org Subject: Re: [websec] HPKP and privacy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:29:42 -0000 On 9 July 2013 00:23, Joseph Bonneau wrote: > There is no advice to implementers, however. Is there a reason not to make > explicit that user agents SHOULD remove pins for privacy reasons, something > along the lines of the text I suggested previously: It states that UAs must let people clear data: >UAs MUST have a way for users to clear current pins for Pinned Hosts. >UAs SHOULD have a way for users to query the current state of Pinned >Hosts. When *should* a user agent automatically remove pins for privacy reasons? Any algorithm anyone comes up with will be known, and will be bypassed with multiple domains, or whatever. -tom From palmer@google.com Tue Jul 9 14:43: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 DAA7311E817E for ; Tue, 9 Jul 2013 14:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=1.450, 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 I886ed4R5r82 for ; Tue, 9 Jul 2013 14:43:12 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7174711E817D for ; Tue, 9 Jul 2013 14:43:07 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id d10so5056912vea.24 for ; Tue, 09 Jul 2013 14:43:07 -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=XsA1rg2qdi/9S9/Km7fj6JB1rjm1KC2xBw0kTbJVr4U=; b=LQQykmCwsg97XnN1m8bqsYaurIgBzqlPubNz36uPc2fSVuRKvNQuRjW3FJEGqqMyDz EwDhu8bvxZsJmsu5Hn1W5z4XhRq0f+6xUx36Wm2r9LKkfuPKEsCrscmKD0utFPEFcXiz 2cyGgOQiRwWXbOvQhky6yZlZl52W8Vptpjq1UhsVsmUIhxe46wnHirTOupybmWD5DVIk 40QYzPhG+t7iqxEGrb5rC5el6up5GhhSt4WeQfD7CnGOhGPLKefKVfdbUhbP+G1R6oYI SQgZ5mDSY27rX+wSmwGVuOzFlc7g1ODAl6XJFKk5ge2GPRsPgdY7Nx9c32sBfdfbrPZS odHw== 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=XsA1rg2qdi/9S9/Km7fj6JB1rjm1KC2xBw0kTbJVr4U=; b=ML3cMAvYjJwRLWGwEa9USzZM02DCgh5xPbVBoyntKrxfkvbvyatrQPrXgZG6sVqU8Y N97Ib7NhQWrxSfjIFooeNsEut4tu/kf3ZaJiU2P43EaOzYDqvQNuK01NG26rimpxy8ra wv+8pDSjJcG5d/UK3VxY33R2yEvyP/oAJRUdPRLVMnFo1j5I8DX7hX760rXUOw8uzo2C OXf1GujsTsqdH6EYUicp3xV8uBrOvz5fz+/pFH3BjVxOrJqXs3+wi7c8YyHfJmZngOLv WPCni8oX3hXlLym5eiSDxQ30abXfmdc6iRKNQg/efMm1bEkXVjZe/oWEEECXSHN+ow4A /CMQ== MIME-Version: 1.0 X-Received: by 10.220.111.206 with SMTP id t14mr17726834vcp.77.1373406186891; Tue, 09 Jul 2013 14:43:06 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Tue, 9 Jul 2013 14:43:06 -0700 (PDT) In-Reply-To: References: <51C7F08F.2090205@gondrom.org> Date: Tue, 9 Jul 2013 14:43:06 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkl2j+lNuVpNSiqEiEWXJrOSGw1KQV1bZj8UsXaqf9cYRVP+AXXqvFo2E78t0c/mR44uvnQFFM7BJYPCXdCZ6v6E+I9MZHEUt0hP70G1F4SkzvRkGvsUbMuFP9JDoDZTagGaywl9PBC2kyafOSMyBjyutclRxyrTijRf9hreIFBw/gKBI28kuRf5wto/ZdtrGveuH+r Cc: IETF WebSec WG Subject: Re: [websec] HPKP and privacy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 21:43:13 -0000 On Tue, Jul 9, 2013 at 6:29 AM, Tom Ritter wrote: >> There is no advice to implementers, however. Is there a reason not to make >> explicit that user agents SHOULD remove pins for privacy reasons, something >> along the lines of the text I suggested previously: > > It states that UAs must let people clear data: Yes. > When *should* a user agent automatically remove pins for privacy > reasons? Any algorithm anyone comes up with will be known, and will > be bypassed with multiple domains, or whatever. Yes. Unfortunately, I don't see a way to have both HPKP and automatic defense against this kind of super-cookie. The problem exists for HSTS, too. From jbonneau@gmail.com Tue Jul 9 15:54: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 BF11321F9607 for ; Tue, 9 Jul 2013 15:54: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, 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 CxJnrXM3cRK3 for ; Tue, 9 Jul 2013 15:54:46 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B21FA21F9A72 for ; Tue, 9 Jul 2013 15:54:30 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so4720350vcb.6 for ; Tue, 09 Jul 2013 15:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=79PRz0wnUEhY3POM1MK90ebGy7bMloTU1zuBXzni+ww=; b=sjhsCNpSj4WlFKEHlLbGIOI5szIvKDb+CeJNAQL2qcMVDMSJ4db1xnOIOWmjaRWWsv 0lh0MrQrKRwESpOpXk9K3TEvwDjarohbrBhQlIR5Hfe0zpfGan+Hz6J1ykQ9ckLeEGEN 1CY06pmNmyzTvigeiZnZe/TckSKRcnC5phnJBD2oCuTVv9p5habIrLlzOQ+wT5Gy7sgd rsDlKxYlrxmljO7bWJBpmHR4edq5SbiouypiIXhaIwkaKsaDVYpg3WvyytXtC+IFmd7E 11Wa5afzlS5bCTuHuE5+dhxjAHg7afGpdc3J2dDWM/EKt0+9edsqyekNsb3nsQ6QDtaF DCtg== X-Received: by 10.58.46.48 with SMTP id s16mr17762440vem.52.1373410468848; Tue, 09 Jul 2013 15:54:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.103.69 with HTTP; Tue, 9 Jul 2013 15:54:08 -0700 (PDT) In-Reply-To: References: <51C7F08F.2090205@gondrom.org> From: Joseph Bonneau Date: Tue, 9 Jul 2013 18:54:08 -0400 Message-ID: To: Chris Palmer Content-Type: multipart/alternative; boundary=089e012945b0206aad04e11c0bcd Cc: IETF WebSec WG Subject: Re: [websec] HPKP and privacy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 22:54:56 -0000 --089e012945b0206aad04e11c0bcd Content-Type: text/plain; charset=UTF-8 > > It states that UAs must let people clear data: > > Yes. Ah I see this text now, I was confused since it's in a different section. > > When *should* a user agent automatically remove pins for privacy > > reasons? Any algorithm anyone comes up with will be known, and will > > be bypassed with multiple domains, or whatever. > > Yes. Unfortunately, I don't see a way to have both HPKP and automatic > defense against this kind of super-cookie. The problem exists for > HSTS, too. > I agree, but there are two things user agents SHOULD do at a minimum: (a) clear pins for domains whenever other domain-specific information is cleared for privacy reasons (delete history since time N, or private browsing mode) (b) not store pins in cases where cookies will not be rejected for privacy reasons (such as third-party cookie blocking policies). I don't think these are obvious to implementers so I would like to seem them in the spec. Joe --089e012945b0206aad04e11c0bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> It states that UAs must let people clear data:

Yes.

Ah I see this text now, I was co= nfused since it's in a different section.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
> When *should* a user agent automatically remove pins for privacy
> reasons? =C2=A0Any algorithm anyone comes up with will be known, and w= ill
> be bypassed with multiple domains, or whatever.

Yes. Unfortunately, I don't see a way to have both HPKP and autom= atic
defense against this kind of super-cookie. The problem exists for
HSTS, too.

I agree, but there are two things user agents S= HOULD do at a minimum: (a) clear pins for domains whenever other domain-spe= cific information is cleared for privacy reasons (delete history since time= N, or private browsing mode) (b) not store pins in cases where cookies wil= l not be rejected for privacy reasons (such as third-party cookie blocking = policies). I don't think these are obvious to implementers so I would l= ike to seem them in the spec.

Joe
--089e012945b0206aad04e11c0bcd-- From sm@resistor.net Tue Jul 9 17:41: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 6A06C21F9D3A; Tue, 9 Jul 2013 17:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 GeTzt+7M4mao; Tue, 9 Jul 2013 17:41:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7487121F9D35; Tue, 9 Jul 2013 17:41:26 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6A0fE1j001199; Tue, 9 Jul 2013 17:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373416880; bh=SOubPN1CvNymPELAoGmiqs67sywGlwolHEwpC07iqvs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ycq4RCL/MMlLagEThg0EArxsHdMoxECI9AqhZ/FLcHtEAcBHKZN2OdvRLX1mG0kcn ehJ5EP7/sQAK1pF5DIRsVnrWa0FWd2BoUF8Irc9qF1lMLTdG6cDhxBPqbW13Fa/TOw OeizPRZGbitYHfShn8vchc2diM9jrB6KVoVJItNw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373416880; i=@resistor.net; bh=SOubPN1CvNymPELAoGmiqs67sywGlwolHEwpC07iqvs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uqgd8NOD1Rs6a9VY+M48HZyAJQS+peW5ZDLQ11a1cZKttCuJjSIcpyf9LuHyH+/7j OLXergPPOw2og4ZUGNHYac38OBQvOasNHwIJWki/kcL4aYUsHEaaMBl0AiPTTirA8q lxkHsz0d2mZvJkYg25pdTDuFy2DdB/0JoMDqaxbU= Message-Id: <6.2.5.6.2.20130709172646.0b2a0978@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 Jul 2013 17:38:34 -0700 To: Tom Ritter From: SM In-Reply-To: References: <51C7F08F.2090205@gondrom.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-privacy@ietf.org, websec@ietf.org Subject: Re: [websec] HPKP and privacy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 00:41:27 -0000 Hi Tom, [Cc to privacy-nuts :-)] At 06:29 09-07-2013, Tom Ritter wrote: >On 9 July 2013 00:23, Joseph Bonneau wrote: > > There is no advice to implementers, however. Is there a reason not to make > > explicit that user agents SHOULD remove pins for privacy reasons, something > > along the lines of the text I suggested previously: > >It states that UAs must let people clear data: > > >UAs MUST have a way for users to clear current pins for Pinned Hosts. > >UAs SHOULD have a way for users to query the current state of Pinned > >Hosts. I read Section 5 and missed the above (it's in Section 7). Section 5 basically says that HPKP can be a super-cookie. It then explains two attack scenarios. I think that the privacy considerations should be made explicit. Regards, -sm From trevp@trevp.net Wed Jul 10 13:00: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 8F4B421F9E5A for ; Wed, 10 Jul 2013 13:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vvg3X+150E8 for ; Wed, 10 Jul 2013 12:59:58 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5401521F99BB for ; Wed, 10 Jul 2013 12:59:57 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so6309014wgg.10 for ; Wed, 10 Jul 2013 12:59:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=VyuPDYq4m/NbiRA2bByr/ZeAm4I6NyatZjp7VCCsaaY=; b=aHNQVfyBDaVPGTqUpGO2ZHgyBiNXsVOAt/JvVdYLV4/tIfTuhk6GG1bfylIJhHTVJt XZSAn0/vV8mkrZvqFJTLWULqpgUzn+1+EWPO7O/+lwAJO8pWUqecJByuvSXbAAYLfigh l4J7Tc3X8VPijkAIxRYBwKxUVPgWGMrSh3m/3K9B/YB/8wU4Z9nL8ndiVArZfhAxTCP5 h5OcAJzRWb3fA8tb/rsCTnHiewy/vDLgRlEClWVzy7p5hDFFZnog5wq38LFZtZSCnaMG WmBC8P3TDrsfo7VSvULUblYG8SASKojP5aTSxR3Ji0mUs1wMM24x4GZbFa2K/2kYcBCH 1SXA== MIME-Version: 1.0 X-Received: by 10.180.101.170 with SMTP id fh10mr21045248wib.22.1373486390150; Wed, 10 Jul 2013 12:59:50 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 10 Jul 2013 12:59:50 -0700 (PDT) X-Originating-IP: [50.37.26.202] Date: Wed, 10 Jul 2013 12:59:50 -0700 Message-ID: From: Trevor Perrin To: IETF WebSec WG Content-Type: multipart/alternative; boundary=14dae9cc96ec639c3404e12db859 X-Gm-Message-State: ALoCoQkjjP8r2uVlDBEVO2cnPNSEBEfoVdJTO12CKG5MsmD3y9y1xPUyec2CrUVxdc/UmJ+Qr/t8 Subject: [websec] Review of key pinning draft-07 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, 10 Jul 2013 20:00:03 -0000 --14dae9cc96ec639c3404e12db859 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, all, There's a few issues that need more discussion: 1) Are SubjectPublicKeyInfos the right things to pin? I suspect the easiest and safest pin for most sites would be a list of trusted CAs. Expressing this in HPKP seems difficult and error-prone. 2) Is an HTTP Response Header, sent on every response from a pinned host, the best way to assert the pin? It's not obvious why this is better than a .well-known URL, or a response that is only returned if the client asks for it. 3) Interaction with preloaded pins needs more thought, see email thread [1]. 4) Interaction with cookies needs discussion. Cookie scoping rules pose a serious problem for pinning, e.g. a pin at "example.com" could be undermined by a MITM inventing a "badguy.example.com" and using it to steal or force cookies. Comments: * Why is there a "Public-Key-Pins-Report-Only" header instead of a "report-only" directive? Most of the document is written as if there was a single "PKP header field", so a directive would make more sense. * In draft-05, client processing was changed from noting a single "expiry" value to noting two values: "Effective Pin Date" and "max-age". The previous approach was simpler, stored less data, and was more aligned with HSTS. * Section 2.3.1 fails to update the Effective Date of a noted pin when it is noted again. * Section 2.6 mandates "When a UA connects to a pinned Host, if the TLS connection has errors, the UA MUST terminate the connection without allowing the user to proceed". HSTS allows the server to specify this, so it seems unnecessary and inflexible to mandate it here. It's also unclear whether a "report-only" pin counts as a "pinned Host". * UA processing rules are confusingly spread across the document. For example, much of "2.2 Server Processing Model" is actually UA processing. Also, 2.3.1 and 2.5 describe the same process so should be combined. * Section 2.5 - Does a failed validation of a "report-only" pin count as an "error" that will inhibit noting of new pins in the connection? * Specified UA behavior with multiple header fields is contradictory: - 2.1.3: "If a Host sets both the Public-Key-Pins header and the Public-Key- Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and MUST note only the pins and directives given in the Public-Key-Pins- Report-Only header." - 2.3.1: "If a UA receives more than one PKP header field in an HTTP response message over secure transport, then the UA MUST process only the first such header field." * Section 3 - Should the failure report contain the certificates sent by the server, as well as the validated chain? Could help debugging and attack analysis. * Why is SHA1 supported? If the reason is size, why not remove it but allow the server to pin to a truncated hash (e.g. pin to the first 16 or 20 bytes of SHA256) * Should there be a list of "excluded" keys that must not appear in the "validated certificate chain"? Chrome's preloaded pinning supports this, apparently to exclude 3rd-party subCAs that might have been issued under a pinned CA. * Would it be better to use the term "pin" for the entire record associating (hostname, HPKP data), instead of calling each individual hash a "pin"? The hostname is "pinned" to the 1-of-n key set as a whole, not each key individually. * Should the header name be changed once this draft stabilizes, to ensure no bad interactions with UAs that implemented earlier drafts? Minor: * "Pinning Policy" and "Pinning Metadata" are synonyms? * 2.3.1 "Known HSTS Host" -> "Known HPKP Host" * 2.3.1 ... "or," ... "Otherwise" is confusing * 2.3.2 - are clients expected to store directives they don't understand? * 2.6 - is pin validation performed on resumed TLS connections? * 3 - can UAs provide additional JSON fields inside the report? * The term "validated certificate chain" is not defined * An IANA registry is needed for directives * The acknowledgement for "pin break codes" is ancient/irrelevant Trevor [1] http://www.ietf.org/mail-archive/web/websec/current/msg01651.html --14dae9cc96ec639c3404e12db859 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Chris, all,

There's a few issues that need more discussion:

=A01) Are SubjectPublicKeyInfos the right = things to pin? =A0I suspect the easiest and safest pin for most sites would= be a list of trusted CAs. =A0Expressing this in HPKP seems difficult and e= rror-prone.

=A02) Is an HTTP Response Header, sent on every respons= e from a pinned host, the best way to assert the pin? =A0It's not obvio= us why this is better than a .well-known URL, or a response that is only re= turned if the client asks for it.

=A03) Interaction with preloaded pins needs more though= t, see email thread [1].

=A04) Interaction with co= okies needs discussion. =A0Cookie scoping rules pose a serious problem for = pinning, e.g. a pin at "example.com= " could be undermined by a MITM inventing a "badguy.example.com" and using it to steal or for= ce cookies.


Comments:
=A0* Why is there a = "Public-Key-Pins-Report-Only" header instead of a "report-on= ly" directive? =A0Most of the document is written as if there was a si= ngle "PKP header field", so a directive would make more sense.
=A0
=A0* In draft-05, client processing was changed from not= ing a single "expiry" value to noting two values: "Effective= Pin Date" and "max-age". =A0The previous approach was simpl= er, stored less data, and was more aligned with HSTS.
=A0
=A0* Section 2.3.1 fails to update the Effective Date of= a noted pin when it is noted again.
=A0=A0
=A0* Sectio= n 2.6 mandates "When a UA connects to a pinned Host, if the TLS connec= tion has errors, the UA MUST terminate the connection without allowing the = user to proceed". =A0HSTS allows the server to specify this, so it see= ms unnecessary and inflexible to mandate it here. =A0It's also unclear = whether a "report-only" pin counts as a "pinned Host".<= /div>

=A0* UA processing rules are confusingly spread across = the document. =A0For example, much of "2.2 Server Processing Model&quo= t; is actually UA processing. =A0Also, 2.3.1 and 2.5 describe the same proc= ess so should be combined.

=A0* Section 2.5 - Does a failed validation of a "= report-only" pin count as an "error" that will inhibit notin= g of new pins in the connection?
=A0
=A0* Specified UA = behavior with multiple header fields is contradictory:
=A0- 2.1.3: "If a Host sets both the Public-Key-Pins header and t= he Public-Key-
=A0 =A0 Pins-Report-Only header, the UA MUST NOT e= nforce Pin Validation, and
=A0 =A0 MUST note only the pins and di= rectives given in the Public-Key-Pins-
=A0 =A0 Report-Only header."
=A0- 2.3.1: "If a UA = receives more than one PKP header field in an HTTP
=A0 =A0 respon= se message over secure transport, then the UA MUST=A0
=A0 =A0 pro= cess only the first such header field."
=A0
=A0* Section 3 - Should the failure report contain the c= ertificates sent by the server, as well as the validated chain? =A0Could he= lp debugging and attack analysis.

=A0* Why is SHA1= supported? =A0If the reason is size, why not remove it but allow the serve= r to pin to a truncated hash (e.g. pin to the first 16 or 20 bytes of SHA25= 6)

=A0* Should there be a list of "excluded" key= s that must not appear in the "validated certificate chain"? =A0C= hrome's preloaded pinning supports this, apparently to exclude 3rd-part= y subCAs that might have been issued under a pinned CA.
=A0
=A0* Would it be better to use the term "pin" = for the entire record associating (hostname, HPKP data), instead of calling= each individual hash a "pin"? =A0The hostname is "pinned&qu= ot; to the 1-of-n key set as a whole, not each key individually.

=A0* Should the header name be changed once this draft = stabilizes, to ensure no bad interactions with UAs that implemented earlier= drafts?
=A0
=A0
Minor:
=A0* "= Pinning Policy" and "Pinning Metadata" are synonyms?
=A0* 2.3.1 "Known HSTS Host" -> "Known HPKP Host&quo= t;
=A0* 2.3.1 ... "or," ... "Otherwise" is co= nfusing
=A0* 2.3.2 - are clients expected to store directives the= y don't understand?
=A0* 2.6 - is pin validation performed on resumed TLS connections?
=A0* 3 - can UAs provide additional JSON fields inside the report?
=A0* The term "validated certificate chain" is not defin= ed
=A0* An IANA registry is needed for directives
=A0* The ackn= owledgement for "pin break codes" is ancient/irrelevant


Trevor =A0


--14dae9cc96ec639c3404e12db859-- From palmer@google.com Wed Jul 10 13:36:28 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E121F9A4B for ; Wed, 10 Jul 2013 13:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=0.725, 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 JLCQklFoPngH for ; Wed, 10 Jul 2013 13:36:27 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DC20D21F9AB7 for ; Wed, 10 Jul 2013 13:36:16 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so5944327vcb.6 for ; Wed, 10 Jul 2013 13:36:14 -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=0Gv/ORY5nF5bEBkpPRSrvRlrNNmjWJXfHD0ikrls7mY=; b=OhDBpzCooAS7TNa3K1c4AqAmdquaAAo/MyOSO92blBGTIKT7w2dCom+3QaUxkXF+8J i1qlqPVbjMqfRdcFKZr9zrIYHdeoMFS2HccZh4GnMRsw/42uh97cvCcR+PetctldaynP LfDAz/YT29ZYI1FjltA4DnNNZVJNCY9qLqpOyJwO/6gL//40IX/4CGOD05iH7IcBo8sk 9T70HNSUeaLpFQHB44ufO0RElhk5D2ies5aamsO+P80qnyk8JBbLWe4oSMhLNlNJWHEJ 7/oyqyWrxFTxFKnSN3GF/VxWVXiqNRNB3A3MHuJeSZXhuniK8VTOx9+G6KOm4h1D4U5g lzPQ== 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=0Gv/ORY5nF5bEBkpPRSrvRlrNNmjWJXfHD0ikrls7mY=; b=bMbcPt/f9SE2Smflo8cVN8x0SAoZFg5UuvOnzWPt5fdLumnQNMVC8hwFK6mDg1mDEF RfesqHDJ4IDrK2PgnwcfrUhUX8ufRLTbyclawamWG5cNdg7eFxSqk4OYkE9jIW500GEM rXeS6ODIMBUkANsvBxbNXDM9Ox5aMvCp80bAiOat0n5Zf++G0505ZK2SjcpjTDh650T8 UP7nwl9rcltmIuveGPMp6ozcvpLT+MwG6yk+Bfa1tW1yJPmiDbAluTHAn4pobwOibmqE tU4DCLBo9rEkh3SNuDWuk9LucINwtvcvkXybmkSM2VFZc928xQczv24vFbgv0qiSj9/R +crQ== MIME-Version: 1.0 X-Received: by 10.52.25.69 with SMTP id a5mr16785395vdg.99.1373488574788; Wed, 10 Jul 2013 13:36:14 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Wed, 10 Jul 2013 13:36:14 -0700 (PDT) In-Reply-To: References: <51C7F08F.2090205@gondrom.org> Date: Wed, 10 Jul 2013 13:36:14 -0700 Message-ID: From: Chris Palmer To: Joseph Bonneau , ietf-privacy@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkVQOlxZAknUkS/oKfSmUj0EPOTGAPugce39DvxEFBqqRprwECcOkX81cTwjPJfzAnnnSQtzDZgFrjAG5yyee5/u93sQfro8AKQ6Bwa3ePDanmEubKeva7N+Jw9Q2iOc1VOwke2MFdinGy86mTfSQwXsiTuVtBdXHrd9RLCs8LnMAF7snP4IGH4mAScJw6gmmU0JXDZ Cc: IETF WebSec WG Subject: Re: [websec] HPKP and privacy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:36:28 -0000 On Tue, Jul 9, 2013 at 3:54 PM, Joseph Bonneau wrote: >> Yes. Unfortunately, I don't see a way to have both HPKP and automatic >> defense against this kind of super-cookie. The problem exists for >> HSTS, too. > > I agree, but there are two things user agents SHOULD do at a minimum: (a) > clear pins for domains whenever other domain-specific information is clea= red > for privacy reasons (delete history since time N, or private browsing mod= e) We currently have decided NOT to do this for HSTS. You can see the somewhat tortured history of the behavior in Chrome here: https://code.google.com/p/chromium/issues/detail?id=3D104935 Chrome's Incognito mode is an easy way to get Chrome to not persistently store any local state (thus defeating a wide range of super-cookie techniques, including but not limited to ETag, HSTS, HPKP, cache hit/miss timing). If you are concerned about privacy side-effects from local state, use Incognito. (Also, it behooves me to refer to the official Incognito documentation: https://support.google.com/chrome/answer/95464?hl=3Den) > (b) not store pins in cases where cookies will not be rejected for privac= y > reasons (such as third-party cookie blocking policies). I don't think the= se > are obvious to implementers so I would like to seem them in the spec. I'm not sure what you mean here. Did you mean to write, "not store pins in cases where cookies WILL be rejected for privacy reasons"? Note that the HSTS and HPKP super-cookie is primarily useful for *recovering* a previously-set but then deleted cookie =E2=80=94 it does not= by itself allow the server to *easily* correlate requests, only to laboriously recover a thing (like a cookie) that does. So if the UA is blocking (say) third-party cookies anyway, the HSTS/HPKP super-cookie technique might not work too well for the third-party adversary. Or at least not as well as other techniques that are already available. I believe we are in the privacy margins here. Incognito mitigates the concern; blocking third-party cookies somewhat mitigates the concern; N-host HSTS/HPKP super-cookies are (probably? I think?) not the most efficient of the many available super-cookie techniques; I assume everyone likes the report-uri feature and that we don't want to get rid of it; et c. As far as I know, the ETag/Last-Modified super-cookie technique is unsolved (http://www.nikcub.com/posts/persistant-and-unblockable-cookies-using-http-= headers), and much more straightforward for implicit-tracking adversaries to use. From trevp@trevp.net Wed Jul 10 14:32: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 3DF5221F9DBC for ; Wed, 10 Jul 2013 14:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFUg0DjxQUmu for ; Wed, 10 Jul 2013 14:32:43 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBDA21F9D80 for ; Wed, 10 Jul 2013 14:32:42 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so6309244wev.16 for ; Wed, 10 Jul 2013 14:32:42 -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=hl0d6Xb9Ljw/b27lpwVyf1roSddfO5S1HBwUSG44QRc=; b=CIju2mWnzLQtVp08EDz/iF/Ib22g4CuZcilfKGv8B461mzfkOUZa1ODGoGwcpfLtpJ D58gmbz5HrWumeC8XXQKluhrL32eHrft5s3/MErArhz3D2KcBcb4GFZbTmuKilLuYOrt aq8Qw/7l+PZ+eQiDBlBETd2UNL0/bcX3eDQkUMKH6XtLbxN/mxR+bKI8rfKc6ZyWWQNp vOcIkGhKWwA8KfiMQvTRkUNVWUofHjq+Pcxwj7/dTbzwvSKPr4A0y4yO96TxMrjCURHs AWlt3yh+pVCxuL6+Ccxv+O0WPUPa8xLT9eTG7hg4HDU8KWsMmbBeOqikRSi6AGKLuqRB XGsg== MIME-Version: 1.0 X-Received: by 10.180.189.5 with SMTP id ge5mr6449083wic.48.1373491961966; Wed, 10 Jul 2013 14:32:41 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 10 Jul 2013 14:32:41 -0700 (PDT) X-Originating-IP: [50.37.26.202] In-Reply-To: <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> Date: Wed, 10 Jul 2013 14:32:41 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c2239a7ec31b04e12f0415 X-Gm-Message-State: ALoCoQneRLwng0GORdCw0KjKo97FUCURHolnc9pZsHCMSPC53rRmflGQvNRhQpP6bHltt4Utvc/9 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 10 Jul 2013 21:32:48 -0000 --001a11c2239a7ec31b04e12f0415 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 7, 2013 at 10:37 PM, Yoav Nir wrote: > Hi all > > This has been submitted with a websec filename, but note that this is not > (yet) on our charter. > > At the Orlando meeting, we discussed some of the security issues with > keeping HTTP sessions using cookies. There was consensus in the room that > this is a problem that needs solving. Nicolas Williams, Phillip > Hallam-Baker, and Yaron Sheffer volunteered to write a problem statement, > and this is it. The message we got from our AD is that first we should show > that the working group has the time and energy to work on solving this > problem, and then we can add this to our charter. > > So please have a look and this document, and answer the following: > - Is this a good starting point for the problem statement? > Hmm, it's surprising there's no discussion of cookie scoping problems like: - "cookie stealing" via MITM-created subdomains [1], or - "cookie forcing" via attacker-controlled sibling or cousin domains [2] These attacks seems particularly relevant to this WG, since they can subvert hostname-specified security like HSTS or HPKP. Also: despite mentioning a few proposals, there's no mention of ChannelID / Channel-bound cookies [3]. ChannelID seems to solve these problems, seems more polished than other proposals, and apparently is being experimentally deployed (see Chrome | Preferences | Cookies and site data | "google.com" or "gmail.com"). - Will you be willing to review the problem statement? > - Will you be willing to read multiple solution proposals to help the > working group choose? > - Will you be willing to review the solution document? > I'd be more interested in websec taking this on if someone could argue why ChannelID is *not* the right solution, and had some ideas how to do better. Trevor [1] http://tools.ietf.org/html/rfc6265 Section 4.1.2.3 WARNING https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies Scope http://tools.ietf.org/html/rfc6797 Section 14.4 [2] http://tools.ietf.org/html/rfc6265 Sections 4.1.2.5 and 8.6 http://scarybeastsecurity.blogspot.com/2008/11/cookie-forcing.html https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies Overwriting cookies [3] http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 --001a11c2239a7ec31b04e12f0415 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Sun, Jul 7, 2013 at 10:37 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi all

This has been submitted with a websec filename, but note that this is not (= yet) on our charter.

At the Orlando meeting, we discussed some of the security issues with keepi= ng HTTP sessions using cookies. There was consensus in the room that this i= s a problem that needs solving. Nicolas Williams, Phillip Hallam-Baker, and= Yaron Sheffer volunteered to write a problem statement, and this is it. Th= e message we got from our AD is that first we should show that the working = group has the time and energy to work on solving this problem, and then we = can add this to our charter.

So please have a look and this document, and answer the following:
=A0- Is this a good starting point for the problem statement?

Hmm, it's surprising there's no discus= sion of cookie scoping problems like:
=A0- "cookie steal= ing" via MITM-created subdomains [1], or=A0
=A0- "cookie forcing" via attacker-controlled sibling or cou= sin domains [2]=A0

These attacks seems particularl= y relevant to this WG, since they can subvert hostname-specified security l= ike HSTS or HPKP.

Also: =A0despite mentioning a few proposals, there= 's no mention of ChannelID / Channel-bound cookies [3]. =A0
<= br>
ChannelID seems to solve these problems, seems more polished = than other proposals, and apparently is being experimentally deployed (see = Chrome | Preferences | Cookies and site data | "google.com" or "gmail.co= m").


=A0- Will you be willing to review the problem statement?
=A0- Will you be willing to read multiple solution proposals to help the wo= rking group choose?
=A0- Will you be willing to review the solution document?
<= div>
I'd be more interested in websec taking this on if s= omeone could argue why ChannelID is *not* the right solution, and had some = ideas how to do better.


Trevor

[1]
http://tool= s.ietf.org/html/rfc6265 =A0Section 4.1.2.3 WARNING

[2]
http://tools.ietf.org/html/rfc62= 65 =A0Sections 4.1.2.5 and 8.6


--001a11c2239a7ec31b04e12f0415-- From nico@cryptonector.com Wed Jul 10 14:39: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 58C5021F9C8C for ; Wed, 10 Jul 2013 14:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 7ellJm2Teqe4 for ; Wed, 10 Jul 2013 14:39:43 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF5B11E8124 for ; Wed, 10 Jul 2013 14:39:43 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id A900910060 for ; Wed, 10 Jul 2013 14:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=SdTWZklFjq5iN7VJBH8C Sv1f7hk=; b=J5jOlsUDvEi4Cga73NGKBsnjlacR0K8Aituk1R9NwMnx9cj//RZd mkJDamvePEVoWldrPPp1wENGINb/nRZASR4h/vNGUI1C1YV7LAuxLo2D9C/1wkli C4rn3MR2vRbO1pufHUj/qUBGlFY0TcLBqzr8iJ/7KUK1UMrkPID4QPs= Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 1B1CB10058 for ; Wed, 10 Jul 2013 14:39:41 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so6517678wgg.32 for ; Wed, 10 Jul 2013 14:39:40 -0700 (PDT) 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; bh=46djknWE52f7NI88oJzMe3zx2Hq1XfjjyKHsPcoYYIc=; b=DLHKks75hsgKeCdeRST15fRhXmjNTVViwTaovd25EEmxKi6YrXBICJZB0AOUnqtB0Z HX+iO0M7+Z7P9hKLXGHYLvpBTzIG3zAZislgfC/qlDKbM+0zQre8D2UQNpWEUJCukoef GPXDSxU1YwhlH8jIhsl0rSPn2TqoptOIe6np8xr7+pyZ447QgoA9KYmYmxMcwzH0rhw9 8GFj821IUK1MAwMNOeZYbknFZ3Xc04Cl7DJ8lq+GGVqrh8buZiEG+tKoFFLjLX2qJOpS yqpBtLN5dWwiDtgMpSCwaK2/0xVaRJR9/wlEzfLi3xvpq/dyEJMwyetyPKdAn4OIPnio 8P2Q== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr18589554wjc.90.1373492380443; Wed, 10 Jul 2013 14:39:40 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 14:39:40 -0700 (PDT) In-Reply-To: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> Date: Wed, 10 Jul 2013 16:39:40 -0500 Message-ID: From: Nico Williams To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 10 Jul 2013 21:39:48 -0000 On Wed, Jul 10, 2013 at 4:32 PM, Trevor Perrin wrote: > Hmm, it's surprising there's no discussion of cookie scoping problems like: > - "cookie stealing" via MITM-created subdomains [1], or > - "cookie forcing" via attacker-controlled sibling or cousin domains [2] There's minimal discussion of the concept of "origin"; it clearly needs more text. I'd love to receive some suggestions for such text :) > Also: despite mentioning a few proposals, there's no mention of ChannelID / > Channel-bound cookies [3]. > > ChannelID seems to solve these problems, seems more polished than other > proposals, and apparently is being experimentally deployed (see Chrome | > Preferences | Cookies and site data | "google.com" or "gmail.com"). There's definitely mention of channel binding. Channel bound cookies used over HTTPS would meet the requirements of this spec, except for the CRIME/BEAST resistance part. I'm not sure that we should mandate CRIME/BEAST resistance -- TLS should arguably be able to resist such attacks. But it will take a long time to deploy TLS that does, and that's what makes it appealing to have CRIME/BEAST resistance in the session continuation protocol. >> - Will you be willing to review the problem statement? >> - Will you be willing to read multiple solution proposals to help the >> working group choose? >> - Will you be willing to review the solution document? > > I'd be more interested in websec taking this on if someone could argue why > ChannelID is *not* the right solution, and had some ideas how to do better. See above. Nico -- From trevp@trevp.net Wed Jul 10 14:54:43 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DA911E8135 for ; Wed, 10 Jul 2013 14:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoZ-+uuVqyzD for ; Wed, 10 Jul 2013 14:54:37 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 45C9011E8132 for ; Wed, 10 Jul 2013 14:54:31 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so6197494wes.24 for ; Wed, 10 Jul 2013 14:54:24 -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=r9dJb1ylbukEgIKSBKl5+6R8ZaxnJhJ6Ti+rnHommPY=; b=GOjVGPCpDaTeTpKzmzPQ0guO+wS1AgyWsEksT3D80rBuAQZNQtS6BxJy7UV/mHEwpw hBSr3ARdjFvzGQm6VDJ8rkbn+lljxkvsgruzcEiqteOVooYWroe4lOhDkpndQEv/S74K pKu87QWe9r6ccsktNU3uKHRfatXD9BOFhgusRrfWUyGV/5zHwwsFr7KhzM5olGwb+Wyq 2854oSNFCnf/uxbceEsO3qbTD1Q5tBn6qNeaunlhu+En9D5KhE80B5/lRY01Kj5oj8ys zACoaZZrxIpJGWhYj5SOj135h74KO5+uX3bxGwzonoKZM/1DuESEjUq3fuK8nYgR5j7e 0ceg== MIME-Version: 1.0 X-Received: by 10.194.24.40 with SMTP id r8mr19122565wjf.7.1373493264501; Wed, 10 Jul 2013 14:54:24 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 10 Jul 2013 14:54:24 -0700 (PDT) X-Originating-IP: [50.37.26.202] In-Reply-To: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> Date: Wed, 10 Jul 2013 14:54:24 -0700 Message-ID: From: Trevor Perrin To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b5d352821e24404e12f5226 X-Gm-Message-State: ALoCoQkH1eas8E5F/ZOq0BkHynTNgM9NSLJsqIwYjnlr9xHtCLcwdLO/bZfGadMUosu348qK7VWf Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 10 Jul 2013 21:54:43 -0000 --047d7b5d352821e24404e12f5226 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 2:39 PM, Nico Williams wrote: > On Wed, Jul 10, 2013 at 4:32 PM, Trevor Perrin wrote: > > Hmm, it's surprising there's no discussion of cookie scoping problems > like: > > - "cookie stealing" via MITM-created subdomains [1], or > > - "cookie forcing" via attacker-controlled sibling or cousin domains [2] > > There's minimal discussion of the concept of "origin"; it clearly > needs more text. I'd love to receive some suggestions for such text > :) I'm not volunteering! It's complicated... > > Also: despite mentioning a few proposals, there's no mention of > ChannelID / > > Channel-bound cookies [3]. > > > > ChannelID seems to solve these problems, seems more polished than other > > proposals, and apparently is being experimentally deployed (see Chrome | > > Preferences | Cookies and site data | "google.com" or "gmail.com"). > > There's definitely mention of channel binding. Channel bound cookies > used over HTTPS would meet the requirements of this spec, except for > the CRIME/BEAST resistance part. > Are you sure about that? I meant "channel-bound cookies" as defined in the ChannelID draft. Even if an attacker stole such cookies via BEAST / CRIME / whatever, the cookies would be unusable without the browser's ChannelID private key for that site. > I'm not sure that we should mandate CRIME/BEAST resistance -- TLS > should arguably be able to resist such attacks. But it will take a > long time to deploy TLS that does, and that's what makes it appealing > to have CRIME/BEAST resistance in the session continuation protocol. > Hmm, haven't browsers already deployed BEAST / CRIME / etc countermeasures? I actually think that TLS-layer fixes to TLS problems are going to be faster, easier, and more comprehensive than trying to get thousands of websites to change how they manage sessions. But the cookie-scoping problems will still exist, so cookies definitely need improvement. For that, ChannelID still seems like the best proposal out there. Trevor --047d7b5d352821e24404e12f5226 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Jul 10, 2013 at 2:39 PM, Nico Williams <nico@cryptonector.com<= /a>> wrote:
On Wed, Jul 10, 2013 at 4:= 32 PM, Trevor Perrin <trevp@trevp.net= > wrote:
> Hmm, it's surprising there's no discussion of cookie scoping p= roblems like:
> =A0- "cookie stealing" via MITM-created subdomains [1], or > =A0- "cookie forcing" via attacker-controlled sibling or cou= sin domains [2]

There's minimal discussion of the concept of "origin"; = it clearly
needs more text. =A0I'd love to receive some suggestions for such text<= br> :)

I'm not volunteering! =A0It= 9;s complicated...

=A0
> Also: =A0despite mentioning a few proposals, there's no mention of= ChannelID /
> Channel-bound cookies [3].
>
> ChannelID seems to solve these problems, seems more polished than othe= r
> proposals, and apparently is being experimentally deployed (see Chrome= |
> Preferences | Cookies and site data | "google.com" or "gmail.com").

There's definitely mention of channel binding. =A0Channel bound c= ookies
used over HTTPS would meet the requirements of this spec, except for
the CRIME/BEAST resistance part.

= Are you sure about that? =A0I meant "channel-bound cookies" as de= fined in the ChannelID draft. =A0Even if an attacker stole such cookies via= BEAST / CRIME / whatever, the cookies would be unusable without the browse= r's ChannelID private key for that site.

=A0
I'm not sure that we should mandate CRIME/BEAST resistance -- TLS
should arguably be able to resist such attacks. =A0But it will take a
long time to deploy TLS that does, and that's what makes it appealing to have CRIME/BEAST resistance in the session continuation protocol.

Hmm, haven't browsers already deplo= yed BEAST / CRIME / etc countermeasures?

I actually think that TLS-layer fixes to TLS problems are going to be faste= r, easier, and more comprehensive than trying to get thousands of websites = to change how they manage sessions.

But the cookie-scoping problems will still exist, so cookies definitely nee= d improvement. =A0For that, ChannelID still seems like the best proposal ou= t there.


Trevor
--047d7b5d352821e24404e12f5226-- From nico@cryptonector.com Wed Jul 10 15:01:15 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 08C9D11E8131 for ; Wed, 10 Jul 2013 15:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 j5g+qXST1tHU for ; Wed, 10 Jul 2013 15:01:10 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77611E811D for ; Wed, 10 Jul 2013 15:01:10 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 4A9B5318072 for ; Wed, 10 Jul 2013 15:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6pZhc0n4ifOjwy20cd2L jkq42Cc=; b=JKLEM17tXhDNjUkxFsFv0BYOI/K4m2Y9azZ/ZQJWfXFTMr09eJJ6 8886lUGgQVTFG8k/KRdtCa6nbvFXN4ZSbPP2GElYulRAYnG013dD7HlYbDcwVU0H 7ywn6SuKPJNdlDT2g8KtloRRbMk8QkFtKrWEVN7g7ejfWyeelLarR4w= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id E63E2318065 for ; Wed, 10 Jul 2013 15:01:02 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so6433947wes.12 for ; Wed, 10 Jul 2013 15:01:01 -0700 (PDT) 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; bh=RwsWjpEtL6RKwdY6/YMDnHqwY9EEbNmKWJGZaWhtwbk=; b=mKT+dvR3oZPMuk/q5aBh9lbAi+CKZw0lXdEHw0I7rX4KpbHDixb1ST/mVJT7QCzycl EC352UuzgbBmj4ggNgK6oSkcFocdhgZ5jaVlDspV9+cV5LmNrRfIkEliCL5qGYk/m+Yo scxKaXh7897x0dndU6tQVUk99J5XYua4C4DSYDF4Z0z3cVUYY15NbIXUGCRLYo8V0Tnn p/8sNPLlOZVgz0TUKUuoMPH69JdJVR4ItPoQdyWBfw+sG0ksGaGFDqfoJIwkq+0XvFQT hgWkGJO1rtGs2q97yH4XlRFqHzFnZSWUFVQ2N3jjIs1XnRhDTuBajnHAMMmH3eFq4rLd 6w1A== MIME-Version: 1.0 X-Received: by 10.180.74.162 with SMTP id u2mr6847766wiv.36.1373493661339; Wed, 10 Jul 2013 15:01:01 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 15:01:01 -0700 (PDT) In-Reply-To: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> Date: Wed, 10 Jul 2013 17:01:01 -0500 Message-ID: From: Nico Williams To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 10 Jul 2013 22:01:15 -0000 On Wed, Jul 10, 2013 at 4:54 PM, Trevor Perrin wrote: > On Wed, Jul 10, 2013 at 2:39 PM, Nico Williams > wrote: >> There's minimal discussion of the concept of "origin"; it clearly >> needs more text. I'd love to receive some suggestions for such text >> :) > > I'm not volunteering! It's complicated... Bummer. It's complicated. >> There's definitely mention of channel binding. Channel bound cookies >> used over HTTPS would meet the requirements of this spec, except for >> the CRIME/BEAST resistance part. > > Are you sure about that? I meant "channel-bound cookies" as defined in the > ChannelID draft. Even if an attacker stole such cookies via BEAST / CRIME / > whatever, the cookies would be unusable without the browser's ChannelID > private key for that site. Ah, right, excuse me. I'd responded without swapping in enough of the channel bound cookie context. Yes, I see that we need to adjust this spec to cover that. The intention is not to exlcude channel bound cookies. I'll fix it. > But the cookie-scoping problems will still exist, so cookies definitely need > improvement. For that, ChannelID still seems like the best proposal out > there. That context I still don't have swapped in, or maybe I've never had it. Nico -- From palmer@google.com Wed Jul 10 16:01:15 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 682F721F972C for ; Wed, 10 Jul 2013 16:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.483, 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 sFQxOG3tK5G1 for ; Wed, 10 Jul 2013 16:01:15 -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 CD5EE21F92B8 for ; Wed, 10 Jul 2013 16:01:07 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id p12so24439vbe.12 for ; Wed, 10 Jul 2013 16:01:06 -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=tIbLrqYVIf1Vt63HlKKSRWgSUzaHTHqbHzyX4TP8bv4=; b=fyWpdcRuMvageVJRhCa4pieP58MG/lPJLU6jSHOMJd9YwjNnYGDMU6O5OAgeMGZjA2 LrWFWMago0lH2ZsN2yhRf6FFm/on+AGUNmuGC5IuRekw4F/uNclKy4noEbWLNgUy2SUV Vihl0ypRb6OrwCkdQTq8W9UsS9OjwQWHMNHEY7cUpDQda2khyi1USanS2g0H/hD3AGZW xq6qvUZoDMJhptwCSOCVf+QxJbmZv3+z2h7fPS5GYDWzCI0xyu40nCW4jbPhZqbo6lSf EfYRB7mXO00TOdjqk1p2X/TRlvKvbnbOTT92RRbFHehzLnxlnS2kpbomwf3fuzimdwUS Rq6A== 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=tIbLrqYVIf1Vt63HlKKSRWgSUzaHTHqbHzyX4TP8bv4=; b=OcKHpMDqdsJE0OvMcFnUmXyKHrZpG7qqBWkfZlXaIgFJelOZ+0K/2dSHGb/UM2z8R0 qYDGicwVhjh5XSvv8n4e7GMrU6Cs01fI/jUa/beWe5WUwyfbn1vLMpbMfutvJNC7qYR+ PtwLWHgnxXnxGX2FZvF4ZyDFcWI+vBQqUJs+Nejcpdd+tuRbgUaG+zZQUdFDVTja2tqB p+xZpxwBY9tQKv0oJveSfuO3ySArZOpdWhLM7a0xSdpydX6lAcQQep+EYm/oGMPbjXFA h6kdVhjUW/8n7v5mWint0tQiNFE0eKuJTXnXJB6FyZzzcWVhnwOvZbwCSzGFHpyAWx1I X2Xw== MIME-Version: 1.0 X-Received: by 10.52.65.10 with SMTP id t10mr17041997vds.90.1373497263157; Wed, 10 Jul 2013 16:01:03 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Wed, 10 Jul 2013 16:01:02 -0700 (PDT) In-Reply-To: <1F476385-849E-41F0-9B8C-A69A9C36FA71@checkpoint.com> References: <51DAF2DA.8050708@isode.com> <1F476385-849E-41F0-9B8C-A69A9C36FA71@checkpoint.com> Date: Wed, 10 Jul 2013 16:01:02 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm4iM5w0Bd13BvgGvpa2axX2l/JMlvMoAT8eZZZ1U2AFdj0ScO3e+GTk7/hZwDV64Mfz15roNCWlYTu7o7lLvACbu96/rFIUhJ2nsGlfCsN3yDlYrsNEh+rgZEHw1bl+1itOhkTToPRWoNNuc4eKy4Imv+knNqF7m1+Ahi/RA1k6wQsP3SL1KHmoylvhjukqnedw7SH Cc: IETF WebSec WG Subject: Re: [websec] Review of draft-ietf-websec-key-pinning-06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 23:01:15 -0000 On Mon, Jul 8, 2013 at 9:57 PM, Yoav Nir wrote: > 3rd Para: "If the Public-Key-Pins response header field does not meet all three of these criteria, the UA MUST NOT note the host as a Pinned Host." > > 4th Para: "The UA MUST ignore Public-Key-Pins response header fields received on connections that do not meet the first criterion." Oh, right. Yes, I think we can just delete that 4th paragraph. Done in an upcoming -08. > The standard way is to add a sentence like: > [RFC EDITOR: PLEASE REMOVE THIS SECTION] Done. Thanks! From ynir@checkpoint.com Thu Jul 11 05:50: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 33A3B21F93BA for ; Thu, 11 Jul 2013 05:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 DGzMz7+gxHEJ for ; Thu, 11 Jul 2013 05:50:49 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 15F9E21F9703 for ; Thu, 11 Jul 2013 05:50:48 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6BCogF4027320; Thu, 11 Jul 2013 15:50:43 +0300 X-CheckPoint: {51DEAA22-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Thu, 11 Jul 2013 15:50:41 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 Thread-Index: AQHOe51K2fjJqAHy/0+f/EfC93QcepleQH6AgAEAfoA= Date: Thu, 11 Jul 2013 12:50:40 +0000 Message-ID: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 110607fcfa15792bbed58b10affc8453c667d13158 Content-Type: multipart/alternative; boundary="_000_D97453ED23524273B8AF0DAA00C1E555checkpointcom_" MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 12:50:57 -0000 --_000_D97453ED23524273B8AF0DAA00C1E555checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 11, 2013, at 12:32 AM, Trevor Perrin > wrote: ChannelID seems to solve these problems, seems more polished than other pro= posals, and apparently is being experimentally deployed (see Chrome | Prefe= rences | Cookies and site data | "google.com" or "gmail= .com"). - Will you be willing to review the problem statement? - Will you be willing to read multiple solution proposals to help the work= ing group choose? - Will you be willing to review the solution document? I'd be more interested in websec taking this on if someone could argue why = ChannelID is *not* the right solution, and had some ideas how to do better. Hi Trevor [wearing no hats] ChannelID is a TLS-layer extension. As such, it does nothing for HTTP. OTOH= a proposal that hashes some header fields with a secret value works with o= r without TLS. But even if we restrict our solution to HTTPS, I don't see how ChannelID he= lps a problem like the BEAST and CRIME attacks. In both cases, the issue is= the scoping of cookie use. An attacker's web page or script can cause the = UA to send requests of the attacker's choosing to a server. This has nothin= g to do with TLS - this in an HTTP behavior. As it is, if I visit a website that has my UA is going to send a request to mail.google.com for "gaaaaaaaaaah", and that request is going to have my c= ookie. I don't see what ChannelID adds here. With channel-bound cookies (se= ction 7.1) my UA will send the same request to mail.google.com, but with a channel-bound cookie. But since it's my valid chann= el, the server will accept it just the same. What we need, IMO, is a new cookie with new rules, such as that cookies wil= l be indexed by origin and refer(r)er so that my UA would use different coo= kies for requests stemming from pages from google and requests initiated by= pages and scripts from other origins. This kind of rule change is more imp= ortant than either the crypto binding or the request hashing. Yoav --_000_D97453ED23524273B8AF0DAA00C1E555checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <59766327BBA7D34487BD823B0B2DA0BB@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable
On Jul 11, 2013, at 12:32 AM, Trevor Perrin <trevp@trevp.net> wrote:


ChannelID seems to solve these problems, seems more polished than othe= r proposals, and apparently is being experimentally deployed (see Chrome | = Preferences | Cookies and site data | "= google.com" or "gmail.com&q= uot;).


 - Will you be willing to review the problem statement?
 - Will you be willing to read multiple solution proposals to help the= working group choose?
 - Will you be willing to review the solution document?

I'd be more interested in websec taking this on if someone could argue= why ChannelID is *not* the right solution, and had some ideas how to do be= tter.


Hi Trevor

[wearing no hats]

ChannelID is a TLS-layer extension. As such, it does nothing for HTTP.= OTOH a proposal that hashes some header fields with a secret value works w= ith or without TLS.

But even if we restrict our solution to HTTPS, I don't see how Channel= ID helps a problem like the BEAST and CRIME attacks. In both cases, the iss= ue is the scoping of cookie use. An attacker's web page or script can cause= the UA to send requests of the attacker's choosing to a server. This has nothing to do with TLS - this in= an HTTP behavior.

As it is, if I visit a website that has <img src=3D"https://mail.google.com/gaaaaaaaaaah= "> my UA is going to send a request to mail.google.com for "gaaaaaaaaa= ah", and that request is going to have my cookie. I don't see what Cha= nnelID adds here. With channel-bound cookies (section 7.1) my UA will send = the same request to mail.google.com, but with a channel-= bound cookie. But since it's my valid channel, the server will accept it ju= st the same.

What we need, IMO, is a new cookie with new rules, such as that cookie= s will be indexed by origin and refer(r)er so that my UA would use differen= t cookies for requests stemming from pages from google and requests initiat= ed by pages and scripts from other origins. This kind of rule change is more important than either the crypto= binding or the request hashing.

Yoav

--_000_D97453ED23524273B8AF0DAA00C1E555checkpointcom_-- From trevp@trevp.net Thu Jul 11 09:51:51 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535A621F9F2A for ; Thu, 11 Jul 2013 09:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMd-ium-1mmX for ; Thu, 11 Jul 2013 09:51:45 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8F21F9EAF for ; Thu, 11 Jul 2013 09:51:35 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so7810674wib.8 for ; Thu, 11 Jul 2013 09:51:35 -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=WF0BivmCaSeDZf1ByGCAMVgFss7evJVLZ5XKV0ZdbJ0=; b=MdVfPNYOwBeouib1YFfTjcMZhpR5OKZsxCXsLNCMD894xUEOTRBFPEVhhQBV0Nvccm 4gf+MpVYM5/UNMYfs7u/olqaKJbirAvzdwoR9Dp0htW224seSONsmtQXARm+2/P5CdNJ /7TqrhaFSYQIhhLgQgs0NUCkCkEjSkBh9OsRkVZ8oi43f7zbCVaCdYOsmwya5K/wc0vn DOGETdA5F8QHKCa86/Lf3lVOCmty5jHoXsKyvsd3eeqAH28tBu1ReyILJcM9su7yKjSr ly8rZCS9Vm2GkIMVae9nq7T9Iyhoq4nyJPqxp1TmzQdOtCvqf8zt5hdE+uLHk1X054gP py8g== MIME-Version: 1.0 X-Received: by 10.180.211.171 with SMTP id nd11mr20516762wic.17.1373561494964; Thu, 11 Jul 2013 09:51:34 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Thu, 11 Jul 2013 09:51:34 -0700 (PDT) X-Originating-IP: [50.37.26.202] In-Reply-To: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> Date: Thu, 11 Jul 2013 09:51:34 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c38500fc1da004e13f3484 X-Gm-Message-State: ALoCoQlcbRyAINhT8HzFc4lQAuY5PVr8ii+Umybg/TRRwONMgkkVZrzhDkqSczD7XZEm6PX0DHRB Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 16:51:51 -0000 --001a11c38500fc1da004e13f3484 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 11, 2013 at 5:50 AM, Yoav Nir wrote: > > On Jul 11, 2013, at 12:32 AM, Trevor Perrin wrote: > > > ChannelID seems to solve these problems, seems more polished than other > proposals, and apparently is being experimentally deployed (see Chrome | > Preferences | Cookies and site data | "google.com" or "gmail.com"). > > > - Will you be willing to review the problem statement? >> - Will you be willing to read multiple solution proposals to help the >> working group choose? >> - Will you be willing to review the solution document? >> > > I'd be more interested in websec taking this on if someone could argue > why ChannelID is *not* the right solution, and had some ideas how to do > better. > > > Hi Trevor > > [wearing no hats] > > ChannelID is a TLS-layer extension. As such, it does nothing for HTTP. > That's true, but is it important? If a site can't be bothered to deploy TLS, is it going to deploy a new session management mechanism? The security gain of improving cookies without deploying TLS seems small - it might protect cookies at "http://example.com" from someone who hacks " http://test.example.com", but that's about it. But even if we restrict our solution to HTTPS, I don't see how ChannelID > helps a problem like the BEAST and CRIME attacks. In both cases, the issue > is the scoping of cookie use. An attacker's web page or script can cause > the UA to send requests of the attacker's choosing to a server. This has > nothing to do with TLS - this in an HTTP behavior. > ChannelID solves this problem. The goal of BEAST, CRIME, or other forms of cookie theft is to steal a *usable* cookie. With ChannelID, the channel-bound cookie that an attacker might steal is unusable. What we need, IMO, is a new cookie with new rules, such as that cookies > will be indexed by origin and refer(r)er so that my UA would use different > cookies for requests stemming from pages from google and requests initiated > by pages and scripts from other origins. This kind of rule change is more > important than either the crypto binding or the request hashing. > Deriving new cookie values based on where the cookie originated and where it is being sent is one approach. But making cookies sent to a particular client untransferable to other clients seems equally valid, and is simpler if you can rely on something (eg "ChannelID") to securely differentiate clients. Trevor --001a11c38500fc1da004e13f3484 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Jul 11, 2013 at 5:50 AM, Yoav Nir <ynir@checkpoint.com> wrote:

On Jul 11, 2013, at 12:32 AM, Trevor Perrin <trevp@trevp.net> wrote:


ChannelID seems to solve these problems, seems more polished than othe= r proposals, and apparently is being experimentally deployed (see Chrome | = Preferences | Cookies and site data | "google.com" or "gmail.com").


=A0- Will you be willing to review the problem statement?
=A0- Will you be willing to read multiple solution proposals to help the wo= rking group choose?
=A0- Will you be willing to review the solution document?

I'd be more interested in websec taking this on if someone could a= rgue why ChannelID is *not* the right solution, and had some ideas how to d= o better.


Hi Trevor

[wearing no hats]

ChannelID is a TLS-layer extension. As such, it does nothing for HTTP.=

That's true, but is it imp= ortant?

If a site can't be bothered to deploy = TLS, is it going to deploy a new session management mechanism?

The security gain of improving cookies without deployin= g TLS seems small - it might protect cookies at "http://example.com" from someone who hacks "http://test.example.com", but that= 9;s about it.


But even if we restrict our solution to HTTPS, I= don't see how ChannelID helps a problem like the BEAST and CRIME attac= ks. In both cases, the issue is the scoping of cookie use. An attacker'= s web page or script can cause the UA to send requests of the attacker's choosing to a server. This has nothing to do with TLS - thi= s in an HTTP behavior.

ChannelI= D solves this problem.

The goal of BEAST, CRIME, o= r other forms of cookie theft is to steal a *usable* cookie. =A0With Channe= lID, the channel-bound cookie that an attacker might steal is unusable.


What we need, IMO, is a new cookie with new rule= s, such as that cookies will be indexed by origin and refer(r)er so that my= UA would use different cookies for requests stemming from pages from googl= e and requests initiated by pages and scripts from other origins. This kind of rule change is more important than either the crypto= binding or the request hashing.

Deriving new cookie values based on where the cookie originated and where= it is being sent is one approach.

But making cookies sent to a particular client untransf= erable to other clients seems equally valid, and is simpler if you can rely= on something (eg "ChannelID") to securely differentiate clients.=


Trevor
=A0
--001a11c38500fc1da004e13f3484-- From nico@cryptonector.com Thu Jul 11 10:44:35 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 92D8311E8159 for ; Thu, 11 Jul 2013 10:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 7r+UbcQweHPQ for ; Thu, 11 Jul 2013 10:44:30 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8628611E8156 for ; Thu, 11 Jul 2013 10:44:30 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id E70A22AC082 for ; Thu, 11 Jul 2013 10:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=kFpmFOAaMxbA/LcffE/Q jfL+r9Q=; b=vXtRFLWpCaz2DD8YoHKgeohBFqsa2jQXowEbEZ/U/B5GhMPUHufc kIswod4QE/N01eYawe2tBEC9E+M7D6WmqWs5EFcBqTtwQ2plfbo5mJ0h/J2IOY97 t1/SPYb26o4tAPtdv4z9NHWONn5bz2JyXmnxQGgMSzqVUk3ATSdKL4s= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 398ED2AC06E for ; Thu, 11 Jul 2013 10:44:28 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so7232409wev.36 for ; Thu, 11 Jul 2013 10:44:26 -0700 (PDT) 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; bh=yZK2C+C7GIowi6kyVKmDwvQHPdLAwJAwki5GMTNaXpk=; b=nwDUoDd/V8cLeGYeBCMeFAEXtQ02lfrIWArYjnCGSkV2ExKbEIwiwtL49VoUd/OcoX I+GN6Iu5b03oWaQB9Lir8sTo10jbfTil9HnRewS3m7lxBVEIgZXCYHnwGnLLS0k+69bG yDjC9VE4y5uAjI5ZvdA+sR3vQ6c1xCesDtmCYFu18/4wCRBn6CcpiSpshMP2Pna62A3C FOmBYcpGj43CWm4h1FFy/Y/CTNAH0Fx6lS8hCA/WFtuFyMKROS5WdCFnn4kOz4nVO0iO Mo6mmbpR1eOIOwN1l397OvzJaS+zFfZLjvbKLiBBargsPZEAEt2jDJWmu91KFjDXCdPo 9YgQ== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr20427077wib.33.1373564666877; Thu, 11 Jul 2013 10:44:26 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 10:44:26 -0700 (PDT) In-Reply-To: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> Date: Thu, 11 Jul 2013 12:44:26 -0500 Message-ID: From: Nico Williams To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 17:44:35 -0000 On Thu, Jul 11, 2013 at 11:51 AM, Trevor Perrin wrote: > On Thu, Jul 11, 2013 at 5:50 AM, Yoav Nir wrote: >> [wearing no hats] >> >> ChannelID is a TLS-layer extension. As such, it does nothing for HTTP. > > That's true, but is it important? Sort of. I think we should have a protocol that doesn't require channel bound cookies. Or even TLS at all. But we should support the use of channel bound cookies as a session continuation protocol for two reasons: one is that there is/will be deployment, and the other is that it works. > If a site can't be bothered to deploy TLS, is it going to deploy a new > session management mechanism? It's not that. There's several problems with using TLS and extensions to it properly. For example, if you have concentrators then you have problems -- not unresolvable, but one i then at the mercy of their concentrator vendor. Another example is that even without concentrators there's layering that complicates a portable service implementation (portable, that is, relative to a variety of HTTP and TLS server stacks). > The security gain of improving cookies without deploying TLS seems small - > it might protect cookies at "http://example.com" from someone who hacks > "http://test.example.com", but that's about it. We want to improve on cookies. IMO we should aim for a solution that works: with and without TLS, with and without extensive support in the TLS and HTTP stacks. Channel bound cookies fit in, but only in a subset of cases. It's a great solution, but I think at least today it's not sufficient for all the cases we should care about. HOWEVER, that's a fair question: which cases should we care about? It's entirely possible that we'd reach consensus on only caring about the cases where channel bound cookies are sufficient, and then reach consensus that it's the only solution we want. I personally want a solution that doesn't require changing *any* part of any TLS or HTTP client or server stack. The reason is that I've had the unpleasant experience of looking at the innards of several widely used HTTP stacks to scope HTTP authentication and proxy improvements, this in an environment where quite a few stacks are used (Java, Apache, nginx, curl -- that's just to start, and just on the HTTP side, and there are many more in use than just those). It's a never-ending saga to improve anything in all of them. A purely application-layer solution has enormous benefits. Almost every server stack, for example, supports FCGI filters, so that's one way to write a universal implementation for servers. With tls-server-end-point channel binding we only need the Host header and a lookup table of host->EE certificate (with a bit more help from the concentrators/servers it's possible to always and efficiently deal with servers for which there are many equivalent certs). On the client-side there's still a large number of stacks for which to implement (e.g., all the browsers), but at least for scripts using XHR a universal implementation is feasible. Channel bound cookies requires fixing all client and server stacks, so it's definitely more difficult to deploy universally. (Or did I misunderstand?) But of course, even an application-layer solution has a massive client-side dev workload to deal with, comparable with channel bound cookies' client-side dev workload. Perhaps the server-side dev workload is less severe than I've thought? Nico -- From ynir@checkpoint.com Thu Jul 11 11:41:31 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300A821F9D31 for ; Thu, 11 Jul 2013 11:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 kBM75BANEVkn for ; Thu, 11 Jul 2013 11:41:25 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AD63F21F92B7 for ; Thu, 11 Jul 2013 11:41:24 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6BIfKqY023461; Thu, 11 Jul 2013 21:41:21 +0300 X-CheckPoint: {51DEFC50-1C-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Thu, 11 Jul 2013 21:41:20 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 Thread-Index: AQHOe51K2fjJqAHy/0+f/EfC93QcepleQH6AgAEAfoCAAENLAIAAHqqA Date: Thu, 11 Jul 2013 18:41:20 +0000 Message-ID: <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.234] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1119c207dfca4db92bb7fb595920aadf454f484d78 Content-Type: multipart/alternative; boundary="_000_44801B83214F47E291B2F3E42DE30249checkpointcom_" MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 18:41:31 -0000 --_000_44801B83214F47E291B2F3E42DE30249checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 11, 2013, at 7:51 PM, Trevor Perrin > wrote: But even if we restrict our solution to HTTPS, I don't see how ChannelID he= lps a problem like the BEAST and CRIME attacks. In both cases, the issue is= the scoping of cookie use. An attacker's web page or script can cause the = UA to send requests of the attacker's choosing to a server. This has nothin= g to do with TLS - this in an HTTP behavior. ChannelID solves this problem. The goal of BEAST, CRIME, or other forms of cookie theft is to steal a *usa= ble* cookie. With ChannelID, the channel-bound cookie that an attacker mig= ht steal is unusable. True, but I believe that the fact that attackers are able to get the UA to = send arbitrary requests to a server and have them bless this request with t= heir cookie is bad enough. I can demonstrate this with a real world example= . This is from a real firewall appliance. I won't mention names, except to = say that it is not from my company (otherwise I would be too embarrassed to= post this to a public mailing list. This firewall had a web-based management interface protected with HTTPS. Th= e pages would have all kinds of buttons, each button had a name pretty simi= lar to the text on the button, and clicking the buttons would cause a GET r= equest like this: GET /mainpage.html?button=3Dsomething,field1=3D"", field2=3D"". So I recorded some traffic (it was HTTPS, so I had to use a browser add-on = to record it), and got this: * GET /maingage.html?button=3Dshutdown caused the firewall to power-o= ff. * GET /mainpage.html?button=3Dunload caused the firewall to unloa= d policy, so that it didn't enforce policy or do IPsec or anything a router= wouldn't do. So I tried opening another browser tab, and loading an HTML document that s= aid Yes, the firewall powered down, and if I had used "unload" instead of "shut= down" that would be the end of enforcing a security policy. Now, granted, this is epic levels of cluelessness. But Channel-bound cookie= s don't save the administrator of this firewall. Only changing the rules ar= ound "blessing" requests with cookies can help. I'm all in favor of binding to TLS or MAC-ing the requests, but I think we = need those in addition to making cookie behavior secure, not instead of. Having re-read draft-balfanz, that draft only has a TLS extension. Section = 7.1 is only an example of how that extension can be used. If we really want= ed a channel-bound cookie, we'd need a different document that specified ch= annel-bound cookies. So we'd need someone two write such a draft. Yoav --_000_44801B83214F47E291B2F3E42DE30249checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3C76253C29D74D4A807E6C64C645491F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable
On Jul 11, 2013, at 7:51 PM, Trevor Perrin <trevp@trevp.net> wrote:

But even if we restrict our solution to= HTTPS, I don't see how ChannelID helps a problem like the BEAST and CRIME = attacks. In both cases, the issue is the scoping of cookie use. An attacker= 's web page or script can cause the UA to send requests of the attacker's choosing to a server. This has nothi= ng to do with TLS - this in an HTTP behavior.

ChannelID solves this problem.

The goal of BEAST, CRIME, or other forms of cookie theft is to steal a= *usable* cookie.  With ChannelID, the channel-bound cookie that an at= tacker might steal is unusable.

True, but I believe that the fact that attackers are able to get the UA to = send arbitrary requests to a server and have them bless this request with t= heir cookie is bad enough. I can demonstrate this with a real world example= . This is from a real firewall appliance. I won't mention names, except to say that it is not from my company (other= wise I would be too embarrassed to post this to a public mailing list.

This firewall had a web-based management interface protected with HTTP= S. The pages would have all kinds of buttons, each button had a name pretty= similar to the text on the button, and clicking the buttons would cause a = GET request like this:

GET /mainpage.html?button=3Dsomething,field1=3D"", field2=3D= "".

So I recorded some traffic (it was HTTPS, so I had to use a browser ad= d-on to record it), and got this:
  • GET /maingage.html?button=3Dshutdown   caused the firewall to powe= r-off.
  • GET /mainpage.html?button=3Dunload       caus= ed the firewall to unload policy, so that it didn't enforce policy or do IP= sec or anything a router wouldn't do.

So I tried opening another browser tab, and loading an HTML document t= hat said <img src=3D"https://myfw/mainpage.html?button=3Dshutdown">

Yes, the firewall powered down, and if I had used "unload" i= nstead of "shutdown" that would be the end of enforcing a securit= y policy. 

Now, granted, this is epic levels of cluelessness. But Channel-bound c= ookies don't save the administrator of this firewall. Only changing the rul= es around "blessing" requests with cookies can help.

I'm all in favor of binding to TLS or MAC-ing the requests, but I thin= k we need those in addition to making cookie behavior secure, not instead o= f.

Having re-read draft-balfanz, that draft only has a TLS extension. Sec= tion 7.1 is only an example of how that extension can be used. If we really= wanted a channel-bound cookie, we'd need a different document that specifi= ed channel-bound cookies. So we'd need someone two write such a draft.

Yoav

--_000_44801B83214F47E291B2F3E42DE30249checkpointcom_-- From dkg@fifthhorseman.net Thu Jul 11 11:51:04 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 BDCE321F9C00 for ; Thu, 11 Jul 2013 11:51:03 -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 FACdPiCgSIGV for ; Thu, 11 Jul 2013 11:50:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id AB4F321F8947 for ; Thu, 11 Jul 2013 11:50:56 -0700 (PDT) Received: from [192.168.13.179] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 82565F948; Thu, 11 Jul 2013 14:50:40 -0400 (EDT) Message-ID: <51DEFE70.6080402@fifthhorseman.net> Date: Thu, 11 Jul 2013 14:50:24 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> In-Reply-To: <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2MXETALQPLXBFQGUATLOO" Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 18:51:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MXETALQPLXBFQGUATLOO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/11/2013 02:41 PM, Yoav Nir wrote: >=20 > * GET /maingage.html?button=3Dshutdown caused the firewall to pow= er-off. > * GET /mainpage.html?button=3Dunload caused the firewall to u= nload policy, so that it didn't enforce policy or do IPsec or anything a = router wouldn't do. >=20 > So I tried opening another browser tab, and loading an HTML document th= at said >=20 > Yes, the firewall powered down, and if I had used "unload" instead of "= shutdown" that would be the end of enforcing a security policy. >=20 > Now, granted, this is epic levels of cluelessness. these are indeed epic levels of cluelessness. at the very least the authors of such an appliance need to learn the distinction between POST and GET, which would prevent your "attack". If the authors aren't capable of making this distinction (which has been around for nearly 20 years), and they don't use widely-known measures for CSRF protection (itself coming up on 10 years old, i think) when they have users who enable javascript, i strongly doubt they'll deploy any sort of fancy session continuation even if we specify it perfectly. I'm not sure this sort of example is a reasonable argument for developing any new standard technical measures, since by definition the culprits here are not making use of standard technical measures. Regards, --dkg ------enig2MXETALQPLXBFQGUATLOO 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/ iQJ8BAEBCgBmBQJR3v5wXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcWZkP/iXl0tPecF5fT0M8E9YNwIs9 ooCzfsR9YDK3J/6MmcpLlxnUwnUws7bhnDhk9ktdYFWclDb3TZwxgbllQxE2SzoG FUxA/w+O3vn+6kdKWn678OLrPztFk7AcTEVmYYPC+AJ1db2EmWfZtBUGMls9rEvV +6c4JBiTCuhSmIUH6HO90lH4lWAsxSltXalJvMEskp/fi1pKjnmR298Jx5Rja1bT j5I1DJQdse7NArtJrGduDlLPsX3tY4BR61DLpxL0ocfuVkF8aJbEDVT/bFGmPb7q tWGJxNRy+VcwtRk9D8Y+RtQt5k22CB8PQh/zxpGJ1+WD4rg7tIl+f1/zP2xbP3Ry OZthDRqWrdN6IDjTz5K529UPhDaW0YthORXhq9AWqyhWL5yewIUjCRmzBfOEH+TL 3xPkUE+fDj1MVQ0CohbJmtcaD7AYC8WQH69CC2W4pmzM5hX1iQLOaNbyLxEqVznb GDmKfVee8ZjGNlRb+gSNRGtUP2/mTYRGyWmjCrrZaQmYZre5FupeoyUw1q64L4b9 np2Y9FCJP2HaaHfKlPQp9JTmklqR44PRdXk180HspOWsEzCfACestP1snpSvUZBx 8t25Sl0G6TCqUkXnTbJ5kVfKf9ZSIwx4oa8CKYtCoy0aJ58gYs2BzWvbynNUknZy ZFFoAIrsYT8ABlvXzU1m =hFi3 -----END PGP SIGNATURE----- ------enig2MXETALQPLXBFQGUATLOO-- From nico@cryptonector.com Thu Jul 11 12:32:02 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 796E121F9F08 for ; Thu, 11 Jul 2013 12:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 BylfJ0wWojg0 for ; Thu, 11 Jul 2013 12:31:57 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6464121F9EE4 for ; Thu, 11 Jul 2013 12:31:57 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 94D2E163B for ; Thu, 11 Jul 2013 12:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=HhHbNQ6x0ckyPcClkQ2O QomlAlQ=; b=GcRX3KWQ+ihytxEKg+5PHu+qumuAt3s7ocXir6+mCegbQM83Ue25 +RlyKRiX8cYOfObKQ896SZFifOBVsaJ/bSV0AQbEJ7D5yKnBAhnEplar5k8hz7zy o2G71mKep5UbnpyMxsvBr4bQ+j/8lQ4CxbgOvBzWm30lx6kB4ekAtXM= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id EC84A161E for ; Thu, 11 Jul 2013 12:31:55 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so7090590wev.8 for ; Thu, 11 Jul 2013 12:31:53 -0700 (PDT) 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; bh=yGzjY/0iLumzmFg7wQsUgX11nQqTRR38wM8IoP31ee0=; b=LV6nHZR3+xk8mQNkOiJWGJ4qrA1vT67kNrsk/3BKwIfatykCQzrmdS7lThq7FDOL/n lH+ofRnFRvI+2smnp2+YeyQ9LwiaCB5r3gVDjkkfycPz9oQBHQEYaM0V1PcCThBuVFgk s/B49F6fKem71EM2FQrUHSzLJkGUSrWaJ3HRwVpNYb+Hi1cZwt3HXNYsi5KJfUGzhAMC HmnR1gzx9EpEE8QDFITXE4395+rPYDIY6BVtmzOjMW+hMoQBrRCamxD80NJjNx9F5oEl YN7CCoY27hrvqcS8QcygeSWNe2QVnIvbBU3yg5Yyz829kYkaS2GehDtO2nSfB+DFWBFc 4tmw== MIME-Version: 1.0 X-Received: by 10.180.185.176 with SMTP id fd16mr13690551wic.20.1373571113408; Thu, 11 Jul 2013 12:31:53 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 12:31:53 -0700 (PDT) In-Reply-To: <51DEFE70.6080402@fifthhorseman.net> References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> <51DEFE70.6080402@fifthhorseman.net> Date: Thu, 11 Jul 2013 14:31:53 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 19:32:02 -0000 On Thu, Jul 11, 2013 at 1:50 PM, Daniel Kahn Gillmor wrote: > On 07/11/2013 02:41 PM, Yoav Nir wrote: >> >> * GET /maingage.html?button=shutdown caused the firewall to power-off. >> * GET /mainpage.html?button=unload caused the firewall to unload policy, so that it didn't enforce policy or do IPsec or anything a router wouldn't do. >> >> So I tried opening another browser tab, and loading an HTML document that said >> >> Yes, the firewall powered down, and if I had used "unload" instead of "shutdown" that would be the end of enforcing a security policy. >> >> Now, granted, this is epic levels of cluelessness. > > these are indeed epic levels of cluelessness. at the very least the > authors of such an appliance need to learn the distinction between POST > and GET, which would prevent your "attack". If the authors aren't > capable of making this distinction (which has been around for nearly 20 > years), and they don't use widely-known measures for CSRF protection > (itself coming up on 10 years old, i think) when they have users who > enable javascript, i strongly doubt they'll deploy any sort of fancy > session continuation even if we specify it perfectly. Would any session continuation protocol alone we've discussed address such epic mistakes? I don't think so. I think we could address these problems by having session IDs that correspond to "requests made by pages from the same or trusted origins" and ones that correspond to "requests made by untrusted third parties", *then* we only have to make sure that the service is HTTPS-only or that if it has any resources not protected with HTTPS then that it can authenticate HTTP requests and responses or otherwise treat the HTTP origin as untrusted. Of course, this all ties into the notion of origins and whether mixed HTTP/HTTPS services are a good idea (and why) -- a bit off-topic for session continuation, but tangential enough. > I'm not sure this sort of example is a reasonable argument for > developing any new standard technical measures, since by definition the > culprits here are not making use of standard technical measures. Actually, several alternatives to channel bound cookies that use MACs have in fact been implemented and deployed. We're not necessarily developing new protocols. New standards, possibly. Nico -- From ynir@checkpoint.com Thu Jul 11 12:37: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 B0CE011E8112 for ; Thu, 11 Jul 2013 12:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.551 X-Spam-Level: X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 GhtnHEcFTkIk for ; Thu, 11 Jul 2013 12:37:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B9B5721F846E for ; Thu, 11 Jul 2013 12:37:40 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6BJbbmp002653; Thu, 11 Jul 2013 22:37:37 +0300 X-CheckPoint: {51DF0981-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Thu, 11 Jul 2013 22:37:36 +0300 From: Yoav Nir To: Daniel Kahn Gillmor Thread-Topic: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 Thread-Index: AQHOe51K2fjJqAHy/0+f/EfC93QcepleQH6AgAEAfoCAAENLAIAAHqqAgAACigCAAA0vgA== Date: Thu, 11 Jul 2013 19:37:35 +0000 Message-ID: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> <51DEFE70.6080402@fifthhorseman.net> In-Reply-To: <51DEFE70.6080402@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.234] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1156f5dca8e089022d592bdd46e2823543d94e8c56 Content-Type: text/plain; charset="us-ascii" Content-ID: <3192FE3ACCA5774FA0993DAD2FF4D664@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 19:37:52 -0000 On Jul 11, 2013, at 9:50 PM, Daniel Kahn Gillmor wr= ote: > On 07/11/2013 02:41 PM, Yoav Nir wrote: >>=20 >> * GET /maingage.html?button=3Dshutdown caused the firewall to power= -off. >> * GET /mainpage.html?button=3Dunload caused the firewall to unl= oad policy, so that it didn't enforce policy or do IPsec or anything a rout= er wouldn't do. >>=20 >> So I tried opening another browser tab, and loading an HTML document tha= t said >>=20 >> Yes, the firewall powered down, and if I had used "unload" instead of "s= hutdown" that would be the end of enforcing a security policy. >>=20 >> Now, granted, this is epic levels of cluelessness. >=20 > these are indeed epic levels of cluelessness. at the very least the > authors of such an appliance need to learn the distinction between POST > and GET, which would prevent your "attack". =20 I would still be able to make a form that would cause a POST. It's just a m= atter of getting the user to click a button, no? I think I could also do i= t in Javascript. > If the authors aren't > capable of making this distinction (which has been around for nearly 20 > years), and they don't use widely-known measures for CSRF protection > (itself coming up on 10 years old, i think) when they have users who > enable javascript, i strongly doubt they'll deploy any sort of fancy > session continuation even if we specify it perfectly. They don't have to. I don't think they wrote the web server from scratch. T= hey have probably some web server and/or framework that does the cookie and= authentication handling for them. CSRF counter-measures are hard. Writing = the application with POST rather than GET is not hard, but it's something y= ou have to think about. New-fangled cookies can be baked into the framework= . > I'm not sure this sort of example is a reasonable argument for > developing any new standard technical measures, since by definition the > culprits here are not making use of standard technical measures. I think anything that takes the requirement for security clue away from the= web developer and into the hands of the framework developer is a good thin= g. That does not mean they won't find other ways to mess up, but this is on= e case we can fix. Yoav From dkg@fifthhorseman.net Thu Jul 11 13:45: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 DEB3121E8051 for ; Thu, 11 Jul 2013 13:45:10 -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 0c1heGacNeMX for ; Thu, 11 Jul 2013 13:45:05 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E44B421F9DA8 for ; Thu, 11 Jul 2013 13:45:04 -0700 (PDT) Received: from [192.168.13.179] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id ECEFEF948; Thu, 11 Jul 2013 16:45:01 -0400 (EDT) Message-ID: <51DF194A.6040604@fifthhorseman.net> Date: Thu, 11 Jul 2013 16:44:58 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> <51DEFE70.6080402@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2COCJKDTDMBGGQVQDRAAE" Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 20:45:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2COCJKDTDMBGGQVQDRAAE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/11/2013 03:37 PM, Yoav Nir wrote: > I would still be able to make a form that would cause a POST. It's just= a matter of getting the user to click a button, no? I think I could als= o do it in Javascript. Which is why you need CSRF protection, as i mentioned. >=20 > They don't have to. I don't think they wrote the web server from scratc= h. They have probably some web server and/or framework that does the cook= ie and authentication handling for them. CSRF counter-measures are hard. = Writing the application with POST rather than GET is not hard, but it's s= omething you have to think about. New-fangled cookies can be baked into t= he framework. Any sane modern webapp framework has CSRF protection built in already. Some not-so-sane and not-so-modern webapp frameworks have it too :P The point is, the devs on this silly appliance you describe weren't using such a framework. > I think anything that takes the requirement for security clue away from= the web developer and into the hands of the framework developer is a goo= d thing. That does not mean they won't find other ways to mess up, but th= is is one case we can fix. Sure, they could also have fixed it using standard tools that we already have available, though, without any new standards. I'm not saying that there are no good arguments for working on the session continuation problem as stated; i'm just saying that this example does not seem like a clear argument for it. --dkg ------enig2COCJKDTDMBGGQVQDRAAE 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/ iQJ8BAEBCgBmBQJR3xlKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc7skQALWBZfVMRzv4buhPLa19K0wE iSXbPNzhvzsl9s4+2/DPc+1sYnrMbtuxF0nrzVuyXjv5HsB1Tioaqs1Yer4Nfv3c Dwdlq8XLEFEWjCP/nsF71VHvMUQcs2GbY0pgJKJ6qprcsxHohbHSoFEP9TzMNTov oy//OkY5woWwHYXJU8I6Ns2Eqyi/x8GsNevIJDUdhh6ydK0GBE42L22ZL5fOSeRx wKXuWUVb9c8WxcLCY+hRpj75NSs1kdpI7ySOOHIAmNEX9djnweAQrzhC6nYbrbeD phdWj8X7fgvgCBUeTr609LRT9b8BQNLwFtA4qeFDmEspzRRJOUfq+8lqzGI4KgHq uR/Ob18/KRyHLQ7CPS9GmnR8Q+dtYW1mEpw9GwEXb57EsMWPgdRQCglAYp1oBXC2 sNwE0DyZYEtYUm0vG24Rg+EcUDPu3Si+jRCz2ZRlZko+4K8ZXmiy77+zAsPOyy0n DgWveBNX1qf68RF4VDIIU1eT4nFrpZbN5FRI+CBswex4Xqs/rRwV2olpGMQuwvVe h1XgneGX5LVWn1wsU8fkUL14T16bJmwC7h8DSfb+kHzkFwp/TWueF+I4OdujuOmJ 5cnf9CQVutNh/4gWdtNdOxSc7dDgNHSmV8fwHu4qVqrru6ycE8itQnweBCNR8koK OCfW2j5R7Cj70ONfVf5a =W18q -----END PGP SIGNATURE----- ------enig2COCJKDTDMBGGQVQDRAAE-- From nico@cryptonector.com Thu Jul 11 13:59: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 946C121F9FF8 for ; Thu, 11 Jul 2013 13:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 nqweSVrvwuVh for ; Thu, 11 Jul 2013 13:58:58 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE4F11E812A for ; Thu, 11 Jul 2013 13:58:48 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id C6FB976806B for ; Thu, 11 Jul 2013 13:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=L51/wuITnC5D+IgjfRNeLXB3+Oo=; b=QfS1mWzSswX C/fzZpj6LJGC7hzL/e/hso0/9H7Wf7haL+j4GBAPNrbB2rcDYGB40ZR9w+UU5JpR wUUzNiScye2ldY/ez3XxL3PH+Favt2F0cIre+WI/03dJ3fW9o3dnm8HKtjSed0bX +tN2wZSJzFO6XT6sJz5yv2UepQDinVDk= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 16517768056 for ; Thu, 11 Jul 2013 13:58:45 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so7651752wgh.9 for ; Thu, 11 Jul 2013 13:58:44 -0700 (PDT) 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; bh=opoTj2ft2Am8WQuSYvns0om/9OS2nlrjDbdRN3qm4nA=; b=IamTPp6NpYd95Fnw9w3YuzRdoITgL6GD4a/S0CdP1i7Tflwcvs8EluKk2fkIhkmV5E WY73yz3ae+KYme92pNZjyhg3bTEJGlSdtUUHW4nxrHqTzJVpZ2ImgVncZT+lYMzjO/rz YplHekg1EOhIyJGOfARfNWm/oy5iqxzNOOtpJslFmzLid42AAP8ItbEIPj69kpNoaT9c M5Uw4beaXwglNYnOpFMSwjS/YRjg2bgOAjyMertlh9nbUSDJsarTpvtSPcjL04cuCyNV 0ABfCIEyLAbWIaek++pybc/IevZxWqHkcT8sVH7p66B9RKtYTOPkRko7RTrLOw0l+W8Y 1OEg== MIME-Version: 1.0 X-Received: by 10.180.84.70 with SMTP id w6mr20918455wiy.36.1373576324103; Thu, 11 Jul 2013 13:58:44 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 13:58:43 -0700 (PDT) In-Reply-To: <51DF194A.6040604@fifthhorseman.net> References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> <51DEFE70.6080402@fifthhorseman.net> <51DF194A.6040604@fifthhorseman.net> Date: Thu, 11 Jul 2013 15:58:43 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 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, 11 Jul 2013 20:59:04 -0000 On Thu, Jul 11, 2013 at 3:44 PM, Daniel Kahn Gillmor wrote: > On 07/11/2013 03:37 PM, Yoav Nir wrote: >> They don't have to. I don't think they wrote the web server from scratch= . They have probably some web server and/or framework that does the cookie = and authentication handling for them. CSRF counter-measures are hard. Writi= ng the application with POST rather than GET is not hard, but it's somethin= g you have to think about. New-fangled cookies can be baked into the framew= ork. > > Any sane modern webapp framework has CSRF protection built in already. > Some not-so-sane and not-so-modern webapp frameworks have it too :P The > point is, the devs on this silly appliance you describe weren't using > such a framework. Not that it's on-topic but, it's hard for a framework to ensure that GETs have no harmful side-effects because GET is allowed to have them, as long as it's idempotent. >> I think anything that takes the requirement for security clue away from = the web developer and into the hands of the framework developer is a good t= hing. That does not mean they won't find other ways to mess up, but this is= one case we can fix. > > Sure, they could also have fixed it using standard tools that we already > have available, though, without any new standards. > > I'm not saying that there are no good arguments for working on the > session continuation problem as stated; i'm just saying that this > example does not seem like a clear argument for it. I think that's correct in this case, unless I misunderstood how session continuation per-se can help in Yoav's example. But this is WEBSEC WG, and other things besides session continuation protocols are on-topic that could, together with session continuation protocols, address the problem. At any rate, I don't think we should do anything to exclude channel bound cookies (at least not yet, not without much more discussion as to why) as a candidate session continuation protocol. I have given reasons why I think it shouldn't be the only candidate at this time, or why we might need to have more than one session continuation protocol (since, in fact, we already do as deployed). Nico -- From internet-drafts@ietf.org Thu Jul 11 15:07: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 3407111E819A; Thu, 11 Jul 2013 15:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL7owXBDbluO; Thu, 11 Jul 2013 15:07:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 906DD11E81A2; Thu, 11 Jul 2013 15:07:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711220747.31290.19591.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 15:07:47 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-08.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:07:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-08.txt Pages : 23 Date : 2013-07-11 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trevp@trevp.net Thu Jul 11 20:40: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 0998211E81E0 for ; Thu, 11 Jul 2013 20:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvylD1RaZ-HU for ; Thu, 11 Jul 2013 20:40:33 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4B811E80F7 for ; Thu, 11 Jul 2013 20:40:32 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so7727305wev.0 for ; Thu, 11 Jul 2013 20:40:32 -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=yrrxYpaGdRBHaEWZOKBVsCoWn6azvJaWW2pnFE20gV8=; b=h9UDSHVktM2yQyDJJsKAoQz8P/RLAyA3IIxg7RXVUk6xJmELFfaE35aUTJk5BoUP/X Vwi4emQiUFU+TiJovJk6aLBpWjlmX943Ivz7HIHN7oeSvYfFFkv7/i4trdiVEFodnky8 WTDoiaszJmP60cb5yCoVvObKbeOtcWJ80RdT9sRtG0tUHB7kL8Pc4kGTicTV1ahFmWJk mSDONYA9/mQXPaAH/GzElTkAJW86hjw+0G93szQ2lqblygzTTOrnv/WpBpsiTzXJfqCj 6BDITOAD2unfzclIoBeR4MYZLKrZjhFOUta8I00dYigeMgVKEMhZPCJ3ZW7d2thVLa4V vGOg== MIME-Version: 1.0 X-Received: by 10.194.83.195 with SMTP id s3mr23345881wjy.82.1373600431917; Thu, 11 Jul 2013 20:40:31 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Thu, 11 Jul 2013 20:40:31 -0700 (PDT) X-Originating-IP: [50.37.26.202] In-Reply-To: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> <51DEFE70.6080402@fifthhorseman.net> <51DF194A.6040604@fifthhorseman.net> Date: Thu, 11 Jul 2013 20:40:31 -0700 Message-ID: From: Trevor Perrin To: Nico Williams Content-Type: multipart/alternative; boundary=047d7bdc7c90cedfd304e14845cf X-Gm-Message-State: ALoCoQlZn3WJV25zgR3RlqI5bfdb+oX7z86Xfi0W4JVhQCnh+avyK7Fe1IK17Pqh+WWoolDedgR4 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 03:40:38 -0000 --047d7bdc7c90cedfd304e14845cf Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 11, 2013 at 1:58 PM, Nico Williams wrote: > > At any rate, I don't think we should do anything to exclude channel > bound cookies (at least not yet, not without much more discussion as > to why) as a candidate session continuation protocol. I have given > reasons why I think it shouldn't be the only candidate at this time, > That's fair, but I do think ChannelID sets a high standard. It's clear, simple and can strongly protect cookies. The proposals from this WG seem much more complicated [1,2], and it's hard to tell whether they resist attacks such as: - Session forcing, where a MITM attacker transfer a session to the victim client, thus logging the victim into the attacker's account. - Session stealing, where an attacker observes or receives a victim client's request, and then makes the same request himself (perhaps just replaying it, perhaps modifying it). Trevor [1] http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00 [2] http://tools.ietf.org/html/draft-hallambaker-httpsession-01 --047d7bdc7c90cedfd304e14845cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Jul 11, 2013 at 1:58 PM, Nico Williams <nico@cryptonector.com<= /a>> wrote:

At any rate, I don't think we should do anything to exclude channel
bound cookies (at least not yet, not without much more discussion as
to why) as a candidate session continuation protocol. =A0I have given
reasons why I think it shouldn't be the only candidate at this time,


--047d7bdc7c90cedfd304e14845cf-- From hallam@gmail.com Fri Jul 12 06:20:50 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 2D1B111E80F9 for ; Fri, 12 Jul 2013 06:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 GWrKdHMpBwS4 for ; Fri, 12 Jul 2013 06:20:49 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 194A011E80F3 for ; Fri, 12 Jul 2013 06:20:47 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so8141844wgh.27 for ; Fri, 12 Jul 2013 06:20:47 -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=/SeFAMYQCeUPaF5v/sHPCt/Hny0szkyqtWM/x8pDuQc=; b=Hmcuc5lr5FIgaxkWrXG5eR0xCD68fbQvINKu1PZNCGODRVyiGz4GCQrxPwmLkYJHtb DnSiH2q4sUGOWYK6Sdh8lAGAT4SYBBz0Jo7NI1pFnnw0XSc35cEMxNUD2rSGETSoa4RC LO8HOmMXcq+UFOmm023juv4uOzOujV9wCLB5INxG94rucDCCf/Zzq8mTyTYDBRjW4WE6 KJSEP8ec+Xxmh6sodhOHoggL8U9VRVFVs/pKQlyDSMUYLps5Gp0Uh26+tvaDh9iPXP3a iX4iseiCV0QbI+GXZYSKsc0O/LnbL1repNvXLbvUZA9zqYNZbEuhJ0Sojnw6UH6xtxUh NHuw== MIME-Version: 1.0 X-Received: by 10.180.126.2 with SMTP id mu2mr1622527wib.63.1373635247165; Fri, 12 Jul 2013 06:20:47 -0700 (PDT) Received: by 10.194.6.65 with HTTP; Fri, 12 Jul 2013 06:20:46 -0700 (PDT) In-Reply-To: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> Date: Fri, 12 Jul 2013 09:20:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=e89a8f642dfcf55a0504e1506017 Cc: IETF WebSec WG Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:20:50 -0000 --e89a8f642dfcf55a0504e1506017 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 5:39 PM, Nico Williams wrote: > > > Also: despite mentioning a few proposals, there's no mention of > ChannelID / > > Channel-bound cookies [3]. > > > > ChannelID seems to solve these problems, seems more polished than other > > proposals, and apparently is being experimentally deployed (see Chrome | > > Preferences | Cookies and site data | "google.com" or "gmail.com"). > > There's definitely mention of channel binding. Channel bound cookies > used over HTTPS would meet the requirements of this spec, except for > the CRIME/BEAST resistance part. > > I'm not sure that we should mandate CRIME/BEAST resistance -- TLS > should arguably be able to resist such attacks. But it will take a > long time to deploy TLS that does, and that's what makes it appealing > to have CRIME/BEAST resistance in the session continuation protocol. We should not be mandating resistance to particular attacks already solved. But we should be mandating a change in the authentication design. The point is that the security of the authentication tokens should not be compromised even if the confidentiality scheme fails. Confidentiality should be built on authentication, not the other way round as using bearer tokens forces us to do. CRIME/BEAST would be a serious problem in any case and I find it amazing that we still have people pushing header compression schemes even now. And thats not the end of the problems either. The 'make it unsafe, we want speed' crowd is currently looking at using HTTP over UDP for bulk transport (not CoAP, web browsing) so expect DoS problems to get much worse. The lesson we should be drawing from CRIME/BEAST is that the web browser developers don't actually give a damn about security. There are security people working for them but don't be fooled, the people who manage those products don't consider security a priority or else we would have revocation checking in SSL clients that is meaningful and many other things. The KGB and the NSA both have doctrines that say that a system must be robust in the case of failure of a cryptographic protocol. We have to adopt the same sort of approach because modern Web browsers are ridiculously complex and getting more so. There is nobody who can claim to understand and be able to vouch for the security of the interactions between all the components. CRIME is a consequence of two design decisions taken without care for security: header compression and active code. Those two decisions are not going to be the last. Since we can't understand the consequences of those interactions our only viable design approach is to design the session continuation scheme so that the security of the authentication secrets ONLY depends on things we can count on. > >> - Will you be willing to review the problem statement? > >> - Will you be willing to read multiple solution proposals to help the > >> working group choose? > >> - Will you be willing to review the solution document? > > > > I'd be more interested in websec taking this on if someone could argue > why > > ChannelID is *not* the right solution, and had some ideas how to do > better. > > See above. > > Nico > -- > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --e89a8f642dfcf55a0504e1506017 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 10, 2013 at 5:39 PM, Nico Williams &l= t;nico@cryptonec= tor.com> wrote:

> Also: =A0despite mentioning a few proposals, there's no mention of= ChannelID /
> Channel-bound cookies [3].
>
> ChannelID seems to solve these problems, seems more polished than othe= r
> proposals, and apparently is being experimentally deployed (see Chrome= |
> Preferences | Cookies and site data | "google.com" or "gmail.com").

There's definitely mention of channel binding. =A0Channel bound c= ookies
used over HTTPS would meet the requirements of this spec, except for
the CRIME/BEAST resistance part.

I'm not sure that we should mandate CRIME/BEAST resistance -- TLS
should arguably be able to resist such attacks. =A0But it will take a
long time to deploy TLS that does, and that's what makes it appealing to have CRIME/BEAST resistance in the session continuation protocol.

We should not be mandating resistance to pa= rticular attacks already solved. But we should be mandating a change in the= authentication design.

The point is that the security of the authe= ntication tokens should not be compromised even if the confidentiality sche= me fails. Confidentiality should be built on authentication, not the other = way round as using bearer tokens forces us to do.


CRIME/BEAST would be a= serious problem in any case and I find it amazing that we still have peopl= e pushing header compression schemes even now. And thats not the end of the= problems either. The 'make it unsafe, we want speed' crowd is curr= ently looking at using HTTP over UDP for bulk transport (not CoAP, web brow= sing) so expect DoS problems to get much worse.

The lesson we should be drawing from CRIME/= BEAST is that the web browser developers don't actually give a damn abo= ut security. There are security people working for them but don't be fo= oled, the people who manage those products don't consider security a pr= iority or else we would have revocation checking in SSL clients that is mea= ningful and many other things.


The KGB and the NSA bo= th have doctrines that say that a system must be robust in the case of fail= ure of a cryptographic protocol. We have to adopt the same sort of approach= because modern Web browsers are ridiculously complex and getting more so. = There is nobody who can claim to understand and be able to vouch for the se= curity of the interactions between all the components. CRIME is a consequen= ce of two design decisions taken without care for security: header compress= ion and active code. Those two decisions are not going to be the last.

Since we can't understand the consequen= ces of those interactions our only viable design approach is to design the = session continuation scheme so that the security of the authentication secr= ets ONLY depends on things we can count on.


=A0
=
>> =A0- Will you be willing to review the problem statement?
>> =A0- Will you be willing to read multiple solution proposals to he= lp the
>> working group choose?
>> =A0- Will you be willing to review the solution document?
>
> I'd be more interested in websec taking this on if someone could a= rgue why
> ChannelID is *not* the right solution, and had some ideas how to do be= tter.

See above.

Nico
--
___________________________________= ____________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec



--
= Website: http://hallambaker.com/
--e89a8f642dfcf55a0504e1506017-- From tobias.gondrom@gondrom.org Mon Jul 15 00:02: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 8880121F8546 for ; Mon, 15 Jul 2013 00:02:36 -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 jJ+QIaiCkGYp for ; Mon, 15 Jul 2013 00:02: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 8CD8221F8415 for ; Mon, 15 Jul 2013 00:02:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=BhR41NCfYlnRuM3VxGwYQdR9tqQC4Z219AJYI+DrlN5bovWbtqtRkz63oa6LRjSpHrLHDxSAscbHRx+8UaEbkRVCch0ySFxBnVKe2Oms82e7VdGXPj8h0xbrlS1a0wnr; 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 18039 invoked from network); 15 Jul 2013 09:02:29 +0200 Received: from static-122-0-22-16.mykris.net (HELO ?172.30.2.80?) (122.0.22.16) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Jul 2013 09:02:28 +0200 Message-ID: <51E39E81.8030807@gondrom.org> Date: Mon, 15 Jul 2013 16:02:25 +0900 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: websec@ietf.org References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@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] Call for adoption: draft-ietf-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:02:37 -0000 Yes to all. Any other volunteers? Best regards, Tobias On 08/07/13 14:40, Yoav Nir wrote: > And I'll start the ball rolling, buy answering yes (with no hats) to all questions. > > On Jul 8, 2013, at 8:37 AM, Yoav Nir > wrote: > >> Hi all >> >> This has been submitted with a websec filename, but note that this is not (yet) on our charter. >> >> At the Orlando meeting, we discussed some of the security issues with keeping HTTP sessions using cookies. There was consensus in the room that this is a problem that needs solving. Nicolas Williams, Phillip Hallam-Baker, and Yaron Sheffer volunteered to write a problem statement, and this is it. The message we got from our AD is that first we should show that the working group has the time and energy to work on solving this problem, and then we can add this to our charter. >> >> So please have a look and this document, and answer the following: >> - Is this a good starting point for the problem statement? >> - Will you be willing to review the problem statement? >> - Will you be willing to read multiple solution proposals to help the working group choose? >> - Will you be willing to review the solution document? >> >> We will have a chance to discuss this in Berlin, but it would be great if we have a rough measure of how much energy we have. >> >> Thanks >> >> Tobias and Yoav >> >> On Jul 8, 2013, at 8:26 AM, internet-drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Web Security Working Group of the IETF. >>> >>> Title : Hypertext Transport Protocol (HTTP) Session Continuation: Problem Statement >>> Author(s) : Nicolas Williams >>> Filename : draft-ietf-websec-session-continue-prob-00.txt >>> Pages : 13 >>> Date : 2013-07-07 >>> >>> Abstract: >>> One of the most often talked about problems in web security is >>> "cookies". Web cookies are a method of associating requests with >>> "sessions" that may have been authenticated somehow. Cookies are a >>> form of bearer token that leave much to be desired. This document >>> describes the session "continuation" problem for the HyperText >>> Transport Protocol (HTTP). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-websec-session-continue-prob >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-websec-session-continue-prob-00 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> >> Email secured by Check Point > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From internet-drafts@ietf.org Mon Jul 15 00:17: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 427EC21F9E6A; Mon, 15 Jul 2013 00:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzZ+o-SCY0WK; Mon, 15 Jul 2013 00:17:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D6221F9E29; Mon, 15 Jul 2013 00:17:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715071740.20201.35805.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 00:17:40 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-05.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:18:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : HTTP Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-05.txt Pages : 11 Date : 2013-07-15 Abstract: To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tobias.gondrom@gondrom.org Mon Jul 15 00:25:32 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 710B721F8956 for ; Mon, 15 Jul 2013 00:25:12 -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 vZJrnZ0gyUO9 for ; Mon, 15 Jul 2013 00:25:00 -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 4DD9A21F8994 for ; Mon, 15 Jul 2013 00:22:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=pfcHqqnYjGSYQ1RZgp8iO/hG9Gk3E8QMEmOPt4sr4zNpW3caeH/RJznylpAcgPG1sYxf+UQQAnFkbGWLfPTRo+GXgOsyLsT/QUCuKsx9xUGOyqvdxf2tnq0a4EJtlZkh; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 18216 invoked from network); 15 Jul 2013 09:22:17 +0200 Received: from static-122-0-22-16.mykris.net (HELO ?172.30.2.80?) (122.0.22.16) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Jul 2013 09:22:17 +0200 Message-ID: <51E3A325.6010203@gondrom.org> Date: Mon, 15 Jul 2013 16:22:13 +0900 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: <20130715071740.20201.35805.idtracker@ietfa.amsl.com> In-Reply-To: <20130715071740.20201.35805.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] I-D Action: draft-ietf-websec-x-frame-options-05.txt - only corrected a typo X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:25:33 -0000 Dear all, just fyi: this new revision only corrected on typo to prepare it for IETF LC (had the word "Clickjacking" twice in the Introduction). No other changes. Best regards, Tobias On 15/07/13 16:17, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Security Working Group of the IETF. > > Title : HTTP Header Field X-Frame-Options > Author(s) : David Ross > Tobias Gondrom > Filename : draft-ietf-websec-x-frame-options-05.txt > Pages : 11 > Date : 2013-07-15 > > Abstract: > To improve the protection of web applications against Clickjacking, > this specification describes the X-Frame-Options HTTP response header > field that declares a policy communicated from the server to the > client browser on whether the browser may display the transmitted > content in frames that are part of other web pages. This > informational document serves to document the existing use and > specification of this X-Frame-Options HTTP response header field. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-x-frame-options-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ynir@checkpoint.com Mon Jul 15 02:46: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 E41DB21F9F90 for ; Mon, 15 Jul 2013 02:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 yjMUOhi0ACM5 for ; Mon, 15 Jul 2013 02:46:34 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C27C621F9F2B for ; Mon, 15 Jul 2013 02:46:33 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6F9kUEF028141; Mon, 15 Jul 2013 12:46:30 +0300 X-CheckPoint: {51E3C4F5-7-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 12:46:28 +0300 From: Yoav Nir To: Tobias Gondrom Thread-Topic: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 Thread-Index: AQHOgSlQPOrg2mPNy0urIM9EhreKK5llS78A Date: Mon, 15 Jul 2013 09:46:28 +0000 Message-ID: References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> <51E39E81.8030807@gondrom.org> In-Reply-To: <51E39E81.8030807@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11628f38353c2d75d0d9ff3b2d23d965b263140c93 Content-Type: text/plain; charset="us-ascii" Content-ID: <2A0EFDA2C200374E8BF8E061DEE3C0AE@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:46:40 -0000 There are some people talking about similar things at httpbis, but for some= reason they're not willing to move the discussion here. On Jul 15, 2013, at 10:02 AM, Tobias Gondrom w= rote: > > Yes to all. >=20 > Any other volunteers? >=20 > Best regards, Tobias >=20 >=20 > On 08/07/13 14:40, Yoav Nir wrote: >> And I'll start the ball rolling, buy answering yes (with no hats) to all= questions. >>=20 >> On Jul 8, 2013, at 8:37 AM, Yoav Nir >> wrote: >>=20 >>> Hi all >>>=20 >>> This has been submitted with a websec filename, but note that this is n= ot (yet) on our charter. >>>=20 >>> At the Orlando meeting, we discussed some of the security issues with k= eeping HTTP sessions using cookies. There was consensus in the room that th= is is a problem that needs solving. Nicolas Williams, Phillip Hallam-Baker,= and Yaron Sheffer volunteered to write a problem statement, and this is it= . The message we got from our AD is that first we should show that the work= ing group has the time and energy to work on solving this problem, and then= we can add this to our charter. >>>=20 >>> So please have a look and this document, and answer the following: >>> - Is this a good starting point for the problem statement? >>> - Will you be willing to review the problem statement? >>> - Will you be willing to read multiple solution proposals to help the w= orking group choose? >>> - Will you be willing to review the solution document? >>>=20 >>> We will have a chance to discuss this in Berlin, but it would be great = if we have a rough measure of how much energy we have. >>>=20 >>> Thanks >>>=20 >>> Tobias and Yoav >>>=20 >>> On Jul 8, 2013, at 8:26 AM, internet-drafts@ietf.org wrote: >>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> This draft is a work item of the Web Security Working Group of the IET= F. >>>>=20 >>>> Title : Hypertext Transport Protocol (HTTP) Session Continu= ation: Problem Statement >>>> Author(s) : Nicolas Williams >>>> Filename : draft-ietf-websec-session-continue-prob-00.txt >>>> Pages : 13 >>>> Date : 2013-07-07 >>>>=20 >>>> Abstract: >>>> One of the most often talked about problems in web security is >>>> "cookies". Web cookies are a method of associating requests with >>>> "sessions" that may have been authenticated somehow. Cookies are a >>>> form of bearer token that leave much to be desired. This document >>>> describes the session "continuation" problem for the HyperText >>>> Transport Protocol (HTTP). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-websec-session-continue-pr= ob >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-websec-session-continue-prob-00 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>>=20 >>> Email secured by Check Point >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ynir@checkpoint.com Mon Jul 15 06:57: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 0837321F9EAF for ; Mon, 15 Jul 2013 06:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNMmJs33VSww for ; Mon, 15 Jul 2013 06:57:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 76FDE11E8106 for ; Mon, 15 Jul 2013 06:57:51 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6FDvnpb031098 for ; Mon, 15 Jul 2013 16:57:50 +0300 X-CheckPoint: {51E3FFDD-12-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 16:57:49 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: WebSec Meeting in Berlin Thread-Index: AQHOgWNKL0jySV6UVkafP8ciScGJ8w== Date: Mon, 15 Jul 2013 13:57:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1145805b0f26bda93c68c7de7566c5dc7f89383e95 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] WebSec Meeting in Berlin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:57:57 -0000 Hi all The WebSec working group will meet on Monday, July 29 at 15:10 for one hour= in the Potsdam 2 room. An audio stream will be available at http://ietf87streaming.dnsalias.net/ie= tf/ietf875.m3u A jabber room will be available at xmpp:websec@jabber.ietf.org?join If anyone would like to volunteer to take minutes or to channel the jabber = room, please contact Tobias or me directly. Thanks in advance. We haven't finalized the agenda, but we intend to spend most of our short s= ession on wrapping up HPKP, and on gauging interest in working on session c= ontinuation. If you have any other items you would like to raise, please co= ntact Tobias and me ASAP. Looking forward to seeing you all in just two weeks. Tobias and Yoav From palmer@google.com Mon Jul 15 17:02: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 0323D21E81B6 for ; Mon, 15 Jul 2013 17:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.363, 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 wx8YrL8TeNGd for ; Mon, 15 Jul 2013 17:02:41 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2E21E8197 for ; Mon, 15 Jul 2013 17:02:41 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so141829iea.17 for ; Mon, 15 Jul 2013 17:02:40 -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=wMBcDUh+TGKk7z1yFwRpXeWepara9kzaJ9JK4JPy9sQ=; b=CwoHMhdFRMB7qdkd1XzTZjloYvtcjegVosRAWBBdgyLrKRuAv74Uaar+EoNvKkNuqr HPXMOlYrc6lJPKPCXTb+UWb+1B8Pwd/AmX6NshQPOWD9K+ssUQ53rv97M0jVhFUgtB3D Yft4R4fKxsr4pGhez+vzCryCoDBMficv78k3/ES00UX+/ebcrQeZgYxatL0XpmVq27To WHTAPkMWu4iXz+QGSC5Ml6J3+0YZRT4Vez/XiMjTLqA7U4DbX9OL46MBPFCDlciJEohg lr07nZC0csrAz9ausVQp1FvapQq+r4AeP36kTg5XgwNd4LphOazFziQuu2Dn51i7u/PB p1wQ== 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=wMBcDUh+TGKk7z1yFwRpXeWepara9kzaJ9JK4JPy9sQ=; b=Sc4s9zUR61KZUvjPbEE5LX/KYBRSShL7TIqWYG+Caf8zZTKMt/ZZ8KmW7+e+Cme5R6 MSV+bJq9k9Bmc2rtn8YGEcoYUJHOoTF7wTiEg14Ix33z79pQ72UEqzUBeluARyZxFFF2 CwBJ4ZzGM7Zmsbyyd9bLa/gPgw9Kqj1uhh0qXbF5PD8deTP/OW9LBsKrt6dPCG+XYnNe 9ZkljRwYTXnQLWRkTatrRMomfTMJabvP0j6HpX6vCqhnbdVTnBoOo6xq6dBUNwnemrVG ilsCZSvanXOo0LqAd63UO0lVnveduwMKvfMvQ9LPomNlfNYr4kdcLG7mUWvw8eCfEdhw tCQA== MIME-Version: 1.0 X-Received: by 10.42.202.144 with SMTP id fe16mr18926292icb.72.1373932960586; Mon, 15 Jul 2013 17:02:40 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Mon, 15 Jul 2013 17:02:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 17:02:40 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlIlwajGhuIJ45aBHJRu4wfk2jNo5s/f2yOVB7ki1cOL9vmEknCXrMceXO/2cDNcCXB6KL0VD6/J1rvvq4Nw0AzJU+GZQHCwvaMHnKDW6MfTbH9fR005sKD4p3WiLli8tYKoC3bZstnSGGEa3NbA3yzQdtxx70iWAALq8UdlUXhJIh1x9iBP0UK8Q0Z2jBq6Ziqb9tL Cc: IETF WebSec WG Subject: Re: [websec] WebSec Meeting in Berlin 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, 16 Jul 2013 00:02:42 -0000 Is that 15:10 Berlin time, or GMT? On Mon, Jul 15, 2013 at 6:57 AM, Yoav Nir wrote: > Hi all > > The WebSec working group will meet on Monday, July 29 at 15:10 for one hour in the Potsdam 2 room. > > An audio stream will be available at http://ietf87streaming.dnsalias.net/ietf/ietf875.m3u > > A jabber room will be available at xmpp:websec@jabber.ietf.org?join > > If anyone would like to volunteer to take minutes or to channel the jabber room, please contact Tobias or me directly. Thanks in advance. > > We haven't finalized the agenda, but we intend to spend most of our short session on wrapping up HPKP, and on gauging interest in working on session continuation. If you have any other items you would like to raise, please contact Tobias and me ASAP. > > Looking forward to seeing you all in just two weeks. > > Tobias and Yoav > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ynir@checkpoint.com Mon Jul 15 20:48: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 5F7E211E81C0 for ; Mon, 15 Jul 2013 20:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 Wuo+vQvMzcFt for ; Mon, 15 Jul 2013 20:48:11 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6B94021F9FFB for ; Mon, 15 Jul 2013 20:48:11 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6G3mLNN004806; Tue, 16 Jul 2013 06:48:21 +0300 X-CheckPoint: {51E4C277-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Tue, 16 Jul 2013 06:48:05 +0300 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] WebSec Meeting in Berlin Thread-Index: AQHOgWNKL0jySV6UVkafP8ciScGJ85lmOoEAgAA+/oA= Date: Tue, 16 Jul 2013 03:48:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.92] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1165b019750d12a12b311538b2e1a89734bf29e92a Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] WebSec Meeting in Berlin 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, 16 Jul 2013 03:48:16 -0000 Local time. On Jul 16, 2013, at 3:02 AM, Chris Palmer wrote: > Is that 15:10 Berlin time, or GMT? >=20 > On Mon, Jul 15, 2013 at 6:57 AM, Yoav Nir wrote: >> Hi all >>=20 >> The WebSec working group will meet on Monday, July 29 at 15:10 for one h= our in the Potsdam 2 room. >>=20 >> An audio stream will be available at http://ietf87streaming.dnsalias.net= /ietf/ietf875.m3u >>=20 >> A jabber room will be available at xmpp:websec@jabber.ietf.org?join >>=20 >> If anyone would like to volunteer to take minutes or to channel the jabb= er room, please contact Tobias or me directly. Thanks in advance. >>=20 >> We haven't finalized the agenda, but we intend to spend most of our shor= t session on wrapping up HPKP, and on gauging interest in working on sessio= n continuation. If you have any other items you would like to raise, please= contact Tobias and me ASAP. >>=20 >> Looking forward to seeing you all in just two weeks. >>=20 >> Tobias and Yoav >>=20 >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >=20 > Email secured by Check Point From ynir@checkpoint.com Wed Jul 17 13:17:33 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 82B3C11E80DC for ; Wed, 17 Jul 2013 13:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 WzADfs0f5Q8z for ; Wed, 17 Jul 2013 13:17:29 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAB821E804C for ; Wed, 17 Jul 2013 13:17:11 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6HKGhhp026620 for ; Wed, 17 Jul 2013 23:16:43 +0300 X-CheckPoint: {51E6FBAB-6-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Wed, 17 Jul 2013 23:16:42 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Draft Agenda for the Berlin Meeting Thread-Index: AQHOgyqNjJPjjyzKwE2fevQjmkR4pg== Date: Wed, 17 Jul 2013 20:16:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.46] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11bdee9440d3bbe2ca2da4cd20fb81b52318a87b5c Content-Type: text/plain; charset="us-ascii" Content-ID: <15EAAB94473A9847917975B3AE5FF769@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Draft Agenda for the Berlin Meeting 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, 17 Jul 2013 20:17:33 -0000 Hi all I've uploaded the draft agenda for the Berlin meeting. If you have any comm= ents or corrections, please send them to Tobias and me either on- or off-li= st. Thanks Yoav http://www.ietf.org/proceedings/87/agenda/agenda-87-websec WebSec Agenda, IETF 87 Monday, July 29, 2013 1510-1610 @ Potsdam 2 Audio stream: http://ietf87streaming.dnsalias.net/ietf/ietf875.m3u Jabber room: xmpp:websec@jabber.ietf.org?join =20 All the drafts in Kindle and epub format: http://tools.ietf.org/ebook/i-d.websec.mobi http://tools.ietf.org/ebook/i-d.websec.epub - Agenda Bashing + Blue Sheets + Note Well + document status 5 min - HPKP WGLC issues 25 min - Session Continuation 20 min - open mic Whatever's left= From trevp@trevp.net Thu Jul 18 01:56: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 9A1D711E80F7 for ; Thu, 18 Jul 2013 01:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 tgYFoKmX1Wzs for ; Thu, 18 Jul 2013 01:56:33 -0700 (PDT) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D111E80D5 for ; Thu, 18 Jul 2013 01:56:32 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id p13so2123381vbe.14 for ; Thu, 18 Jul 2013 01:56:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=r19G2CTMAqvTnxPf4sqvIbSTSSdD4qiqmzP5DXH3XjI=; b=iQyTxMDMmLpUIFymQNLY6Fbzvk8BgHSqlr8CnDXUmdj5z//XXq7HVRz7RicBQ1vwzb 3kU+0bYVcUhT2wOKVMgLLyNn4n2gSurqf8rgvntxK/93nRAsvF/FWTFX4JMUt5Oo/N1K HzeAtBjf7+91hMZjbLNwuRj8ObnkmwofndBtbsIDRw85WkId8x7/eZVqU1wMOyY/mIrn dAAlD3EEM3mk8rKXYKRWjccUUAuCi2Ga/+v12IjRlmBsOe4oGHcXs//O5doFDPsAnMdr 65B3yCEP6tnblGWb4ZixI7Gdr8iYB8VRdD6zi793yhZUIg0+D/G1vgz0p3dE0+dOoDXC +ByA== MIME-Version: 1.0 X-Received: by 10.221.36.4 with SMTP id sy4mr3689469vcb.11.1374137792164; Thu, 18 Jul 2013 01:56:32 -0700 (PDT) Received: by 10.220.216.2 with HTTP; Thu, 18 Jul 2013 01:56:32 -0700 (PDT) X-Originating-IP: [216.31.230.230] Date: Thu, 18 Jul 2013 01:56:32 -0700 Message-ID: From: Trevor Perrin To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnUxaT1utrd9lNJY7GFQuTiknw+gPurep7kTERiQTuF62JJNRvyiYlW0QxI4j/TKWk3IzoY Subject: [websec] Cookies: What is to be done? 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, 18 Jul 2013 08:56:37 -0000 Hi, I tried to send this earlier, but I don't think it went through. Here's an attempt to summarize the main cookie problems and proposals. I'd be interested if anyone sees thing differently. Problems ========= 1) Bearer token problem: Cookies are transmitted frequently, and if a transmitted cookie is somehow stolen, it could be used by an attacker. 2a) Cookie scoping (confidentiality): Cookies set on example.com will typically be sent to all subdomains of example.com. So the security of example.com can be undermined by less-secure subdomains. Even HSTS/HPKP/TACK/DANE for example.com could be undermined if a hacker can take over test.example.com, or a MITM can invent badguy.example.com, since the browser would hand these attackers the example.com session cookie. There are partial mitigations for this, but nothing that could work reliably across all sites and browsers: - Omitting the cookie's "Domain" attribute will cause cookies to be sent only to "example.com" and not its subdomains (RFC 6265), on all browsers except IE. IE seems unwilling to change this, presumably due to legacy web apps. - Setting a cookie's "Secure" attribute will require the browser to only transmit it over SSL/TLS. However, the subdomain may not have the same HSTS/HPKP/TACK/DANE/etc requirements as its parent. HSTS and HPKP provide "includeSubdomains" to address this (RFC 6797, 14.4). However, it's common for example.com to have subdomains that can't comply with HSTS or HPKP (for example: mobile.example.com doesn't use SSL; images.example.com is hosted on a CDN; test.example.com has a self-signed cert, etc). In these cases, "includeSubdomains" can't be used. 2b) Cookie scoping (integrity): Cookies set on webmail.example.com can be overwritten or deleted by its subdomains, regardless of the "Secure" or "Domain" attributes. Also, example.com and its subdomains could set an identically-named cookie for Domain=example.com, which will get sent to webmail.example.com. "Forcing" a cookie on the victim could allow an attacker to log a victim into the attacker's account. The victim might then enter credit card numbers or other data, similar to the "login CSRF" attacks in [1]. This is harder to mitigate than 2a, as "Domain" and "Secure" attributes have no effect, and the scope of hostnames that can affect a victim hostname is not just the victim's subdomains, but everything sharing the same TLD+1 domain (*.example.com, in this case). Proposals ========== 1) Origin Cookies: http://tools.ietf.org/html/draft-abarth-cake-01 http://w2spconf.com/2011/papers/session-integrity.pdf This adds an "Origin" attribute to cookies. Such cookies are backwards-compatible with old browsers. New browsers would only return them to the hostname that set them, via an "Origin-Cookie" header, thus fixing 2a. To fix 2b, the browser might have to always send something like "Origin-Cookie-Support: true" as an HTTP header, so that an Origin Cookie supporting server would know to disregard old-style cookies that might have been forced on the browser. This doesn't fix the "bearer token" aspect of cookies, but it seems a simple, clean fix to the scoping problems. What happened to this? 2) ChannelID http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 The browser adds an ECDSA public key and signature to every TLS handshake. The server can implement "Channel-bound cookies" which are associated with the public key. Such cookies can't be transferred from one browser to another. This solves the "bearer token" aspect of cookies. It also solves a big part of the scoping problem, since an attacker can't steal usable cookies, or force her cookies on someone else. However, since the same ChannelID public key is used for an entire TLD+1, an attacker who could hack subdomain hosts or perform MITM could still: - Delete cookies - Steal a cookie from a user at A.example.com, and force it on the same user at B.example.com - Steal a cookie via a subdomain and then force it later on the same user to "rollback" to an earlier state This also modifies the TLS stack, and adds a client-side signature computation to every TLS session. 3) Session Continuation Protocol http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00 Instead of cookies, the server can set a symmetric "session key" into the browser, and specify a range of hostnames to use it for. The browser will send a nonce, and a MAC over the nonce, for every connection to those hostnames. Since the nonce and MAC, if stolen, would suffice as a bearer token, this doesn't solve 1. Since the Host-Scope of the session can be specified arbitrarily, this solves 2a but not 2b. 4) HTTP Session Management http://tools.ietf.org/html/draft-hallambaker-httpsession-01 This is similar to (3), except the MAC can optionally be calculated over "portions of the HTTP message", and the scoping rules are defined to be identical to cookies as defined somewhere (not specified). This might mitigate 1 somewhat, since a MAC, if stolen, could only be used to replay requests similar to the stolen one. Cookie scoping problems don't seem to be addressed. Trevor [1] http://seclab.stanford.edu/websec/csrf/csrf.pdf From hannes.tschofenig@gmx.net Thu Jul 18 02:24:18 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3905A21F9DD0 for ; Thu, 18 Jul 2013 02:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 035tdSmJYKKA for ; Thu, 18 Jul 2013 02:24:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id CE0A421F9AAE for ; Thu, 18 Jul 2013 02:24:13 -0700 (PDT) Received: from [172.16.254.104] ([80.92.116.207]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MeMOx-1Umsom3K0d-00QFfP; Thu, 18 Jul 2013 11:24:12 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 18 Jul 2013 11:24:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Trevor Perrin X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:Vg58UiuWUbwR9sHHYL69iDHWD/PZbDTwA6hXc9EDku5nco2uTem Q16nj3w/mkLxOl2qBiOZfxomA1+2GfH/EngZnvFucvbhLod3cUTjnoKcXee0WHfzy+azinr AVX8wSDJXZy4NxPaAs9I/RLMZyH4uRaBKsiiLctAq0S/VI2uQwG4vp9xnfvqsAnLTuyqaV/ 1nwRe5/B+Op7MC0BCraBw== Cc: IETF WebSec WG Subject: Re: [websec] Cookies: What is to be done? 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, 18 Jul 2013 09:24:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Trevor,=20 nice writeup! There is also a relationship to the work we are doing in the OAuth = working group.=20 Here is the relevant document:=20 http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-04 The OAuth work (obviously) has a different story on how the parties = actually get the key. There are, obviously, various reasons why people = use cookies.=20 Ciao Hannes On Jul 18, 2013, at 10:56 AM, Trevor Perrin wrote: > Hi, >=20 > I tried to send this earlier, but I don't think it went through. >=20 > Here's an attempt to summarize the main cookie problems and proposals. >=20 > I'd be interested if anyone sees thing differently. >=20 >=20 > Problems > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1) Bearer token problem: > Cookies are transmitted frequently, and if a transmitted cookie is > somehow stolen, it could be used by an attacker. >=20 > 2a) Cookie scoping (confidentiality): > Cookies set on example.com will typically be sent to all subdomains of > example.com. So the security of example.com can be undermined by > less-secure subdomains. Even HSTS/HPKP/TACK/DANE for example.com > could be undermined if a hacker can take over test.example.com, or a > MITM can invent badguy.example.com, since the browser would hand these > attackers the example.com session cookie. There are partial > mitigations for this, but nothing that could work reliably across all > sites and browsers: >=20 > - Omitting the cookie's "Domain" attribute will cause cookies to be > sent only to "example.com" and not its subdomains (RFC 6265), on all > browsers except IE. IE seems unwilling to change this, presumably > due to legacy web apps. >=20 > - Setting a cookie's "Secure" attribute will require the browser to > only transmit it over SSL/TLS. However, the subdomain may not have the > same HSTS/HPKP/TACK/DANE/etc requirements as its parent. HSTS and > HPKP provide "includeSubdomains" to address this (RFC 6797, 14.4). > However, it's common for example.com to have subdomains that can't > comply with HSTS or HPKP (for example: mobile.example.com doesn't use > SSL; images.example.com is hosted on a CDN; test.example.com has a > self-signed cert, etc). In these cases, "includeSubdomains" can't be > used. >=20 > 2b) Cookie scoping (integrity): > Cookies set on webmail.example.com can be overwritten or deleted by > its subdomains, regardless of the "Secure" or "Domain" attributes. > Also, example.com and its subdomains could set an identically-named > cookie for Domain=3Dexample.com, which will get sent to > webmail.example.com. "Forcing" a cookie on the victim could allow an > attacker to log a victim into the attacker's account. The victim > might then enter credit card numbers or other data, similar to the > "login CSRF" attacks in [1]. >=20 > This is harder to mitigate than 2a, as "Domain" and "Secure" > attributes have no effect, and the scope of hostnames that can affect > a victim hostname is not just the victim's subdomains, but everything > sharing the same TLD+1 domain (*.example.com, in this case). >=20 >=20 > Proposals > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1) Origin Cookies: > http://tools.ietf.org/html/draft-abarth-cake-01 > http://w2spconf.com/2011/papers/session-integrity.pdf >=20 > This adds an "Origin" attribute to cookies. Such cookies are > backwards-compatible with old browsers. New browsers would only > return them to the hostname that set them, via an "Origin-Cookie" > header, thus fixing 2a. To fix 2b, the browser might have to always > send something like "Origin-Cookie-Support: true" as an HTTP header, > so that an Origin Cookie supporting server would know to disregard > old-style cookies that might have been forced on the browser. >=20 > This doesn't fix the "bearer token" aspect of cookies, but it seems a > simple, clean fix to the scoping problems. What happened to this? >=20 >=20 > 2) ChannelID > http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 >=20 > The browser adds an ECDSA public key and signature to every TLS > handshake. The server can implement "Channel-bound cookies" which are > associated with the public key. Such cookies can't be transferred > from one browser to another. >=20 > This solves the "bearer token" aspect of cookies. It also solves a > big part of the scoping problem, since an attacker can't steal usable > cookies, or force her cookies on someone else. However, since the > same ChannelID public key is used for an entire TLD+1, an attacker who > could hack subdomain hosts or perform MITM could still: > - Delete cookies > - Steal a cookie from a user at A.example.com, and force it on the > same user at B.example.com > - Steal a cookie via a subdomain and then force it later on the same > user to "rollback" to an earlier state >=20 > This also modifies the TLS stack, and adds a client-side signature > computation to every TLS session. >=20 >=20 > 3) Session Continuation Protocol > = http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00= >=20 > Instead of cookies, the server can set a symmetric "session key" into > the browser, and specify a range of hostnames to use it for. The > browser will send a nonce, and a MAC over the nonce, for every > connection to those hostnames. >=20 > Since the nonce and MAC, if stolen, would suffice as a bearer token, > this doesn't solve 1. Since the Host-Scope of the session can be > specified arbitrarily, this solves 2a but not 2b. >=20 >=20 > 4) HTTP Session Management > http://tools.ietf.org/html/draft-hallambaker-httpsession-01 >=20 > This is similar to (3), except the MAC can optionally be calculated > over "portions of the HTTP message", and the scoping rules are defined > to be identical to cookies as defined somewhere (not specified). This > might mitigate 1 somewhat, since a MAC, if stolen, could only be used > to replay requests similar to the stolen one. Cookie scoping problems > don't seem to be addressed. >=20 >=20 > Trevor >=20 >=20 > [1] http://seclab.stanford.edu/websec/csrf/csrf.pdf > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR57Q6AAoJEGhJURNOOiAt+mgIAKEm3q1CoSMDkthRkh6IPYWE HNcQcKiyCow0SnWfZ5LytduYoT1zKWIjr5e6L+6DAPIVx1xm3WnNjOhofnle6oHk UFhCG1qFLT3yriyoY24544wboGRIvvpiOoiueAhRPNsxra4bZVTCb0xFttc8QgFH 3jZ6SITAinPuLmU6nNYkuOM0vHBypeSUvnkNcX5HHbyE9b1rMsNNuQB1VOVEuKFA AatH/5k2Gd1rJGmgvgWo7Cxc9g+xnMEeGJVZ/4aSk3lTXQpJt78EIQTPBMLSns6A Hb6uXxhhJCVgpOf2mOwDPa6Zc+y2KSfAz94V1ooRgtmACM03AzQw+vdF0Ze7tHs=3D =3DtuMj -----END PGP SIGNATURE----- From ynir@checkpoint.com Thu Jul 18 07:04:43 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B1411E814F for ; Thu, 18 Jul 2013 07:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 r222TrTAEj3R for ; Thu, 18 Jul 2013 07:04:38 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4058311E814D for ; Thu, 18 Jul 2013 07:04:37 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6IE4ZTC013035; Thu, 18 Jul 2013 17:04:36 +0300 X-CheckPoint: {51E7F5F3-19-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Thu, 18 Jul 2013 17:04:35 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] Cookies: What is to be done? Thread-Index: AQHOg5S+m4hZWMDMaUuAldHP9mK/eplqRgEA Date: Thu, 18 Jul 2013 14:04:34 +0000 Message-ID: <68B579B6-A35B-4CF2-AE12-32F2A2DA745B@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11191a3189ee896d332233b3238149221dcd78e93d Content-Type: text/plain; charset="us-ascii" Content-ID: <71593152E1D17046A15C3D4336600DA3@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Cookies: What is to be done? 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, 18 Jul 2013 14:04:43 -0000 Hi Trevor Excellent summary. I would add one more problem. =20 3) Cookie availability to MitB All requests from the UA to the same server contain the same cookie, and so= are deemed to belong to the same session.=20 So if I'm connected to webmail.example.com in one browser tab, and also loo= king attacks.acme.com in another tab, some script or even some plain HTML c= an cause arbitrary requests to be sent to webmail.example.com, and all thes= e requests are "blessed" by my cookie. I think if cookiev2 was (at least by default) identified by the triplet (so= urce-origin, target-origin, cookie-name) we would get many less opportuniti= es for cross-site attacks.=20 On Jul 18, 2013, at 11:56 AM, Trevor Perrin wrote: > Hi, >=20 > I tried to send this earlier, but I don't think it went through. >=20 > Here's an attempt to summarize the main cookie problems and proposals. >=20 > I'd be interested if anyone sees thing differently. >=20 >=20 > Problems > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1) Bearer token problem: > Cookies are transmitted frequently, and if a transmitted cookie is > somehow stolen, it could be used by an attacker. >=20 > 2a) Cookie scoping (confidentiality): > Cookies set on example.com will typically be sent to all subdomains of > example.com. So the security of example.com can be undermined by > less-secure subdomains. Even HSTS/HPKP/TACK/DANE for example.com > could be undermined if a hacker can take over test.example.com, or a > MITM can invent badguy.example.com, since the browser would hand these > attackers the example.com session cookie. There are partial > mitigations for this, but nothing that could work reliably across all > sites and browsers: >=20 > - Omitting the cookie's "Domain" attribute will cause cookies to be > sent only to "example.com" and not its subdomains (RFC 6265), on all > browsers except IE. IE seems unwilling to change this, presumably > due to legacy web apps. >=20 > - Setting a cookie's "Secure" attribute will require the browser to > only transmit it over SSL/TLS. However, the subdomain may not have the > same HSTS/HPKP/TACK/DANE/etc requirements as its parent. HSTS and > HPKP provide "includeSubdomains" to address this (RFC 6797, 14.4). > However, it's common for example.com to have subdomains that can't > comply with HSTS or HPKP (for example: mobile.example.com doesn't use > SSL; images.example.com is hosted on a CDN; test.example.com has a > self-signed cert, etc). In these cases, "includeSubdomains" can't be > used. >=20 > 2b) Cookie scoping (integrity): > Cookies set on webmail.example.com can be overwritten or deleted by > its subdomains, regardless of the "Secure" or "Domain" attributes. > Also, example.com and its subdomains could set an identically-named > cookie for Domain=3Dexample.com, which will get sent to > webmail.example.com. "Forcing" a cookie on the victim could allow an > attacker to log a victim into the attacker's account. The victim > might then enter credit card numbers or other data, similar to the > "login CSRF" attacks in [1]. >=20 > This is harder to mitigate than 2a, as "Domain" and "Secure" > attributes have no effect, and the scope of hostnames that can affect > a victim hostname is not just the victim's subdomains, but everything > sharing the same TLD+1 domain (*.example.com, in this case). >=20 >=20 > Proposals > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1) Origin Cookies: > http://tools.ietf.org/html/draft-abarth-cake-01 > http://w2spconf.com/2011/papers/session-integrity.pdf >=20 > This adds an "Origin" attribute to cookies. Such cookies are > backwards-compatible with old browsers. New browsers would only > return them to the hostname that set them, via an "Origin-Cookie" > header, thus fixing 2a. To fix 2b, the browser might have to always > send something like "Origin-Cookie-Support: true" as an HTTP header, > so that an Origin Cookie supporting server would know to disregard > old-style cookies that might have been forced on the browser. >=20 > This doesn't fix the "bearer token" aspect of cookies, but it seems a > simple, clean fix to the scoping problems. What happened to this? >=20 >=20 > 2) ChannelID > http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 >=20 > The browser adds an ECDSA public key and signature to every TLS > handshake. The server can implement "Channel-bound cookies" which are > associated with the public key. Such cookies can't be transferred > from one browser to another. >=20 > This solves the "bearer token" aspect of cookies. It also solves a > big part of the scoping problem, since an attacker can't steal usable > cookies, or force her cookies on someone else. However, since the > same ChannelID public key is used for an entire TLD+1, an attacker who > could hack subdomain hosts or perform MITM could still: > - Delete cookies > - Steal a cookie from a user at A.example.com, and force it on the > same user at B.example.com > - Steal a cookie via a subdomain and then force it later on the same > user to "rollback" to an earlier state >=20 > This also modifies the TLS stack, and adds a client-side signature > computation to every TLS session. >=20 >=20 > 3) Session Continuation Protocol > http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-0= 0 >=20 > Instead of cookies, the server can set a symmetric "session key" into > the browser, and specify a range of hostnames to use it for. The > browser will send a nonce, and a MAC over the nonce, for every > connection to those hostnames. >=20 > Since the nonce and MAC, if stolen, would suffice as a bearer token, > this doesn't solve 1. Since the Host-Scope of the session can be > specified arbitrarily, this solves 2a but not 2b. >=20 >=20 > 4) HTTP Session Management > http://tools.ietf.org/html/draft-hallambaker-httpsession-01 >=20 > This is similar to (3), except the MAC can optionally be calculated > over "portions of the HTTP message", and the scoping rules are defined > to be identical to cookies as defined somewhere (not specified). This > might mitigate 1 somewhat, since a MAC, if stolen, could only be used > to replay requests similar to the stolen one. Cookie scoping problems > don't seem to be addressed. >=20 >=20 > Trevor >=20 >=20 > [1] http://seclab.stanford.edu/websec/csrf/csrf.pdf > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Thu Jul 18 16:22:35 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 02BAD21E8143 for ; Thu, 18 Jul 2013 16:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.023 X-Spam-Level: ** X-Spam-Status: No, score=2.023 tagged_above=-999 required=5 tests=[AWL=5.000, 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 NkfNhkm9yo-t for ; Thu, 18 Jul 2013 16:22:18 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4E22C21E8148 for ; Thu, 18 Jul 2013 16:22:14 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so15371wgg.3 for ; Thu, 18 Jul 2013 16:22:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WnsiEXMMh2gQeLwtjl+CwD3vx4N813hJoylNhiy+hU8=; b=NpCh6pGLJpsIqk+GFAUP2XNHVRub5+uZhjGlF+HFEc3wWAJDWTKNV6gVZ+WptqLazs ejV654eJ0i8Rpy5CKcsK4tQpnyTEABGOx4jmQGaSTpqJGx53KhgOPK5sxd8mPg8/ZW1k S3BKyS31AvrUKyXDxw9axav5YMb11eKAxF7AGzf8SS2vcrp4QXq6XmemYU75CvbfdqKC nWdxFrTdaIAIxTsDoCyTvuimZy6SBc3snU2gzKVrlHLKF9RGflJTsLuM2zWgXf8xtf2d hauHfrTCk6UI8mxNscNHPaeNAh2OGEuwRuT/AUWgS2o7+IwiMTbXM3A5SHuXngjKK3TV g5Fw== MIME-Version: 1.0 X-Received: by 10.180.75.41 with SMTP id z9mr9646598wiv.22.1374189733758; Thu, 18 Jul 2013 16:22:13 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Thu, 18 Jul 2013 16:22:13 -0700 (PDT) X-Originating-IP: [173.11.71.218] In-Reply-To: <68B579B6-A35B-4CF2-AE12-32F2A2DA745B@checkpoint.com> References: <68B579B6-A35B-4CF2-AE12-32F2A2DA745B@checkpoint.com> Date: Thu, 18 Jul 2013 16:22:13 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnR5UlJRriQpupfN7Hsd3YcCIsNr5GYMPq8QLn8MFpZDHYkYSTfskv7HrcHgTaEqtamrXrD Cc: IETF WebSec WG Subject: Re: [websec] Cookies: What is to be done? 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, 18 Jul 2013 23:22:35 -0000 On Thu, Jul 18, 2013 at 7:04 AM, Yoav Nir wrote: > > Excellent summary. I would add one more problem. [...] > So if I'm connected to webmail.example.com in one browser tab, and also looking attacks.acme.com in another tab, some script or even some plain HTML can cause arbitrary requests to be sent to webmail.example.com Hi Yoav, So in a word: "CSRF"? > I think if cookiev2 was (at least by default) identified by the triplet (source-origin, target-origin, cookie-name) we would get many less opportunities for cross-site attacks. By "source-origin" you mean the referrer? I'm not sure session-continuation is the right place to address CSRF, since CSRF can happen even without a session (see "Login CSRF" from [1]). That makes me think associating an HTTP request with a "referrer" is orthogonal to the problem of associating a request with a "session". Also, I think good CSRF mitigations exist, so it's not as pressing a problem, whereas cookie scope problems can undo a lot of the benefit of HSTS and pinning. Trevor [1] http://seclab.stanford.edu/websec/csrf/csrf.pdf From ynir@checkpoint.com Thu Jul 18 22:51:50 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 B782F11E8292 for ; Thu, 18 Jul 2013 22:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 pQ08hHlt6FCN for ; Thu, 18 Jul 2013 22:51:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D8BFE11E8282 for ; Thu, 18 Jul 2013 22:51:35 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6J5pQup024478; Fri, 19 Jul 2013 08:51:30 +0300 X-CheckPoint: {51E8D3DE-31-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Fri, 19 Jul 2013 08:51:26 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] Cookies: What is to be done? Thread-Index: AQHOg5S+m4hZWMDMaUuAldHP9mK/eplqRgEAgACbz4CAAGy9gA== Date: Fri, 19 Jul 2013 05:51:26 +0000 Message-ID: <9FF6FF4E-3064-43E6-A199-962C0481BB0A@checkpoint.com> References: <68B579B6-A35B-4CF2-AE12-32F2A2DA745B@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.245] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11b794fcce5ba039b0724ad799fa59c206d627b59d Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7AE81066ABF3984F8D90B5C35585F73B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Cookies: What is to be done? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 05:51:50 -0000 On Jul 19, 2013, at 2:22 AM, Trevor Perrin wrote: > On Thu, Jul 18, 2013 at 7:04 AM, Yoav Nir wrote: >>=20 >> Excellent summary. I would add one more problem. > [...] >> So if I'm connected to webmail.example.com in one browser tab, and also = looking attacks.acme.com in another tab, some script or even some plain HTM= L can cause arbitrary requests to be sent to webmail.example.com >=20 > Hi Yoav, >=20 > So in a word: "CSRF"? Not exactly. I think it's architecturally wrong that the same cookie (or ra= ther, session) is used for all requests from a server. Yes, this facilitate= s CSRF, but it also makes it harder for a website to give you different ser= vices based on where the requests originate. I would have liked to have a d= ifferent session with facebook when I'm directly connected to facebook.com = vs when I'm fetching a "Like" button for the bottom of some article on my f= avorite news site. By tracking referrer-cookie pairs, this allows Facebook = to track what I'm reading, even if I never click any of those "Like" button= s. To solve the different sessions for different referrers, we could just have= the websites treat the referrer-cookie pair as the session identifier, wit= hout any changes to the UA or the protocol, but that would not solve the pr= ivacy issue.=20 OTOH that would make life harder for Facebook. First, tracking is a part of= their business (and any other business that relies on targeted advertising= ), but we'd have to think about how the "Like" buttons could still be made = to work (and whether we care about it) Yoav= From tobias.gondrom@gondrom.org Fri Jul 19 00:46:44 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 129BC11E81FD for ; Fri, 19 Jul 2013 00:46:44 -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 ylqKBzkWNz14 for ; Fri, 19 Jul 2013 00:46:40 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 92A0311E80F5 for ; Fri, 19 Jul 2013 00:46:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=uidmgT22KFPGptdQznJ0Gk9na0crl5fu1kVQo/FvY+IDzLhKy9+N0j4JvG/PMxMPAKDwZN/Wz5GzJuYLBAWlQM3WR5sYd5n147JIw7DF3+2os5o6g6QRPn50evhAzBLk; 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 1163 invoked from network); 19 Jul 2013 09:46:38 +0200 Received: from unknown (HELO ?10.1.2.13?) (111.223.113.6) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Jul 2013 09:46:37 +0200 Message-ID: <51E8EED7.90301@gondrom.org> Date: Fri, 19 Jul 2013 15:46:31 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: websec@ietf.org References: <68B579B6-A35B-4CF2-AE12-32F2A2DA745B@checkpoint.com> <9FF6FF4E-3064-43E6-A199-962C0481BB0A@checkpoint.com> In-Reply-To: <9FF6FF4E-3064-43E6-A199-962C0481BB0A@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] Cookies: What is to be done? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 07:46:44 -0000 On 19/07/13 13:51, Yoav Nir wrote: > On Jul 19, 2013, at 2:22 AM, Trevor Perrin wrote: > >> On Thu, Jul 18, 2013 at 7:04 AM, Yoav Nir wrote: >>> Excellent summary. I would add one more problem. >> [...] >>> So if I'm connected to webmail.example.com in one browser tab, and also looking attacks.acme.com in another tab, some script or even some plain HTML can cause arbitrary requests to be sent to webmail.example.com >> Hi Yoav, >> >> So in a word: "CSRF"? > Not exactly. I think it's architecturally wrong that the same cookie (or rather, session) is used for all requests from a server. Yes, this facilitates CSRF, but it also makes it harder for a website to give you different services based on where the requests originate. I would have liked to have a different session with facebook when I'm directly connected to facebook.com vs when I'm fetching a "Like" button for the bottom of some article on my favorite news site. By tracking referrer-cookie pairs, this allows Facebook to track what I'm reading, even if I never click any of those "Like" buttons. Hm, seems we have two issues here: one is security and one is privacy. For security against CSRF, I think the common solution of the hidden token field is actually doing it's job quite ok. So not sure we need another solution against CSRF. And secondly, I have the feeling that not sending cookies to a domain where they originate from would mean a major paradigm shift and could possibly break a lot of web applications. The second issue of privacy: I would agree that it is potentially bad that you can track user behaviour via displayed images and the cookies without any actions or consent of the user. But not sure we can really fix that. Just my 5 cents, Tobias > To solve the different sessions for different referrers, we could just have the websites treat the referrer-cookie pair as the session identifier, without any changes to the UA or the protocol, but that would not solve the privacy issue. > > OTOH that would make life harder for Facebook. First, tracking is a part of their business (and any other business that relies on targeted advertising), but we'd have to think about how the "Like" buttons could still be made to work (and whether we care about it) > > Yoav > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From hallam@gmail.com Sun Jul 21 18:13: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 0E2FF21F9C08 for ; Sun, 21 Jul 2013 18:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 GChJstLy1Cm3 for ; Sun, 21 Jul 2013 18:13:41 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 39FBB21F9A50 for ; Sun, 21 Jul 2013 18:13:41 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so1328999wiv.5 for ; Sun, 21 Jul 2013 18:13:39 -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=mU3vntZszfjUfap13T9W1kCgw2eGTGwUSmX7UBB36Bs=; b=09ZwI2cE8I39rlKYWdl6monnM32GY2M5Lk3GIZxdpdPPp1hkW+LcSjQufNNixHVETZ ol67cmDd36fpxc7xqkLSQXRLfT0k8TAf318cOsJ1hAUNvuQXgD20wOopG+cIQpy++DsY KZdgMyZhUDV292qt138GNdaHSQCRqkdpZlvNSLZ0GTzeIwgLp/AyxlTPRb1ifI7GV3s6 v4MY4pR84PLBp1PF9VKGsMN+Oa/wcnL4Aw07kFpjtGAEmRq6KbqQXk9zxR/lzxi/Di3L EVrtdIGxFYvCftG4Md5+odaG5xbsVnu4WAiN5wiwPtW17Jh5Kcx9A1oKWrVPB/DCQuG2 6jmQ== MIME-Version: 1.0 X-Received: by 10.180.126.2 with SMTP id mu2mr28107086wib.63.1374455619471; Sun, 21 Jul 2013 18:13:39 -0700 (PDT) Received: by 10.194.6.65 with HTTP; Sun, 21 Jul 2013 18:13:39 -0700 (PDT) In-Reply-To: References: Date: Sun, 21 Jul 2013 21:13:39 -0400 Message-ID: From: Phillip Hallam-Baker To: Trevor Perrin Content-Type: multipart/alternative; boundary=e89a8f642dfcf5525704e20f6273 Cc: IETF WebSec WG Subject: Re: [websec] Cookies: What is to be done? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 01:13:42 -0000 --e89a8f642dfcf5525704e20f6273 Content-Type: text/plain; charset=ISO-8859-1 The reason the Session header mechanism I propose does not address cookie scoping is that there is already a perfectly adequate confidentiality and integrity solution in the hands of the Server: encrypt the cookie contents and append a MAC to the end. The only situation where I see cookie stealing as a problem is where the cookie is a bearer token. Since the client never looks at cookie content there is no good reason not to encrypt if the data is at all confidential. Cookie overwriting is a little more complicated as merely being able to detect overwriting is not the same as being able to prevent a denial of cookie attack. If people think the existing scope mechanism in cookies is insufficient, I am open to extending the Session draft to add an origin cookie type capability. Or we can redefine the cookie handling as well if that is needed to ensure backwards compatibility. On the issue of preventing replay attacks, the session continuation draft I wrote describes two application scenarios. The first being the Web browser scenario, the second being Web Services. The Web service I have developed that uses the draft uses nonces passed in the protocol to prevent replay attacks. Web Services typically require much stronger replay attack prevention than Web Browsing. But this is easier to achieve since some of the checking lives more naturally in the Web Service protocol layer than the HTTP binding. I don't see the need to prevent replay attacks in Web Browsing except in the very special case of forms entry which servers can check themselves by using a nonce passed in a hidden form field. I should probably add a section to the draft explaining the reasoning there. --e89a8f642dfcf5525704e20f6273 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The reason the Session header mechanism I propose does not= address cookie scoping is that there is already a perfectly adequate confi= dentiality and integrity solution in the hands of the Server: encrypt the c= ookie contents and append a MAC to the end.

The only situation where I see cookie stealing as a problem = is where the cookie is a bearer token. Since the client never looks at cook= ie content there is no good reason not to encrypt if the data is at all con= fidential.

Cookie overwriting is a little more complicated as mere= ly being able to detect overwriting is not the same as being able to preven= t a denial of cookie attack.

If people think the e= xisting scope mechanism in cookies is insufficient, I am open to extending = the Session draft to add an origin cookie type capability. Or we can redefi= ne the cookie handling as well if that is needed to ensure backwards compat= ibility.


On the issue of preventing replay attack= s, the session continuation draft I wrote describes two application scenari= os. The first being the Web browser scenario, the second being Web Services= .

The Web service I have developed that uses the draft us= es nonces passed in the protocol to prevent replay attacks. Web Services ty= pically require much stronger replay attack prevention than Web Browsing. B= ut this is easier to achieve since some of the checking lives more naturall= y in the Web Service protocol layer than the HTTP binding.

I don't see the need to prevent replay attacks in W= eb Browsing except in the very special case of forms entry which servers ca= n check themselves by using a nonce passed in a hidden form field. I should= probably add a section to the draft explaining the reasoning there.
--e89a8f642dfcf5525704e20f6273-- From ynir@checkpoint.com Sun Jul 21 20:53:35 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 93BCA21F9EDF for ; Sun, 21 Jul 2013 20:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 vUAy+JwR1I3U for ; Sun, 21 Jul 2013 20:53:27 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 12BC511E80A2 for ; Sun, 21 Jul 2013 20:53:26 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6M3rMqf016367; Mon, 22 Jul 2013 06:53:22 +0300 X-CheckPoint: {51ECACB2-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 22 Jul 2013 06:53:21 +0300 From: Yoav Nir To: Tobias Gondrom Thread-Topic: [websec] Cookies: What is to be done? Thread-Index: AQHOg5S+m4hZWMDMaUuAldHP9mK/eplqRgEAgACbz4CAAGy9gIAAICmAgAR12AA= Date: Mon, 22 Jul 2013 03:53:21 +0000 Message-ID: <4DFB5992-B2A6-4596-B742-FE5435A0FB00@checkpoint.com> References: <68B579B6-A35B-4CF2-AE12-32F2A2DA745B@checkpoint.com> <9FF6FF4E-3064-43E6-A199-962C0481BB0A@checkpoint.com> <51E8EED7.90301@gondrom.org> In-Reply-To: <51E8EED7.90301@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.164] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 114686508b5aa2c16559b0f6f638bda7ceace8c2d4 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] Cookies: What is to be done? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:53:35 -0000 On Jul 19, 2013, at 10:46 AM, Tobias Gondrom w= rote: > On 19/07/13 13:51, Yoav Nir wrote: >> On Jul 19, 2013, at 2:22 AM, Trevor Perrin wrote: >>=20 >>> On Thu, Jul 18, 2013 at 7:04 AM, Yoav Nir wrote: >>>> Excellent summary. I would add one more problem. >>> [...] >>>> So if I'm connected to webmail.example.com in one browser tab, and als= o looking attacks.acme.com in another tab, some script or even some plain H= TML can cause arbitrary requests to be sent to webmail.example.com >>> Hi Yoav, >>>=20 >>> So in a word: "CSRF"? >> Not exactly. I think it's architecturally wrong that the same cookie (or= rather, session) is used for all requests from a server. Yes, this facilit= ates CSRF, but it also makes it harder for a website to give you different = services based on where the requests originate. I would have liked to have = a different session with facebook when I'm directly connected to facebook.c= om vs when I'm fetching a "Like" button for the bottom of some article on m= y favorite news site. By tracking referrer-cookie pairs, this allows Facebo= ok to track what I'm reading, even if I never click any of those "Like" but= tons. >=20 > Hm, seems we have two issues here: one is security and one is privacy. > For security against CSRF, I think the common solution of the hidden > token field is actually doing it's job quite ok. So not sure we need > another solution against CSRF. And secondly, I have the feeling that not > sending cookies to a domain where they originate from would mean a major > paradigm shift and could possibly break a lot of web applications. > The second issue of privacy: I would agree that it is potentially bad > that you can track user behaviour via displayed images and the cookies > without any actions or consent of the user. But not sure we can really > fix that. > Just my 5 cents, Tobias The hidden token field mechanism does its job, but it requires work and som= e inevitably get it wrong. Not necessarily as wrong as that firewall exampl= e ([1]), but still wrong. But I agree, that the more interesting concern is= the privacy issue. To be sure, changing the cookie-handling rules makes it so that the new ses= sion mechanism is not a drop-in replacement to session by cookies, and that= means slow adoption, and that means that the old cookies live forever - yo= u can't disable them. And yes, this is the kind of feature creep that made = us wait 15 years to see any volume of IPv6 adoption. Still, it's something = for the working group to consider. Yoav From ynir@checkpoint.com Sun Jul 21 20:56: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 958F921F9B8C for ; Sun, 21 Jul 2013 20:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 1jbmp7xaMblt for ; Sun, 21 Jul 2013 20:56:50 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EB9FF21F8459 for ; Sun, 21 Jul 2013 20:56:49 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6M3umIH017071 for ; Mon, 22 Jul 2013 06:56:48 +0300 X-CheckPoint: {51ECAD80-18-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 22 Jul 2013 06:56:48 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] Cookies: What is to be done? Thread-Index: AQHOg5S+m4hZWMDMaUuAldHP9mK/eplqRgEAgACbz4CAAGy9gIAAICmAgAR12ACAAAD5gA== Date: Mon, 22 Jul 2013 03:56:48 +0000 Message-ID: <7B737773-8398-453B-AE51-F57F8559B7C9@checkpoint.com> References: <68B579B6-A35B-4CF2-AE12-32F2A2DA745B@checkpoint.com> <9FF6FF4E-3064-43E6-A199-962C0481BB0A@checkpoint.com> <51E8EED7.90301@gondrom.org> <4DFB5992-B2A6-4596-B742-FE5435A0FB00@checkpoint.com> In-Reply-To: <4DFB5992-B2A6-4596-B742-FE5435A0FB00@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.164] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11b9f2890888d62e8dd2f8b70d92fef3b2932cf0ce Content-Type: text/plain; charset="Windows-1252" Content-ID: <828143FA517E6A46810852039ADCF0C8@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Cookies: What is to be done? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:56:54 -0000 Forgot the reference=85 On Jul 19, 2013, at 10:46 AM, Tobias Gondrom w= rote: > On 19/07/13 13:51, Yoav Nir wrote: >> On Jul 19, 2013, at 2:22 AM, Trevor Perrin wrote: >>=20 >>> On Thu, Jul 18, 2013 at 7:04 AM, Yoav Nir wrote: >>>> Excellent summary. I would add one more problem. >>> [...] >>>> So if I'm connected to webmail.example.com in one browser tab, and als= o looking attacks.acme.com in another tab, some script or even some plain H= TML can cause arbitrary requests to be sent to webmail.example.com >>> Hi Yoav, >>>=20 >>> So in a word: "CSRF"? >> Not exactly. I think it's architecturally wrong that the same cookie (or= rather, session) is used for all requests from a server. Yes, this facilit= ates CSRF, but it also makes it harder for a website to give you different = services based on where the requests originate. I would have liked to have = a different session with facebook when I'm directly connected to facebook.c= om vs when I'm fetching a "Like" button for the bottom of some article on m= y favorite news site. By tracking referrer-cookie pairs, this allows Facebo= ok to track what I'm reading, even if I never click any of those "Like" but= tons. >=20 > Hm, seems we have two issues here: one is security and one is privacy. > For security against CSRF, I think the common solution of the hidden > token field is actually doing it's job quite ok. So not sure we need > another solution against CSRF. And secondly, I have the feeling that not > sending cookies to a domain where they originate from would mean a major > paradigm shift and could possibly break a lot of web applications. > The second issue of privacy: I would agree that it is potentially bad > that you can track user behaviour via displayed images and the cookies > without any actions or consent of the user. But not sure we can really > fix that. > Just my 5 cents, Tobias The hidden token field mechanism does its job, but it requires work and som= e inevitably get it wrong. Not necessarily as wrong as that firewall exampl= e ([1]), but still wrong. But I agree, that the more interesting concern is= the privacy issue. To be sure, changing the cookie-handling rules makes it so that the new ses= sion mechanism is not a drop-in replacement to session by cookies, and that= means slow adoption, and that means that the old cookies live forever - yo= u can't disable them. And yes, this is the kind of feature creep that made = us wait 15 years to see any volume of IPv6 adoption. Still, it's something = for the working group to consider. Yoav [1] http://www.ietf.org/mail-archive/web/websec/current/msg01702.html= From trevp@trevp.net Mon Jul 22 00:58: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 21AFF21F9D9A for ; Mon, 22 Jul 2013 00:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 FSfOWolwlGxB for ; Mon, 22 Jul 2013 00:57:52 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7541E21F94DC for ; Mon, 22 Jul 2013 00:55:21 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so1197057wes.9 for ; Mon, 22 Jul 2013 00:53:53 -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=ha1uBfrSV/tPauexhP2MCEjR3tphtA8vjkznfvOtSYA=; b=UUpzM39a3630TRuzqNAnhyFDpuDt18TmZUufvX01iA79EBZh4FP4FjSxF22JID3Wkq Lj9NMwhQCQPZtE0qN3v9IPtRsaLr3S4+JEPpe86N+/oFnX/iSJ/yvVxtM6ehUdhImPDT dLvQrRMHbu1FQgG5b/JDufE9NMLqKg9A/U/oX7eltOTEnDb9oPpLkP8mJ2Q/AqWOtIQo Dp9oiNEbqZeer8aGV8YFCJdCy5Xewz1Mnq5CbiQ/BwzaEoCj3OKYOtAXxxAwBQ3+FyM5 CKZtA16ThMHJ1wzdNR6if6wRh6exCsg9nVu/gsvIzFhXsHZkuJepLY9D7Xyv9mkU3Ewp eWGw== MIME-Version: 1.0 X-Received: by 10.194.24.40 with SMTP id r8mr18403739wjf.7.1374479633590; Mon, 22 Jul 2013 00:53:53 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 22 Jul 2013 00:53:53 -0700 (PDT) X-Originating-IP: [12.178.131.2] In-Reply-To: References: Date: Mon, 22 Jul 2013 00:53:53 -0700 Message-ID: From: Trevor Perrin To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnr3oGFSlX6GJCTqc/W2ht3QavlsS5Be/S8Bj0AZwL+LL8OVxobcs3rQKYS39SraZqDwsJX Cc: IETF WebSec WG Subject: Re: [websec] Cookies: What is to be done? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 07:58:11 -0000 On Sun, Jul 21, 2013 at 6:13 PM, Phillip Hallam-Baker wrote: [...] > Cookie overwriting is a little more complicated as merely being able to > detect overwriting is not the same as being able to prevent a denial of > cookie attack. > > If people think the existing scope mechanism in cookies is insufficient, I > am open to extending the Session draft to add an origin cookie type > capability. Yeah, scoping things to an Origin seems the best way to prevent one domain from being able to force cookies/sessions for another domain. [...] > I don't see the need to prevent replay attacks in Web Browsing except in the > very special case of forms entry which servers can check themselves by using > a nonce passed in a hidden form field. Well, it's possible to prevent a user from being able to replay a different user's requests, as ChannelID shows. In ChannelID, the cookie is bound to the legitimate browser's public key, so can't be replayed by a different browser. This seems better than a mechanism that allows replay. Trevor From trevp@trevp.net Mon Jul 22 01:02: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 B347711E80E0 for ; Mon, 22 Jul 2013 01:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 ChcPB0MgKFaV for ; Mon, 22 Jul 2013 01:02:28 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0913121F826B for ; Mon, 22 Jul 2013 01:02:22 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so1552496wid.16 for ; Mon, 22 Jul 2013 01:02:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Apk3OWduTqhkS2nZw5dnNKFBta7C4pEYHXo0nTyBiJc=; b=XyMXn/qHeRQq+z4Sr5xBmqAh1dmgSC+evaukZQ90BTD+QY+8N3UYTpmr3FTJ7Hdv5E 3mxb77Cn5/IJj4NHPQ8r9jZz+BlTngvukRhPn+wS/MNRA3M5o+RDU+l6qAeREM3wJSaR 9IJtsGM8T/O4xwXj29Ej6hMoY92ZU3E8DC9DJVSUDMwUT7QXwocXnUAH58xFNDyZ9b0s KFbUwPWVe6t/eYMpG5GwHmGpTWLhGGiqA+Vz7YwqrhwBne0IEDfD7YhP/LHgwOhispAL 6+nHeA9StylFi37HiUcu0v+YeKnk7OaKFdfFaOfX5Q9XoghoBjrLRevFThQP99LZ0uhk u1TA== MIME-Version: 1.0 X-Received: by 10.194.83.195 with SMTP id s3mr18973473wjy.82.1374480141382; Mon, 22 Jul 2013 01:02:21 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 22 Jul 2013 01:02:21 -0700 (PDT) X-Originating-IP: [12.178.131.2] Date: Mon, 22 Jul 2013 01:02:21 -0700 Message-ID: From: Trevor Perrin To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk45lHl/c9/Ate8MYay5Ubqm/iqeUA/rH978QqILD2dv71987hXJl6CUMklTwFthJQJzO6r Subject: [websec] Smart Cookies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 08:02:37 -0000 Hi, Here's an attempt to combine the benefits of a couple cookie proposals. I'm curious what people think... "Smart cookies" ============= Rationale ---------- The "Origin Cookie" proposal seems a good solution to cookie scoping. The "ChannelID" proposal seems a good approach to the "bearer token" problem, but requires on-the-wire TLS changes and a client signature for all TLS connections. Smart cookies combine the benefits of both proposals, and don't require TLS changes or client signatures. Smart cookies are bound to the Origin, and cannot be read or written from other Origins. Smart cookies are also cryptographically bound to two TLS connections: 1) The TLS connection on which the server set the cookie 2) The TLS connection on which the client is returning the cookie This binding is done by a cryptographic "MAC" sent from browser to server along with each smart cookie. The "smart" attribute ---------------------- Smart cookies are set the same way as normal cookies, but have an additional "smart" attribute: Set-Cookie: session=123; secure; smart; Smart cookies SHALL only be set from HTTPS connections. The "domain" attribute MUST be omitted, and the "secure" attribute MUST be present. Smart cookies are backwards-compatible. Older browsers ignore the "smart" attribute, and return it as a regular cookie. A smart cookie aware browser does two extra things: (1) The smart cookie is bound to the Origin that set it. The smart cookie is only returned to that Origin. The smart cookie can only be overwritten by that Origin. If a smart cookie is being returned, any cookies with the same name stored in parent domains are ignored. (2) When returning a smart cookie, the browser returns an associated MAC, e.g. Cookie: session=123 Smart-Cookie-MAC: session=lMVoh17EQNE1Rd6nT+hh6A== MAC calculation ---------------- The MAC is calculated as follows: - cookie_str: HTTP Request line for cookie ("Cookie: session=123") - cookie_key: 32 byte secret key derived from the TLS master secret for the connection on which the server sent the cookie. - cookie_binding: 32 byte value derived from the TLS master secret for the connection on which the client is returning the cookie. (The key and binding values are derived using RFC 5705 with labels "smart_cookie_key" and "smart_cookie_binding".) MAC = HMAC-SHA256(cookie_key, cookie_binding || cookie_str)[0:16] Key handling ------------- The browser can easily calculate the key and binding values for every TLS connection. For every smart cookie the browser receives in a TLS connection, the browser stores the connection's cookie_key with the cookie. For every smart cookie returned to the server in a TLS connection, the browser uses the cookie's key along with the connection's binding value to calculate the MAC. The cookie_key values are secrets which the browser MUST never send over the network, or make accessible to javascript. Advertising support -------------------- Browsers MUST advertise support for smart cookies in every HTTP Request with "Smart-Cookies: true". This lets the website allow legacy clients to use old cookies, while requiring smart cookies for capable clients so they are protected from cookie forcing. Misc ----- * A website can have stateless smart cookies by including the cookie_key in the cookie, and encrypting the cookie to itself. On receiving such a cookie, the website will decrypt it, then check its MAC. * A website could ignore the MAC values, and just use smart cookies for their origin-binding properties. * An attacker who somehow observes a transmitted smart cookie and MAC can't replay it on a different TLS connection (as it's tied to its connection's binding value), and can't calculate the MAC for a different connection without the cookie_key. Trevor From tobias.gondrom@gondrom.org Mon Jul 22 02:09:47 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30E711E8107 for ; Mon, 22 Jul 2013 02:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, 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 myGAKlGTTblw for ; Mon, 22 Jul 2013 02:09:40 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id DF29721E80B3 for ; Mon, 22 Jul 2013 01:57:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=BI+Fymcp+Qbb09j3mHVPGmr1rTLEXLIWvCBCEMVGfQDKqIFnCXHtzlp91EI9hkvBBaSUPlC4K9ZMLHU4ZF444nSu+vH5cRk68xQMbrqI5bfWKBZvgMRQ/ojaCYIh00Fw; 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 13773 invoked from network); 22 Jul 2013 10:55:18 +0200 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.27.103?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Jul 2013 10:55:18 +0200 Message-ID: <51ECF36D.4010902@gondrom.org> Date: Mon, 22 Jul 2013 16:55:09 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: trevp@trevp.net References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Smart Cookies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 09:09:47 -0000 Hi Trevor, interesting. But am not totally sure, I understand what specific threat you want to protect against with the smart cookie? - CSRF? Don't see how this would exactly help here? - MitM? IMHO, today people who put a MitM of a SSL communication to steal the cookie and abuse it, are using either SSL Stripping, SSL downgrading or actualyl have a fake certificate impersonating the server and then open a second line with the right cert to the server. So also not sure how this would help here? Maybe you could explain a little the specific risk/attack scenario that you want to protect against? Best regards, Tobias On 22/07/13 16:02, Trevor Perrin wrote: > Hi, > > Here's an attempt to combine the benefits of a couple cookie > proposals. I'm curious what people think... > > > "Smart cookies" > ============= > > Rationale > ---------- > The "Origin Cookie" proposal seems a good solution to cookie scoping. > The "ChannelID" proposal seems a good approach to the "bearer token" > problem, but requires on-the-wire TLS changes and a client signature > for all TLS connections. > > Smart cookies combine the benefits of both proposals, and don't > require TLS changes or client signatures. > > Smart cookies are bound to the Origin, and cannot be read or written > from other Origins. Smart cookies are also cryptographically bound to > two TLS connections: > 1) The TLS connection on which the server set the cookie > 2) The TLS connection on which the client is returning the cookie > > This binding is done by a cryptographic "MAC" sent from browser to > server along with each smart cookie. > > > The "smart" attribute > ---------------------- > Smart cookies are set the same way as normal cookies, but have an > additional "smart" attribute: > > Set-Cookie: session=123; secure; smart; > > Smart cookies SHALL only be set from HTTPS connections. The "domain" > attribute MUST be omitted, and the "secure" attribute MUST be present. > > Smart cookies are backwards-compatible. Older browsers ignore the > "smart" attribute, and return it as a regular cookie. A smart cookie > aware browser does two extra things: > > (1) The smart cookie is bound to the Origin that set it. The smart > cookie is only returned to that Origin. The smart cookie can only be > overwritten by that Origin. If a smart cookie is being returned, any > cookies with the same name stored in parent domains are ignored. > > (2) When returning a smart cookie, the browser returns an associated MAC, e.g. > > Cookie: session=123 > Smart-Cookie-MAC: session=lMVoh17EQNE1Rd6nT+hh6A== > > > MAC calculation > ---------------- > The MAC is calculated as follows: > > - cookie_str: HTTP Request line for cookie ("Cookie: session=123") > - cookie_key: 32 byte secret key derived from the TLS master secret > for the connection on which the server sent the cookie. > - cookie_binding: 32 byte value derived from the TLS master secret > for the connection on which the client is returning the cookie. > > (The key and binding values are derived using RFC 5705 with labels > "smart_cookie_key" and "smart_cookie_binding".) > > MAC = HMAC-SHA256(cookie_key, cookie_binding || cookie_str)[0:16] > > > Key handling > ------------- > The browser can easily calculate the key and binding values for every > TLS connection. For every smart cookie the browser receives in a TLS > connection, the browser stores the connection's cookie_key with the > cookie. For every smart cookie returned to the server in a TLS > connection, the browser uses the cookie's key along with the > connection's binding value to calculate the MAC. > > The cookie_key values are secrets which the browser MUST never send > over the network, or make accessible to javascript. > > > Advertising support > -------------------- > Browsers MUST advertise support for smart cookies in every HTTP > Request with "Smart-Cookies: true". This lets the website allow > legacy clients to use old cookies, while requiring smart cookies for > capable clients so they are protected from cookie forcing. > > > Misc > ----- > * A website can have stateless smart cookies by including the > cookie_key in the cookie, and encrypting the cookie to itself. On > receiving such a cookie, the website will decrypt it, then check its > MAC. > * A website could ignore the MAC values, and just use smart cookies > for their origin-binding properties. > * An attacker who somehow observes a transmitted smart cookie and MAC > can't replay it on a different TLS connection (as it's tied to its > connection's binding value), and can't calculate the MAC for a > different connection without the cookie_key. > > > Trevor > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Mon Jul 22 10:14: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 ECE1B21F8425 for ; Mon, 22 Jul 2013 10:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[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 eBz4zNaGX3XC for ; Mon, 22 Jul 2013 10:14:05 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6E52321F8526 for ; Mon, 22 Jul 2013 10:13:16 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so6280626wgh.30 for ; Mon, 22 Jul 2013 10:13:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zDJjhY+YnYrEqVybk0B8YGT+8F6+AbVRIPkIkEoJvUk=; b=d76bOg4veb5y4B29OX5yTTPjDIw7pIhwV1yTeAXiEL2QLpYOvLuTMEd95mXaLnmzkf wPUdO/pFc+xQUIzO5SxYTIRL0saElOfEADVsukxiNT9YbEcvTEx2hmfModK68JvkesVI boo+9jTZnwYIgApwCLXvb26uYVAgX0GuoEUl/yaHMh3cChCNjkIIdBUNAOeqVnNyat8u 9VSkTypA1LdFO6zRJAr7JFAumGjA2VsHiOebYNxviBkP7s+FdzZi/x9v76/zYIar3nSu RHKv9EM+TWHQtmfwdGFpLVGpr/TZVkMeMrHiFA6OQ7IWCUB+1Av1cP/iZA+yzZZXxg+L TmFA== MIME-Version: 1.0 X-Received: by 10.194.93.74 with SMTP id cs10mr20817609wjb.9.1374513195483; Mon, 22 Jul 2013 10:13:15 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 22 Jul 2013 10:13:15 -0700 (PDT) X-Originating-IP: [208.184.35.186] In-Reply-To: <51ECF36D.4010902@gondrom.org> References: <51ECF36D.4010902@gondrom.org> Date: Mon, 22 Jul 2013 10:13:15 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkQWswYaPiqt4458hF6jd007oIPgl0nFc9pUyzXml5WAFqfoQ/G66h6r+bmCWr1dH1Pe1aq Cc: IETF WebSec WG Subject: Re: [websec] Smart Cookies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:14:12 -0000 On Mon, Jul 22, 2013 at 1:55 AM, Tobias Gondrom wrote: > Hi Trevor, > > > > interesting. > But am not totally sure, I understand what specific threat you want to > protect against with the smart cookie? > - CSRF? The threats mentioned here: http://www.ietf.org/mail-archive/web/websec/current/msg01719.html Not CSRF. The "bearer token" issue is solved because an intercepted smart cookie can't be used in a different TLS connection (the MAC will fail). The "cookie scoping" issues are solved because smart cookies for an Origin can only be read / written by that Origin. > Don't see how this would exactly help here? > > - MitM? > IMHO, today people who put a MitM of a SSL communication to steal the > cookie and abuse it, are using either SSL Stripping, SSL downgrading or > actualyl have a fake certificate impersonating the server and then open > a second line with the right cert to the server. So also not sure how > this would help here? It would prevent that because the transmitted cookie from the legitimate browser is bound to that browser's TLS connection, via a MAC. So the MITM can't reuse the cookie. Trevor From jbonneau@gmail.com Mon Jul 22 10:21:02 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 E528911E80D9 for ; Mon, 22 Jul 2013 10:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 5eB3jznnEcLh for ; Mon, 22 Jul 2013 10:21:01 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 614C111E80E7 for ; Mon, 22 Jul 2013 10:20:55 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id id13so1482693vcb.38 for ; Mon, 22 Jul 2013 10:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KzFK4lN48fcUQDurQlxxfEtugQtST/IIZf5DUl12Daw=; b=ivK7lPG4iT0Z8FiCKbOdFkOmbkRRD6sVNpL388rpK+vzfVcl/TNi6oTDoI4dhRaLv9 qcVwDGs0uOevwxfpv1fnNNQ3ey3pygVY0lCXUSdZ9UUf0zh78+OWiwuGTYeBgBRvCUB7 yZV+Vl5MgSAZJJ+7C1X+ps7c0BX2aiZy4O7hDWK2Qvwh3+vqzB33XwvNTeSGA+hnqEOd d49JYzVD8U/iM/hhTOGmbLIYxYU0CufRFpvHvAcW+2NWpznsVs/as/kHaqKi9tA5dxe4 VcvrYid6PpptwP8z4pM97BL7VoPhRj4o7h61lTxW+0O161qpVCFnCJ+DfIqKOoxprufX XG5Q== X-Received: by 10.52.95.113 with SMTP id dj17mr8174266vdb.82.1374513654785; Mon, 22 Jul 2013 10:20:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.103.69 with HTTP; Mon, 22 Jul 2013 10:20:33 -0700 (PDT) In-Reply-To: References: <51ECF36D.4010902@gondrom.org> From: Joseph Bonneau Date: Mon, 22 Jul 2013 13:20:33 -0400 Message-ID: To: Trevor Perrin Content-Type: multipart/alternative; boundary=20cf3071c81e21ec9a04e21ce6de Cc: IETF WebSec WG Subject: Re: [websec] Smart Cookies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:21:02 -0000 --20cf3071c81e21ec9a04e21ce6de Content-Type: text/plain; charset=UTF-8 > It would prevent that because the transmitted cookie from the > legitimate browser is bound to that browser's TLS connection, via a > MAC. So the MITM can't reuse the cookie. Perhaps like Tobias I'm not seeing how this is enforced. You mention in your proposal that "The browser can easily calculate the key and binding values for every TLS connection" indicating that an attacker who steals the cookie value "session=123" could simply start a new TLS connection and send "session=123", computing a new MAC based on the new TLS connection details and this would appear legitimate to the server. What prevents this, which seems like an attack the system is designed to guard against? Joe --20cf3071c81e21ec9a04e21ce6de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would prev= ent that because the transmitted cookie from the
legitimate browser is bound to that browser's TLS connection, via a
MAC. =C2=A0So the MITM can't reuse the cookie.

Perhaps like Tobias I'm not seeing how this is enforced. You me= ntion in your proposal that "Th= e browser can easily calculate the key and binding values for every=C2=A0TLS connection" indicating= that an attacker who steals the cookie value "session=3D123" cou= ld simply start a new TLS connection and send=C2=A0"session=3D123", computing a ne= w MAC based on the new TLS connection details and this would appear legitim= ate to the server.

What prevents t= his, which seems like an attack the system is designed to guard against?

Joe
--20cf3071c81e21ec9a04e21ce6de-- From trevp@trevp.net Mon Jul 22 10:27: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 9A56E11E80EF for ; Mon, 22 Jul 2013 10:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[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 KvDrVzXVripq for ; Mon, 22 Jul 2013 10:27:46 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 811E211E80D9 for ; Mon, 22 Jul 2013 10:27:46 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so2184342wib.6 for ; Mon, 22 Jul 2013 10:27:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=r5cma1O9HOLiV3Oe1qIwH0A8EAJiyuVAO97iKznEXI8=; b=E6MAy93TR1QOv3Kl2gkcvbtHJNKa/jpOxW7gChZrp5XJOCC/8Tw1AutRJ/+1lNY/kN IXIvlIp3Em2R1C7xuKwEMJ2sEdAWLVUqIW11NJuYio6r36tJHAIENAm7xLcVvnVhuOW7 ohfFa2KXSQ6mQJV/zUScWcAPsfybRkCIglAgq5l1An7Bm5EjxeRAOYLtoOB6oAi4ZVjY NkFVMxosCPNHdTtBMNwOrfQo6zXqRmTB7GYJ5qTfNwA8lzEJbMfYBiHxz/7Vz93FnJe7 +0FiWCgJ97OrAsyjuVU022+F17rFuaeLnSYLioCR55Iq8Di7gxlaRs8Niuc/ar6FT7UP u/kg== MIME-Version: 1.0 X-Received: by 10.180.211.171 with SMTP id nd11mr19195057wic.17.1374514065644; Mon, 22 Jul 2013 10:27:45 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 22 Jul 2013 10:27:45 -0700 (PDT) X-Originating-IP: [208.184.35.186] In-Reply-To: References: <51ECF36D.4010902@gondrom.org> Date: Mon, 22 Jul 2013 10:27:45 -0700 Message-ID: From: Trevor Perrin To: Joseph Bonneau Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk7qg30zEWq0asWUzzgm3EYU3vrqncP5BeJPX9yWdP9oUc0mYX4fD7QZgQ7xcElUAfy4aA5 Cc: IETF WebSec WG Subject: Re: [websec] Smart Cookies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:27:52 -0000 On Mon, Jul 22, 2013 at 10:20 AM, Joseph Bonneau wrote: > >> It would prevent that because the transmitted cookie from the >> legitimate browser is bound to that browser's TLS connection, via a >> MAC. So the MITM can't reuse the cookie. > > > Perhaps like Tobias I'm not seeing how this is enforced. You mention in your > proposal that "The browser can easily calculate the key and binding values > for every TLS connection" indicating that an attacker who steals the cookie > value "session=123" could simply start a new TLS connection and send > "session=123", computing a new MAC based on the new TLS connection details > and this would appear legitimate to the server. > > What prevents this, which seems like an attack the system is designed to > guard against? The "cookie_key", which is derived from the original TLS connection where the server sent the cookie. This key is never transmitted, so it won't be known to a MITM attacker. Trevor From jbonneau@gmail.com Mon Jul 22 10:49: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 ED16511E8141 for ; Mon, 22 Jul 2013 10:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Hcy7tOPkHIdC for ; Mon, 22 Jul 2013 10:49:03 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 510FE11E813F for ; Mon, 22 Jul 2013 10:49:03 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id da11so5321693veb.34 for ; Mon, 22 Jul 2013 10:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aKItUHQjXtPoLuiBjtYa357zTShNAwhsnyZJ1+Wgmp0=; b=Fok25fMZ2pu7W3+GWxsvXERXyDYhIUWYHWCvZRkeCVYSv+cCCbcpcxJnccjMT2dkea Oa4cBMJ6ES/PXVhcxpgc4dIUe5hk8X4yJJ7xbi9dYV2QmOJhx9sBmorGRmvmFuf0BiJy gJbjINBcUatDKDl0XgadgZvHs5X7c4QJC4ir9HfJh7r9lTvVQHm4MNTUozX1hxEbsmml UZgWplyHXZ23+IJRmI/CddA6ltsWDXPffclExoQ2dt1lxP8wCt88qQXpwOw+Fr4m4REy taQOi9gcoshusCJ1vWRQ6Az2bG1kujKzEEqzWBBlObbOioPPW4njFHIrZZV4YpdkOlu1 +mFA== X-Received: by 10.58.119.233 with SMTP id kx9mr9807445veb.3.1374515341685; Mon, 22 Jul 2013 10:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.103.69 with HTTP; Mon, 22 Jul 2013 10:48:41 -0700 (PDT) In-Reply-To: References: <51ECF36D.4010902@gondrom.org> From: Joseph Bonneau Date: Mon, 22 Jul 2013 13:48:41 -0400 Message-ID: To: Trevor Perrin Content-Type: multipart/alternative; boundary=001a11c391beadfb0b04e21d4a0e Cc: IETF WebSec WG Subject: Re: [websec] Smart Cookies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:49:04 -0000 --001a11c391beadfb0b04e21d4a0e Content-Type: text/plain; charset=UTF-8 On Mon, Jul 22, 2013 at 1:27 PM, Trevor Perrin wrote: > On Mon, Jul 22, 2013 at 10:20 AM, Joseph Bonneau > wrote: > > > >> It would prevent that because the transmitted cookie from the > >> legitimate browser is bound to that browser's TLS connection, via a > >> MAC. So the MITM can't reuse the cookie. > > > What prevents this, which seems like an attack the system is designed to > > guard against? > > The "cookie_key", which is derived from the original TLS connection > where the server sent the cookie. > > This key is never transmitted, so it won't be known to a MITM attacker. Thanks, this makes more sense now. This seems to means the server either needs to store (and verify) the correct cookie_key for every connection it has ever sent a cookie on, or use the "stateless" variant you mentioned. I think simplifying the proposal and only having the "stateless" variant makes more sense-really this is just assuming the server has a long-lived cookie-minting secret, which is also assumed in ChannelID and other proposals. The difference here is that instead of binding to an Origin-bound certificate to lock to a particular client, you're binding to the original TLS master secret on which the cookie was set. Makes sense to me now but I think this could be spelled out much more clearly. > > > Trevor > --001a11c391beadfb0b04e21d4a0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 22, 2013 at 1:27 PM, Trevor Perr= in <trevp@trevp.net> wrote:
On Mon, Jul 22, 2013 at 10:20 AM, J= oseph Bonneau <jbonneau@gmail.com<= /a>> wrote:
>
>> It would prevent that because the transmitted cookie from the
>> legitimate browser is bound to that browser's TLS connection, = via a
>> MAC. =C2=A0So the MITM can't reuse the cookie.

> What prevents this, which seems like an attack the system is designed = to
> guard against?

The "cookie_key", which is derived from the original = TLS connection
where the server sent the cookie.

This key is never transmitted, so it won't be known to a MITM attacker.=

=C2=A0


Trevor

--001a11c391beadfb0b04e21d4a0e-- From trevp@trevp.net Mon Jul 22 11:49: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 F1A9121F95EF for ; Mon, 22 Jul 2013 11:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=1.299, 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 CJDiCTKsqvcg for ; Mon, 22 Jul 2013 11:49:44 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 017A221F94DC for ; Mon, 22 Jul 2013 11:49:43 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so860791wgh.7 for ; Mon, 22 Jul 2013 11:49:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=AnkzGmf8ZSqVwTEY8fKvyJ/7jiYCxxY08ZuJIQ1jY7E=; b=EewIibxXk8RB2di2N/ovP29+FAm/nMesCTSKdm/RXsxinFs5t5sLCggaUGuUuFnEP9 hXmMnrI/xBQVKTyV8IChYQJ6Sz7FL/GrbDLQNClvaYsHOLywZ+Uh7X4/liou+l2IF1Q3 mQbtUPqW7f5wby6hjNivzNrsE+qUDwKjlXWxMXVb6KrNqwJ11olA3bZU7G9ZqB0wvpZr 39Jp3/hcTI1TgUYoXeGIwIXuht4aFQqWRHwhsxm3KTbLLqZgHhlyHSSvjU6DskY0C2Ec GhJUiXT6ATx9VgxTZz7jTLVTmAn5i9D4nFmd/G6+xBZPjN3kKyGefWmqyY2OcJXSQwts l26Q== MIME-Version: 1.0 X-Received: by 10.194.24.40 with SMTP id r8mr20272992wjf.7.1374518983006; Mon, 22 Jul 2013 11:49:43 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 22 Jul 2013 11:49:42 -0700 (PDT) X-Originating-IP: [208.184.35.186] In-Reply-To: References: <51ECF36D.4010902@gondrom.org> Date: Mon, 22 Jul 2013 11:49:42 -0700 Message-ID: From: Trevor Perrin To: Joseph Bonneau Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlRAc0/V4CIz14aJ1oU8y130SK9Tit7VHzxMGsQh5t5bHCTxEPLpaHEtcQkCsfbcFdwi3Qe Cc: IETF WebSec WG Subject: Re: [websec] Smart Cookies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:49:49 -0000 On Mon, Jul 22, 2013 at 10:48 AM, Joseph Bonneau wrote: > > On Mon, Jul 22, 2013 at 1:27 PM, Trevor Perrin wrote: >> >> On Mon, Jul 22, 2013 at 10:20 AM, Joseph Bonneau [...] > Thanks, this makes more sense now. This seems to means the server either > needs to store (and verify) the correct cookie_key for every connection it > has ever sent a cookie on, or use the "stateless" variant you mentioned. The server can store the cookie_key with the user's session state - either in a database, or in an encrypted cookie for stateless operation. The server can also ignore the cookie_key and MAC, and then these are just "Origin cookies". > I > think simplifying the proposal and only having the "stateless" variant makes > more sense Whether to be stateful or stateless is up to the server. I'm not sure what simplification you're proposing? > -really this is just assuming the server has a long-lived > cookie-minting secret, which is also assumed in ChannelID and other > proposals. The difference here is that instead of binding to an Origin-bound > certificate to lock to a particular client, you're binding to the original > TLS master secret on which the cookie was set. That's one difference. The other difference is that these cookies have Origin scope, so they protect against "cookie scoping" integrity attacks that ChannelID does not: http://www.ietf.org/mail-archive/web/websec/current/msg01719.html Trevor From tobias.gondrom@gondrom.org Mon Jul 22 20:27: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 924E411E81D6 for ; Mon, 22 Jul 2013 20:27:56 -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 7ZuRRlsCTMBw for ; Mon, 22 Jul 2013 20:27: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 C414821F8895 for ; Mon, 22 Jul 2013 20:27:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=toCT6uhvzwsfXsDkCyBZN1d+v8eT5IpKM8B5b32EDh7Mf0itFNgetQcPNdVcyoUun7HejaTMa8BS7X1DzQZ1TBWMnSIDFiY7CbJQ78ASVlsQPT99CsKxIMhu+WneerY3; 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 28323 invoked from network); 23 Jul 2013 05:27:48 +0200 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.27.103?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Jul 2013 05:27:47 +0200 Message-ID: <51EDF82F.9080503@gondrom.org> Date: Tue, 23 Jul 2013 11:27:43 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: trevp@trevp.net References: <51ECF36D.4010902@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Smart Cookies 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, 23 Jul 2013 03:27:56 -0000 Ok. Thanks for the explanation. I can see how this could help data leakage against sub-domains. As far as I understand the best solution would be HSTS incl subdomains plus "secure" cookie. But if that is not feasible for some subdomains for some reason, the smart cookie would allow to compensate? Best regards, Tobias On 23/07/13 02:49, Trevor Perrin wrote: > On Mon, Jul 22, 2013 at 10:48 AM, Joseph Bonneau wrote: >> On Mon, Jul 22, 2013 at 1:27 PM, Trevor Perrin wrote: >>> On Mon, Jul 22, 2013 at 10:20 AM, Joseph Bonneau > [...] >> Thanks, this makes more sense now. This seems to means the server either >> needs to store (and verify) the correct cookie_key for every connection it >> has ever sent a cookie on, or use the "stateless" variant you mentioned. > The server can store the cookie_key with the user's session state - > either in a database, or in an encrypted cookie for stateless > operation. > > The server can also ignore the cookie_key and MAC, and then these are > just "Origin cookies". > >> I >> think simplifying the proposal and only having the "stateless" variant makes >> more sense > Whether to be stateful or stateless is up to the server. I'm not sure > what simplification you're proposing? > > >> -really this is just assuming the server has a long-lived >> cookie-minting secret, which is also assumed in ChannelID and other >> proposals. The difference here is that instead of binding to an Origin-bound >> certificate to lock to a particular client, you're binding to the original >> TLS master secret on which the cookie was set. > That's one difference. The other difference is that these cookies > have Origin scope, so they protect against "cookie scoping" integrity > attacks that ChannelID does not: > > http://www.ietf.org/mail-archive/web/websec/current/msg01719.html > > > Trevor From trevp@trevp.net Mon Jul 22 22:37: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 323B411E8140 for ; Mon, 22 Jul 2013 22:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 UEtDQCxS3WWS for ; Mon, 22 Jul 2013 22:36:56 -0700 (PDT) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id E307811E8138 for ; Mon, 22 Jul 2013 22:36:55 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x17so5226172vbf.10 for ; Mon, 22 Jul 2013 22:36:53 -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=9cpH0U9Qi4IGs5nS609OlmM6J+XsZagbcZqRwbygGoE=; b=H6iQxthml2I/vU8AqZQPZaA9yUX1xlOr+RQH/iHURayxDy/HzdhF7OiRdBwHXlINmV dN1zuOpawvcGSkHriDEtqGSB4i65kTNxMY6a7/I2MLZrJXs/mlgVGdc8juTUkG6YZdHb TYREjNSkn40EiSI3ebDFq+Ry8epdmMrG0NoyPg/JNlCsLYy+PJ2KLTh1KRRu4koCDpw4 RLfQ67sjdfjwdrtMdirdVDap5FD21d66SGW/j8rSE9rgibUf2GMpO3pmbUeowWDudhRS vVCUB7NxVoKPlA3VUgvTzc3ZTp8b0o5NK0BPctr/G8RBYz3jT3CjqQFCCqyxd9bYADy+ l9lA== MIME-Version: 1.0 X-Received: by 10.52.188.73 with SMTP id fy9mr8989365vdc.53.1374557812678; Mon, 22 Jul 2013 22:36:52 -0700 (PDT) Received: by 10.220.216.2 with HTTP; Mon, 22 Jul 2013 22:36:52 -0700 (PDT) X-Originating-IP: [12.178.131.2] In-Reply-To: <51EDF82F.9080503@gondrom.org> References: <51ECF36D.4010902@gondrom.org> <51EDF82F.9080503@gondrom.org> Date: Mon, 22 Jul 2013 22:36:52 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkId3nOLhDYlH+1A96K71MkcB9bjHGQPzW+0USWIU2jnI/TARIujSARDBYwEbiNb7zdR5Ol Cc: IETF WebSec WG Subject: Re: [websec] Smart Cookies 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, 23 Jul 2013 05:37:00 -0000 On Mon, Jul 22, 2013 at 8:27 PM, Tobias Gondrom wrote: > Ok. Thanks for the explanation. I can see how this could help data > leakage against sub-domains. > > As far as I understand the best solution would be HSTS incl subdomains > plus "secure" cookie. But if that is not feasible for some subdomains > for some reason, the smart cookie would allow to compensate? "includeSubdomains" is often infeasible. As a data point: Chrome has preloaded HSTS for ~180 non-Google hostnames, but only ~100 use "includeSubdomains" [1]. With key pinning, "includeSubdomains" will probably be used even less, since subdomains and parent domains are likely to have different keys, and even different CAs (hosting a subdomain on a CDN, for example). And even if HSTS includeSubdomains and "secure" cookies are used, they don't stop cookie forcing (an attacker logs you in to her session). And they don't make stolen cookies unusable (like ChannelID's channel-bound cookies, or smart cookies). -- I think the best easy solution is probably just "Origin Cookies" [2]. This solves all the cookie-scoping problems, and brings cookies in line with the "same-origin policy". If we had that, then cookies would not be stealable unless there was some TLS flaw, or some failure in cookie handling. Adding channel-bound cookies or smart cookies gives the additional assurance that stolen cookies would be unusable, but that's more of a "defense-in-depth" approach. Anyways. Are "Origin Cookies" in scope for this WG? Trevor [1] http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json [2] http://w2spconf.com/2011/papers/session-integrity.pdf http://tools.ietf.org/html/draft-abarth-cake-01 From hallam@gmail.com Tue Jul 23 15:18: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 A369C11E8164 for ; Tue, 23 Jul 2013 15:18: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 eTY5yp+M4OQP for ; Tue, 23 Jul 2013 15:18:37 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3411E815B for ; Tue, 23 Jul 2013 15:18:19 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id j13so2286000wgh.3 for ; Tue, 23 Jul 2013 15:18:18 -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=6yWnX+rg6nzSOV7IXH/x3h7CybzSkkNqxHUpAi3Qo2Q=; b=0xXtfIUihcfGx5UKarRGNa0zLSDRpJd0uLorOdk8d3nat4eR3WiXQ4cTIuU9FdCYbk ktUTkZRI9SigfZrQf34Dxm+wHdtza9ilHzqVOG3z3+UVVAyi5InZoFO4i7MI9tHGFUJR /uqxYL+UoardaejLzWcmGHCoRIB1SFPDpa5t97fQnkILt8KehxgKUx9ySATjAQ5G8Rpu 0VKZsPo+5pJD3SUiSe9c+VFubjuQ+LLh8/xDj2yIzoeiX5z1vgJ/6hV5T6kRlMwQKD18 jibS4GJdEOWq6iGjMTCuSP5B9y5e4rDH+Z/WQxt9X89kbIkAfk3D1oyW4ii7PnR7Agen KSZA== MIME-Version: 1.0 X-Received: by 10.194.81.39 with SMTP id w7mr3085356wjx.51.1374617898873; Tue, 23 Jul 2013 15:18:18 -0700 (PDT) Received: by 10.194.6.65 with HTTP; Tue, 23 Jul 2013 15:18:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jul 2013 18:18:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Trevor Perrin Content-Type: multipart/alternative; boundary=047d7bb70e12907c1304e2352b0e Cc: IETF WebSec WG Subject: Re: [websec] Smart Cookies 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, 23 Jul 2013 22:18:38 -0000 --047d7bb70e12907c1304e2352b0e Content-Type: text/plain; charset=ISO-8859-1 I guess I could replace the 'Set-Session' mechanism that I set out in my session continuation draft with a scheme that encodes the same information as Set-Cookie attributes. That would then mean that a browser that knows how to do Macs on the session cookie can do so and those that don't will simply send the cookie back and forth as per usual. It has nice backwards compatibility properties. On Mon, Jul 22, 2013 at 4:02 AM, Trevor Perrin wrote: > Hi, > > Here's an attempt to combine the benefits of a couple cookie > proposals. I'm curious what people think... > > > "Smart cookies" > ============= > > Rationale > ---------- > The "Origin Cookie" proposal seems a good solution to cookie scoping. > The "ChannelID" proposal seems a good approach to the "bearer token" > problem, but requires on-the-wire TLS changes and a client signature > for all TLS connections. > > Smart cookies combine the benefits of both proposals, and don't > require TLS changes or client signatures. > > Smart cookies are bound to the Origin, and cannot be read or written > from other Origins. Smart cookies are also cryptographically bound to > two TLS connections: > 1) The TLS connection on which the server set the cookie > 2) The TLS connection on which the client is returning the cookie > > This binding is done by a cryptographic "MAC" sent from browser to > server along with each smart cookie. > > > The "smart" attribute > ---------------------- > Smart cookies are set the same way as normal cookies, but have an > additional "smart" attribute: > > Set-Cookie: session=123; secure; smart; > > Smart cookies SHALL only be set from HTTPS connections. The "domain" > attribute MUST be omitted, and the "secure" attribute MUST be present. > > Smart cookies are backwards-compatible. Older browsers ignore the > "smart" attribute, and return it as a regular cookie. A smart cookie > aware browser does two extra things: > > (1) The smart cookie is bound to the Origin that set it. The smart > cookie is only returned to that Origin. The smart cookie can only be > overwritten by that Origin. If a smart cookie is being returned, any > cookies with the same name stored in parent domains are ignored. > > (2) When returning a smart cookie, the browser returns an associated MAC, > e.g. > > Cookie: session=123 > Smart-Cookie-MAC: session=lMVoh17EQNE1Rd6nT+hh6A== > > > MAC calculation > ---------------- > The MAC is calculated as follows: > > - cookie_str: HTTP Request line for cookie ("Cookie: session=123") > - cookie_key: 32 byte secret key derived from the TLS master secret > for the connection on which the server sent the cookie. > - cookie_binding: 32 byte value derived from the TLS master secret > for the connection on which the client is returning the cookie. > > (The key and binding values are derived using RFC 5705 with labels > "smart_cookie_key" and "smart_cookie_binding".) > > MAC = HMAC-SHA256(cookie_key, cookie_binding || cookie_str)[0:16] > > > Key handling > ------------- > The browser can easily calculate the key and binding values for every > TLS connection. For every smart cookie the browser receives in a TLS > connection, the browser stores the connection's cookie_key with the > cookie. For every smart cookie returned to the server in a TLS > connection, the browser uses the cookie's key along with the > connection's binding value to calculate the MAC. > > The cookie_key values are secrets which the browser MUST never send > over the network, or make accessible to javascript. > > > Advertising support > -------------------- > Browsers MUST advertise support for smart cookies in every HTTP > Request with "Smart-Cookies: true". This lets the website allow > legacy clients to use old cookies, while requiring smart cookies for > capable clients so they are protected from cookie forcing. > > > Misc > ----- > * A website can have stateless smart cookies by including the > cookie_key in the cookie, and encrypting the cookie to itself. On > receiving such a cookie, the website will decrypt it, then check its > MAC. > * A website could ignore the MAC values, and just use smart cookies > for their origin-binding properties. > * An attacker who somehow observes a transmitted smart cookie and MAC > can't replay it on a different TLS connection (as it's tied to its > connection's binding value), and can't calculate the MAC for a > different connection without the cookie_key. > > > Trevor > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --047d7bb70e12907c1304e2352b0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I guess I could replace the 'Set-Session' mechanis= m that I set out in my session continuation draft with a scheme that encode= s the same information as Set-Cookie attributes. That would then mean that = a browser that knows how to do Macs on the session cookie can do so and tho= se that don't will simply send the cookie back and forth as per usual.<= div>
It has nice backwards compatibility properties.
<= div class=3D"gmail_extra">

On Mon, Jul 22= , 2013 at 4:02 AM, Trevor Perrin <trevp@trevp.net> wrote:
Hi,

Here's an attempt to combine the benefits of a couple cookie
proposals. =A0I'm curious what people think...


"Smart cookies"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Rationale
----------
The "Origin Cookie" proposal seems a good solution to cookie scop= ing.
The "ChannelID" proposal seems a good approach to the "beare= r token"
problem, but requires on-the-wire TLS changes and a client signature
for all TLS connections.

Smart cookies combine the benefits of both proposals, and don't
require TLS changes or client signatures.

Smart cookies are bound to the Origin, and cannot be read or written
from other Origins. =A0Smart cookies are also cryptographically bound to two TLS connections:
=A01) =A0The TLS connection on which the server set the cookie
=A02) =A0The TLS connection on which the client is returning the cookie

This binding is done by a cryptographic "MAC" sent from browser t= o
server along with each smart cookie.


The "smart" attribute
----------------------
Smart cookies are set the same way as normal cookies, but have an
additional "smart" attribute:

=A0 Set-Cookie: session=3D123; secure; smart;

Smart cookies SHALL only be set from HTTPS connections. =A0The "domain= "
attribute MUST be omitted, and the "secure" attribute MUST be pre= sent.

Smart cookies are backwards-compatible. =A0Older browsers ignore the
"smart" attribute, and return it as a regular cookie. =A0A smart = cookie
aware browser does two extra things:

=A0(1) The smart cookie is bound to the Origin that set it. =A0The smart cookie is only returned to that Origin. =A0The smart cookie can only be
overwritten by that Origin. =A0If a smart cookie is being returned, any
cookies with the same name stored in parent domains are ignored.

=A0(2) When returning a smart cookie, the browser returns an associated MAC= , e.g.

=A0 Cookie: session=3D123
=A0 Smart-Cookie-MAC: session=3DlMVoh17EQNE1Rd6nT+hh6A=3D=3D


MAC calculation
----------------
The MAC is calculated as follows:

=A0 - cookie_str: HTTP Request line for cookie ("Cookie: session=3D123= ")
=A0 - cookie_key: 32 byte secret key derived from the TLS master secret
for the connection on which the server sent the cookie.
=A0 - cookie_binding: 32 byte value derived from the TLS master secret
for the connection on which the client is returning the cookie.

(The key and binding values are derived using RFC 5705 with labels
"smart_cookie_key" and "smart_cookie_binding".)

=A0 MAC =3D HMAC-SHA256(cookie_key, cookie_binding || cookie_str)[0:16]


Key handling
-------------
The browser can easily calculate the key and binding values for every
TLS connection. =A0For every smart cookie the browser receives in a TLS
connection, the browser stores the connection's cookie_key with the
cookie. =A0For every smart cookie returned to the server in a TLS
connection, the browser uses the cookie's key along with the
connection's binding value to calculate the MAC.

The cookie_key values are secrets which the browser MUST never send
over the network, or make accessible to javascript.


Advertising support
--------------------
Browsers MUST advertise support for smart cookies in every HTTP
Request with "Smart-Cookies: true". =A0This lets the website allo= w
legacy clients to use old cookies, while requiring smart cookies for
capable clients so they are protected from cookie forcing.


Misc
-----
=A0* A website can have stateless smart cookies by including the
cookie_key in the cookie, and encrypting the cookie to itself. =A0On
receiving such a cookie, the website will decrypt it, then check its
MAC.
=A0* A website could ignore the MAC values, and just use smart cookies
for their origin-binding properties.
=A0* An attacker who somehow observes a transmitted smart cookie and MAC can't replay it on a different TLS connection (as it's tied to its<= br> connection's binding value), and can't calculate the MAC for a
different connection without the cookie_key.


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



--
Website: http://hallambaker.com/
--047d7bb70e12907c1304e2352b0e-- From mt.oezil@gmail.com Wed Jul 24 08:21: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 B497211E8232 for ; Wed, 24 Jul 2013 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] 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 AoHIwDEaqgwF for ; Wed, 24 Jul 2013 08:21:12 -0700 (PDT) Received: from mail-pb0-x241.google.com (mail-pb0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) by ietfa.amsl.com (Postfix) with ESMTP id BE4B211E80DF for ; Wed, 24 Jul 2013 08:20:55 -0700 (PDT) Received: by mail-pb0-f65.google.com with SMTP id un1so4190387pbc.4 for ; Wed, 24 Jul 2013 08:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bdRPKfs+uPseYt2H3brbYhU3ilU3evuaxtlTKW0gPsE=; b=qlvnvpySzgU5fW55xD0iKUzwb1SzdLcZxoEoUkzmAtdAziNmCCGMpeZm3EPJdnvE88 yX/qyajSbrfrNZpjzZWyK9sxon0gxJEEZ/AbsujTuY03Ck4rtitJdNJ0pkh2J59crrCW SqhDY/kSSLX1UB1JdoUWIgGgtXeN0twQELP/uLNLbM5EabjBTe6o5L+p8ChF4RWOw7lC HL/YBFzWs15GRFrxTQVqJKyIz9GOxAaT1Fun4jg2cVParGRw3KCqWQJWOHm8+lrbkfr1 Y/XVKOApytX7ZgTLwkgZf5AlH6k7Xq4UnruCspPtX5wUvWJan4BzQSfNayLGiJSsEHms GZmQ== MIME-Version: 1.0 X-Received: by 10.66.249.202 with SMTP id yw10mr43458958pac.145.1374679202285; Wed, 24 Jul 2013 08:20:02 -0700 (PDT) Received: by 10.70.49.47 with HTTP; Wed, 24 Jul 2013 08:20:02 -0700 (PDT) Date: Wed, 24 Jul 2013 17:20:02 +0200 Message-ID: From: Feixia Xiao To: websec@ietf.org Content-Type: multipart/alternative; boundary=047d7b15ad4f884b3f04e2437103 Subject: [websec] review for draft-ietf-websec-framework-reqs-00 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, 24 Jul 2013 15:21:13 -0000 --047d7b15ad4f884b3f04e2437103 Content-Type: text/plain; charset=ISO-8859-1 Dear authors, I have read draft-ietf-websec-framework-reqs-00. I think this draft is a very useful document, clearly written, proposing a common framework expressing security constraints on HTTP interactions. To further improve the document, you could consider the following comments. 1. ------------ Section 1. Introduction In the introduction, people might confuse why the "Gazelle Web Browser[27]" is classified in the category "proposals aimed at addressing other facets of inherent web vulnerabilities". A more detailed description would make it easier for readers to understand. 2. ------------ Section 4. 1. Policy conveyance The text could give more reasons for "It may be reasonable to device distinct sets of headers...". How about explaining what is the result if we could not distinguish in-band and out-of-band signals in the NOTE? 3. ------------ Section 4. 3. Configurability It's not obvious what are "the simple cases, like those mentioned above". So some exemples for both "the simple cases" and the "fine-grained multi-faceted policies" might make it more easy for readers to understand. 4. ------------ Section 7. Detailed Functional Requirements In the overall functional requirement categories, bullet NO. 4 could be renamed "Performance and evaluation mechanism", which would do better in minimizing performance impact. ------------ Thanks again for your work. Best wishes, Tianhui Meng --047d7b15ad4f884b3f04e2437103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear authors,

I have read=A0draft-ietf-websec-fr= amework-= reqs-00. I think=A0this draft is a
very useful doc= ument, clearly written, proposing a common
framework expressing security constraints on HTTP interact= ions. To further
improve the doc= ument, you could consider the following comments.

1.
------------
Section 1. Intr= oduction
In the introduction, people might = confuse why the "Gazelle Web
Browser[27]&quo= t; is classified in the category "proposals aimed at addressing=
other facets of inherent web vul= nerabilities". A more detailed description
would make it e= asier for readers to understand.

2.
------------
Section 4. 1. P= olicy conveyance

The text could give more r= easons for "It may be reasonable to device distinct
sets of headers= ...".
= How about expla= ining what is the result if we could not distinguish
in-band and out= -of-band signals in the NOTE?

3.
------------
Section 4. 3. C= onfigurability

It's not obvious what = are "the simple cases, like those
mentioned above= ". So some exemples for both "the simple cases" andthe "fine-grained multi-facet= ed policies" might make it more easy for readers to
understand.

4.
------------
Section 7. Detailed Functi= onal Requirements

In the overall functional requir= ement categories, bullet NO. 4 could be renamed
"Performan= ce and evaluation mechanism", which would do better in
minimizing performance impact.


------------

Thanks again for your work.

Best wishes,
Tianhui Meng
--047d7b15ad4f884b3f04e2437103-- From internet-drafts@ietf.org Sun Jul 28 23:01:30 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C7E11E80D3; Sun, 28 Jul 2013 23:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O02IYgch9DIB; Sun, 28 Jul 2013 23:01:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB08921E8054; Sun, 28 Jul 2013 23:01:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729060127.9383.42640.idtracker@ietfa.amsl.com> Date: Sun, 28 Jul 2013 23:01:27 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-06.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 06:01:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : HTTP Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-06.txt Pages : 11 Date : 2013-07-28 Abstract: To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 29 01:59:19 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFEC21F9FE9; Mon, 29 Jul 2013 01:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFta0BcFRRni; Mon, 29 Jul 2013 01:59:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9598521F9EB2; Mon, 29 Jul 2013 01:59:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729085916.8571.42138.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 01:59:16 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-07.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:59:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : HTTP Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-07.txt Pages : 11 Date : 2013-07-29 Abstract: To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Jul 29 02:38:07 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7334A21F9CEF; Mon, 29 Jul 2013 02:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 110aSo-Rodtq; Mon, 29 Jul 2013 02:38:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AED621F9A37; Mon, 29 Jul 2013 02:37:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Sender: Message-ID: <20130729093755.20677.91084.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 02:37:55 -0700 Cc: websec@ietf.org Subject: [websec] Last Call: (HTTP Header Field X-Frame-Options) to Informational RFC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:38:07 -0000 The IESG has received a request from the Web Security WG (websec) to consider the following document: - 'HTTP Header Field X-Frame-Options' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ballot/ No IPR declarations have been submitted directly on this I-D. From ietf-secretariat-reply@ietf.org Mon Jul 29 02:38: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 7606A21E8085 for ; Mon, 29 Jul 2013 02:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZxKnJ8vdGXN; Mon, 29 Jul 2013 02:38:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC4721E8093; Mon, 29 Jul 2013 02:37:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729093757.20677.64790.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 02:37:57 -0700 From: IETF Secretariat X-Mailman-Approved-At: Mon, 29 Jul 2013 03:08:56 -0700 Subject: [websec] ID Tracker State Update Notice: X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:38:13 -0000 Last call has been made for draft-ietf-websec-x-frame-options and state has= been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-o= ptions/ From stpeter@stpeter.im Mon Jul 29 06:59:04 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 857AF21F9A29; Mon, 29 Jul 2013 06:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 qmKA-OyBZiUa; Mon, 29 Jul 2013 06:58:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AECE711E80F1; Mon, 29 Jul 2013 06:57:43 -0700 (PDT) Received: from dhcp-10f3.meeting.ietf.org (unknown [130.129.16.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0870B40049; Mon, 29 Jul 2013 07:59:50 -0600 (MDT) Message-ID: <51F674D4.8010603@stpeter.im> Date: Mon, 29 Jul 2013 15:57:40 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF list References: <20130729093755.20677.91084.idtracker@ietfa.amsl.com> In-Reply-To: <20130729093755.20677.91084.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Last Call: (HTTP Header Field X-Frame-Options) to Informational RFC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:59:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/29/13 11:37 AM, The IESG wrote: > > The IESG has received a request from the Web Security WG (websec) > to consider the following document: - 'HTTP Header Field > X-Frame-Options' as > Informational RFC Section 1 states: This specification provides informational documentation about the current use and definition of the X-Frame-Options HTTP header field. Given that the "X-" construction is deprecated [RFC6648], the X -Frame-Options header field will in the future be replaced by the Frame-Options directive in the Content Security Policy Version 1.1 [CSP-1-1]. IMO, RFC 6648 does not necessitate deprecating the X-Frame-Options header field in favor of the Frame-Options header field, since RFC 6648 is not retroactive. We might want to make the relationship clearer here. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR9nTUAAoJEOoGpJErxa2p+j0QAIh/eaMB0hj8C0YwFphmDE6w bBnOaqLAEtb1A269cx9Uzx0+gjnQz+9PI0wvrev08kKWR4DFNxXNKAGC8rxJx6T/ dXcB3WjwDAg7iinoL+LRcP5ionE9519gU6V65Ff4IpkBpFiY2KhkC6FKV1AgeH7C EIIpjHNH2dzeDQSBkYY1WGk5xDcXwoo+isUhF8TXhSf9mwY0NrUD2zO3UDDiAf// ZTWbAH1vvMl4BDduq1bSt0Yt0H4gBtOOjeo86N0EsfHNoPPSOmHQ/4aX18rGa7/A 7ddk5GXFRmaLR6zLXCrOIWc+RSe5rIHOKk1Im2OC/S7D/t1zaDhRROLIekMGZafa ySOo2dih/tQav7uAkdzDQr1HQ9LRRkzx5EnIdrbrVJGIPuDnOfvZ2ddE+7LDLQB7 SiZdacYVAKa3whaDiY4i2JVduv/2LyHG+JUhMDtD+J8PYSf4gPLRC4l8XqneIri7 9X+3UIW+I34c9mopbzwD+UiB+gPaHcBGKE3+LEBPJM1/+sUh7uM0Pm5SaU9NvXP1 VlR8H9cnvjf7DBm/p+cZ/hQiy78f/Zox/zRobeVlZUoW/+o4jqunYJA0EBNqHSKp 4hm2fBWMfQZZdVhYymHGY8+uhhKGp6U/fqJ95J6fwtlQhvo+O3MwzGywhHFFsgJV fVAvCigEvz3XX+RfaVJq =VZfS -----END PGP SIGNATURE----- From trac+websec@trac.tools.ietf.org Mon Jul 29 08:11: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 85D9B21F99CF for ; Mon, 29 Jul 2013 08:11:38 -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 13A+jcOEP+Pt for ; Mon, 29 Jul 2013 08:11:37 -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 9DAD011E80EE for ; Mon, 29 Jul 2013 08:10:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:40882 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V3p56-0007o3-AH; Mon, 29 Jul 2013 17:09:52 +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: Mon, 29 Jul 2013 15:09:52 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/58 Message-ID: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 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: <20130729151103.9DAD011E80EE@ietfa.amsl.com> Resent-Date: Mon, 29 Jul 2013 08:10:41 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [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: Mon, 29 Jul 2013 15:11:39 -0000 #58: Should we pin only SPKI, or also names It has been suggested that instead or in addition to pinning to a has of the SPKI, we should also be able to pin to a certificate vendor. So in addition to the current pins, like Public-Key-Pins: max-age=2592000; pin-sha1="4n972HfV354KP560yw4uqe/baXc="; pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=" We will also be able to specify something like this: Public-Key-Pins: max-age=2592000; pin-name="comodo" -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-key- ynir@checkpoint.com | pinning@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: In WG Last | Keywords: HPKP Call | -------------------------+------------------------------------------------- Ticket URL: websec From jeremy.rowley@digicert.com Mon Jul 29 08:19:18 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE3421F9ED2 for ; Mon, 29 Jul 2013 08:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WshLxoeXZgs for ; Mon, 29 Jul 2013 08:19:07 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id B8FD421F997B for ; Mon, 29 Jul 2013 08:19:05 -0700 (PDT) Received: from JROWLEYL1 (dhcp-45d8.meeting.ietf.org [130.129.69.216]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id CF4D28FA20F; Mon, 29 Jul 2013 09:19:03 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1375111144; bh=EX0cRXRhUpMZWO7xumDvnCyq08a+fzXFtYDpGTdUI8Y=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date; b=YGG+ZEjtIQJwHAy2I0x8rDcw1eVtQHM7qp0xa0ZrqR/bBDlcSVBLYu+BuNXcuBdpd iu3jvr4bSzAf20o4x/gAmwY4kTVoczxDeVOB5ClI0llXrTvZzFpFdwu4OcI+LdrJfn FzlCextxSpZpPsZbndXliU+bmYRIga4nSEjJOK6U= From: "Jeremy Rowley" To: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> In-Reply-To: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> Date: Mon, 29 Jul 2013 09:19:03 -0600 Organization: DigiCert Message-ID: <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoJKS5/1/Jv2JXKWhm99jqPYGDVJhIk2JA Content-Language: en-us Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:19:18 -0000 The primary reason for this suggestion is that some CAs switch which intermediates and roots are used to issue certs on a periodic basis to help minimize the impact of revocation and ensure small CRLs. Pinning a single intermediate to a domain may screw up certificates issued later on for the domain. Pinning a set CA will permit the CA to change intermediates/roots when necessary without impacting the end user. The effect is primarily noticeable when intermediates are pinned over roots since a CA may limit its issuance from a single intermediate to <500 cert whereas roots are rarely rotated. Jeremy -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of websec issue tracker Sent: Monday, July 29, 2013 9:10 AM To: draft-ietf-websec-key-pinning@tools.ietf.org; ynir@checkpoint.com Cc: websec@ietf.org Subject: [websec] #58: Should we pin only SPKI, or also names #58: Should we pin only SPKI, or also names It has been suggested that instead or in addition to pinning to a has of the SPKI, we should also be able to pin to a certificate vendor. So in addition to the current pins, like Public-Key-Pins: max-age=2592000; pin-sha1="4n972HfV354KP560yw4uqe/baXc="; pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=" We will also be able to specify something like this: Public-Key-Pins: max-age=2592000; pin-name="comodo" -- -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-ietf-websec-key- ynir@checkpoint.com | pinning@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: In WG Last | Keywords: HPKP Call | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: websec _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From ynir@checkpoint.com Mon Jul 29 08:21: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 EE41F11E80FB for ; Mon, 29 Jul 2013 08:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 tZIz6dFSV54C for ; Mon, 29 Jul 2013 08:21:03 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2D16911E8116 for ; Mon, 29 Jul 2013 08:20:39 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6TFKcLu029920 for ; Mon, 29 Jul 2013 18:20:38 +0300 X-CheckPoint: {51F68846-18-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.90]) by IL-EX10.ad.checkpoint.com ([169.254.2.105]) with mapi id 14.02.0342.003; Mon, 29 Jul 2013 18:20:38 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Issue #58: Should we pin only SPKI, or also names Thread-Index: AQHOjG8tkT5bXWZLa0Kezp2M4AMjew== Date: Mon, 29 Jul 2013 15:20:37 +0000 Message-ID: <0C4F9B2E-5394-4193-8AA2-533C5707B130@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.82] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11bdb1d06fa52b3e49fe861efcf33fd8dae9e2ceca Content-Type: text/plain; charset="us-ascii" Content-ID: <4B2EB11BE0DCDE42876E4AA9FE2EB21D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Issue #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:21:08 -0000 Hi all This issue ( http://trac.tools.ietf.org/wg/websec/trac/ticket/58 - see text= below my sig ) has been raised at WGLC. Current text does not allow the ne= w format. This was discussed in the meeting. Two people liked the idea because it's e= asier for administrators to manage, others didn't like it because it's unwi= eldy, and because the list of "corporation_name" roots changes constantly t= hrough the issuing of new CAs and through mergers and acquisitions. Absent a working group consensus, we will not ask the editors to modify the= draft. If you feel strongly one way or the other, please reply to this thr= ead, and tell what we should do. At this stage, general silence will be int= erpreted as assent, so if you want those names in, please speak up within t= he next two weeks. Tobias and Yoav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Issue #58 text: It has been suggested that instead or in addition to pinning to a has of th= e SPKI, we should also be able to pin to a certificate vendor. So in additi= on to the current pins, like=20 Public-Key-Pins: max-age=3D2592000; pin-sha1=3D"4n972HfV354KP560yw4uqe/baXc=3D"; pin-sha256=3D"LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=3D" We will also be able to specify something like this: Public-Key-Pins: max-age=3D2592000; pin-name=3D"comodo" From hallam@gmail.com Mon Jul 29 09:13:33 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 2146D21F9D07 for ; Mon, 29 Jul 2013 09:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 m6Su6XBaEB8N for ; Mon, 29 Jul 2013 09:13:30 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 359B321F9F31 for ; Mon, 29 Jul 2013 09:13:18 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so1081213wib.5 for ; Mon, 29 Jul 2013 09:13:18 -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=48GsVF7Fvc+q6XPwtFhX5srmwsIN+UPm6YAzPqNSunw=; b=ptBBR+hrfOy7O1snhEZGGocmTIYyfy4InmY+pGdotTsDZ6UUXJxtPhZSXOVsMNfA2W AjE+hmfQMZdkoW8bvRz0WnQ41mrE9d0cmSe2Dw15VeDFzqhovD2ZYIVcMCzKVVF+R1dE 34FnTsBqlbfM9nfV5JB3rPTjKIaJCJ4ZWvxYOgl+1rbEcZffJwnbzunh5ZoF3ZxRXIoS aS2HoasuVsKL1eN0NQnKsP9FFZMmECJBX06iFV71FmtjpejF8g2SbWzBjxtHOx1XdG8Y DvOUqeYIZ1y8C7SG9vMvUiXZw1cPzzLy2CmCzYA8e2v6DRQkPWdX/Pv+LMwsuRBqSXBq MXOA== MIME-Version: 1.0 X-Received: by 10.180.126.2 with SMTP id mu2mr7648613wib.63.1375114398234; Mon, 29 Jul 2013 09:13:18 -0700 (PDT) Received: by 10.194.6.65 with HTTP; Mon, 29 Jul 2013 09:13:18 -0700 (PDT) In-Reply-To: <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> Date: Mon, 29 Jul 2013 12:13:18 -0400 Message-ID: From: Phillip Hallam-Baker To: jeremy.rowley@digicert.com Content-Type: multipart/alternative; boundary=e89a8f642dfc3b839904e2a8c5d5 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 16:13:33 -0000 --e89a8f642dfc3b839904e2a8c5d5 Content-Type: text/plain; charset=ISO-8859-1 The fact that an online intermediate has a 4-5 year expiry date is likely deceptive. The intermediate has to have validity for all the issued life of a cert so it will typically be 6-12 months + the longest expected certlife + margin. Been a while since I looked at the system in that detail but my guess would be that a cert will never be renewed off the same intermediate. Tying the pins to the CAs seems like a much better approach to me. The browsers have to understand the CAs as root cert entries in any case. If we have a diginotar type situation again (FSM forefend), we want the pins to a root to be broken at the same time the root is unloaded, yes? The trust anchor data structures are outside the PKIX model but they browser providers do need to track them regardless. I would rather tie pins to the actual entity we want to pin to (the CA) rather than attempt pinning to some sort of proxy. There are CAs that are not represented in CABForum but CABForum is a place where we can get a requirement of the form 'every CA must pick a DNS name as a unique identifier for their service and report it to the browser providers'. And that requirement will quickly become universal. While we could choose a different string, Paul H.'s argument for using DNS names in CAA was a good one and I can't see any advantage to inconsistency. It also makes it much easier to make any scheme work with a private CA. On Mon, Jul 29, 2013 at 11:19 AM, Jeremy Rowley wrote: > The primary reason for this suggestion is that some CAs switch which > intermediates and roots are used to issue certs on a periodic basis to help > minimize the impact of revocation and ensure small CRLs. Pinning a single > intermediate to a domain may screw up certificates issued later on for the > domain. Pinning a set CA will permit the CA to change intermediates/roots > when necessary without impacting the end user. The effect is primarily > noticeable when intermediates are pinned over roots since a CA may limit > its > issuance from a single intermediate to <500 cert whereas roots are rarely > rotated. > > Jeremy > > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf > Of > websec issue tracker > Sent: Monday, July 29, 2013 9:10 AM > To: draft-ietf-websec-key-pinning@tools.ietf.org; ynir@checkpoint.com > Cc: websec@ietf.org > Subject: [websec] #58: Should we pin only SPKI, or also names > > #58: Should we pin only SPKI, or also names > > It has been suggested that instead or in addition to pinning to a has of > the SPKI, we should also be able to pin to a certificate vendor. So in > addition to the current pins, like > > Public-Key-Pins: max-age=2592000; > pin-sha1="4n972HfV354KP560yw4uqe/baXc="; > pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=" > > We will also be able to specify something like this: > > Public-Key-Pins: max-age=2592000; > pin-name="comodo" > > -- > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: | Owner: draft-ietf-websec-key- > ynir@checkpoint.com | pinning@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: > Component: key-pinning | Version: > Severity: In WG Last | Keywords: HPKP > Call | > -------------------------+---------------------------------------------- > -------------------------+--- > > Ticket URL: > websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --e89a8f642dfc3b839904e2a8c5d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The fact that an online intermediate has a 4-5 year expiry= date is likely deceptive. The intermediate has to have validity for all th= e issued life of a cert so it will typically be 6-12 months + the longest e= xpected certlife + margin.

Been a while since I looked at the system in that detail but= my guess would be that a cert will never be renewed off the same intermedi= ate.


Tying the pins to the CAs seem= s like a much better approach to me. The browsers have to understand the CA= s as root cert entries in any case.=A0

If we have a diginotar type situation again (FSM forefe= nd), we want the pins to a root to be broken at the same time the root is u= nloaded, yes?


The trust anchor data= structures are outside the PKIX model but they browser providers do need t= o track them regardless. I would rather tie pins to the actual entity we wa= nt to pin to (the CA) rather than attempt pinning to some sort of proxy.

There are CAs that are not represented in CABForum but = CABForum is a place where we can get a requirement of the form 'every C= A must pick a DNS name as a unique identifier for their service and report = it to the browser providers'. And that requirement will quickly become = universal.

While we could choose a different string, Paul H.'s= argument for using DNS names in CAA was a good one and I can't see any= advantage to inconsistency. It also makes it much easier to make any schem= e work with a private CA.




On Mon, Jul 29, 2013 at 11:19 AM, Jeremy Rowley <jeremy.rowley@digicert.com> wrote:
The primary reason for this suggestion is th= at some CAs switch which
intermediates and roots are used to issue certs on a periodic basis to help=
minimize the impact of revocation and ensure small CRLs. =A0Pinning a singl= e
intermediate to a domain may screw up certificates issued later on for the<= br> domain. =A0Pinning a set CA will permit the CA to change intermediates/root= s
when necessary without impacting the end user. =A0The effect is primarily noticeable when intermediates are pinned over roots since a CA may limit it= s
issuance from a single intermediate to <500 cert whereas roots are rarel= y
rotated.

Jeremy

-----Original Message-----
From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.or= g] On Behalf Of
websec issue tracker
Sent: Monday, July 29, 2013 9:10 AM
To: draft-i= etf-websec-key-pinning@tools.ietf.org; ynir@checkpoint.com
Cc: websec@ietf.org
Subject: [websec] #58: Should we pin only SPKI, or also names

#58: Should we pin only SPKI, or also names

=A0It has been suggested that instead or in addition to pinning to a has of=
the SPKI, we should also be able to pin to a certificate vendor. So in
addition to the current pins, like

=A0 =A0 Public-Key-Pins: max-age=3D2592000;
=A0 =A0 =A0 =A0 pin-sha1=3D"4n972HfV354KP560yw4uqe/baXc=3D";
=A0 =A0 =A0 =A0 pin-sha256=3D"LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOL= mCQ=3D"

=A0We will also be able to specify something like this:

=A0 =A0 Public-Key-Pins: max-age=3D2592000;
=A0 =A0 =A0 =A0 pin-name=3D"comodo"

--
-------------------------+----------------------------------------------
-------------------------+---
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Own= er: =A0draft-ietf-websec-key-
=A0 ynir@checkpoint.com =A0 =A0|= =A0pinning@tools.ietf.org =A0 =A0 =A0Type: =A0enhancement =A0| =A0 =A0 Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0| =A0Milestone:
Component: =A0key-pinning =A0| =A0 =A0Version:
=A0Severity: =A0In WG Last =A0 | =A0 Keywords: =A0HPKP
=A0 Call =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/58<= /a>>
websec <http= ://tools.ietf.org/websec/>

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

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



--
= Website: http://hallambaker.com/
--e89a8f642dfc3b839904e2a8c5d5-- From trac+websec@trac.tools.ietf.org Mon Jul 29 13:27:04 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 CA27A21E80A9 for ; Mon, 29 Jul 2013 13:27:04 -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 029qLMhfnTFs for ; Mon, 29 Jul 2013 13:27:04 -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 397AE21E809A for ; Mon, 29 Jul 2013 13:27:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:34947 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V3u1v-0005lj-6T; Mon, 29 Jul 2013 22:26:55 +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: Mon, 29 Jul 2013 20:26:55 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/59 Message-ID: <060.baff63c76c3965bf04b0fab1f8cc5ab7@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 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: <20130729202702.397AE21E809A@ietfa.amsl.com> Resent-Date: Mon, 29 Jul 2013 13:27:01 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #59: Is the interaction between pre-loaded pins and dynamic pins clear? 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: Mon, 29 Jul 2013 20:27:04 -0000 #59: Is the interaction between pre-loaded pins and dynamic pins clear? On June 20th, Trevor Perrin sent this message to the list: http://www.ietf.org/mail-archive/web/websec/current/msg01651.html The relevant section is 2.2.1: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08#section-2.7 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-key- ynir@checkpoint.com | pinning@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: In WG Last | Keywords: HPKP Call | -------------------------+------------------------------------------------- Ticket URL: websec From ynir@checkpoint.com Mon Jul 29 13:29: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 920AB21F8D6D for ; Mon, 29 Jul 2013 13:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 wLhO1m+-Ic-i for ; Mon, 29 Jul 2013 13:29:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0B10D21F8D10 for ; Mon, 29 Jul 2013 13:29:50 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6TKTmag021100 for ; Mon, 29 Jul 2013 23:29:48 +0300 X-CheckPoint: {51F6D0BC-8-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.90]) by IL-EX10.ad.checkpoint.com ([169.254.2.105]) with mapi id 14.02.0342.003; Mon, 29 Jul 2013 23:29:51 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] #59: Is the interaction between pre-loaded pins and dynamic pins clear? Thread-Index: AQHOjJoCjTaCPB9su0CLJGAYbDmvHZl76T2A Date: Mon, 29 Jul 2013 20:29:56 +0000 Message-ID: <4C47E8B1-F849-41C0-95B8-A761A7D985AF@checkpoint.com> References: <060.baff63c76c3965bf04b0fab1f8cc5ab7@trac.tools.ietf.org> In-Reply-To: <060.baff63c76c3965bf04b0fab1f8cc5ab7@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.23] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 113a5f2b2aa7e39caa0b757ba9137184f616a02e52 Content-Type: text/plain; charset="us-ascii" Content-ID: <4ECC221992495A4A9C114EDAE2A9211D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] #59: Is the interaction between pre-loaded pins and dynamic pins clear? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:29:56 -0000 Hi all This ticket describes Trevor's message to the list saying that section 2.7 = is clear enough. We think that it represents the WG consensus, but we're gi= ving you another chance to weigh in. As with the other tickets in this series, silence will be interpreted as as= sent, so if you believe that section 2.7 is not clear enough, please speak = up, and speak up soon. Thanks Tobias & Yoav On Jul 29, 2013, at 10:26 PM, websec issue tracker wrote: > #59: Is the interaction between pre-loaded pins and dynamic pins clear? >=20 > On June 20th, Trevor Perrin sent this message to the list: >=20 > http://www.ietf.org/mail-archive/web/websec/current/msg01651.html >=20 > The relevant section is 2.2.1: >=20 > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08#section-2.7 >=20 > --=20 > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-websec-key- > ynir@checkpoint.com | pinning@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: key-pinning | Version: > Severity: In WG Last | Keywords: HPKP > Call | > -------------------------+-----------------------------------------------= -- >=20 > Ticket URL: > websec >=20 From trac+websec@trac.tools.ietf.org Mon Jul 29 13:38:35 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 468E721F997B for ; Mon, 29 Jul 2013 13:38:35 -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 h0KbctgqhFYf for ; Mon, 29 Jul 2013 13:38:34 -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 936CE21F9967 for ; Mon, 29 Jul 2013 13:38:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:35378 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V3uD4-00014G-1j; Mon, 29 Jul 2013 22:38:26 +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: Mon, 29 Jul 2013 20:38:26 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/60 Message-ID: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> X-Trac-Ticket-ID: 60 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: <20130729203834.936CE21F9967@ietfa.amsl.com> Resent-Date: Mon, 29 Jul 2013 13:38:34 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [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: Mon, 29 Jul 2013 20:38:35 -0000 #60: Well Known URIs vs Response Headers This is about a suggestion to replace the HPKP header with an RFC 5785 well-known URI. This would allow lower bandwidth, as this resource would be read at most once per connection, rather than with each request. However, the same is true for HSTS, CSP, and any other policy-conveying header. The consensus in the room was to not change this for HPKP. If all policies get moved to w-k URIs, HPKP should move as well, but it should not lead the way. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-key- ynir@checkpoint.com | pinning@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: In WG Last | Keywords: HPKP RFC5785 Call | -------------------------+------------------------------------------------- Ticket URL: websec From ynir@checkpoint.com Mon Jul 29 13:44:26 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08F21F8CDD for ; Mon, 29 Jul 2013 13:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.573 X-Spam-Level: X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 d4NAFvzkXTLR for ; Mon, 29 Jul 2013 13:44:21 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EFC7421F8C71 for ; Mon, 29 Jul 2013 13:44:20 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6TKiJCP026082 for ; Mon, 29 Jul 2013 23:44:19 +0300 X-CheckPoint: {51F6D423-69-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.90]) by IL-EX10.ad.checkpoint.com ([169.254.2.105]) with mapi id 14.02.0342.003; Mon, 29 Jul 2013 23:44:18 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USA Date: Mon, 29 Jul 2013 20:44:18 +0000 Message-ID: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> In-Reply-To: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.23] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11d743ef4e880bfa3d5f11c0f3948e6dc72d30ff5c Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] #60: Well Known URIs vs Response Headers X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:44:26 -0000 Hi This is the last in this series of post-LC issues. The consensus in the roo= m was almost unanimous, with only Mark pointing out that in his opinion, if= we don't do it now, it will never be any different. So, if you feel this (rather major) change is needed, please speak up, or e= lse your silence will be interpreted as assent to the status quo. Tobias and Yoav On Jul 29, 2013, at 10:38 PM, websec issue tracker wrote: > #60: Well Known URIs vs Response Headers >=20 > This is about a suggestion to replace the HPKP header with an RFC 5785 > well-known URI. This would allow lower bandwidth, as this resource would > be read at most once per connection, rather than with each request. >=20 > However, the same is true for HSTS, CSP, and any other policy-conveying > header. >=20 > The consensus in the room was to not change this for HPKP. If all policie= s > get moved to w-k URIs, HPKP should move as well, but it should not lead > the way. >=20 > --=20 > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-websec-key- > ynir@checkpoint.com | pinning@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: > Component: key-pinning | Version: > Severity: In WG Last | Keywords: HPKP RFC5785 > Call | > -------------------------+-----------------------------------------------= -- >=20 > Ticket URL: > websec From masinter@adobe.com Tue Jul 30 01:51: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 6CAE321F9AB4 for ; Tue, 30 Jul 2013 01:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYctEWtZRyTY for ; Tue, 30 Jul 2013 01:51:44 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id D1C9621F9A74 for ; Tue, 30 Jul 2013 01:51:03 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUfd+bu55uK3owt0Ne2Mi6nbaeS+T9vq8@postini.com; Tue, 30 Jul 2013 01:51:04 PDT Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6U8oqAI027114; Tue, 30 Jul 2013 01:50:52 -0700 (PDT) Received: from SJ1SWM219.corp.adobe.com (sj1swm219.corp.adobe.com [10.5.77.61]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6U8op6A003597; Tue, 30 Jul 2013 01:50:51 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%11]) with mapi; Tue, 30 Jul 2013 01:50:51 -0700 From: Larry Masinter To: Yoav Nir , IETF WebSec WG Date: Tue, 30 Jul 2013 01:50:48 -0700 Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USAgAD8uoA= Message-ID: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 30 Jul 2013 08:51:49 -0000 This seems like a good idea. Do people think it isn't a good idea, or just = "not now"? If it's a good idea but not now, then when? > > This is about a suggestion to replace the HPKP header with an RFC 5785 > > well-known URI. This would allow lower bandwidth, as this resource wou= ld > > be read at most once per connection, rather than with each request. > > > > However, the same is true for HSTS, CSP, and any other policy-conveying > > header. > > > > The consensus in the room was to not change this for HPKP. If all polic= ies > > get moved to w-k URIs, HPKP should move as well, but it should not lead > > the way. > > > > -- > > -------------------------+---------------------------------------------= ---- > > Reporter: | Owner: draft-ietf-websec-key- > > ynir@checkpoint.com | pinning@tools.ietf.org > > Type: enhancement | Status: new > > Priority: major | Milestone: > > Component: key-pinning | Version: > > Severity: In WG Last | Keywords: HPKP RFC5785 > > Call | > > -------------------------+---------------------------------------------= ---- > > > > Ticket URL: > > websec >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ynir@checkpoint.com Tue Jul 30 03:14:24 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 86FF621E80C8 for ; Tue, 30 Jul 2013 03:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.348 X-Spam-Level: X-Spam-Status: No, score=-9.348 tagged_above=-999 required=5 tests=[AWL=-1.204, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 EMD6BKyGNtm8 for ; Tue, 30 Jul 2013 03:14:19 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1421E808B for ; Tue, 30 Jul 2013 03:14:09 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6UAE1Yl014498; Tue, 30 Jul 2013 13:14:01 +0300 X-CheckPoint: {51F791E9-29-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.90]) by IL-EX10.ad.checkpoint.com ([169.254.2.105]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 13:14:01 +0300 From: Yoav Nir To: IETF WebSec WG , Larry Masinter Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USAgAD8uoD//+WDgA== Date: Tue, 30 Jul 2013 10:14:00 +0000 Message-ID: <2D9A5484-1D1F-4E65-B39F-8087C33BA06D@checkpoint.com> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.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.188] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11bc788fe41989f54f087073ace2e567fbe785cf32 Content-Type: text/plain; charset="us-ascii" Content-ID: <596B5D3C8D86754A81A38CB92E093CCB@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 30 Jul 2013 10:14:24 -0000 I guess the time would be when everybody ([1]) gets together and decides to= create a big, unified policy format that goes in a resource and can convey= all policy. It's far better to do this consistently among all the policies that are con= veyed from the server to the client. Yoav [1] should include people responsible for both things that were standardize= d in W3C and in IETF, so I guess that would require (shudder!) collaboratio= n with the WebAppSec. On Jul 30, 2013, at 10:50 AM, Larry Masinter wrote: > This seems like a good idea. Do people think it isn't a good idea, or jus= t "not now"? > If it's a good idea but not now, then when? >=20 >=20 >>> This is about a suggestion to replace the HPKP header with an RFC 5785 >>> well-known URI. This would allow lower bandwidth, as this resource wou= ld >>> be read at most once per connection, rather than with each request. >>>=20 >>> However, the same is true for HSTS, CSP, and any other policy-conveying >>> header. >>>=20 >>> The consensus in the room was to not change this for HPKP. If all polic= ies >>> get moved to w-k URIs, HPKP should move as well, but it should not lead >>> the way. >>>=20 >>> -- >>> -------------------------+---------------------------------------------= ---- >>> Reporter: | Owner: draft-ietf-websec-key- >>> ynir@checkpoint.com | pinning@tools.ietf.org >>> Type: enhancement | Status: new >>> Priority: major | Milestone: >>> Component: key-pinning | Version: >>> Severity: In WG Last | Keywords: HPKP RFC5785 >>> Call | >>> -------------------------+---------------------------------------------= ---- >>>=20 >>> Ticket URL: >>> websec >>=20 >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Tue Jul 30 12:17:41 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 1EEAD21E8093 for ; Tue, 30 Jul 2013 12:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 A4MuEzZqJZ1Z for ; Tue, 30 Jul 2013 12:17:35 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id E261421E8089 for ; Tue, 30 Jul 2013 12:17:34 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id f14so2526973wiw.4 for ; Tue, 30 Jul 2013 12:17:34 -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=yuIQVRde0uwVMQrzSVoXNJ87IdzSR9IkgLhfRIjnL5s=; b=pgFeBbw4e3qH/bfH1ShckRIdLe3OOBWYRMQAXKDdSHjaXWB2sCYFziKy/lQ7EAiVA8 +dc/9o5z6nWTt88yoYrA0TzYYOBZ3nmC5TmqDocsbG+JEtSc7soQYtcQHNSihLlAXhoq SJuR/CwbCzmONAViL+FC8NX8oov9hGNCKFLIb2dGLZLk1QcIOuNBEYES827dvYQY1irM Zm6I4EwB5CfsZDDXnyBU5bGebjehJGe+4R+tsV1AbtOoZIv3+7g3SeNHTUuTu5tswKAJ mDDxaGW9vHKL1r9DXl1fRUqFQODcpjyNq3hus5y4VOZwHMbM8yy2kNvRa4weUnyJHhER uMgw== MIME-Version: 1.0 X-Received: by 10.180.21.229 with SMTP id y5mr1976888wie.17.1375211853870; Tue, 30 Jul 2013 12:17:33 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Tue, 30 Jul 2013 12:17:33 -0700 (PDT) X-Originating-IP: [24.234.111.18] In-Reply-To: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> Date: Tue, 30 Jul 2013 12:17:33 -0700 Message-ID: From: Trevor Perrin To: websec issue tracker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmjDvM3e+qAem3F98S0T7tPzEFAt8uYsjXoGiNOc+ghQeRguxtbyw54U4OGvrxx66la7pwb Cc: draft-ietf-websec-key-pinning@tools.ietf.org, IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 30 Jul 2013 19:17:41 -0000 On Mon, Jul 29, 2013 at 1:38 PM, websec issue tracker wrote: > #60: Well Known URIs vs Response Headers > > This is about a suggestion to replace the HPKP header with an RFC 5785 > well-known URI. This would allow lower bandwidth, as this resource would > be read at most once per connection, rather than with each request. To me this seems related to a couple other issues: - can a client pin CAs by name, or will the client have to list potentially dozens of hashes in the header? - is the header sent on every response from the pinned host, or is it only returned infrequently or to a client who asks for it? If CAs can be pinned by name, or if response headers are only returned to a client who asks for them, then large headers don't matter much. But the current draft seems inefficient / inelegant, since an HPKP header may contain dozens of hashes. The header must be sent on *every* response from a pinned site (draft-08, section 2.2.1), so the client must process the header on every response. > However, the same is true for HSTS, CSP, and any other policy-conveying > header. It's not exactly the same - HSTS does not interpret an absent response header as max-age=0, so the headers doesn't need to be sent on every response. HSTS headers are also smaller. Trevor From jbonneau@gmail.com Tue Jul 30 14:40: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 DA41D11E814B for ; Tue, 30 Jul 2013 14:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 OwIdhf-JK30G for ; Tue, 30 Jul 2013 14:40:38 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0936911E8125 for ; Tue, 30 Jul 2013 14:40:37 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id db10so4789826veb.0 for ; Tue, 30 Jul 2013 14:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2UF55V8yYZOgDj3AZQ4fpD7aFOya8Yq5fvLQtkI96eI=; b=fFSrQgEYv0ifOtnSIbNR4t3SshDHjAyUbvnEleKMMtprH2nSVDkm+5pagpaqnKMueZ 16RiXpMEbugeKYnuAe4oedV09d7UnEq2VNo7kyswrSDjilPTY9OFvNZbbhxdRFQ4//LZ PJOnBrQimywpkvZkk7So8IVjNBopYaPra4x3IatqZ5OqCApkTVP3iR2lfevMRxuiTBbp VSk4GA/tk1yZbztSAI8xctPITZ9+eIL4cu8bvhUXvP8emdlpNNrPgKxfOWSfZMA6y2qh 8yTyemrH1u/0evFYiTjSPpiyXP61RFU/YjozlXxknitKK1HScHAFkvLwPX/DK7+XJDcR vzqQ== X-Received: by 10.58.118.200 with SMTP id ko8mr27804865veb.94.1375220437318; Tue, 30 Jul 2013 14:40:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.103.69 with HTTP; Tue, 30 Jul 2013 14:40:17 -0700 (PDT) In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> From: Joseph Bonneau Date: Tue, 30 Jul 2013 17:40:17 -0400 Message-ID: To: Trevor Perrin Content-Type: multipart/alternative; boundary=089e013a1e60a7854f04e2c1754f Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec issue tracker , IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 30 Jul 2013 21:40:39 -0000 --089e013a1e60a7854f04e2c1754f Content-Type: text/plain; charset=UTF-8 > > However, the same is true for HSTS, CSP, and any other policy-conveying > > header. > > It's not exactly the same - HSTS does not interpret an absent response > header as max-age=0, so the headers doesn't need to be sent on every > response. HSTS headers are also smaller. This is a big issue I wouldn't overlook. In my experience looking at web crawls and trying to determine which sites are consistently setting HSTS, almost nobody consistently sets the header for every path and subdomain within a domain. For HSTS, this is okay as pointed out, but for HPKP I expect this will lead to a lot of accidentally clearing of pins. So we should think about what makes life easiest for server admins deploying HPKP in addition to efficiency. This could be argued either way-if servers aren't disciplined enough to always set the header, they may not be disciplined enough to always satisfy their own pins and they'll hang themselves that way. Serving everything satisfying a set of pins is strictly harder than serving everything over HSTS, and that's an issue. On the other hand servers will be more motivated to fix anything they serve not satisfying pins, since clients will lose access and complain, whereas accidentally clearing client pins by not setting the header is a siient failure. Personally I'd advocate strongly for a well-known URI. This is a tragedy of the commons-if every working group uses a header since this is a little less work, we end up with lots of headers being set and it being much harder for everybody to manage than a well-known URI specifying all TLS policy would be, as well as far less extensible. As an example, it would be useful during the rollout of Certificate Transparency if sites can specify that they are a "CT required" domain before this policy could be turned on by default for every domain in the world. Should this be another new header "Strict-Certificate-Transparency"? An extra directive for HSTS? Having a simple JSON file at a well-known URI to add a new field to makes much more sense. --089e013a1e60a7854f04e2c1754f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> =C2=A0However, the same is true for HSTS, CSP, and any other policy-co= nveying
> =C2=A0header.

It's not exactly the same - HSTS does not interpret an absent res= ponse
header as max-age=3D0, so the headers doesn't need to be sent on every<= br> response. =C2=A0HSTS headers are also smaller.

<= div>This is a big issue I wouldn't overlook. In my experience looking a= t web crawls and trying to determine which sites are consistently setting H= STS, almost nobody consistently sets the header for every path and subdomai= n within a domain. For HSTS, this is okay as pointed out, but for HPKP I ex= pect this will lead to a lot of accidentally clearing of pins. So we should= think about what makes life easiest for server admins deploying HPKP in ad= dition to efficiency.

This could be argued either way-if servers aren't d= isciplined enough to always set the header, they may not be disciplined eno= ugh to always satisfy their own pins and they'll hang themselves that w= ay. Serving everything satisfying a set of pins is strictly harder than ser= ving everything over HSTS, and that's an issue. On the other hand serve= rs will be more motivated to fix anything they serve not satisfying pins, s= ince clients will lose access and complain, whereas accidentally clearing c= lient pins by not setting the header is a siient failure.

Personally I'd advocate strongly for a well-known U= RI. This is a tragedy of the commons-if every working group uses a header s= ince this is a little less work, we end up with lots of headers being set a= nd it being much harder for everybody to manage than a well-known URI speci= fying all TLS policy would be, as well as far less extensible.

As an example, it would be useful during the rollout of= Certificate Transparency if sites can specify that they are a "CT req= uired" domain before this policy could be turned on by default for eve= ry domain in the world. Should this be another new header "Strict-Cert= ificate-Transparency"? An extra directive for HSTS? Having a simple JS= ON file at a well-known URI to add a new field to makes much more sense.
--089e013a1e60a7854f04e2c1754f-- From tobias.gondrom@gondrom.org Wed Jul 31 11:18: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 6799A11E81A6 for ; Wed, 31 Jul 2013 11:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.314 X-Spam-Level: X-Spam-Status: No, score=-96.314 tagged_above=-999 required=5 tests=[AWL=-0.952, 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 eHfqxOQxp9Cs for ; Wed, 31 Jul 2013 11:18:13 -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 6017211E81A5 for ; Wed, 31 Jul 2013 11:18:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=GqSugWbiF/ifi1WHyIfs1a7iW4fxGWUCqlygiEqbx4iZdFErSWVtKlhrxXfxxYPWwDZHmF3kIOtlTQSHeinYhbLzQTA9nMI5aKKr7Vzlp7Qxi4uWc9dI0zjvLkp9PVXS; 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 26339 invoked from network); 31 Jul 2013 20:18:07 +0200 Received: from dhcp-411f.meeting.ietf.org (HELO ?130.129.65.31?) (130.129.65.31) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 31 Jul 2013 20:18:07 +0200 Message-ID: <51F954DE.4090907@gondrom.org> Date: Wed, 31 Jul 2013 20:18:06 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: trevp@trevp.net References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-websec-key-pinning@tools.ietf.org, trac+websec@trac.tools.ietf.org, websec@ietf.org Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 31 Jul 2013 18:18:17 -0000 On 30/07/13 21:17, Trevor Perrin wrote: > On Mon, Jul 29, 2013 at 1:38 PM, websec issue tracker > wrote: >> #60: Well Known URIs vs Response Headers >> >> This is about a suggestion to replace the HPKP header with an RFC 5785 >> well-known URI. This would allow lower bandwidth, as this resource would >> be read at most once per connection, rather than with each request. > To me this seems related to a couple other issues: > - can a client pin CAs by name, or will the client have to list > potentially dozens of hashes in the header? > - is the header sent on every response from the pinned host, or is it > only returned infrequently or to a client who asks for it? > > If CAs can be pinned by name, or if response headers are only returned > to a client who asks for them, then large headers don't matter much. > > But the current draft seems inefficient / inelegant, since an HPKP > header may contain dozens of hashes. The header must be sent on > *every* response from a pinned site (draft-08, section 2.2.1), so the > client must process the header on every response. actually the client does not have to process the hash for every response. A simple compare with the previous cached hash(es) is sufficient. So less processing effort. Best regards, Tobias > >> However, the same is true for HSTS, CSP, and any other policy-conveying >> header. > It's not exactly the same - HSTS does not interpret an absent response > header as max-age=0, so the headers doesn't need to be sent on every > response. HSTS headers are also smaller. > > > Trevor > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Wed Jul 31 11: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 A927711E80E9 for ; Wed, 31 Jul 2013 11:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 38JcGitoCCUS for ; Wed, 31 Jul 2013 11:53:40 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C51621F8F4F for ; Wed, 31 Jul 2013 11:53:40 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so945678wgg.24 for ; Wed, 31 Jul 2013 11:53:39 -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=rNk7SC2sua2Ja+I7J+dfsWr54hCPBLzGD/FGz3QgqjI=; b=KdtW3c8nAgo8mpfh12Kbp6KMsW/YkrKTdJNm8ORml5fiPsKWDZbaXB1sXbXN/y7zXl +Ac2xuvuDCLqe33N6hzEGyAET0oe1DpN8nnDznzeuygGZJGDSHaUUgzVdHKLuZuS9RUk 1xUGHoN894m9UJDZ3+hdnQPXEUfzDh998bWdj0BTsRTHcoHYWGI0LFNdiW3iXgxnn25J h2muuLDbdDk+ovAgO1YWu1qnJ3+XV+Wq/pZvB2ZvBhDnOcKsW6W++BxyikEQexmSqSun 6nQqnDcgqwW4D9JD2QA3P56eDmeD48YL74NaeEZWKsiDi3kGOneW5dCPsj5+ZPtjIYa+ pO0w== MIME-Version: 1.0 X-Received: by 10.194.93.74 with SMTP id cs10mr52172007wjb.9.1375296819414; Wed, 31 Jul 2013 11:53:39 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 31 Jul 2013 11:53:39 -0700 (PDT) X-Originating-IP: [24.120.221.242] In-Reply-To: <51F954DE.4090907@gondrom.org> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <51F954DE.4090907@gondrom.org> Date: Wed, 31 Jul 2013 11:53:39 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkN13zzdFKLUXRKb6Rvz736jo5u0unLg3A4Tq2Jm0Ld2nbloAU9qrqyhY2ai7bd7rpXDO8U Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec issue tracker , IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 31 Jul 2013 18:53:46 -0000 On Wed, Jul 31, 2013 at 11:18 AM, Tobias Gondrom wrote: > > > On 30/07/13 21:17, Trevor Perrin wrote: >> On Mon, Jul 29, 2013 at 1:38 PM, websec issue tracker >> wrote: >>> #60: Well Known URIs vs Response Headers >>> >>> This is about a suggestion to replace the HPKP header with an RFC 5785 >>> well-known URI. This would allow lower bandwidth, as this resource would >>> be read at most once per connection, rather than with each request. >> To me this seems related to a couple other issues: >> - can a client pin CAs by name, or will the client have to list >> potentially dozens of hashes in the header? >> - is the header sent on every response from the pinned host, or is it >> only returned infrequently or to a client who asks for it? >> >> If CAs can be pinned by name, or if response headers are only returned >> to a client who asks for them, then large headers don't matter much. >> >> But the current draft seems inefficient / inelegant, since an HPKP >> header may contain dozens of hashes. The header must be sent on >> *every* response from a pinned site (draft-08, section 2.2.1), so the >> client must process the header on every response. > > actually the client does not have to process the hash for every > response. A simple compare with the previous cached hash(es) is > sufficient. So less processing effort. For *every* HTTPS response from a pinned site the client would have to load its cached entry, parse the header, compare all parsed hashes with all stored hashes, and update the cache / writethrough to disk (because the "most recently observed" time changes on every HTTP response, and the spec mandates tracking that). Not a big deal in the scheme of things, maybe, but in my limited browser devel experience they are extremely performance sensitive. All this strikes me as inelegant. Trevor From ynir@checkpoint.com Wed Jul 31 13: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 6190F21E80C1 for ; Wed, 31 Jul 2013 13:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 lXSViIesQ4HS for ; Wed, 31 Jul 2013 13:33:52 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAF521E80B7 for ; Wed, 31 Jul 2013 13:33:51 -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 r6VKXkwu032665 for ; Wed, 31 Jul 2013 23:33:46 +0300 X-CheckPoint: {51F974AA-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 23:33:45 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USAgAD8uoCAAiUAAA== Date: Wed, 31 Jul 2013 20:33:45 +0000 Message-ID: <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.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.170] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 119c60efd55c10076fbea7b43283ff8c529bd94947 Content-Type: text/plain; charset="us-ascii" Content-ID: <6EC54C5AE661C343B0AAD212B2343959@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 31 Jul 2013 20:33:58 -0000 Hi all This issue turned out to be more contentious that I had expected. We've had= two people in support of the change, in addition to one response that seem= s to indicate support for such a change, and Mark's remarks at the meeting,= which were also kind-of, sort-of in support of such a change. This does not look to me like consensus to keep the status quo. Do others f= eel differently? If so, please speak up soon. And for those who would like to use a .well-known resource, can you suggest= a format for the key pinning resource? Yoav From jbonneau@gmail.com Wed Jul 31 14:01:43 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8621F8A85 for ; Wed, 31 Jul 2013 14:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 TvRLLaTEep7R for ; Wed, 31 Jul 2013 14:01:43 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0019A21F89A6 for ; Wed, 31 Jul 2013 14:01:42 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id db10so1442882veb.0 for ; Wed, 31 Jul 2013 14:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/w+NnLXGSMxnj2/bIzY1zN4el3S4Fn9dqLlPOkYKa5s=; b=E8q4d9Mbxx0sgkYureg7CCuiLme19PnncH3exI/uYuB8lD9L7o4QiPBF8MiH7/GBeI JIK3Wuwl8DBPT2wZ8KM3SHIGs3VJ6lxL/WdsP3+uol5M5sPxduEMfCKy+rL6taeI5XqQ e5MKnq7/sjBsPn8ZGmDE4nVMihFO6gaY6M+sCW8tDY7c//uB7fBq7R082Db9KfwlnzPw bpJIvVeuceggj6asS4r9H3LpFYM09tLY0SBgLlI1LRG4CmwWNAdbkM5TMWWrHlFoOoXK FxB3C5hex7IXWXlpOWKc5kpkp7XP8XRtR4S3pOc7K++p+ZZ9zTFr0jYiTYJuUwRaZxOG /P6A== X-Received: by 10.52.77.5 with SMTP id o5mr24493598vdw.46.1375304502149; Wed, 31 Jul 2013 14:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.103.69 with HTTP; Wed, 31 Jul 2013 14:01:22 -0700 (PDT) In-Reply-To: <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> From: Joseph Bonneau Date: Wed, 31 Jul 2013 17:01:22 -0400 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=20cf3071c6ee4f0a3a04e2d508a5 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 31 Jul 2013 21:01:43 -0000 --20cf3071c6ee4f0a3a04e2d508a5 Content-Type: text/plain; charset=UTF-8 > This issue turned out to be more contentious that I had expected. We've > had two people in support of the change, in addition to one response that > seems to indicate support for such a change, and Mark's remarks at the > meeting, which were also kind-of, sort-of in support of such a change. > I'm in support of a change, I hope I'm counted as such. > And for those who would like to use a .well-known resource, can you > suggest a format for the key pinning resource? I think the simplest option is to use a CSP-style format, with multiple lines of "directive-name : value," such that Strict-Transport-Security and Public-Key-Pins headers could be pasted directly on such lines with no other changes to the spec. Future security policies could be defined/added as needed such as "Strict-Certificate-Transparency : max-age=N" An alternative would be a JSON or XML file which might be a little more extensible and easier to parse, but would require more re-writing of this and other specs. Joe --20cf3071c6ee4f0a3a04e2d508a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This issue turned out to be more contentious that I had expected. We've= had two people in support of the change, in addition to one response that = seems to indicate support for such a change, and Mark's remarks at the = meeting, which were also kind-of, sort-of in support of such a change.

I'm in support of a change, I hope I&#= 39;m counted as such.
=C2=A0
= And for those who would like to use a .well-known resource, can you suggest= a format for the key pinning resource?

I think the simplest option is to use a CSP-style forma= t, with multiple lines of "directive-name : value," such that Str= ict-Transport-Security and Public-Key-Pins headers could be pasted directly= on such lines with no other changes to the spec. Future security policies = could be defined/added as needed such as "Strict-Certificate-Transpare= ncy : max-age=3DN"=C2=A0

An alternative would be a JSON or XML file which = might be a little more extensible and easier to parse, but would require mo= re re-writing of this and other specs.

Joe
--20cf3071c6ee4f0a3a04e2d508a5-- From trevp@trevp.net Wed Jul 31 16:51: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 78DDD21E8056 for ; Wed, 31 Jul 2013 16:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 Lx7tEy+m4vUH for ; Wed, 31 Jul 2013 16:50:55 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE0A21F996A for ; Wed, 31 Jul 2013 16:50:54 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so1112116wgh.13 for ; Wed, 31 Jul 2013 16:50:53 -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=H/kvt8IN2LUueI2VFR0yk0XUhKpxoHhK5IT+ift9HQc=; b=lxMqw/DyIZUV0mqQl07kkZHzedzl6MuK2Sq3EYfj3lDCGBFlkkwks+Krwgy/UO07JJ cVYK7MDNHergkwLg3sCz4KdIr3OlvyOKWB20y4fucjPPHfVnkx0/PU28ul1cVXHvkKds s852YD/IEQitHqZoLZUUcPp153axT9FZ1DFLiWOAYfv23hr0MdnLO5HmybsvvuFFmfFb B7lPLUIfc/aOaFWttKzI3Au+NPyil1EJnN2gY7QXRFD2u8jEVRXA2fgQmMFVukdp9NYh zK3S//yEAc2fuGquNeXh2/hqst813xLHyHkP7vLiDpkoTt8975gUNM/hmulhWjJ7ol4s +qqA== MIME-Version: 1.0 X-Received: by 10.180.74.232 with SMTP id x8mr5834947wiv.48.1375314653278; Wed, 31 Jul 2013 16:50:53 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 31 Jul 2013 16:50:53 -0700 (PDT) X-Originating-IP: [24.120.221.242] In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> Date: Wed, 31 Jul 2013 16:50:53 -0700 Message-ID: From: Trevor Perrin To: Joseph Bonneau Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmwEouh0SjdaoEDT4BX5r18TcUItQQGJ4KYOgP/UicX1s6PlSOk2jMBdwbCl5YyL+6zGl2x Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 31 Jul 2013 23:51:01 -0000 On Wed, Jul 31, 2013 at 2:01 PM, Joseph Bonneau wrote: > > I'm in support of a change, I hope I'm counted as such. Me too. >> And for those who would like to use a .well-known resource, can you >> suggest a format for the key pinning resource? I'd vote for JSON, I think it's easier & safer than custom parsers based on BNF. I looked over the websec slides, and I think there's one misconception about this: """ W-K URI introduces a blocking load in the path for loading pages/resources, increased pageload latency. "" I don't see why this would be a blocking load. I would expect it to be done in the background, so have no latency impact. Trevor From palmer@google.com Wed Jul 31 17:53:50 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 6735221F9346 for ; Wed, 31 Jul 2013 17:53:50 -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 YxHJIQP5PL0r for ; Wed, 31 Jul 2013 17:53:50 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 013AB21F856A for ; Wed, 31 Jul 2013 17:53:49 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wc20so2756107obb.0 for ; Wed, 31 Jul 2013 17:53:49 -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=Ef+F1InADIilYtXgMWGRHx7HMkHQexVWON1Sqo7y12Y=; b=E7524aLc9mXJQnipUCnUwLKZPzk+usJgA8cgwFSl/TKNdRYhcr+sPxO2jmFXhWq5CP +c2d/iQ5kQt53SIn6TZgtnmvoArRJd6vq7AWFl4vWW2wGaOYN2OqdctEmLgiB2hkzTMK 7tk/MBDvtl2lYPrB0921p0JGhZOQB9oW/xpzU9qLm9LEWes89bSaS9nmo2gDMyyz2EDH vU+k4n8qcm6q0a0Uq7I0wbK5ROlLKOG21/1uhWBhqjK1WHqXFJC8enCz0XgUYYCiVyrk gHEggJgzkep0I+wi/AetdundoJCrBPdDzzviGu8EBK6/9WHQsu7NMxf71gICH1KFZKEv zQZw== 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=Ef+F1InADIilYtXgMWGRHx7HMkHQexVWON1Sqo7y12Y=; b=S90l0pL7U9MomciJXc/3G68kCq6uhjUlHcEqIuuKSWVoS3n1wkyGZAQgt/pZSUyXN7 j4NR/cGE+k7oamqkLSiy7ji/8uunrszzS6WbMGMRzVeVe5+l5QNg/kHeKeneiVcB6JZg eUwAfW6FiC0aHPu/Kz17jXGpSndqOVrQcBS0STF8I9VFeTeOhgYwev0YcO5UDoRkJVsh NIu3lf1tFEiowfztuEYGEWQfFBNuLM/cl/1kB2Fj4/4jNY/v/o++i7KX8CZxgeqq0wQo TaqRRqgyyX129lDT8UU9UC0W/2Qu+vwgWG/kqkSi9l3MSnu93DM52ZEaDcM7P1poXx0i f1KA== MIME-Version: 1.0 X-Received: by 10.42.224.136 with SMTP id io8mr12217026icb.54.1375318427457; Wed, 31 Jul 2013 17:53:47 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Wed, 31 Jul 2013 17:53:47 -0700 (PDT) In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> Date: Wed, 31 Jul 2013 17:53:47 -0700 Message-ID: From: Chris Palmer To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmcVQVimPLOmzBp9rODJIoyvtle3uBt4fmoPHNUCSviSw7Ic7Ly+afxSuoGHlJPT8WAM81i9Cw1M3HqAulARfUeFZ3NT6M7ZuEpXPxhOotf0Y9+UEm0mkTDEJYHiiRKTufe0rVylJ56yrzHHn/iALTMqZj6ubBXLN8qJHm6kbkJwMQ3U3U3/mtIdW2vRRmXLhx43V0h Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 00:53:50 -0000 On Wed, Jul 31, 2013 at 4:50 PM, Trevor Perrin wrote: > I don't see why this would be a blocking load. I would expect it to > be done in the background, so have no latency impact. So are we supposed to send cookies (for example) to the server before finishing the W-K URI load? If I completely rewrite HPKP to be a W-K URI I-D encompassing all of HSTS, HPKP, and CSP (and what else?), does that actually have a chance of flying? Or would it be a waste of everyone's time? Keep in mind that including more people, including the authors of RFCs who think their work is done, will make for a very slow and expensive process. From trevp@trevp.net Wed Jul 31 20:22: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 712C911E80FD for ; Wed, 31 Jul 2013 20:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 epAUJX80sXwk for ; Wed, 31 Jul 2013 20:22:36 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7116F21F90CC for ; Wed, 31 Jul 2013 20:22:31 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t57so1224854wes.24 for ; Wed, 31 Jul 2013 20:22:31 -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=/BHoE+QF0Kv/5fpE1JDYt95go0mcMbQpxROWJKe9e7w=; b=A6KPyIIF/3lPy/oO9yOr6m0v+cixSJzorqBQYB6IEWFXzPrzxF4sDkvlgEXpECFJwf iIMyD9Q5dk9GpCUk9OUUhfSdJfQa9jMhcgxcZDvkKwPTnCvcl2Yho4kjULa6cKt2WPS+ +KtjcjIdz8zpuk9c1RUS8GTn2uYIMXqJ6Iw20YHEdHF45avCY5URWTVnuC228XiSee8c J+3cq7a0Z30YN+jyiUrqeQHIprcovzgkodaWnKPbdZ6I6Q8t51Dr5k0eeVPwCRV6AUfv 868fTCyj7M0n69o+iGAYoH8BOZwz6nAQ01ZN6zw3jC6MAkfeXS6EQpM+GlUcesQQecD0 CUIA== MIME-Version: 1.0 X-Received: by 10.194.93.74 with SMTP id cs10mr53286374wjb.9.1375327350966; Wed, 31 Jul 2013 20:22:30 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 31 Jul 2013 20:22:30 -0700 (PDT) X-Originating-IP: [24.120.221.242] In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> Date: Wed, 31 Jul 2013 20:22:30 -0700 Message-ID: From: Trevor Perrin To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm3UW8iBadXwh6g/FwrKjBad5BmjcMJ7u623wvW0xkZ1vl0lwTdzOs4iYnVUhcbusTijOUS Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 03:22:42 -0000 On Wed, Jul 31, 2013 at 5:53 PM, Chris Palmer wrote: > On Wed, Jul 31, 2013 at 4:50 PM, Trevor Perrin wrote: > >> I don't see why this would be a blocking load. I would expect it to >> be done in the background, so have no latency impact. > > So are we supposed to send cookies (for example) to the server before > finishing the W-K URI load? Sure. That's how HPKP currently works: cookies are sent before the server has a chance to deliver an HPKP header. I don't think this needs to be different? > If I completely rewrite HPKP to be a W-K URI I-D encompassing all of > HSTS, HPKP, and CSP (and what else?), does that actually have a chance > of flying? Hmm, I wouldn't encompass all those things. I'd just create a "security_policy.json" with HPKP data in it. But allow it to be extended in the future. If other people want to write their own specs to add data into it, that's great - it's a convenient single place for browsers and web crawlers to find security policy for a site. But we don't need to do all that immediately... Trevor From dkg@fifthhorseman.net Wed Jul 31 21:13: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 880B621F9AD8 for ; Wed, 31 Jul 2013 21:13:03 -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 y8lbuFn-kJeK for ; Wed, 31 Jul 2013 21:12:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4021F9ABB for ; Wed, 31 Jul 2013 21:12:52 -0700 (PDT) Received: from [192.168.13.102] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 149BDF984 for ; Thu, 1 Aug 2013 00:12:47 -0400 (EDT) Message-ID: <51F9E03E.2070103@fifthhorseman.net> Date: Thu, 01 Aug 2013 00:12:46 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: IETF WebSec WG References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2EDTBFUUJXJKCNUGLCJXA" Subject: Re: [websec] #60: Well Known URIs vs Response Headers X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF WebSec WG List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 04:13:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EDTBFUUJXJKCNUGLCJXA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/31/2013 11:22 PM, Trevor Perrin wrote: > If other people want to write their own specs to add data into it, > that's great - it's a convenient single place for browsers and web > crawlers to find security policy for a site. I'm finding myself more and more convinced by the well-known URI suggestion as well, despite the PITA that overhauling the spec is likely to be. Headers usually say something about a given HTTP request; the headers we're discussing here say something about the site as a whole. In addition to the extra overhead of re-evaluating the header on each request, there is a potential security hole for sites which permit users to control some subtree of the URL space. For example, if the administrators of https://example.net/ allow the user foo to publish arbitrary content below https://example.net/~foo/, and that user emits an HPKP header, they could potentially override the backup pins offered by the site administrator, or set an HSTS header with includeSubDomains that would cause other unrelated requests to fail closed, potentially for weeks or months depending on the max-age. Control of a specific well-known URI seems more likely to be restricted to the administrator. With a well-known URI, there are probably still caching issues to stake out; how often should a browser update its security policy for a given site in the absence of standard HTTP caching headers from the server? Or is it a MUST that the well-known URI needs to publish caching headers?= --dkg ------enig2EDTBFUUJXJKCNUGLCJXA 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.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJR+eA+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcmKQQAKZEZDzMzos2xWKVHInyM5QK ZVBx/nA/ZD0kldJ41raRQjkmWS7pgKEClghGw4Dk7J1S3LfKdN/lFj/afNcoPYk4 NZbzWJMJl4jsYT1IPmpm9He2Wm2wkHNxHQtgeaM/VE6zAinIIVSj/RJNsIOraQr/ nV6Y9hdnNbjsXz5z61T0ecJP/uvXWDtWmHEKBffeGrALXbiLprfeByE0UhFFWdPy Z1SiPRJ51VGI1kjzI3eCErBTfAaQ6oIDrf2eL5JT7+/QWYaSP+P/oYqd93wzsS1L zTuxMjye+OqYUl7xjyvOlKGImdhDg/6m8ReqGOHCHVHsqeoBODYcbuObwDwfKOdo K+YABnYkyuualdSpu3iSlF/fHw5zE3o2fU61o2BKARLNv3aNbCzYO2y+w0QZZGWj 2tcxnjf+eLfGWS84ROLeMyfktQb8/AsauyxEe/lo35nUKNxcd4YDIYekQGIhOOTE bN70r6mYTFdR6uUkDLRbaHsg2INLDq+AsWi93YVPnm5G7jPbI6vkdh/fZ6k75sni 7BhhTHnbstyCvjzLn5bdeulA7phHmgs5I6/OOiZZRaCrWlfNR9btkhfVsRaR3yqn 7gfQUXfrsqylwvKKtRUPWIcS2ulQmh4L8uTOWzAUu85DoMrUY7POv2fSF0Tk0DxI WD4M576nB9qLZq8OJGxs =SHfW -----END PGP SIGNATURE----- ------enig2EDTBFUUJXJKCNUGLCJXA-- From tobias.gondrom@gondrom.org Wed Jul 31 23:22:50 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 9A45E21F9B10 for ; Wed, 31 Jul 2013 23:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.124 X-Spam-Level: X-Spam-Status: No, score=-96.124 tagged_above=-999 required=5 tests=[AWL=-0.762, 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 fn1YvRhMMVNE for ; Wed, 31 Jul 2013 23:22: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 59E1A21F9CE3 for ; Wed, 31 Jul 2013 23:22:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=uMe58btTBkJXW5ZasBO13z99A9tO/p/w/XPLiVvLtt89AC+lVYVfk5tU5T8KzPoI/vRROGp9nocMvD5foNgwiwzyKjVGmbOLnfCbx9L4JKkma++QanMlHfWPh3dQHycg; 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 31874 invoked from network); 1 Aug 2013 08:22:44 +0200 Received: from dhcp-461e.meeting.ietf.org (HELO ?130.129.70.30?) (130.129.70.30) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Aug 2013 08:22:44 +0200 Message-ID: <51F9FEB3.90500@gondrom.org> Date: Thu, 01 Aug 2013 08:22:43 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: palmer@google.com References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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, 01 Aug 2013 06:22:50 -0000 On 01/08/13 02:53, Chris Palmer wrote: > On Wed, Jul 31, 2013 at 4:50 PM, Trevor Perrin wrote: > >> I don't see why this would be a blocking load. I would expect it to >> be done in the background, so have no latency impact. > So are we supposed to send cookies (for example) to the server before > finishing the W-K URI load? > > If I completely rewrite HPKP to be a W-K URI I-D encompassing all of > HSTS, HPKP, and CSP (and what else?), does that actually have a chance > of flying? Or would it be a waste of everyone's time? Keep in mind > that including more people, including the authors of RFCs who think > their work is done, will make for a very slow and expensive process. I would not expect the draft to be extended to HSTS and CSP or other things. Only consider the approach for HPKP at this time. Btw. a few thoughts: personally I am not so comfortable with the resource part yet and would still prefer the header, but like to do some more research before I make any arguments. And there might actually be another approach: Finish HPKP as is with header and start a generic draft on moving "everything" (extendable) to a resource location. Btw. we should also start a discussion with W3C webappsec to learn what they think about it, as CSP is done there. Cheers, Tobias > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ynir@checkpoint.com Wed Jul 31 23:46:26 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C530821F9AAE for ; Wed, 31 Jul 2013 23:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 4bApODNzXNw2 for ; Wed, 31 Jul 2013 23:46:22 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6D97F21F864D for ; Wed, 31 Jul 2013 23:46:21 -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 r716k8Xl011188; Thu, 1 Aug 2013 09:46:09 +0300 X-CheckPoint: {51FA0430-25-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 09:46:08 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USAgAD8uoCAAiUAAIAAB7gAgAAvXYCAAHQGgA== Date: Thu, 1 Aug 2013 06:46:08 +0000 Message-ID: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.100] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11d4f35d621f8fa60d6d285ce53a4c5bbffbe1a6e2 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <98744D11ABDFBB4CB6911B83BE667D2C@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 06:46:26 -0000 On Aug 1, 2013, at 1:50 AM, Trevor Perrin wrote: > On Wed, Jul 31, 2013 at 2:01 PM, Joseph Bonneau wrot= e: >=20 >>> And for those who would like to use a .well-known resource, can you >>> suggest a format for the key pinning resource? >=20 > I'd vote for JSON, I think it's easier & safer than custom parsers based = on BNF. And for maximum IETF buzzword-compliance, JSON encoded with CBOR ( http://t= ools.ietf.org/html/draft-bormann-cbor-04 ) > I looked over the websec slides, and I think there's one misconception > about this: > """ > W-K URI introduces a blocking load in the path > for loading pages/resources, increased pageload latency. > "" >=20 > I don't see why this would be a blocking load. I would expect it to > be done in the background, so have no latency impact. Yes, we did mention it at the meeting. HPKP only impacts the next connectio= n, so we might as well load it last in HTTP/1 and load it with low priority= in HTTP/2. Yoav= From ynir@checkpoint.com Wed Jul 31 23:56:26 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B34C21F8F2E for ; Wed, 31 Jul 2013 23:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.531 X-Spam-Level: X-Spam-Status: No, score=-10.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 9MVIkmZ89xav for ; Wed, 31 Jul 2013 23:56:20 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0D15B21F8D96 for ; Wed, 31 Jul 2013 23:56: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 r716pPvO013511; Thu, 1 Aug 2013 09:56:17 +0300 X-CheckPoint: {51FA056D-6-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 09:53:59 +0300 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USAgAD8uoCAAiUAAIAAB7gAgAAvXYCAABGTgIAAZKIA Date: Thu, 1 Aug 2013 06:53:58 +0000 Message-ID: <59E82BE9-84A0-4BC2-803D-5FB3C6A1E270@checkpoint.com> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.100] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 116672a0bd2c4283ae8b302f516478c4a58c5d0192 Content-Type: text/plain; charset="us-ascii" Content-ID: <7D49DE278526A14BA315DC23122F08AC@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 06:56:26 -0000 On Aug 1, 2013, at 2:53 AM, Chris Palmer wrote: > On Wed, Jul 31, 2013 at 4:50 PM, Trevor Perrin wrote: >=20 >> I don't see why this would be a blocking load. I would expect it to >> be done in the background, so have no latency impact. >=20 > So are we supposed to send cookies (for example) to the server before > finishing the W-K URI load? >=20 > If I completely rewrite HPKP to be a W-K URI I-D encompassing all of > HSTS, HPKP, and CSP (and what else?), does that actually have a chance > of flying? Or would it be a waste of everyone's time? Keep in mind > that including more people, including the authors of RFCs who think > their work is done, will make for a very slow and expensive process. I agree with Tobias. Assuming this is the consensus, we should do /.well-kn= own/PublicKeyPinning If someone ever wants to encompass all of the policy things (CSP, HSTS, and= HPKP) in one big /.well-known/ServerPolicy that's another effort that coul= d start here or at W3C, and is not in our charter. But anyway, that's maybe= in the future. Adding a well-known URI to the server is fairly easy. Since you (Chris) wor= k for Google, you're in a better position than us to tell the group whether= it would be acceptable for a browser such as Chrome to go and fetch the we= ll-known URI. IMO it's not much different than fetching favicon, but I gues= s would know better. Yoav