From Jeff.Hodges@KingsMountain.com Thu Dec 6 08:06:41 2012 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 4824D21F8582 for ; Thu, 6 Dec 2012 08:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcDj5+AnQtIb for ; Thu, 6 Dec 2012 08:06:40 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 4AFF221F85B2 for ; Thu, 6 Dec 2012 08:06:40 -0800 (PST) Received: (qmail 20974 invoked by uid 0); 6 Dec 2012 16:06:18 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 6 Dec 2012 16:06:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=J32l3+TGlhjK9n5rYIrEnbsEi9H/sIAOPZhsYmAvlx4=; b=AZq3X7tnvUFGqnZedTktQhEjPQ00j02sumngQk8kZfsyr+7lYBSdE/Figa5AjqGlZWkvWe01HtyTfXpUHh/lh+ZefIt9Mf7Q6DuBym/ceVTWng3IsOzuvLdPqAQ62WJ2; Received: from [216.113.168.128] (port=26266 helo=[10.244.137.210]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Tgdxp-0005qY-MJ; Thu, 06 Dec 2012 09:06:17 -0700 Message-ID: <50C0C278.7050302@KingsMountain.com> Date: Thu, 06 Dec 2012 08:06:16 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: HTTP State , IETF WebSec WG , HTTP Working Group , Apps Discuss , IETF oauth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] fyi: IETF conflict review results for draft-secure-cookie-session-protocol 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, 06 Dec 2012 16:06:41 -0000 [ I was nosing around and noticed this relatively recent decision, it didn't appear to have been fwd'd to these lists. fyi/fwiw... ] Subject: Results of IETF-conflict review for draft-secure-cookie-session-protocol-08 From: The IESG Date: Mon, 19 Nov 2012 14:46:52 -0800 To: "Nevil Brownlee" , draft-secure-cookie-session-protocol@tools.ietf.org Cc: iana@iana.org, The IESG , ietf-announce@ietf.org The IESG has completed a review of draft-secure-cookie-session-protocol-08 consistent with RFC5742. The IESG has no problem with the publication of 'SCS: Secure Cookie Sessions for HTTP' as an Informational RFC. The IESG has concluded that this work is related to IETF work done in the websec and httpbis working groups, but this relationship does not prevent publishing. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-secure-cookie-session-protocol/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary ### IETF conflict review for draft-secure-cookie-session-protocol [conflict-review-secure-cookie-session-protocol-00] https://datatracker.ietf.org/doc/conflict-review-secure-cookie-session-protocol/ Conflict Review State: Approved No Problem - announcement sent Shepherding AD: Barry Leiba Last updated: 2012-11-19 Conflict Review for draft-secure-cookie-session-protocol-09 The IESG has concluded that this work is related to IETF work done in the websec and httpbis working groups, but this relationship does not prevent publishing. ### From barryleiba.mailing.lists@gmail.com Thu Dec 6 11:34:55 2012 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 7C3C921F88C1; Thu, 6 Dec 2012 11:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.093 X-Spam-Level: X-Spam-Status: No, score=-103.093 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf1yeV96Vi7G; Thu, 6 Dec 2012 11:34:55 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47D3E21F867A; Thu, 6 Dec 2012 11:34:49 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5909765lbk.31 for ; Thu, 06 Dec 2012 11:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6hgqy6AxD2R9SZxoPfFAKdFGbY/9J4+Dx5UZdm8Mfqo=; b=w9guA4XFOKSC774g7SX+soD1m+Y6+QRF6mkNXKlBVdISLQvhx9Hihwr00e+plLeDPP yHZR2tTQo0G+zV3FyM7tZu/jQu9cdx1jzjKKCLCoPU4OqwQM3PqqDd0n2rL7zJ36MugA ccWGI3qYiDQoC/bOh+YVlm2u1VmQvsTaJUdbO54KGju5CkNy9mYKgaUF0Ui0519+H4u6 IInq3oMD3sep0OCh+sxvkgSyXmusixHxB0tIu1UzxDyW6GakQEeVI0jl4ZCkAO2KaKi9 o017MtkfpQ72bYWg5x8FqEaQhtDNa6Ak0iYQ8D+GS3/CyLk2EDeLfSIudBKZaEuHGDWL 9P8A== MIME-Version: 1.0 Received: by 10.112.25.34 with SMTP id z2mr1449204lbf.125.1354822488183; Thu, 06 Dec 2012 11:34:48 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Thu, 6 Dec 2012 11:34:48 -0800 (PST) In-Reply-To: <50C0C278.7050302@KingsMountain.com> References: <50C0C278.7050302@KingsMountain.com> Date: Thu, 6 Dec 2012 14:34:48 -0500 X-Google-Sender-Auth: OX0NyyE18yghle8XQywQyo6h5PI Message-ID: From: Barry Leiba To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF oauth WG , IETF WebSec WG , HTTP Working Group , Apps Discuss , HTTP State Subject: Re: [websec] [OAUTH-WG] fyi: IETF conflict review results for draft-secure-cookie-session-protocol 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, 06 Dec 2012 19:34:55 -0000 > [ I was nosing around and noticed this relatively recent decision, it didn't > appear to have been fwd'd to these lists. fyi/fwiw... ] ... > The IESG has no problem with the publication of 'SCS: Secure Cookie > Sessions for HTTP' as an > Informational RFC. > > The IESG has concluded that this work is related to IETF work done in the > websec and httpbis working groups, but this relationship does not prevent > publishing. Yes, Jeff, and thanks for forwarding this. To make sure people have the background... I announced on 17 Oct to this set of mailing lists that we were looking for input to the conflict review to be posted to the SAAG mailing list. The discussion thread starts here: http://www.ietf.org/mail-archive/web/saag/current/msg04049.html On 9 November, I closed the discussion with this message on the SAAG list: http://www.ietf.org/mail-archive/web/saag/current/msg04164.html If anyone has any questions about the document, I suggest they contact the authors directly. You can do that with the following tools alias: Barry, App AD From internet-drafts@ietf.org Thu Dec 6 18:11:26 2012 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 D286921F86CE; Thu, 6 Dec 2012 18:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI+KDwvOypj0; Thu, 6 Dec 2012 18:11:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6ED21F86E2; Thu, 6 Dec 2012 18:11:26 -0800 (PST) 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.36 Message-ID: <20121207021126.497.12190.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 18:11:26 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-04.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 02:11:27 -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-04.txt Pages : 19 Date : 2012-12-06 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From palmer@google.com Fri Dec 7 13:31:56 2012 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 9F72821F864D for ; Fri, 7 Dec 2012 13:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmNz9aWPzevQ for ; Fri, 7 Dec 2012 13:31:56 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFEC821F84F8 for ; Fri, 7 Dec 2012 13:31:55 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so751212lah.31 for ; Fri, 07 Dec 2012 13:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eO9l8e1Oaz11Ax3uHUPPrCYOALQvyT64deHLBiKh/B0=; b=m5LCmruiXEHtmUHq0OqoeBXS63hmD8tQ88RsPadwPCTN9pSLkGT0BR3dNf23aznN3O lO5+UHLENmmeLfR78fToaLBB+eyFLTKDWhpGwgOg513zLOsIQ2Gk9xe/m22ejeAGSGJn PjqpylZUhbYcB9iXHduvVSzj/E6TwmMtQOyN2jsOqYc7Xo5mqBtKhDbcI8XOt2PELc6P 4nCzZrsvrF9VXTCqlNUyvxLVIykZb4rpNR8aGIktru3bvW3KZDRJW4mNE/stZTYwVMAB buwiudLT6+U/7m+8MJtuWDg48JOK0OEVFZINLFnyWqumr2JRerN+XYlkZAwr9IVTKARr mQmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=eO9l8e1Oaz11Ax3uHUPPrCYOALQvyT64deHLBiKh/B0=; b=AIapzmEGWyoW6NXdSEdTNZZdclwQcUJR9DJ23Gq/EwkXZMNYoTuyIFi6VaPDqmpK0t MdyN+jmbtmFVUCUeFe6Lx+bTPTNOT9j/rAkWOxY9G68ezhbDmVDTBqVZiAMXrXp+xdmt ptfagYoMjolkOTNlMhkSBS4XupJvA4aDOEY5UB+mZXSBZRxQdi4m0pevSAPeX1uAz+qz x6uGt2x6u/Yt0uJA3hMuYa7a+gqj95ZInSbFKsmylzu3u/TBJywwpBQEp4tbQ9G6zrh3 ddzqRWjBPHNQjhmS3PuYnRTAlcNM5acaPUhjy32JRqQotMk0yyaNNteutLp2LmL7iqPw tODg== MIME-Version: 1.0 Received: by 10.152.124.226 with SMTP id ml2mr6592856lab.46.1354915914432; Fri, 07 Dec 2012 13:31:54 -0800 (PST) Received: by 10.112.11.10 with HTTP; Fri, 7 Dec 2012 13:31:54 -0800 (PST) In-Reply-To: <073.d40b91d81cbf3caf09f91a3f886f6120@trac.tools.ietf.org> References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> <073.d40b91d81cbf3caf09f91a3f886f6120@trac.tools.ietf.org> Date: Fri, 7 Dec 2012 13:31:54 -0800 Message-ID: From: Chris Palmer To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQku5VPIklJDhmSjcxDGRToMxopLHAc6CeDW8BdiU4AAGIfG949GlYIHHgSRB8GoPtLOqQBByGFaN9c+rPvRZfOEoOjyqS2cQjkTNq/rM/SkaUK+EjJnSdVPvtxnEniIizRi8EsIgbQ2imiG/XvWO47hPkJOx+PJlsCrplqclnEcahayEoA2CUXiulBw/t5RP1tTZFnO Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 21:31:56 -0000 On Thu, Nov 8, 2012 at 2:01 PM, websec issue tracker wrote: > #56: Specify includeSubdomains directive for HPKP > > Ticket URL: Do people agree that draft -04 resolves this issue? From ynir@checkpoint.com Fri Dec 7 14:17:08 2012 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 2969121F8635 for ; Fri, 7 Dec 2012 14:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsKnM8DaHigV for ; Fri, 7 Dec 2012 14:17:07 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 37CAC21F8554 for ; Fri, 7 Dec 2012 14:17:06 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qB7MH3N5014122; Sat, 8 Dec 2012 00:17:03 +0200 X-CheckPoint: {50C26A77-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.14]) by IL-EX10.ad.checkpoint.com ([169.254.2.14]) with mapi id 14.02.0318.004; Sat, 8 Dec 2012 00:17:02 +0200 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] #56: Specify includeSubdomains directive for HPKP Thread-Index: Ac29/KFqbNwecIobRmigYbSjgVG+YAWtOHUAAAGTOgA= Date: Fri, 7 Dec 2012 22:17:02 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EDD6872@IL-EX10.ad.checkpoint.com> References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> <073.d40b91d81cbf3caf09f91a3f886f6120@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.199] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11c08715ba730164c69a35807b6668c38162ea6dea Content-Type: text/plain; charset="us-ascii" Content-ID: <9EC43DF6A277F748B1E88FD186EB1498@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 22:17:08 -0000 On Dec 7, 2012, at 11:31 PM, Chris Palmer wrote: > On Thu, Nov 8, 2012 at 2:01 PM, websec issue tracker > wrote: >=20 >> #56: Specify includeSubdomains directive for HPKP >>=20 >> Ticket URL: >=20 > Do people agree that draft -04 resolves this issue? Sort of. I see that includeSubdomains is included, but I couldn't find the = discussion about resolving conflicts between a superdomain (such as google.= com) that has the includeSubdomain directive, and a subdomain (such as www.= google.com) that has a different key in its PKP directive. This question is= asked in the ticket. I'm also not sure how that could ever work. Suppose I go to google.com, an= d get the pin with the includeSubdomain directive. Next, I go to www.google.com, and the pin doesn't match the TLS handshake. = Wouldn't the UA immediately terminate the connection, with no opportunity t= o ever receive any HTTP header? How will the more specific pin ever get set= ? Yoav From ryan-ietfhasmat@sleevi.com Fri Dec 7 21:58:11 2012 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 26ABA21F859D for ; Fri, 7 Dec 2012 21:58:11 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTJMNmXKGQNX for ; Fri, 7 Dec 2012 21:58:10 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5645721F854E for ; Fri, 7 Dec 2012 21:58:10 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id C90536B0070; Fri, 7 Dec 2012 21:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=jUH8krW3IcfPtbOG5u5iTk8Wt+c=; b=GRJsqQDYe26+hvsdg Vry6egr2yVeTflPV6LKuIfJBDXzmSCUJoh6QhceUEC47zJhJ78Ld7SQYtm7assgm +DQVaHK3Ctzu/WLUr2tuFgSkjL1xq57FhN/mMW+BzZj1fvj7hlJxK5SzV6O6f6+x cw0tOsdQt5i9WIm9ic0iiVr79Y= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id 848506B0059; Fri, 7 Dec 2012 21:58:09 -0800 (PST) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 7 Dec 2012 21:58:06 -0800 Message-ID: <727f8e6f1f34de7a08381f04a1f076fc.squirrel@webmail.dreamhost.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277210EDD6872@IL-EX10.ad.checkpoint.com> References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> <073.d40b91d81cbf3caf09f91a3f886f6120@trac.tools.ietf.org> <4613980CFC78314ABFD7F85CC30277210EDD6872@IL-EX10.ad.checkpoint.com> Date: Fri, 7 Dec 2012 21:58:06 -0800 From: "Ryan Sleevi" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 05:58:11 -0000 On Fri, December 7, 2012 2:17 pm, Yoav Nir wrote: > > On Dec 7, 2012, at 11:31 PM, Chris Palmer wrote: > > > On Thu, Nov 8, 2012 at 2:01 PM, websec issue tracker > > wrote: > > > >> #56: Specify includeSubdomains directive for HPKP > >> > >> Ticket URL: > > > > Do people agree that draft -04 resolves this issue? > > Sort of. I see that includeSubdomains is included, but I couldn't find= the > discussion about resolving conflicts between a superdomain (such as > google.com) that has the includeSubdomain directive, and a subdomain (= such > as www.google.com) that has a different key in its PKP directive. This > question is asked in the ticket. > > I'm also not sure how that could ever work. Suppose I go to google.co= m, > and get the pin with the includeSubdomain directive. > > Next, I go to www.google.com, and the pin doesn't match the TLS handsh= ake. > Wouldn't the UA immediately terminate the connection, with no opportun= ity > to ever receive any HTTP header? How will the more specific pin ever g= et > set? > > Yoav So, let's say the workflow is: You first visit "google.com" (or, through whatever U-A specific means exist, you have a pre-loaded pin for "google.com"). It has a PKP directive that asserts Pin(A) and Pin(B), along with includeSubDomains. The validated cert chain contains Pin(A), so the PKP is accepted, and google.com (and all of its subdomains through all levels) are set to Pin(A) and Pin(B) You now visit www.google.com IF www.google.com is not valid for Pin(A), fail the connection. That is the only acceptable path. IF www.google.com IS valid for Pin(A), it MAY assert a different pin. Since, as noted above, it MUST be valid for Pin(A), the only possible pinning that www.google.com would be to Pin to a more narrow scope of authority than A. For example, assume that Pin(A) refers to a root cert/trust anchor. www.google.com may wish to Pin(C), which is a specific subordinate CA certificate beneath A - such as an OV CA, rather than a DV CA. Further, www.google.com may wish to assert includeSubdomains as well, and all domains beneath www.google.com should pin to Pin(C) instead. This equally applies to the Enterprise PKI scenario, where you may have a DNS hierarchy that reflects an organizational layout - divisiona.mycorp.example and divisionb.mycorp.example. mycorp.example may chain to the MyCorp trust anchor, but divisiona and divisionb may assert pins to their respective Division A CA (which is cross-certified by the MyCorp root) and Division B CA (which is cross-certified by the MyCorp root). In this case, Division A CA will NOT be able to issue certificates for any name under divisionb.mycorp.example This latter case is a bit contrived, I admit - name constraints function much better for the enterprise PKI case - but hopefully it demonstrates how you can, at each level, further scope the trust anchors to the minima= l acceptable set. You may have an example.com PKP that asserts trust for 4 different, distinct root CAs, but that subdomains individually limit to specific roo= t CAs (or specific intermediates - such as EV, DV, OV, or however the root CA is configured) Finally, it may simply be the case that an entity like "example.com" want= s to assert a single pinning directive for ALL their subdomains - that is, they do not care about restricting trust as much as simply being able to have a single unified policy - and includeSubDomains (obtained dynamicall= y through the header or through a-priori crawling, much like HSTS has been done) is one way to do that. However, it sounds like all of this needs more clarification, so if the description above matches peoples expectations, I'll work to draft text t= o concisely explain these rules in the spec. From palmer@google.com Mon Dec 10 11:19:06 2012 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 B170421F860B for ; Mon, 10 Dec 2012 11:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25P2H22JFCGy for ; Mon, 10 Dec 2012 11:19:06 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5A8421F860F for ; Mon, 10 Dec 2012 11:19:05 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1951726eek.31 for ; Mon, 10 Dec 2012 11:19:05 -0800 (PST) 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=jY7MTTR9tqMS7UViD83kNgetnarG7HX62LHxsQrei5U=; b=N3e+j2HEeF/oqOesk5VnCszDXPidalLIgrV+ZcuyctC9UjnT7ituTlL2bX1Fw8Cm2d Qu8FZs2yPPcEgslRLiehAvH0TqM8MYH6ahteK4+KqqF1ckPoR+EqQbJjTuMQi/wmJEKp B2wmYRemvU4tsWc2mtKNygI9JxpLsDPJlEGOE8FJNTyNunzYwH+peNkHsV9dkJgzDeZe 9LcQudzAFfX1md0S4d3ohPg37Gy64yWlFpTIZQ4qk1mFhrCUBRCg6wnGwcS2PHZwwMtj xIZuJW20Rr2dcZCj2jR5r5yS2E5cHKKGJgxXpB15XN6+GxRVOcGnFnDzT2G8qt+cQ17f /b5g== 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=jY7MTTR9tqMS7UViD83kNgetnarG7HX62LHxsQrei5U=; b=MgatSqWH/g0JH1B9WaLjuznBWW/NioUynE5JmbP4zHSTIyx0NkPvgkTEfzzVsi2Q2y oR3eP84anD2YoDO1tegbsH3j2oJrgrjYzjkw2TejwBIuKLRScUqmuRMAu5mPlkeO4aBP Bf+aO3bWkvMdcVFkBF3b/MT3DVP2vyPk/hkQJsUvFfVoubyVulbiD00Qsin2lPTLQW8N VgTxQ2lFYTrLBE2ygeH8vkcJiFH6WB/X94fvUsYY5P4mRtFez1Fh7lP0QE+loYhkwK5m uhsojpktcGR/NHD+hno8w2a8Qetwl9s9wXO9zSXplN3/Rb9i8NqniyDrRQd/onJafDwW Lynw== MIME-Version: 1.0 Received: by 10.14.174.198 with SMTP id x46mr52646574eel.23.1355167144982; Mon, 10 Dec 2012 11:19:04 -0800 (PST) Received: by 10.223.157.143 with HTTP; Mon, 10 Dec 2012 11:19:04 -0800 (PST) In-Reply-To: <4613980CFC78314ABFD7F85CC30277210EDD6872@IL-EX10.ad.checkpoint.com> References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> <073.d40b91d81cbf3caf09f91a3f886f6120@trac.tools.ietf.org> <4613980CFC78314ABFD7F85CC30277210EDD6872@IL-EX10.ad.checkpoint.com> Date: Mon, 10 Dec 2012 11:19:04 -0800 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmGB5/rqJXPWicOQbjoLGwLdNI86zF0xIIfVkNW/pmyAIMGILUDJLFwqrjWBob3q14gg5EnVWuyxu2w6OpYNFNDjV3uP1p+4NTuuHAXxmmGJYf0ulP3I1c44JJWphnTQcGvkjirRXlpRkAvlOpFho1NuM81+4cmmqjuCNlQPoZUzzMI86Mn9A4EjlPIo2ev3J8Cn/D1 Cc: "" Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP 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, 10 Dec 2012 19:19:06 -0000 On Fri, Dec 7, 2012 at 2:17 PM, Yoav Nir wrote: > Sort of. I see that includeSubdomains is included, but I couldn't find th= e discussion about resolving conflicts between a superdomain (such as googl= e.com) that has the includeSubdomain directive, and a subdomain (such as ww= w.google.com) that has a different key in its PKP directive. This question = is asked in the ticket. In addition to Ryan's comments, I'll add that I think we should talk more in the draft about how we follow the hostname matching rules of HSTS. The only reference to it in our I-D is in section 2.3.2: """ Otherwise, if the substring does not congruently match a Known Pinned Host's domain name, per the matching procedure specified in Section 8.2 of [RFC6797], then the UA MUST note this host as a Known Pinned Host, caching the Pinned Host's domain name and noting along with it the expiry time of this information, as effectively stipulated per...""" So I think we'll add a discussion of how this affects Pin Validation (section 2.6) as well. From palmer@google.com Mon Dec 10 11:20:53 2012 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 7B47121F85D5 for ; Mon, 10 Dec 2012 11:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA4V+qc+V-F2 for ; Mon, 10 Dec 2012 11:20:52 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28F2221F85AA for ; Mon, 10 Dec 2012 11:20:50 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1324494eaa.31 for ; Mon, 10 Dec 2012 11:20:50 -0800 (PST) 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=NPv6yREkyJHTTa3rrvDxhCCQ4E/zik3agG103Ts3ReA=; b=RKC/lyLQXx0xv5tSz0HQWmKlgTVKqXMUZR0cneLLj7Bca9a0xw4wrjm6rHtwe8PC/j tOirDV5HCCh6CPsU0i/uPzQwF4Kjw8VakOt8vbkvv3hGeObEnc5+AMqdNw9IlFNMm0QZ Y/+2WpW8PonjGB5cVqAHayv2kz000uwG8QASu2CJ6Ni29SmlI2Y1y+q84HxMMy0HDylU sm4wGVVT4BN/VVVS6SnVSGWuxcbgeNl8IyKRptWS2pSR2/SFmwO63xOQIlBl4W06dBeq hPXeY2sDSq/Ck8xNZeSAoCfPh7qWPiY5j+vgnRjqH4jahzkDJMd6vlM3pjecAY/U7poq VOLg== 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=NPv6yREkyJHTTa3rrvDxhCCQ4E/zik3agG103Ts3ReA=; b=JjgkR0KlkC5TbQgdEo4qeccRrubcUYl+zO0p3ehktsPIuCEQ5KeocqMD9irl2ppo1m izeMtqDvlcxkyZyBdS3WwVQvmXTXb5fq+AWiurjm7sSELr6S7aXI1PS8YwkaTGM2m6oq Vns2cvG7AVHHk77FPUcW1JyGENvXA+cL7X4MWLytLUN2zEC2fagl1Piyot+N1qU7vuNN 9A+mRs1oB3x/5EIacbsKOoVQocGDej0t+dnglCPicaW1LtjgoAYxetJU3PcAtkGQBmVx xSbVdTvFZjyDoexhtEaUBN+m3Mg4h3x98Gm21nL+BeB62nUJmn8jdnFz5mQmjay3CSgk qFcw== MIME-Version: 1.0 Received: by 10.14.174.198 with SMTP id x46mr52660633eel.23.1355167250262; Mon, 10 Dec 2012 11:20:50 -0800 (PST) Received: by 10.223.157.143 with HTTP; Mon, 10 Dec 2012 11:20:50 -0800 (PST) In-Reply-To: <727f8e6f1f34de7a08381f04a1f076fc.squirrel@webmail.dreamhost.com> References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> <073.d40b91d81cbf3caf09f91a3f886f6120@trac.tools.ietf.org> <4613980CFC78314ABFD7F85CC30277210EDD6872@IL-EX10.ad.checkpoint.com> <727f8e6f1f34de7a08381f04a1f076fc.squirrel@webmail.dreamhost.com> Date: Mon, 10 Dec 2012 11:20:50 -0800 Message-ID: From: Chris Palmer To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmNwgKo2UVZfOEIJP9qcZphRmln0JhxWdL2/qLpSOXJ2AfDiCEO8Y6SXr2voA4ubwF+CbeS2+pFRHw8KskQ7/Ognm5nR4pHDOWReGjSyT+P8dDnMfiLXh83GkcZmoY+jbmXR6xqD4G8uH4xz8W0DvBySRkQX5Gz3Js1b4tLnFYubh1rL0D3JqSKqEQGIGwkzpBsEmN7 Cc: websec@ietf.org Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP 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, 10 Dec 2012 19:20:53 -0000 On Fri, Dec 7, 2012 at 9:58 PM, Ryan Sleevi wrote: > So, let's say the workflow is: > You first visit "google.com" (or, through whatever U-A specific means > exist, you have a pre-loaded pin for "google.com"). > It has a PKP directive that asserts Pin(A) and Pin(B), along with > includeSubDomains. > The validated cert chain contains Pin(A), so the PKP is accepted, and > google.com (and all of its subdomains through all levels) are set to > Pin(A) and Pin(B) > > You now visit www.google.com > > IF www.google.com is not valid for Pin(A), fail the connection. That is > the only acceptable path. Quick clarification: Pin(B) would also be acceptable.