From nobody Fri Apr 4 13:58:40 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E211A00B4 for ; Fri, 4 Apr 2014 13:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NerAWcSQCSB4 for ; Fri, 4 Apr 2014 13:58:35 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 092191A00CA for ; Fri, 4 Apr 2014 13:58:34 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so3953566iec.10 for ; Fri, 04 Apr 2014 13:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bDibj/ffzufxytKFYbHtdPpfu0v0AIkalGjrGfVk6u8=; b=emmBYP9iPsj87Io5fb+k50d/YUc0U6hO3s/g5SY3qvlQYbdkKaLXT1iYyzI2JRKNU3 xHTfT40wG0vubD8burAmltEoghntsOaVZVA6nLfyA8f7hR2pAvsgvEMA5IuBdISpfYOy NtMksOT//lw2HAnvUbF5rwiZ2WakndQrYgpWRoqLwjviRnIXZ4vR9zziNi2kWC+vALY/ s41Aw9dx2Vp2mtFBn3ikfIgEhqYfCGk+1hmCXDocXkiE6bVNCYIRgmsCDGiiXoDpSF8a USBNaTXOabjVpq/Te0Jk4Fj+fAhrS49Q2on1U7lzwYsm3lcPgOFqLOtGBAygUm+7OkmC J2vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bDibj/ffzufxytKFYbHtdPpfu0v0AIkalGjrGfVk6u8=; b=LEBjQO1X9xZNOf5IBHQ0EbylvP23D8zREyANmSybgqWlBksdoii0vSI68Bc/FcrV2o UYthqNAjB+1UjG8Q4v6ZQ/OxPCXieuwmdF/M75DQwCzp1+PMhyPwO09AkLzkg0FqwHWT wFv8f5ZtDOue9+Vz+NNbDb67hrPkhm80XZOabjG6BVmYMh9niK1Dql9745sae0BARvgS kPFikVQJUvafYilyJY4pHImR2RxPFrqK+InKnoGcRem+jXPHarod2WGS4A5UFlckzfnZ JSBvBmsijdgmoHWYVshHX/ZLcY27/qEptRSKejFTNX2JSpL1348jhhYFl13Eo8twkhwA 2OZg== X-Gm-Message-State: ALoCoQlnBemd4QVjtQMGk/7G7o3GDTwcvbYG6h6F9cXl1b2efZAAfVuvHRm8OyBZrY+1vgR5I6cVMV5Pmz9Ta5vvdWkX3Kzxw0S+wHHAmd1gWVZrYmybkdCWsZN315qfkOO5ATMzD+QkBO+nhNtXiPXpR9pLtqdVNuAXLmb2zh1QmtQOw6X9xmpH6j1mTErjVLtVWONy7ruX MIME-Version: 1.0 X-Received: by 10.50.136.168 with SMTP id qb8mr5712433igb.13.1396645110185; Fri, 04 Apr 2014 13:58:30 -0700 (PDT) Received: by 10.64.165.2 with HTTP; Fri, 4 Apr 2014 13:58:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Apr 2014 13:58:30 -0700 Message-ID: From: Chris Palmer To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/IS25l_iMgwPWD8TTdnrLPY8nwxg Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 20:58:39 -0000 On Fri, Feb 21, 2014 at 12:24 AM, Trevor Perrin wrote: > How should HPKP's Public-Key-Pins-Report-Only header work? > > Does it only apply a check to the current TLS connection, or is the UA > is expected to remember the pins and apply them to future connections? > > If the UA is expected to remember them, how do "Report-Only" pins > interact with regular pins? Do they override each other or are > Report-Only pins tracked separately, so that a browser might have a > Report-Only pin and a "regular" pin for the same site? Good question, thanks. I've tried to answer it in the latest rev of the draft (https://code.google.com/p/key-pinning-draft/): ===== When used in the Public-Key-Pins-Report-Only header, the UA SHOULD POST reports for Pin Validation failures to the indicated report-uri, although the UA MUST NOT enforce Pin Validation. That is, in the event of Pin Validation failure when the host has set the Public-Key-Pins-Report-Only header, the UA performs Pin Validation only to check whether or not it should POST a report, but not for causing connection failure. If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD note the Pins and directives given in the Public-Key-Pins-Report-Only header. If the UA does note the Pins and directives in the Public-Key-Pins-Report-Only header it SHOULD evaluate the specified policy and SHOULD report any would-be Pin Validation failures that would occur if the report-only policy were enforced. If a Host sets both the Public-Key-Pins header and the Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin Validation as specified by the Public-Key-Pins header, and SHOULD note the Pins and directives given in the Public-Key-Pins-Report-Only header. If the UA does note the Pins and directives in the Public-Key-Pins-Report-Only header it SHOULD evaluate the specified policy and SHOULD report any would-be Pin Validation failures that would occur if the report-only policy were enforced. When used in the Public-Key-Pins header, the presence of a report-uri directive indicates to the UA that in the event of Pin Validation failure it SHOULD POST a report to the report-uri, in addition to terminating the connection (as described in ). ===== Does that clarify? From nobody Fri Apr 4 14:12:58 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C98E1A0168 for ; Fri, 4 Apr 2014 14:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc6EwOeTdRUh for ; Fri, 4 Apr 2014 14:12:50 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BED541A00E5 for ; Fri, 4 Apr 2014 14:12:47 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rp18so3806542iec.5 for ; Fri, 04 Apr 2014 14:12:43 -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=5fHzzHgQwGZMOLHUtla7yML/13d8d/mNl0uyNeCB8Hs=; b=DjjVeY8Ml7kkOJDF4N/HxGj0V2DnD5y9wKsuRCxmKv/nmBGNSuPWNJSguxTJe9B93c 5gsFCFQumsUIi5uSUIpvoX6nQO5SvBhmSw6jraqInXC+ngjd7dJaOZNrEEMuCLDL7dFF jxSgcer7vGTSpWshCpjGrZVxVtwROO+EAV47A2ipkw3BlZ/hIiPz7oGnvz3uwUQoGhXJ sek+BYyGcJBnhJYh9zd2KNY/IWIpZonSDzTrjvbbhXvwlRUzxJvoeLG9BA37G9g4iPi3 qNBctwFqOybd9tQ4y5bWOfPXEMnz3eAVyp3AKDEWXg7FeCq8A20JpthSxtgQ645P/7Xy V1Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5fHzzHgQwGZMOLHUtla7yML/13d8d/mNl0uyNeCB8Hs=; b=EyQ7wrE2wJY5q5zpBeQTW5G18bofB1pazJx8NhjjoaZtyqGnMORAczAwZZOvnmzjW8 fZs75RNcxfb4VNLyCSOO+UaPTZPxFB3bOeYY/0ilrZW0GZWlhGCGVFEBZEoAen5vL0cR a/Z/PHho8jOT+UXS2ARgpyJCDW9oMsINZMXcq4vdDgWi+PziJtMNFPbC1XlgVlCJRVws s1TgwB9VRirr5qdQ6DM8p2yIPh+bBE/9SuXxo9FoN+ZhcqTnNXjYJgqE3zxNDSCqjseN ngAVDVIUr0nTbeK/n3HsfzI+j/QkmRlh2WO4c4aDeu0U9TwPn9iLPprgLd2b4Hx9YbOi S0og== X-Gm-Message-State: ALoCoQmVngBqBx23zx7BI7s1S42Vav+qxRVV6KXaaQiO1js6RVXMDdYf1R4i/41n6OLhuAO6AFck8fPvDPFFTztncbYh52sgu/BUwjmoio0PNSJh9smJC9V8HYQZG7vMUG60CpU/cpujdRKtrXB269xGagEy/uxIHichpswPaAt8bnaJ4qmsSMYDkq83CeFf8T2zKJPA/87u MIME-Version: 1.0 X-Received: by 10.43.51.65 with SMTP id vh1mr14852895icb.24.1396645962913; Fri, 04 Apr 2014 14:12:42 -0700 (PDT) Received: by 10.64.165.2 with HTTP; Fri, 4 Apr 2014 14:12:42 -0700 (PDT) In-Reply-To: <5307BBC3.9080505@gondrom.org> References: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> <7D003007-1B62-4365-8B0E-28647FBB21C8@checkpoint.com> <5307BBC3.9080505@gondrom.org> Date: Fri, 4 Apr 2014 14:12:42 -0700 Message-ID: From: Chris Palmer To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/frR1Z_mhb-Bi3mHlZ_Y6HTUuhIk Cc: IETF WebSec WG Subject: Re: [websec] Pre-loaded pins vs dynamic pins X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 21:12:54 -0000 On Fri, Feb 21, 2014 at 12:49 PM, Tobias Gondrom wrote: >>>> Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implementer? If not, we'll resolve it that way. >>> I don't object; I like that well enough. >> Seconded/Thirded/Fourthed > > > I agree. Thirded Done: https://code.google.com/p/key-pinning-draft/source/detail?r=261a8e2adc98156ef9c2016ffbe7af27c777dff6 From nobody Fri Apr 4 15:15:28 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E090C1A012E for ; Fri, 4 Apr 2014 15:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0MMZSXGoOV9 for ; Fri, 4 Apr 2014 15:15:20 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 82CD61A014F for ; Fri, 4 Apr 2014 15:14:53 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so4079950ier.27 for ; Fri, 04 Apr 2014 15:14: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=jb7hzuT9GV5Iy9I+7tj5s6w5E0JwcKfpaybS+XVxlZI=; b=IoMdlIBO1UR9w5zT5AQtgstoOpXSMsaIWBiLhpF80AABbIzGYT7xtTRy3zL3ST0khA MYw/K71c1EhMl8qb5g0+RBfZrsFVqxvsyNBrGh9MzGj1e2GkPKArBgxMI8BQu/HdNRY1 vXBJeTvTl4M+NHGIigROugkc+5PXcbCRBmbEBetKyLvOwmVjaFu+sThHnkMq53wQpyyq 6SOf7IS7ukOk2B3McWNcIPJZ4IGEfIkiApRvXtZj8WfFvkqvgTszJSKlNpNqAMkbRNr1 uf/4NOJ16A7QdSOeheMqaCAIJFbLmFoggkRGYR6/xv9vIFJHzxS/3bHDz76UCzf8tiYL TJxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jb7hzuT9GV5Iy9I+7tj5s6w5E0JwcKfpaybS+XVxlZI=; b=PO81YCZSr9i8C1pZ4C2IvQ6yS0rpWH0MefZuyb926UyaHKOFZG3SeA7p8szI2CHZt4 X8RGDK8Zhik4mvaEv6D4Cgd/WLF+4ySwWZ4eIZ0ffl1ArvgLAnGMTfFvTZgVjCz5TwXS chHJtO+DUuMY365NAjd1twLi2EINyMZvY0U3AzNACAe6dCTDZJOu/Bmlp4vz8cLtyqDT DT/vMreQGpMEUzB7O5AxEN0X7fOpEMj7IJWJW62MFwy4NINEFna2z4zCrlqssaVEzij3 s38CPWJ09/irIDTOvA4FXsJCp/uqScy7EPsf6i4HsTJKlmwYJqZrDxOJzdDtAUas6iAL 8awA== X-Gm-Message-State: ALoCoQlcZjWyncDWv/yiYoAFyfWo8hS+YZ1GgwA41GjlEw8bvnmUj+iUt3SX9QnkosDsqTTP09dG4qZEKpeC5lPFy2HsUonAnSqRKB0/TXxfxtKghxXYGqLNVKiLsYpzpllyTD78WoH8BNqpaL5zU7b4pKwiSQRNtbdjKhJNVscgudqPaNaQTMxs4tvrHZbONElBpnpizh3O MIME-Version: 1.0 X-Received: by 10.50.83.38 with SMTP id n6mr6026745igy.30.1396649688575; Fri, 04 Apr 2014 15:14:48 -0700 (PDT) Received: by 10.64.165.2 with HTTP; Fri, 4 Apr 2014 15:14:48 -0700 (PDT) In-Reply-To: <5308F126.7020308@fifthhorseman.net> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <5307BDFD.7060009@gondrom.org> <5308F126.7020308@fifthhorseman.net> Date: Fri, 4 Apr 2014 15:14:48 -0700 Message-ID: From: Chris Palmer To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/vAz64PWJ4-QmcUmX-vrdH0SawhE Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 22:15:25 -0000 On Sat, Feb 22, 2014 at 10:49 AM, Daniel Kahn Gillmor wrote: > I also think that (b) (unpinning) is the right answer here, considering > the semantics of the decision. > > Consider it this way: > > * the site operator gets to decide what pins they issue, and what hash > algorithms to use. > > * the site operator presumably has a rough idea of how many of their > clients are using software that might not be able to handle new hash > algorithms > > * the site operator also decides what security properties/strength they > require of a given hash algorithm. > > If the site operator considers an older hash algorithm to be too weak to > rely on, and a client only knows that hash algorithm, then the site > operator asking that client to unpin (and perhaps acknowledge the lack > of pinning to the user via whatever UI provides information about the > pin) is the right thing to do. I think I agree. > 0) if a site operator decides to use more than one hash algorithms in > the future, do we require that they issue the same set of pins under > each algorithm? So if i'm pinning keys X and Y and Z, and i'm using > both pin-sha2-256 and pin-sha3-256, must i issue 6 pins? I think it's > reasonable to say yes here, even if we don't have any other digests > defined yet. No, I'd like to say that sha256(foo.getSPKI()) == sha3(foo.getSPKI()) == sha4(foo.getSPKI()), and for UAs to treat them as identical. Any thoughts on how to write that into the spec? Or, is treating such pins as identical too crazy? > Why would you want to pin different keys with different > hash algorithms? People are weird. :) But yeah, I am kind of hoping that SHA-256 remains the only hash algorithm for HPKP for as long as that is safe, and that it is safe for a long time. > 1) If a UA knows about two hashing algorithms, then the language in 2.6 > is potentially problematic for visiting a site that provides pins using > both hashing algorithms. In particular, checking the set intersection > of all pins suggests that an attacker need only defeat the weakest hash. > I suggest that when multiple hash algorithms are known to the UA, and > it has pins for a given site under more than one hash algorithm, then it > must look for the set intersection *per hash algorithm used by the site* > and only proceed if all hash algorithms show a set intersection. Does treating H(foo) for all specified H mitigate or exacerbate your concern? From nobody Sat Apr 5 11:37:29 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B7F1A0239 for ; Sat, 5 Apr 2014 11:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJK4Z1f9hJQI for ; Sat, 5 Apr 2014 11:37:22 -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 403EA1A0259 for ; Sat, 5 Apr 2014 11:37:20 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so4969451wes.14 for ; Sat, 05 Apr 2014 11:37:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iJJ7jtFnQ4PcJXNZ+H9TX/IKfwaYF3s5zFNlUwsqN+w=; b=O/9c1ZmDZEt0CmXJTDbYpKYcsSxoDznH+eirARQxw2TjbzCLa9VdSmpLU+UilmEsYz HWr7byukfSxVmQ2/uVhk6XTOZItjlOSQ4H1dNTFsbQd3jmCY40xrFEkpZNj22LtRxSwz bkIFt8onI85BmMsBfMj/dCdATqIbN3doqUdpKY69emevvhcAxmsqsskFk2iol3q32QxF FtUcMrAQAaUXV7bktTHIYB49IvWOkF75GKXRF9H2B1RLiEpvoqpcXmL8/WB79591wQEx vvGzs6FjsZboV9ZiB5TUyJkYUoEBopSkfcFEXL1jfAZ8jdCb7O1wlCvvaWyBjVk3HMy3 3q2w== X-Gm-Message-State: ALoCoQmM3kq6BP2u0bTCSQCxsf9LCuc81ce1Q6ECzQ0qeCLOTWLWrQk8r40YUuE/wnLkRiCDLsTy MIME-Version: 1.0 X-Received: by 10.194.190.42 with SMTP id gn10mr29927810wjc.9.1396723034404; Sat, 05 Apr 2014 11:37:14 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Sat, 5 Apr 2014 11:37:14 -0700 (PDT) X-Originating-IP: [166.137.186.13] In-Reply-To: References: Date: Sat, 5 Apr 2014 11:37:14 -0700 Message-ID: From: Trevor Perrin To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/xpkLv5ChgGq7kaRa6s2NoJ7frns Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 18:37:27 -0000 On Fri, Apr 4, 2014 at 1:58 PM, Chris Palmer wrote: > On Fri, Feb 21, 2014 at 12:24 AM, Trevor Perrin wrote: > >> How should HPKP's Public-Key-Pins-Report-Only header work? >> >> Does it only apply a check to the current TLS connection, or is the UA >> is expected to remember the pins and apply them to future connections? >> >> If the UA is expected to remember them, how do "Report-Only" pins >> interact with regular pins? Do they override each other or are >> Report-Only pins tracked separately, so that a browser might have a >> Report-Only pin and a "regular" pin for the same site? > > Good question, thanks. I've tried to answer it in the latest rev of > the draft (https://code.google.com/p/key-pinning-draft/): > > ===== > > When used in the Public-Key-Pins-Report-Only header, the UA SHOULD POST > reports for Pin Validation failures to the indicated report-uri, although > the UA MUST NOT enforce Pin Validation. That is, in the event of Pin > Validation failure when the host has set the Public-Key-Pins-Report-Only > header, the UA performs Pin Validation only to check whether or not it > should POST a report, but not for causing connection failure. > > If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD note > the Pins and directives given in the Public-Key-Pins-Report-Only header. If > the UA does note the Pins and directives in the Public-Key-Pins-Report-Only > header it SHOULD evaluate the specified policy and SHOULD report any > would-be Pin Validation failures that would occur if the report-only policy > were enforced. > > If a Host sets both the Public-Key-Pins header and the > Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin > Validation as specified by the Public-Key-Pins header, and SHOULD note the > Pins and directives given in the Public-Key-Pins-Report-Only header. If the > UA does note the Pins and directives in the Public-Key-Pins-Report-Only > header it SHOULD evaluate the specified policy and SHOULD report any > would-be Pin Validation failures that would occur if the report-only policy > were enforced. > > When used in the Public-Key-Pins header, the presence of a report-uri > directive indicates to the UA that in the event of Pin Validation failure it > SHOULD POST a report to the report-uri, in addition to terminating the > connection (as described in target="validating-pinned-connections"/>). > > ===== > > Does that clarify? I think your intent is that there's 2 different types of pins (regular and report-only), which don't interact. I.e. setting max-age=0 on a regular PKP header doesn't clear PKP-RO pins, and vice versa. And when contacting a pinned site, the UA might have to apply both pins to it. Seems reasonable, if other people agree. Regarding the specific text, my guess is this will need more changes to make clear, since the document was mostly written from the perspective of there only being 0 or 1 "pins" for a connection. But I'd have to re-read it to make sure. Trevor From nobody Mon Apr 7 06:29:48 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E0A1A0771 for ; Mon, 7 Apr 2014 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zAo9O6jet2K for ; Mon, 7 Apr 2014 06:29:40 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C5FDC1A0738 for ; Mon, 7 Apr 2014 06:29:40 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id kq14so6716936pab.23 for ; Mon, 07 Apr 2014 06:29:35 -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=JIN/AczPI1SZkiNV9HIUDtapuqto2ZQlbsKPuYr2wEE=; b=KOf9dwuwcqkGMr1ImjSO20avahdfr7Z33BjKk5mP7aSVnRh/Si6W7nUfFvRtBFIr2g hXA2aZV5RKFP11jqVosMfEuiWIW2BDKuRIpmgDtrCS6HjYZimeKvwuE2LuJ8SevJ9XjF QA6FYgxxB7wYHhEN/hzjXuds+2BEr4Ile8+48= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JIN/AczPI1SZkiNV9HIUDtapuqto2ZQlbsKPuYr2wEE=; b=iBDFPAh7Q/f1b0F61uhCAs7gn7l2ithg8Z/K/O5YrxWL7ty3867UGvUPfpj1SMqZGJ 4CPVpQ4mNjU8d2tO0adq+RBnFJvaZNgg7G7y/sJJmSmXWebwMkWOUBxLEGJhKOwENIjB sztlde3R1/Cgvr7EMhxI/uW1VpAWylzc/UH7Gt03BKtsMILADoxdZu8Eg/1dcuwATWY5 tfq0YlXnIFIFTUVBHoBU/EHRTZm2Yf0y4eGwB6jYs3t3AUIw1mybWi/z69F5UEBzBSv6 KbZEhVTVoTk7dW1VGdvJzdLf+v7LdXQLftYjoKb1zZPXOspnheAAXhFdQobwRNjuu/tK yqxw== X-Gm-Message-State: ALoCoQnQFnlq6JuXfAJVqUBJgPGdYD283ftx5gvYd5wdPdRlbMlErDHDvCqphvwys5UELNwOXX3u X-Received: by 10.68.197.99 with SMTP id it3mr30517957pbc.37.1396877375256; Mon, 07 Apr 2014 06:29:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Mon, 7 Apr 2014 06:29:15 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Mon, 7 Apr 2014 09:29:15 -0400 Message-ID: To: Trevor Perrin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/5uzZMkuK2h3TeKEB5zNjDwiHJnU Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 13:29:46 -0000 On 5 April 2014 14:37, Trevor Perrin wrote: > I think your intent is that there's 2 different types of pins (regular > and report-only), which don't interact. I.e. setting max-age=0 on a > regular PKP header doesn't clear PKP-RO pins, and vice versa. And > when contacting a pinned site, the UA might have to apply both pins to > it. > > Seems reasonable, if other people agree. That is my take on it as well, and what I desired. I think the wording needs to be clarified significantly however. All of the logic around the interaction of PKP and PKPRO is buried in the report-uri subsection. I would suggest a new 2.3.2 and change the report-uri section. Textual Suggestions: My thoughts on the report-uri section:
The OPTIONAL "report-uri" directive indicates the URI to which the UA SHOULD report Pin Validation failures (). The UA POSTs the reports to the given URI as described in . When used in the Public-Key-Pins or Public-Key-Pins-Report-Only header, the presence of a report-uri directive indicates to the UA that in the event of Pin Validation failure it SHOULD POST a report to the report-uri. If the header is Public-Key-Pins, the UA should do this in addition to terminating the connection (as described in ). Hosts may set report-uris that use HTTP, HTTPS, or other schemes. If the scheme in the report-uri is HTTPS, UAs MUST perform Pinning Validation when the host in the report-uri is a Known Pinned Host; similarly, UAs MUST apply HSTS if the host in the report-uri is a Known HSTS Host. Note that the report-uri need not necessarily be in the same Internet domain or web origin as the Known Pinned Host. UAs SHOULD make their best effort to report Pin Validation failures to the report-uri, but may fail to report in exceptional conditions. For example, if connecting the report-uri itself incurs a Pinning Validation failure or other certificate validation failure, the UA MUST cancel the connection (and MAY attempt to re-send the report later). Similarly, if Known Pinned Host A sets a report-uri referring to Known Pinned Host B, and if B sets a report-uri referring to A, and if both hosts fail Pin Validation, the UA SHOULD detect and break the loop by failing to send reports to and about those hosts. UAs SHOULD limit the rate at which they send reports. For example, it is unnecessary to send the same report to the same report-uri more than once.
New 2.3.2 Interaction of Public-Key-Pins and Public-Key-Pins-Report-Only A server MAY set both the Public-Key-Pins and Public-Key-Pins-Report-Only headers simultaneously. The headers do not interact with one another but the UA MUST process the Public-Key-Pins header and SHOULD process both. The Public-Key-Pins header is processed as according to section 2.3.1. When the Public-Key-Pins-Report-Only header is used with a report-uri, the UA SHOULD POST reports for Pin Validation failures to the indicated report-uri, although the UA MUST NOT enforce Pin Validation. That is, in the event of Pin Validation failure when the host has set the Public-Key-Pins-Report-Only header, the UA performs Pin Validation only to check whether or not it should POST a report, but not for causing connection failure. Note: There is no purpose to using the Public-Key-Pins-Report-Only header without the report-uri directive. User Agents MAY discard such headers without interpretting them further. If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD note the Pins and directives given in the Public-Key-Pins-Report-Only header as specified by the max-age directive. If the UA does note the Pins and directives in the Public-Key-Pins-Report-Only header it SHOULD evaluate the specified policy and SHOULD report any would-be Pin Validation failures that would occur if the report-only policy were enforced. If a Host sets both the Public-Key-Pins header and the Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin Validation as specified by the Public-Key-Pins header, and SHOULD note the Pins and directives given in the Public-Key-Pins-Report-Only header. If the UA does note the Pins and directives in the Public-Key-Pins-Report-Only header it SHOULD evaluate the specified policy and SHOULD report any would-be Pin Validation failures that would occur if the report-only policy were enforced. From nobody Mon Apr 7 06:30:20 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2551A0782 for ; Mon, 7 Apr 2014 06:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swg6Lmd-rAVF for ; Mon, 7 Apr 2014 06:30:13 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8D43D1A0771 for ; Mon, 7 Apr 2014 06:30:01 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so6766587pbb.11 for ; Mon, 07 Apr 2014 06:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:content-type; bh=a9NbdYO4VRdLLU885YDR+/qR49DG+eImIwEy4AhftVQ=; b=ptDTwyRJrrkkcElaGszW0iyEtBbi7RU6xwm0WjUvTBMS1oyJEhHVDpCK2pVU/y9OnH IwE8E+5hkvVa6xRmA1xxwZWmGztlBqC8fnbLrabh82zkdzajzdx0zvOrcHyByQ/L3MWv 8vSPwEvcNyZyKFztQ+xA7qFxxtyHdL7ynUiRU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=a9NbdYO4VRdLLU885YDR+/qR49DG+eImIwEy4AhftVQ=; b=lcHe2mNnYixXZS2ip2CMSuzRrTLVt4I0U61vEJvnKrqGpRplwIt/V6HP9mrS9hkYOD fPNcBWj7G+NRTfQW65ObfhTHeVGxK3SbNsYGlziRR17QVmd8cfgcY/Q/9xZERZzENLHH VPG5b0KA2VDsNqJcwDO5mZ7bQLxL8z6DKFtch+3cWy9E2K0k+VdEBV7TdFTpvhLIEqOy NTWzuxKef9Os2ZmowlRP1qfEvfLxtsiGPwt8aUHEjwdAHQcjp7MUyi9+7VBQK9KmYT96 ELM+ZOskTM47Rt4gENSg2Z1vsY1zmzlj1uCaKv9doCudbfPmENb7hnpoCn70GPljswlz K/BA== X-Gm-Message-State: ALoCoQkbToNy6zAWfyf2iZjqJaxg60QRi+AvaR6iDpx+9pY0iBCPrLK5Q78KlDBY72fwUqQY/C8K X-Received: by 10.68.237.133 with SMTP id vc5mr31110622pbc.92.1396877396096; Mon, 07 Apr 2014 06:29:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Mon, 7 Apr 2014 06:29:36 -0700 (PDT) From: Tom Ritter Date: Mon, 7 Apr 2014 09:29:36 -0400 Message-ID: To: IETF WebSec WG , Chris Palmer Content-Type: multipart/alternative; boundary=047d7b338f1dfd503904f673dc5b Archived-At: http://mailarchive.ietf.org/arch/msg/websec/6pggmEjepGhGKLyEsylPoIGq0GU Subject: [websec] First Connection Active Attack in HPKP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 13:30:18 -0000 --047d7b338f1dfd503904f673dc5b Content-Type: text/plain; charset=ISO-8859-1 Sorry to be second guessing you Chris, but wanted to ask about this change: https://code.google.com/p/key-pinning-draft/source/detail?r=5810662a42e56938272d9db4b2e5373914b266f4 Let's say an active attacker does MITM on a client. (That's the scenario you reference, right?) The client can have pins for the server or not. If the client does have pins, the active attack fails and generates a report event. The attacker knows the attack fails because a) perhaps they observe metadata about the report event being sent right away but more concretely b) because their attack fails. If the client doesn't have pins, the active attack succeeds. The attacker knows the attack succeeded and that the pinning wasn't effective because... it succeeded. Whether or not a report event is generated the attacker knows it succeeded. Furthermore, if an attacker is attacking the client and wants to learn if it supports pinning or not, it can look at the User Agent header, TLS handshake fingerprinting, or active javascript injection. If the attack succeeds, and the attack already knows about it succeeding, I don't understand the harm in generating a report event. Maybe the attack will block it (and know it was generated), but maybe they won't and it will get out. Maybe the report will be held for some time and sent later. -tom --047d7b338f1dfd503904f673dc5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry to be second guessing you Chris, but wanted to ask a= bout this change:=A0https://code.google.com/p/key-pinning-draft/source/detail?r=3D5810662a42= e56938272d9db4b2e5373914b266f4

Let's say an active attacker does MITM on a client. =A0(= That's the scenario you reference, right?) =A0The client can have pins = for the server or not.

If the client does have pin= s, the active attack fails and generates a report event. =A0The attacker kn= ows the attack fails because a) perhaps they observe metadata about the rep= ort event being sent right away but more concretely b) because their attack= fails.

If the client doesn't have pins, the active attack = succeeds. =A0The attacker knows the attack succeeded and that the pinning w= asn't effective because... it succeeded. =A0Whether or not a report eve= nt is generated the attacker knows it succeeded. =A0Furthermore, if an atta= cker is attacking the client and wants to learn if it supports pinning or n= ot, it can look at the User Agent header, TLS handshake fingerprinting, or = active javascript injection.

If the attack succeeds, and the attack already knows ab= out it succeeding, I don't understand the harm in generating a report e= vent. Maybe the attack will block it (and know it was generated), but maybe= they won't and it will get out. =A0Maybe the report will be held for s= ome time and sent later.=A0

-tom
--047d7b338f1dfd503904f673dc5b-- From nobody Tue Apr 8 21:36:02 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDC81A0097 for ; Tue, 8 Apr 2014 21:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eARVy8E3uXaP for ; Tue, 8 Apr 2014 21:35:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 959171A008A for ; Tue, 8 Apr 2014 21:35:58 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 425F3F986; Wed, 9 Apr 2014 00:35:57 -0400 (EDT) Message-ID: <5344CE2D.6050701@fifthhorseman.net> Date: Wed, 09 Apr 2014 00:35:57 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Chris Palmer References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <5307BDFD.7060009@gondrom.org> <5308F126.7020308@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DBTxJVnhNqesvpV8qpBe1kbGeXov6DiWH" Archived-At: http://mailarchive.ietf.org/arch/msg/websec/RrFIoPLPP-N7oXQ1PEBFzNlmb9M Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 09 Apr 2014 04:36:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DBTxJVnhNqesvpV8qpBe1kbGeXov6DiWH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/04/2014 06:14 PM, Chris Palmer wrote: > On Sat, Feb 22, 2014 at 10:49 AM, Daniel Kahn Gillmor > wrote: >=20 >> I also think that (b) (unpinning) is the right answer here, considerin= g >> the semantics of the decision. >> >> Consider it this way: >> >> * the site operator gets to decide what pins they issue, and what has= h >> algorithms to use. >> >> * the site operator presumably has a rough idea of how many of their >> clients are using software that might not be able to handle new hash >> algorithms >> >> * the site operator also decides what security properties/strength th= ey >> require of a given hash algorithm. >> >> If the site operator considers an older hash algorithm to be too weak = to >> rely on, and a client only knows that hash algorithm, then the site >> operator asking that client to unpin (and perhaps acknowledge the lack= >> of pinning to the user via whatever UI provides information about the >> pin) is the right thing to do. >=20 > I think I agree. can this be stated explicitly in the draft then? I think this guidance would be useful for the inevitable corner cases. >> 0) if a site operator decides to use more than one hash algorithms in= >> the future, do we require that they issue the same set of pins under >> each algorithm? So if i'm pinning keys X and Y and Z, and i'm using >> both pin-sha2-256 and pin-sha3-256, must i issue 6 pins? I think it's= >> reasonable to say yes here, even if we don't have any other digests >> defined yet. >=20 > No, I'd like to say that sha256(foo.getSPKI()) =3D=3D sha3(foo.getSPKI(= )) > =3D=3D sha4(foo.getSPKI()), and for UAs to treat them as identical. i'm afraid i'm not sure what you're using =3D=3D to mean here, or "UAs to= treat them as identical". Given a key that produces three different digests, if the digests are not broken, then sure a match on any one is as good as a match on any oth= er. But if implementations of this spec are expected to survive an algorithm agility shift (even if we want it to be all-sha256 for now) then we need to specify what happens when some of the known digests match and others don't. consider a world where we've made sha3 available in this spec, and someone figures out a preimage attack against sha-256. now, that attacker can create a match on the sha256 pin but can't create a match on the sha3 pin. if we treat the sha256 pin as identical to the sha3 pin, that we've just reduced the strength of the pin to the weakest algorithm. or am i misunderstanding what you mean by "identical"? >> Why would you want to pin different keys with different >> hash algorithms? >=20 > People are weird. :) But yeah, I am kind of hoping that SHA-256 > remains the only hash algorithm for HPKP for as long as that is safe, > and that it is safe for a long time. i also hope for this scenario, and am fine with sha256 as the only algorithm for this spec. But that's no reason to avoid specifying what to do in the case where multiple digests are present, though. >> 1) If a UA knows about two hashing algorithms, then the language in 2= =2E6 >> is potentially problematic for visiting a site that provides pins usin= g >> both hashing algorithms. In particular, checking the set intersection= >> of all pins suggests that an attacker need only defeat the weakest has= h. >> I suggest that when multiple hash algorithms are known to the UA, and= >> it has pins for a given site under more than one hash algorithm, then = it >> must look for the set intersection *per hash algorithm used by the sit= e* >> and only proceed if all hash algorithms show a set intersection. >=20 > Does treating H(foo) for all specified H mitigate or exacerbate your co= ncern? sorry, i'm unclear what you mean here too. how exactly do you want to treat H(foo)? --dkg --DBTxJVnhNqesvpV8qpBe1kbGeXov6DiWH 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 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTRM4tXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc5AgQAI3ZI+vglnX6ZBE3DaOBZa/Z 3CzIV8PHzVn218D84tkgEsi/oKEBqQaoWoBeP715cXLi3Jo1fL6+xjKvuYvSQQeI KMiO9KtXBzozwUKJ7rotsIxdW62NkKQ6cXXLsR1NxWnPqamtZ4WjkPah+bPE4tea qtlvjLY96x3RuLrxB2dNjx7ABv2ntGMoYS4xDoeHeF3LIuKeGkSjvaUGfLZD1quZ Hg9mPSQZDzPithm8PEodMBDPb31YgKbzqbwJs7g0WuQ2NpJ2tYKoh6lNF7y7/pC8 CMBRQM2YbxSSCQ0eEbVhpl8kBIgwgzDENA+xdb4eort5KD9oN1x8uyIb72dfRVGD fm6eMbxBeKuXO52uz8v7AFcdu5lNZBMPKoCcdoLCZpieSd7tc47QFE7Aeguyl6C5 XtBvVSu03cswcS3W1CLWT7UA5LZ4rZ+q7YJWrcFP5IKGYcIM99NO58rucgFQX0bg bNODKWX/uTrB2b38qMr027FA1UJ/hAci0cw0ZWl+HsHr/nLauayonpXwZ+PVnzaj tHN1QxhtYMoVBJ8572b+6Ah1++C2O4XMvvlZwzhyiEAG/+0Gw9aezanwUn3GCyt/ /JJY4L0rtgK5chnZpYAtpH5AQIBiMT0uUn13mXTMf87jcA5Lxjxpjfm1PbUrLNeU awKBLMveq/s2WA3DmzwV =PrAW -----END PGP SIGNATURE----- --DBTxJVnhNqesvpV8qpBe1kbGeXov6DiWH-- From john.r.moser@gmail.com Tue Apr 15 10:15:00 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D051A04C8 for ; Tue, 15 Apr 2014 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.302 X-Spam-Level: * X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHDA3XrgjI2J for ; Tue, 15 Apr 2014 10:14:56 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id F40B41A01F8 for ; Tue, 15 Apr 2014 10:14:55 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so10671147qcx.24 for ; Tue, 15 Apr 2014 10:14:52 -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=7jXg+bRUPfF9Z21WEb5HnlHOMkAl2979EVen4dAWF5g=; b=JLMPlxcI0DxTuh9dVI3gUeV1b6Yd021Cvnu1arcaVrhiDZyv+q5xWYVswhkT0Sv8hJ 0o58eLgoIrvJi61fE1VhgmZ7ztz4Tr5GW1SyXW+FmeHvjm1ts6ImJVd9hlx0FZRNbduX N3xwlMEmqDgKNOaMw2LKoNYR/Q5QHxS88m5jYDMXHmn2DomMypeNrCD06kBV/UHnun7E hYlUcle0oVKSIROZhHpPEn++oJF4xdCNC/Yu7jaEt4Y1lfltguJt/zujzEiyaLW0Lt1w Wx7ylqgix9+8cjlILpnGzxbwQtYpE++dN2M51tLyBPTsamLjN68Rdkb3fRraUkFYDR2u 8C/w== MIME-Version: 1.0 X-Received: by 10.140.109.132 with SMTP id l4mr4331597qgf.72.1397582092845; Tue, 15 Apr 2014 10:14:52 -0700 (PDT) Received: by 10.140.104.100 with HTTP; Tue, 15 Apr 2014 10:14:52 -0700 (PDT) Date: Tue, 15 Apr 2014 13:14:52 -0400 Message-ID: From: John Moser To: websec@ietf.org Content-Type: multipart/alternative; boundary=001a113ba71630b65204f717f07d Archived-At: http://mailarchive.ietf.org/arch/msg/websec/UGv1zmlBU-s5M4atIF8HPCqyHO8 X-Mailman-Approved-At: Sun, 20 Apr 2014 03:24:58 -0700 Subject: [websec] Web app security proxies, specifications X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 21:02:52 -0000 --001a113ba71630b65204f717f07d Content-Type: text/plain; charset=UTF-8 Relevant to: HTTP Web application security I'm imagining (probably to no fruitful endeavor) a Web application security proxy. I was thinking about that old mod_security thing in Apache, where you could essentially tell it what requests look like and it would reject bad requests, and it got me thinking: a secure proxy for this would be interesting. I could make a product... or I could make a specification and a reference implementation. That brought up some interesting thoughts. Suppose I define, among other things, the ability to recognize valid/invalid headers and requests. Say I expect POST requests of the form (normalized to equivalent GET requests, with regexes): /login.php?u=[\w\d]{3,16}&p=[\w\d]{6,45} So we have a rule: login.php { "POST" { u ~ /[\w\d]{3,16}/; p ~ /[\w\d]{6,45}/; !*; } !*; } Only POST requests, with u and p fields, no other fields, defined as regex. Now let's say we install an application at http://www.example.com/myapp/which has http://www.example.com/myapp/login.php and we want to define security rules for it. I guess we could load these into a proxy, do all kinds of configuration? Or... We could set up a http://www.example.com/security.txt file: /security.pxsd /myapp/security.pxsd root=/myapp/ And in /myapp/security.pxsd we have the above rule, among others. The Web server proper SHOULD deny access to security.txt and all pxsd files by application-specific configuration, except to the trusted security reverse proxy. The trusted security reverse proxy SHOULD deny proxy access for these files as well. The reverse proxy will: - Checks security.txt for all PXSD files required (ProXy Security Definition) - Checks the request against the full policy - Rejects the request if it violates In implementation, there would be a caching period (seconds, minutes, etc), an if-modified-since and/or hash check, etc. so that excess work fetching, parsing, and integrating policy isn't done. PXSD is root-relative; root is specified in security.pxsd. Thus /myapp/security.pxsd cannot specify rules for /otherapp/login.py or whatnot. Thus a Web application may ship with security definitions dictating valid data. A Web server or a reverse proxy may read these definitions from a security file and apply standard validation. The Web server itself may read a security file (/security.txt or some out-of-web-space file) and PXSD files, applying policy internally; or a reverse proxy (Squid, Varnish, nginx, etc.) may fetch and cache these policy files and prevent requests from passing. The advantage of a proxy doing such is that it is a bastion host: broken requests which pass as seemingly-valid HTTP but which are unorthodox and cause buffer overruns and other nastiness will stop at the bastion host. Broken requests which are wholly invalid and crash the software will either stop at the bastion host or give an exploit onto the bastion host, which itself may not carry anything critical and can be rebooted or replaced with a functioning server in the event of an exploit. In any case, the above is illustrative, wordy, and highly hypothetical. The point is: I believe there would be value in defining a DSL and standard for Web application input validation, such that either a Web server itself or a reverse proxy may read a set of standard-format files (starting with the expected file /security.txt) and obtain a definition of requests which wholly encompasses all valid requests (but may or may not also encompass some invalid requests). I'm only interested in HTTP query validation in this scope. I have no interest in access controls (i.e. only these IP addresses may do these things; only these file types are valid; you may not pull .htaccess; etc.). Thoughts? Would this be something worth researching, designing, and RFCing? --001a113ba71630b65204f717f07d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Relevant to:=C2=A0 HTTP Web application security

I'= m imagining (probably to no fruitful endeavor) a Web application security p= roxy.=C2=A0 I was thinking about that old mod_security thing in Apache, whe= re you could essentially tell it what requests look like and it would rejec= t bad requests, and it got me thinking:=C2=A0 a secure proxy for this would= be interesting.

I could make a product... or I could make a specification and a r= eference implementation.=C2=A0 That brought up some interesting thoughts.
Suppose I define, among other things, the ability to recognize = valid/invalid headers and requests.=C2=A0 Say I expect POST requests of the= form (normalized to equivalent GET requests, with regexes):

/login.php?u=3D[\w\d]{3,16}&p=3D[\w\d]{6,45}

So = we have a rule:

login.php {
=C2=A0 "POST&qu= ot; {
=C2=A0=C2=A0=C2=A0 u ~ /[\w\d]{3,16}/;
=C2=A0=C2=A0= =C2=A0 p ~ /[\w\d]{6,45}/;
=C2=A0=C2=A0=C2=A0 !*;
=C2=A0 }
=C2=A0 !*;
}

Only POST requests, with u and p f= ields, no other fields, defined as regex.

Now let's say we= install an application at http:/= /www.example.com/myapp/ which has http://www.example.com/myapp/login.php and we want to def= ine security rules for it.=C2=A0 I guess we could load these into a proxy, = do all kinds of configuration?

Or...

We could set up a http://www.example.com/security.txt file:

/security.pxsd
/myapp/security.pxsd root=3D/myapp/

And in /myapp/security.pxsd we have the above rule, among others.
<= br>
The Web server proper SHOULD deny access to security.txt and = all pxsd files by application-specific configuration, except to the trusted= security reverse proxy.

The trusted security reverse proxy SHOULD deny proxy access = for these files as well.

The reverse proxy will:

<= /div>
=C2=A0- Checks security.txt for all PXSD files required (ProXy Se= curity Definition)
=C2=A0- Checks the request against the full policy
=C2=A0- Rejects the request if it violates

In implementa= tion, there would be a caching period (seconds, minutes, etc), an if-modifi= ed-since and/or hash check, etc. so that excess work fetching, parsing, and= integrating policy isn't done.

PXSD is root-relative; root is specified in security.pxsd.= =C2=A0 Thus /myapp/security.pxsd cannot specify rules for /otherapp/login.p= y or whatnot.

Thus a Web application may ship = with security definitions dictating valid data.=C2=A0 A Web server or a rev= erse proxy may read these definitions from a security file and apply standa= rd validation.=C2=A0 The Web server itself may read a security file (/secur= ity.txt or some out-of-web-space file) and PXSD files, applying policy inte= rnally; or a reverse proxy (Squid, Varnish, nginx, etc.) may fetch and cach= e these policy files and prevent requests from passing.

The advantage of a proxy doing such is that it is a bastion host:=C2=A0= broken requests which pass as seemingly-valid HTTP but which are unorthodo= x and cause buffer overruns and other nastiness will stop at the bastion ho= st.=C2=A0 Broken requests which are wholly invalid and crash the software w= ill either stop at the bastion host or give an exploit onto the bastion hos= t, which itself may not carry anything critical and can be rebooted or repl= aced with a functioning server in the event of an exploit.



In any case, the above is illustrative, wordy, and h= ighly hypothetical.=C2=A0 The point is:=C2=A0 I believe there would be valu= e in defining a DSL and standard for Web application input validation, such= that either a Web server itself or a reverse proxy may read a set of stand= ard-format files (starting with the expected file /security.txt) and obtain= a definition of requests which wholly encompasses all valid requests (but = may or may not also encompass some invalid requests).

I'm only interested in HTTP query validation in this scope.=C2=A0 I= have no interest in access controls (i.e. only these IP addresses may do t= hese things; only these file types are valid; you may not pull .htaccess; e= tc.).

Thoughts?=C2=A0 Would this be something worth researching, d= esigning, and RFCing?
--001a113ba71630b65204f717f07d-- From nobody Wed Apr 23 00:14:58 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557941A00BE for ; Wed, 23 Apr 2014 00:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bS4PKmr8Jil for ; Wed, 23 Apr 2014 00:14:56 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3642B1A00AA for ; Wed, 23 Apr 2014 00:14:56 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so440204wes.7 for ; Wed, 23 Apr 2014 00:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=SOJ7vUE6nRDplrBryaZG9YVWOgeUXizk1sblnhZscss=; b=T8c6Dsp3xafmbK3+SxXtb2L79HGo542HXdB7Mn7oW2yGYOmA07Jsr3niF0ApwNJXxU EzK/s9EnyaJC1bYa6lntf++O6tPdexoVbJVAFSb/V40GregFzOJxzPzgb4z/k8RkkhHy 9oBRvSkFYW0Xfo/7cepEAZPB1bwzaEDfTzsGKTYweU31ilHKGkOwmFwgd/wPCoZ78aPh gAX240YoXO4gwQSDgqaf8f5e9dnIZ24yuCfsjUoPbLWM54E/kMqYTFvsuUbQBOwCFgWO 86p/n/EE+uibncAjX4W10nzb65O34erwkP9N7Zs+fzsKhflAMM9TB1Ro0pshL7JFzO8K fHYw== X-Received: by 10.180.38.107 with SMTP id f11mr417222wik.31.1398237290135; Wed, 23 Apr 2014 00:14:50 -0700 (PDT) Received: from [192.168.0.5] (57518371.skybroadband.com. [87.81.131.113]) by mx.google.com with ESMTPSA id t18sm2454830wiv.16.2014.04.23.00.14.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 00:14:49 -0700 (PDT) Message-ID: <53576894.4020005@gmail.com> Date: Wed, 23 Apr 2014 08:15:32 +0100 From: =?UTF-8?B?SXZhbiBSaXN0acSH?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: websec@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/e7J01Q7_qKetWn2EeJYylvFOSxI Subject: [websec] Why are multiple PKP header fields allowed? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 07:14:57 -0000 According to the HPKP spec: "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." What's the rationale for this decision? (The same logic is applied in HSTS, so perhaps the behaviour is copied from there?) HPKP and HSTS are both vulnerable to response header injection attacks. Assuming an application that correctly sets the security headers, a successful attack produces a response with multiple security headers and the attacker has a good chance to place his headers first. Have you considered instructing UAs to ignore all headers when there are two or more? -- Ivan From nobody Wed Apr 23 00:43:13 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BF1A00C3 for ; Wed, 23 Apr 2014 00:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SezpfZwnViiI for ; Wed, 23 Apr 2014 00:43:05 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED601A00CF for ; Wed, 23 Apr 2014 00:43:05 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so4434677wiv.13 for ; Wed, 23 Apr 2014 00:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p9G75Pw18JapC4uc82d/JTBH77dNw+rIlJEvCWoWuZk=; b=RhfmHCZuY16onezYYxQLaxnf2/O8CcE5IDjUHiQxvv2TQwwIvcc8+JD2YVrPBepj23 zcFr/g1OZyJqSV6WFFOycis5MjppQvZ9wf0uapdwTpgAc8F2pfDmZysrxYZkh9JCV8Bw 2EOkyugdobmdz7HC2MzRCX1cQb9G4JVYOx161jvQ2XfVp3BPyyNoVGY0PIVTrM45maGv r04KaAMofI6rsOc5BLp2ZyXBLMYp23F7h2wwMUVYlYWLeuuE+Gc4xAL1TiOkOWEPezOT bpXYlzeKCDeogXPOEDYoIA0xdMninEkfOSWM7ie6VsVGaXMfMuhb5rFN0Jhj0eLsN5yy G42Q== X-Received: by 10.194.58.79 with SMTP id o15mr390180wjq.62.1398238978971; Wed, 23 Apr 2014 00:42:58 -0700 (PDT) Received: from [172.24.248.99] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id pm5sm295675wjc.11.2014.04.23.00.42.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 00:42:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <53576894.4020005@gmail.com> Date: Wed, 23 Apr 2014 10:42:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <32B47C46-14AD-418A-B18D-9AC1CCF1CD7C@gmail.com> References: <53576894.4020005@gmail.com> To: =?utf-8?Q?Ivan_Risti=C4=87?= X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/HKx2O8NPTgDpUnfSb2UHv-hZVdk Cc: websec@ietf.org Subject: Re: [websec] Why are multiple PKP header fields allowed? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 07:43:09 -0000 Hi, Ivan Both HPKP and HSTS are only considered when they are received over a = TLS-protected connection. TLS should protect against response header = injection, no? Yoav On Apr 23, 2014, at 10:15 AM, Ivan Risti=C4=87 = wrote: > According to the HPKP spec: >=20 > "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." >=20 > What's the rationale for this decision? (The same logic is applied in > HSTS, so perhaps the behaviour is copied from there?) >=20 > HPKP and HSTS are both vulnerable to response header injection = attacks. > Assuming an application that correctly sets the security headers, a > successful attack produces a response with multiple security headers = and > the attacker has a good chance to place his headers first. >=20 > Have you considered instructing UAs to ignore all headers when there = are > two or more? >=20 > --=20 > Ivan >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Wed Apr 23 01:20:22 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69EC1A013C for ; Wed, 23 Apr 2014 01:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxVsrIl4x3wC for ; Wed, 23 Apr 2014 01:20:10 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id E98171A00CF for ; Wed, 23 Apr 2014 01:20:07 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so511480wgh.35 for ; Wed, 23 Apr 2014 01:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wXpHeQtmqt1QrKfue/Dp4wBTBYw+M5eYQM5rwC4jCbM=; b=LYxjr33WpklI287X3B206TPcYiCKE9y/JlWUoM1vB3hmYMw1YLKgBR31APGReSdrkA mxnrowMK5bGgDH3cxmiZ+SiQyF9dg+giUf6p4e4xrfqD3DvyGrnRgMv4Lf9DPH8/Wc5j DHivZZ0oA9fqfCT6BXn3lgGq+v/xXTyJ5u3re90aF7AUbRFZwIYy9MFUTGYdszgOO57n Mhi8X3TiL4JUDFEdWAuUfoq9i84zyPzhr1yg93JnIFZc+RV3rO6WMGPhnSWU1TLimeEi uiFPqK/k0Soxv6EUc7gT/2OkAtDZQXeY3+JYTveICJ7GMTE9JbQ0sX+JKk+6+8sbIrkW gAYQ== X-Received: by 10.180.19.69 with SMTP id c5mr697983wie.7.1398241201886; Wed, 23 Apr 2014 01:20:01 -0700 (PDT) Received: from [192.168.0.5] (57518371.skybroadband.com. [87.81.131.113]) by mx.google.com with ESMTPSA id f7sm414496wjy.24.2014.04.23.01.20.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 01:20:01 -0700 (PDT) Message-ID: <535777DB.5030804@gmail.com> Date: Wed, 23 Apr 2014 09:20:43 +0100 From: =?UTF-8?B?SXZhbiBSaXN0acSH?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Yoav Nir References: <53576894.4020005@gmail.com> <32B47C46-14AD-418A-B18D-9AC1CCF1CD7C@gmail.com> In-Reply-To: <32B47C46-14AD-418A-B18D-9AC1CCF1CD7C@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/sdLqv1HEqPmKQdWASrOaI4lRL1U Cc: websec@ietf.org Subject: Re: [websec] Why are multiple PKP header fields allowed? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 08:20:14 -0000 On 23/04/2014 08:42, Yoav Nir wrote: > Hi, Ivan > > Both HPKP and HSTS are only considered when they are received over a > TLS-protected connection. TLS should protect against response header > injection, no? No, the attack vector here is not transport, but a vulnerable web application. The vulnerability exists whenever an attacker is able to freely inject CRLF sequences into a HTTP response. For example: https://www.example.com/redirect.jsp?target=https://www.example.com/%0d%0aPublic-Key-Pins:%20max-age=0 If the target parameter is used without checking when constructing the Location header in the redirection, the result could be something like: HTTP/1.1 302 Moved Temporarily Some-Header: ... Location: https://www.example.com/ Public-Key-Pins: max-age=0 Other-Headers: ... Public-Key-Pins: max-age=3000; pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; To be fair, an attacker who can do this can also inject a double-CRLF and terminate the HTTP response early, leaving only his PKP response. In other words, this attack vector cannot be fully avoided. Still, being less tolerant to malformed HTTP headers is generally a good thing. I was wondering if there was a reason for doing otherwise. In any case, I think it's worth mentioning this attack in the RFC, so that the risk is understood. Another attack vector that could be described is against the user clock. > Yoav > > On Apr 23, 2014, at 10:15 AM, Ivan Ristić > wrote: > >> According to the HPKP spec: >> >> "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." >> >> What's the rationale for this decision? (The same logic is applied >> in HSTS, so perhaps the behaviour is copied from there?) >> >> HPKP and HSTS are both vulnerable to response header injection >> attacks. Assuming an application that correctly sets the security >> headers, a successful attack produces a response with multiple >> security headers and the attacker has a good chance to place his >> headers first. >> >> Have you considered instructing UAs to ignore all headers when >> there are two or more? >> >> -- Ivan >> >> _______________________________________________ websec mailing >> list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec > -- Ivan From nobody Wed Apr 23 01:31:12 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6281A0113 for ; Wed, 23 Apr 2014 01:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAfzdqRxwua6 for ; Wed, 23 Apr 2014 01:31:11 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A05DA1A010F for ; Wed, 23 Apr 2014 01:31:02 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so4493999wiv.7 for ; Wed, 23 Apr 2014 01:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=X4qESU3bcT4lfejSAaTzSFhD6F7lwg6+ExYSym5UvA0=; b=EoFoo8x6xPf1t+EmeZUhZcXtke4221o4JqhEvrrXAPIYJOHaJbOXXm0jfHi7Fpix6o 7tzoGJwP9nDaynQ8zsq6tXo0yaarH/zMaTmQSJa4rd+Da1DapWILXv2gRYuVpSiWqdjl 7plL6f6o06oI1JxOTXfgMLl5kjSQd8e8VC9xbb6tx402D62nW6zpG62qZjRMzpf/H6Lw 2X+6WAPjj9T5FVcSwHLzQSNgIwltTbdJQoGV5w9MQMXimKAHfzxQjs71WfVfR1X2U23X aVCPLVbrRdS38QguS7mWzc/dYdsLYhOKS8cmKVd0031qKVm5Yejyij9UTzrsw+S+RG/F jtqw== X-Received: by 10.180.11.178 with SMTP id r18mr683013wib.41.1398241856414; Wed, 23 Apr 2014 01:30:56 -0700 (PDT) Received: from [192.168.0.5] (57518371.skybroadband.com. [87.81.131.113]) by mx.google.com with ESMTPSA id hu7sm27580862wib.10.2014.04.23.01.30.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 01:30:55 -0700 (PDT) Message-ID: <53577A6A.80408@gmail.com> Date: Wed, 23 Apr 2014 09:31:38 +0100 From: =?UTF-8?B?SXZhbiBSaXN0acSH?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: websec@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/TFAiilpSrSi4sLzA2gRDVM4rAhY Subject: [websec] Clarify pin validation for hosts with multiple trust paths X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 08:31:12 -0000 In Section 2.6. ("Validating Pinned Connections"), there is this wording: "To perform Pin Validation, the UA will compute the SPKI Fingerprints for each certificate in the Pinned Host's validated certificate chain, [...]" It is assumed that there is only one validated certificate chain. In practice, there could be multiple valid certificate chains, some with pins, others without. It's possible that a UA will first process the paths, select one deemed to be the "best", only after which the pins will be examined. If the selected path is without pins, the connection will fail, even though there might be another paths that could have been used. I think the specification should describe this situation, and instruct UAs to try alternative (acceptable) trust paths in case of pin failure. -- Ivan From nobody Wed Apr 23 11:28:11 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344B91A023A for ; Wed, 23 Apr 2014 11:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.335 X-Spam-Level: * X-Spam-Status: No, score=1.335 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, SPF_FAIL=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh4DGFl9bcVA for ; Wed, 23 Apr 2014 11:28:09 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA71A0031 for ; Wed, 23 Apr 2014 11:28:09 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 625BF2006D30B; Wed, 23 Apr 2014 11:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=vJvQB4N/9zuqwbkhFm+N9hYUK/8=; b=D3zE1NRdo5jglMiUb amdze9ZYvZs43lFlM3xOW2iJm4aCmLsfcMU/NGT2xV7xPSdo1r8z0NEdzL5u9JUx ZsCEBuAZ6jnLbfOaVjaVrQRBa34CGc2aiahuZhg/Gq80uDjGVqV6nRE8RA/X//K9 /fwXejB48Zr4PTGnb1oCWisaFw= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 16DF32006D309; Wed, 23 Apr 2014 11:28:03 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 23 Apr 2014 11:28:03 -0700 Message-ID: In-Reply-To: <53576894.4020005@gmail.com> References: <53576894.4020005@gmail.com> Date: Wed, 23 Apr 2014 11:28:03 -0700 From: "Ryan Sleevi" To: =?iso-8859-1?Q?=22Ivan_Risti=C4=87=22?= User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/iV-SjskVOZDynrBpWmN0eP-ezDw Cc: websec@ietf.org Subject: Re: [websec] Why are multiple PKP header fields allowed? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 18:28:10 -0000 On Wed, April 23, 2014 12:15 am, Ivan Risti=C4=87 wrote: > According to the HPKP spec: > > "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." > > What's the rationale for this decision? (The same logic is applied in > HSTS, so perhaps the behaviour is copied from there?) Correct. > > HPKP and HSTS are both vulnerable to response header injection attacks= . > Assuming an application that correctly sets the security headers, a > successful attack produces a response with multiple security headers a= nd > the attacker has a good chance to place his headers first. > > Have you considered instructing UAs to ignore all headers when there a= re > two or more? > The choice here was made explicitly *because* of header injection. The disagreement here is whether or not an attacker has a greater chance of getting their headers to appear first or last. The belief - of both HPKP and HSTS - is that it is harder, in most web servers (and, for that matter, scripting languages), for an attacker to get their headers to appear first. Instead, a webserver is more likely to send any system-wide/host-wide headers first, and then append any (scripting, user-specific) headers. From nobody Wed Apr 23 11:35:06 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0B1A04A1 for ; Wed, 23 Apr 2014 11:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.335 X-Spam-Level: * X-Spam-Status: No, score=1.335 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, SPF_FAIL=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-DK3gwTFisE for ; Wed, 23 Apr 2014 11:35:02 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C496F1A0435 for ; Wed, 23 Apr 2014 11:35:02 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id DFBA220202C; Wed, 23 Apr 2014 11:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=UXTJFLRpjnjR/tQTfAh5A2mPmjM=; b=SjmpvOAD2ADgfbEru mrNw49bmcaw4dLgK2vVdv0vJUYOhdblWXcR7cWc9gtkTS3/4a5weBWQC9tB1IiEh k+2OD9JqckBjKV6spo8h70D+VZFDBtn94nyNA+FvynxsPIoTzZkeoBnxBTQJvL9H Sk3oLuESwyYtWchVHTmNKpwEio= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id 8BE14202022; Wed, 23 Apr 2014 11:34:56 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 23 Apr 2014 11:34:56 -0700 Message-ID: <74b4601bba58daeb9b09bae7fd96e794.squirrel@webmail.dreamhost.com> In-Reply-To: <53577A6A.80408@gmail.com> References: <53577A6A.80408@gmail.com> Date: Wed, 23 Apr 2014 11:34:56 -0700 From: "Ryan Sleevi" To: =?iso-8859-1?Q?=22Ivan_Risti=C4=87=22?= User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/nxfnPEoX8ljMtu8REIzXP93vv-k Cc: websec@ietf.org Subject: Re: [websec] Clarify pin validation for hosts with multiple trust paths X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 18:35:04 -0000 On Wed, April 23, 2014 1:31 am, Ivan Risti=C4=87 wrote: > In Section 2.6. ("Validating Pinned Connections"), there is this wordi= ng: > > "To perform Pin Validation, the UA will compute the SPKI Fingerprints > for each certificate in the Pinned Host's validated certificate > chain, [...]" > > It is assumed that there is only one validated certificate chain. In > practice, there could be multiple valid certificate chains, some with > pins, others without. It's possible that a UA will first process the > paths, select one deemed to be the "best", only after which the pins > will be examined. If the selected path is without pins, the connection > will fail, even though there might be another paths that could have be= en > used. > > I think the specification should describe this situation, and instruct > UAs to try alternative (acceptable) trust paths in case of pin failure= . > > -- > Ivan > Note that describing path *building* algorithms has largely been outside the scope of most protocol work. The fact that there are multiple valid paths - eg: via the chasing of authorityInfoAccess - has in fact been contentious in other WGs (PKIX/TLS, for example) - in part because the aI= A is unvalidated, attacker-controlled data being processed by the client. The exact behaviour of the UA's path building algorithm is equally one that differs wildly between UAs (and notably, sometimes between the same UA on different platforms). The behaviour you describe as preferable (check-while-building) is something that's been/being implemented in Firefox, while the behaviour you dislike (check-after-building) is something that's been implemented i= n Chrome. For Chrome, when dealing with different platforms' path validatin= g APIs, the check-after-building is the only implementation *possible* usin= g these APIs. I don't think the check-while-building algorithm provides any more determinism for clients than the check-after-building algorithm. For site= s that are implementing pinning, they have two absolute guarantees - the SPKI of the EE cert, and the SPKI of the EE's signer - will always be in the chain. Above that, the exact nature of what's valid - either with check-after or check-while - is somewhat dependent on the applications' trust store - and if you wish to pin at those levels or above, you need a robust pin set. PKP-R-O provides a means to discover that pin set proactively prior to pinning. Cheers, Ryan From nobody Thu Apr 24 11:44:05 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DC01A039B for ; Thu, 24 Apr 2014 11:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V825GFtVQLHc for ; Thu, 24 Apr 2014 11:44:01 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 883091A01DB for ; Thu, 24 Apr 2014 11:44:01 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so2668486wes.32 for ; Thu, 24 Apr 2014 11:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eAyoLt+i4vZwg9EYFI6tbcpogD27Kv7DpGEmYyatHvs=; b=qNB1vKYpcP8fSBSuQUQ3PdSUl2KWb6eXKKa6/zDSNqDDTiA1Ltrbb3GUiz/Y8LXprv et7gTlALUsaVheP7F1eBWqzlWykB+0Q6+mhqj5JVs76X3H0fJmUsPbLe3nhKj4+Qyc1s moXgqqjnhB82AwGw+mhWefLofaQcc/tie5s0FU/FD9AvhXSLOePVWm2n6DrDZp23ePj7 cPD3n78hOleY0kk3/RA4cFrLsSAX7pzIFg2LE7WTGA4FbFHcTxZPhZjFnNGXv6qUGZCf WQLU49M/kiQM+wKSTLYwO/Y543S61RXC1vG0QnK9qA+JyAKrbXw+CNUjj4JG0YeKJBML tz5A== X-Received: by 10.194.203.42 with SMTP id kn10mr3100808wjc.54.1398365034909; Thu, 24 Apr 2014 11:43:54 -0700 (PDT) Received: from crispy.local (57518371.skybroadband.com. [87.81.131.113]) by mx.google.com with ESMTPSA id go20sm7341920wjc.18.2014.04.24.11.43.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 11:43:53 -0700 (PDT) Message-ID: <53595B67.5010101@gmail.com> Date: Thu, 24 Apr 2014 19:43:51 +0100 From: Ivan Ristic User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ryan-ietfhasmat@sleevi.com References: <53576894.4020005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/OGoYj_FTQEwR4TrZwVT1PGyD3Y0 Cc: websec@ietf.org Subject: Re: [websec] Why are multiple PKP header fields allowed? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 18:44:03 -0000 On 23/04/2014 19:28, Ryan Sleevi wrote: > On Wed, April 23, 2014 12:15 am, Ivan Ristić wrote: >> According to the HPKP spec: >> >> "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." >> >> What's the rationale for this decision? (The same logic is applied in >> HSTS, so perhaps the behaviour is copied from there?) > > Correct. > >> >> HPKP and HSTS are both vulnerable to response header injection attacks. >> Assuming an application that correctly sets the security headers, a >> successful attack produces a response with multiple security headers and >> the attacker has a good chance to place his headers first. >> >> Have you considered instructing UAs to ignore all headers when there are >> two or more? >> > > The choice here was made explicitly *because* of header injection. > > The disagreement here is whether or not an attacker has a greater chance > of getting their headers to appear first or last. The belief - of both > HPKP and HSTS - is that it is harder, in most web servers (and, for that > matter, scripting languages), for an attacker to get their headers to > appear first. Instead, a webserver is more likely to send any > system-wide/host-wide headers first, and then append any (scripting, > user-specific) headers. I don't think that's the disagreement. My first point is that this attack vector should be discussed in the RFC, and the decision to use the first PKP header explained. The second (and less important) point is that rejecting HTTP responses with multiple PKP headers might be marginally better than the current behaviour. No matter where the header is injected (first or second), it's never wrong reject both. It certainly feels safer to me; after all we know that that response is contaminated. Further, there'll be a class of attackers who can inject at the first position, but can't inject a double CRLF to perform full HTTP response splitting. For example, the length of the parameter might be limited. -- Ivan From nobody Thu Apr 24 12:01:53 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DF21A0389 for ; Thu, 24 Apr 2014 12:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcUgliYZ809O for ; Thu, 24 Apr 2014 12:01:46 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CECE21A03D0 for ; Thu, 24 Apr 2014 12:01:45 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so2629133wes.20 for ; Thu, 24 Apr 2014 12:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BT4hVVNGebACxhozO6L7jg7zB7Fq9FhvzyfVAcgisfo=; b=U+t5a/IKDbDqb2ZkdUDYWmxb1KO7NJy/dffUul5cyIeOVvAC46U+KP+n6DlWdfaMui gW9URvMJRVsJVEURNOscpzf6X3GAPiHc/moEvtnu6oF74nFeaylzMJsr7VkidyCO7A9J /nWO6HrQuYiVIYSAR2BRu6eJt55dMdKbUJpJa5EYxxONS5qTLno+xV3ARdcFobQ+g95Z hQ+zoayC/pKlXrkhKlCsbHQ9AMqEUstbP1b1sABks8DvNY9KALIodRXI8mICrqXtZXk9 kAoP8uFgkLqbls9JRpkl8XNYK6u1IdidTf8TPf19btD91Qi8jI18f5jh37mZfkV5bMgS CDvQ== X-Received: by 10.180.206.205 with SMTP id lq13mr282231wic.11.1398366099047; Thu, 24 Apr 2014 12:01:39 -0700 (PDT) Received: from crispy.local (57518371.skybroadband.com. [87.81.131.113]) by mx.google.com with ESMTPSA id u1sm7404147wjx.16.2014.04.24.12.01.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 12:01:38 -0700 (PDT) Message-ID: <53595F90.2020901@gmail.com> Date: Thu, 24 Apr 2014 20:01:36 +0100 From: Ivan Ristic User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ryan-ietfhasmat@sleevi.com References: <53577A6A.80408@gmail.com> <74b4601bba58daeb9b09bae7fd96e794.squirrel@webmail.dreamhost.com> In-Reply-To: <74b4601bba58daeb9b09bae7fd96e794.squirrel@webmail.dreamhost.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/uxatxkXGs1hWrdFuFb77a5QbukA Cc: websec@ietf.org Subject: Re: [websec] Clarify pin validation for hosts with multiple trust paths X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 19:01:48 -0000 On 23/04/2014 19:34, Ryan Sleevi wrote: > On Wed, April 23, 2014 1:31 am, Ivan Ristić wrote: >> In Section 2.6. ("Validating Pinned Connections"), there is this wording: >> >> "To perform Pin Validation, the UA will compute the SPKI Fingerprints >> for each certificate in the Pinned Host's validated certificate >> chain, [...]" >> >> It is assumed that there is only one validated certificate chain. In >> practice, there could be multiple valid certificate chains, some with >> pins, others without. It's possible that a UA will first process the >> paths, select one deemed to be the "best", only after which the pins >> will be examined. If the selected path is without pins, the connection >> will fail, even though there might be another paths that could have been >> used. >> >> I think the specification should describe this situation, and instruct >> UAs to try alternative (acceptable) trust paths in case of pin failure. >> >> -- >> Ivan >> > > Note that describing path *building* algorithms has largely been outside > the scope of most protocol work. The fact that there are multiple valid > paths - eg: via the chasing of authorityInfoAccess - has in fact been > contentious in other WGs (PKIX/TLS, for example) - in part because the aIA > is unvalidated, attacker-controlled data being processed by the client. > > The exact behaviour of the UA's path building algorithm is equally one > that differs wildly between UAs (and notably, sometimes between the same > UA on different platforms). > > The behaviour you describe as preferable (check-while-building) is > something that's been/being implemented in Firefox, while the behaviour > you dislike (check-after-building) is something that's been implemented in > Chrome. For Chrome, when dealing with different platforms' path validating > APIs, the check-after-building is the only implementation *possible* using > these APIs. > > I don't think the check-while-building algorithm provides any more > determinism for clients than the check-after-building algorithm. For sites > that are implementing pinning, they have two absolute guarantees - the > SPKI of the EE cert, and the SPKI of the EE's signer - will always be in > the chain. Above that, the exact nature of what's valid - either with > check-after or check-while - is somewhat dependent on the applications' > trust store - and if you wish to pin at those levels or above, you need a > robust pin set. PKP-R-O provides a means to discover that pin set > proactively prior to pinning. OK. I get it; different approaches are taken by different UAs, and this standard cannot resolve that. The fact still remains that check-after-building approach could result with pin failures if the "wrong" certificate in the chain is pinned (e.g., the root). If the UA decides to use a different path (for whatever reason), the pinning will fail. Perhaps the paths can also change with time, making these problems even more dangerous. If we accept that path building is outside the scope of PKP, then the RFC should at least describe these problems and give strong advice to either (1) pin the EE's signer and (2) do something else at own risk. > Cheers, > Ryan > -- Ivan From nobody Thu Apr 24 12:24:33 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA151A03D6 for ; Thu, 24 Apr 2014 12:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_FAIL=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zr9H8SwM7s5 for ; Thu, 24 Apr 2014 12:24:29 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DAA961A0381 for ; Thu, 24 Apr 2014 12:24:29 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id C98862007871C; Thu, 24 Apr 2014 12:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=jUT4nQe2eRFuV8Jd4VF/AhnasTo=; b=RnUR6sBJi0WMwbGiB EKjeoflJkfoW1Ah8Km30fWfgxd9bTX5Aue/l4nj1ZB2TLPqk/IBijwM6XG5+SkZl 2/1ylYLlt38rXqpd/VAV1YI/q+T9vHtz7LV/Z/oFsZ6+csmEK/9fnU80xxUceok8 9goINK0j8RZiP58JvpqK5KuFb8= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 9347F2005D82E; Thu, 24 Apr 2014 12:24:23 -0700 (PDT) Received: from 216.239.45.82 (proxying for 216.239.45.82) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 24 Apr 2014 12:24:23 -0700 Message-ID: <6a2064f8530f65e9c4f1db3c426e2dfd.squirrel@webmail.dreamhost.com> In-Reply-To: <53595F90.2020901@gmail.com> References: <53577A6A.80408@gmail.com> <74b4601bba58daeb9b09bae7fd96e794.squirrel@webmail.dreamhost.com> <53595F90.2020901@gmail.com> Date: Thu, 24 Apr 2014 12:24:23 -0700 From: "Ryan Sleevi" To: "Ivan Ristic" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/Xlud1ZgQoml_vdw26zQ9LhFVVM0 Cc: websec@ietf.org Subject: Re: [websec] Clarify pin validation for hosts with multiple trust paths X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:24:31 -0000 On Thu, April 24, 2014 12:01 pm, Ivan Ristic wrote: > On 23/04/2014 19:34, Ryan Sleevi wrote: > > On Wed, April 23, 2014 1:31 am, Ivan Risti=C4=87 wrote: > >> In Section 2.6. ("Validating Pinned Connections"), there is this > >> wording: > >> > >> "To perform Pin Validation, the UA will compute the SPKI Fingerprin= ts > >> for each certificate in the Pinned Host's validated certificate > >> chain, [...]" > >> > >> It is assumed that there is only one validated certificate chain. I= n > >> practice, there could be multiple valid certificate chains, some wi= th > >> pins, others without. It's possible that a UA will first process th= e > >> paths, select one deemed to be the "best", only after which the pin= s > >> will be examined. If the selected path is without pins, the connect= ion > >> will fail, even though there might be another paths that could have > >> been > >> used. > >> > >> I think the specification should describe this situation, and instr= uct > >> UAs to try alternative (acceptable) trust paths in case of pin > >> failure. > >> > >> -- > >> Ivan > >> > > > > Note that describing path *building* algorithms has largely been outs= ide > > the scope of most protocol work. The fact that there are multiple val= id > > paths - eg: via the chasing of authorityInfoAccess - has in fact been > > contentious in other WGs (PKIX/TLS, for example) - in part because th= e > > aIA > > is unvalidated, attacker-controlled data being processed by the clien= t. > > > > The exact behaviour of the UA's path building algorithm is equally on= e > > that differs wildly between UAs (and notably, sometimes between the s= ame > > UA on different platforms). > > > > The behaviour you describe as preferable (check-while-building) is > > something that's been/being implemented in Firefox, while the behavio= ur > > you dislike (check-after-building) is something that's been implement= ed > > in > > Chrome. For Chrome, when dealing with different platforms' path > > validating > > APIs, the check-after-building is the only implementation *possible* > > using > > these APIs. > > > > I don't think the check-while-building algorithm provides any more > > determinism for clients than the check-after-building algorithm. For > > sites > > that are implementing pinning, they have two absolute guarantees - th= e > > SPKI of the EE cert, and the SPKI of the EE's signer - will always be= in > > the chain. Above that, the exact nature of what's valid - either with > > check-after or check-while - is somewhat dependent on the application= s' > > trust store - and if you wish to pin at those levels or above, you ne= ed > > a > > robust pin set. PKP-R-O provides a means to discover that pin set > > proactively prior to pinning. > > OK. I get it; different approaches are taken by different UAs, and thi= s > standard cannot resolve that. > > The fact still remains that check-after-building approach could result > with pin failures if the "wrong" certificate in the chain is pinned > (e.g., the root). If the UA decides to use a different path (for > whatever reason), the pinning will fail. Perhaps the paths can also > change with time, making these problems even more dangerous. > > If we accept that path building is outside the scope of PKP, then the > RFC should at least describe these problems and give strong advice to > either (1) pin the EE's signer and (2) do something else at own risk. > > > > Cheers, > > Ryan > > > > -- > Ivan > Right, this has been the fundamental tension that others, such as Trevor Perrin, have called attention to. Different applications have different trust stores - this is, arguably, a good thing (for example, more security conscious applications can move at a quicker pace to deprecate insecure algorithms/configurations than a generic, OS-level store can). Further, CAs can and do cycle certs - with the transition to SHA-2, we are already seeing a variety of CAs who have = a variety of root certificates (RSA, ECC) x (SHA1, SHA2) that are all capable of cross-signing the same intermediate. There was the past discussion about whether or not it makes sense to pin to a 'named entity', and leave it up to the UA to correlate that named entity into a specific root. This was discussed in Issue 58, but the end is that there isn't a good framework for naming here. I don't agree that pinning the EE's signer is necessarily good advice - CAs regularly rotate their intermediates (eg: for CRL partitioning), so it's hard to suggest that's a good, long-term stable solution. Really, th= e solution is for the site operator to coordinate with their CA and work on recommended pinning practices for the CA's PKI. This would be easier if CA's actually documented their PKI consistently, but sadly, my experience is that most CA's repositories only contain the "current" view of their PKI, and not historically-and-still-valid or trans-valid (to borrow Peter Eckersley's term) certificate paths. From nobody Thu Apr 24 12:33:13 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC1D1A038E for ; Thu, 24 Apr 2014 12:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rDL3LEOH4WS for ; Thu, 24 Apr 2014 12:33:09 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6B41A036B for ; Thu, 24 Apr 2014 12:33:09 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 49D20F984; Thu, 24 Apr 2014 15:33:01 -0400 (EDT) Message-ID: <535966ED.3030009@fifthhorseman.net> Date: Thu, 24 Apr 2014 15:33:01 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: ryan-ietfhasmat@sleevi.com, Ivan Ristic References: <53577A6A.80408@gmail.com> <74b4601bba58daeb9b09bae7fd96e794.squirrel@webmail.dreamhost.com> <53595F90.2020901@gmail.com> <6a2064f8530f65e9c4f1db3c426e2dfd.squirrel@webmail.dreamhost.com> In-Reply-To: <6a2064f8530f65e9c4f1db3c426e2dfd.squirrel@webmail.dreamhost.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3X38hwD6PP36uIChs0DC1E8q4bdJP2Xps" Archived-At: http://mailarchive.ietf.org/arch/msg/websec/_afeqlCA-Gv6Gh6NRLVLLkeSMZE Cc: websec@ietf.org Subject: Re: [websec] Clarify pin validation for hosts with multiple trust paths X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 19:33:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3X38hwD6PP36uIChs0DC1E8q4bdJP2Xps Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/24/2014 03:24 PM, Ryan Sleevi wrote: > I don't agree that pinning the EE's signer is necessarily good advice -= > CAs regularly rotate their intermediates (eg: for CRL partitioning), so= > it's hard to suggest that's a good, long-term stable solution. just wanted to give real-world confirmation on this: with heartbleed i know a lot of folks have done a lot of cert reissuance. at least one CA has re-issued certs in this context from a different intermediate CA than the original cert was issued from. Had the re-issuing site been pinning to its immediate issuer, the re-issued cert would have been rejected by pinning clients. > Really, the > solution is for the site operator to coordinate with their CA and work = on > recommended pinning practices for the CA's PKI. I agree with this, and that CAs need to be much clearer (to both subscribers and relying parties) about their planned infrastructure transitions. --dkg --3X38hwD6PP36uIChs0DC1E8q4bdJP2Xps 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 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTWWbtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcA/sP/3/B0ffpDzfuV6UPSJ9sEkPu C5Dbw44Vqtd3pYqOtXppKAoE2Nqvr4RY97/OY5JHPeGZJQi6RHxnD4ZWMsT+8px7 Mglz06eI+8lCNJrgg4bZN+ho0Jgc5odGWvrE0T8LsKc4iapON0j8F74nLmw03/zq adNQKnLoP13+vBHZkGGnQVDmduxI2bBn4Lhkq4/1hP6wW0TI3z3kaYodie3gIst0 +SwZDKCqRenVtnwkULdUPESXC+qmZUqM00xkEmbN6UytDbrJtcXwneq0dFeJ0XIO dOZbyBRpEy6/88HD05RdoYaVFM3r+nrKwDXYKTkZUQ8VjYDHG4N+Uvm0LyvOFDTg 5L3KBrwtVZIGmsq4dpbs/Hxk3Zy5ZO33oB6zfHYuwsWmAtZRCpV+sHItCqQfvXpg jVg7bvYLIzV3RJWKZc2kJtcRTSBu/5BM9h8byWTsIjSLB5I05pw248x+OAvS64ei dq7qi86j6m9ou2oQPjDWBME5CwEDH9ZbZrb/nSrPLLvIv/yb70CJ0KWc2DESYcNP E1T8Zlwv84vL01rfuI9ORYPuCYUrJAfwy+2KzXGwxhl0LLkjrQrW0d1yIb8/0bP9 XCo5/CIXNtO3Iu2WybximPFH+k1FsV+ksSu+7xA01oIg9sXZ4UrfQAKQxx4pEtIv 9da8bQW+gfhfnxrUy3v2 =VBOC -----END PGP SIGNATURE----- --3X38hwD6PP36uIChs0DC1E8q4bdJP2Xps-- From nobody Mon Apr 28 15:23:27 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBB91A8832 for ; Mon, 28 Apr 2014 15:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKa8teTsf7fy for ; Mon, 28 Apr 2014 15:23:20 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 533AC1A8852 for ; Mon, 28 Apr 2014 15:23:15 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h18so5412533igc.2 for ; Mon, 28 Apr 2014 15:23: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; bh=3QN+KbaWjcLudbMONFIeG5DacF8BqMgF+w8PG1iA6hA=; b=LHVgD7iLBoqisgh09MQrLm6737eQIVXe4s7lNv4INYPR0+qh/nW9JjQITIgkugEXM9 C2XWdBzvBcG8AHm7VFSTmpcIP9uRjqlbWV0XU7gKiJEGjWpkzGqp8yXdZgZiYl9g8YyO naxnf0o0J0HORkdkmMieRRAwZMnnqHqaRZo9fz+sHwEIWi+8QgzyEtP2Qysfi5F987FU jBaYA6Tmke4n1HliL2QTyVria1WXJyoD8QtqP1awc+Z8czLrwaODzLZ18x4sYnsaWrtc gLGdqLqsrRCG6SK+ILzKRIVpoDh2kB46VuX5nvw0pcBBtKwdEBMouYRakBQAER4/1ooR BvIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3QN+KbaWjcLudbMONFIeG5DacF8BqMgF+w8PG1iA6hA=; b=Z01xnpQ8cokSPwgsRQXS6ypvcQt8dEhzGsLJfbO65v3enBVymAv58F1N8tQ256jhaF dlQeaGrKgrQw9j3zQ3ydohv2z1Jsk9yRW+NUmuddvbU37bBkoLVDwrFcWkBW08mmWnjw nb4F8f9xz2XUYek/7bMMtNt7yNc8ZPavelor4Qul4XaAjy34jaIDF2wVSOUZd2+0+j9z F+l0XL99u4K2LP3m9GV8+6+GkVrl1wSiiro8H9QGwNxMdIjZPSJ5xovlctARR+VyG2BC aB841fwY6j2gBkjjYCQ+h4CAbeJDFsnFVCoIbdqnqcEuyWC/f0IYoLKdW1OoIKNhhTgv 00jw== X-Gm-Message-State: ALoCoQlOB3JxjEmvV7DKbjhng50W0a/SXPLVwM4MO1ZWprKQ2ducyT734v0aDqKrYoKruZHgItNphq2sycMWEUD+yAg+TQ8GQDWI+kpwU+RbFWll/9EKPc6Depnnw2lLcEijIvgJyUB+/aVLpnO/l/jS56hvcAg4Sy90O62uIh/mml+WWltpvuD9hQia0BLT7vhr56LUjdHM MIME-Version: 1.0 X-Received: by 10.43.132.136 with SMTP id hu8mr5184191icc.61.1398723794235; Mon, 28 Apr 2014 15:23:14 -0700 (PDT) Received: by 10.64.165.2 with HTTP; Mon, 28 Apr 2014 15:23:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 15:23:14 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/fefwcSu3iqUkT49pc9idBZe4S24 Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 22:23:23 -0000 Thank you very much Tom! I've adopted your text: https://code.google.com/p/key-pinning-draft/source/detail?r=399853be11c34f6621cfc9b9de35db44d819be98 As for: we'll follow up about that in the separate thread. On Mon, Apr 7, 2014 at 6:29 AM, Tom Ritter wrote: > On 5 April 2014 14:37, Trevor Perrin wrote: >> I think your intent is that there's 2 different types of pins (regular >> and report-only), which don't interact. I.e. setting max-age=0 on a >> regular PKP header doesn't clear PKP-RO pins, and vice versa. And >> when contacting a pinned site, the UA might have to apply both pins to >> it. >> >> Seems reasonable, if other people agree. > > That is my take on it as well, and what I desired. I think the > wording needs to be clarified significantly however. All of the logic > around the interaction of PKP and PKPRO is buried in the report-uri > subsection. I would suggest a new 2.3.2 and change the report-uri > section. Textual Suggestions: > > My thoughts on the report-uri section: > >
> > The OPTIONAL "report-uri" directive indicates the URI to which the UA > SHOULD report Pin Validation failures ( target="validating-pinned-connections"/>). The UA POSTs the reports to the > given URI as described in target="reporting-pin-validation-failure"/>. > > When used in the Public-Key-Pins or Public-Key-Pins-Report-Only header, > the presence of a report-uri > directive indicates to the UA that in the event of Pin Validation failure it > SHOULD POST a report to the report-uri. If the header is Public-Key-Pins, > the UA should do this in addition to > terminating the connection (as described in target="validating-pinned-connections"/>). > > Hosts may set report-uris that use HTTP, HTTPS, or other schemes. If the > scheme in the report-uri is HTTPS, UAs MUST perform Pinning Validation when > the host in the report-uri is a Known Pinned Host; similarly, UAs MUST apply > HSTS if the host in the report-uri is a Known HSTS Host. > > Note that the report-uri need not necessarily be in the same Internet > domain or web origin as the Known Pinned Host. > > UAs SHOULD make their best effort to report Pin Validation failures to > the report-uri, but may fail to report in exceptional conditions. For > example, if connecting the report-uri itself incurs a Pinning Validation > failure or other certificate validation failure, the UA MUST cancel the > connection (and MAY attempt to re-send the report later). Similarly, if > Known Pinned Host A sets a report-uri referring to Known Pinned Host B, and > if B sets a report-uri referring to A, and if both hosts fail Pin > Validation, the UA SHOULD detect and break the loop by failing to send > reports to and about those hosts. > > UAs SHOULD limit the rate at which they send reports. For example, it > is unnecessary to send the same report to the same report-uri more than > once. > > > >
> > > > > New 2.3.2 > > Interaction of Public-Key-Pins and Public-Key-Pins-Report-Only > > A server MAY set both the Public-Key-Pins and Public-Key-Pins-Report-Only > headers simultaneously. The headers do not interact with one another but > the UA MUST process the Public-Key-Pins header and SHOULD process both. > > The Public-Key-Pins header is processed as according to section 2.3.1. > > When the Public-Key-Pins-Report-Only header is used with a report-uri, the > UA SHOULD POST reports for Pin Validation failures to the indicated > report-uri, although the UA MUST NOT enforce Pin Validation. That is, > in the event of Pin Validation failure when the host has set the > Public-Key-Pins-Report-Only header, the UA performs Pin Validation > only to check whether or not it should POST a report, but not for causing > connection failure. > > Note: There is no purpose to using the Public-Key-Pins-Report-Only header > without the report-uri directive. User Agents MAY discard such headers > without interpretting them further. > > If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD note > the Pins and directives given in the Public-Key-Pins-Report-Only header as > specified by the max-age directive. If > the UA does note the Pins and directives in the Public-Key-Pins-Report-Only > header it SHOULD evaluate the specified policy and SHOULD report any > would-be Pin Validation failures that would occur if the report-only policy > were enforced. > > If a Host sets both the Public-Key-Pins header and the > Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin > Validation as specified by the Public-Key-Pins header, and SHOULD note the > Pins and directives given in the Public-Key-Pins-Report-Only header. If the > UA does note the Pins and directives in the Public-Key-Pins-Report-Only > header it SHOULD evaluate the specified policy and SHOULD report any > would-be Pin Validation failures that would occur if the report-only policy > were enforced. From nobody Mon Apr 28 16:04:56 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A755F1A8839 for ; Mon, 28 Apr 2014 16:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_1NKccvCVpo for ; Mon, 28 Apr 2014 16:04:52 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id DFB521A6FB8 for ; Mon, 28 Apr 2014 16:04:51 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id h18so5308129igc.0 for ; Mon, 28 Apr 2014 16:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OtpWtS+KYSFWLFzMjnn//JNPbM2nQBhZPzHCZOPMn0k=; b=p1qkNHC3nLvsaOC5hufeW0xCMmidcU31Bf4LG9WZ7C5VpMKXVIX0108t1mrd4ax9e+ iRuraragbKYFH3C2xT74amt3gMnbEfLdrmKcLPgdvjnKPpdUSv8S3AyqGlpHBCv5Xnqh aRSCcgmHu5Q1HyExi0xgQFAHvuEgp3FK8sCeik4MrUtvxVTzWPfYRhc0H7AazmmLr8wV m6ziq1D8xPBl/c4ZAG1PmHQQxEvatiJpwr2AyivT6FsyMhHdQQ4vSNhHJa/kE3jhgjYI vdK+ys5w5AB3sCUTjvE3s6CqKbtyCAJMK8addivyN+DI44ywSGkjU3fK8wScA2dvf3s7 85mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OtpWtS+KYSFWLFzMjnn//JNPbM2nQBhZPzHCZOPMn0k=; b=Dd8H9YTc/NKa7IX6RH/N+ij6AL+63vUVH1iTk6W3OT18OJBNWRJUnzmqyflom1BxW3 lhLxjF5MLw1sjq0vM4F+zCalkhcVSR2/HRVzmb1f+rm+DxXE+K21eLgddOoUr8kXoWch TpRGx8cpOC+ts9OeeCc+rB4U13uuu4KL8YcSH1yo4GtwLuaCIDhXQ2IJOInRUAFiT+7u Wzdf2FxL3+TBbGkO6Y8nopsKyiSa5+HWjLF8CkbRftNpjRTy2vkwZmIEcwOCb54tQNSH g6m754e+24sDa/LYX8FOqKcXZwQ26wVFWj+If/lKBr/uus2UHNV9vTsIJSwO+JEvXdtj uZMA== X-Gm-Message-State: ALoCoQmLaRP8OnmxU2YZLF/h9WQq27eqmXqEP9Aa/sq1PWZWFy4VKRnvBie4zor5K89L9ybTRidCvBlszhIPXSQdbL2RspVMpRI3xClRMxEkKI5XpIgVJ6bc/qMcSFEKb4tLjsGILv1AGeiGnYCTaZ272p+AlDtggLu7JzPnHCJbgCTY/acSo2VWCqByNGHYYsEX3xQIl+Gp MIME-Version: 1.0 X-Received: by 10.50.23.52 with SMTP id j20mr23759790igf.13.1398726290689; Mon, 28 Apr 2014 16:04:50 -0700 (PDT) Received: by 10.64.165.2 with HTTP; Mon, 28 Apr 2014 16:04:50 -0700 (PDT) In-Reply-To: <5344CE2D.6050701@fifthhorseman.net> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <5307BDFD.7060009@gondrom.org> <5308F126.7020308@fifthhorseman.net> <5344CE2D.6050701@fifthhorseman.net> Date: Mon, 28 Apr 2014 16:04:50 -0700 Message-ID: From: Chris Palmer To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/SwDnTgk0CumsIcHyxPdS2rTgx1o Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 23:04:54 -0000 On Tue, Apr 8, 2014 at 9:35 PM, Daniel Kahn Gillmor wrote: >>> I also think that (b) (unpinning) is the right answer here, considering >>> the semantics of the decision. >>> >>> Consider it this way: >>> >>> * the site operator gets to decide what pins they issue, and what hash >>> algorithms to use. >>> >>> * the site operator presumably has a rough idea of how many of their >>> clients are using software that might not be able to handle new hash >>> algorithms >>> >>> * the site operator also decides what security properties/strength the= y >>> require of a given hash algorithm. >>> >>> If the site operator considers an older hash algorithm to be too weak t= o >>> rely on, and a client only knows that hash algorithm, then the site >>> operator asking that client to unpin (and perhaps acknowledge the lack >>> of pinning to the user via whatever UI provides information about the >>> pin) is the right thing to do. >> >> I think I agree. > > can this be stated explicitly in the draft then? I think this guidance > would be useful for the inevitable corner cases. Well, it's hard to draft text that reads well. There are a lot of hypotheti= cals: * A new version of this spec has been published that specifies BetterHash. * Separately, SHA256 becomes deemed unsafe. * Some site operators would rather be un-pinned than to pin with a hash function that is vulnerable to a preimage attack of complexity (pretend with me) 2**80. * Some UA that is fancy enough to support HPKP, but not fancy enough to also support BetterHash, exists in the wild for long enough that site operators actually face that weird choice. Honestly, I'd rather deal with this question in the future version of the spec that actually specifies the use of a second hash function. I am not real excited :) to specify how the UA should behave if a situation arises that the spec currently doesn't even allow for. >>> 0) if a site operator decides to use more than one hash algorithms in >>> the future, do we require that they issue the same set of pins under >>> each algorithm? So if i'm pinning keys X and Y and Z, and i'm using >>> both pin-sha2-256 and pin-sha3-256, must i issue 6 pins? I think it's >>> reasonable to say yes here, even if we don't have any other digests >>> defined yet. >> >> No, I'd like to say that sha256(foo.getSPKI()) =3D=3D sha3(foo.getSPKI()= ) >> =3D=3D sha4(foo.getSPKI()), and for UAs to treat them as identical. > > i'm afraid i'm not sure what you're using =3D=3D to mean here, or "UAs to > treat them as identical". > > Given a key that produces three different digests, if the digests are > not broken, then sure a match on any one is as good as a match on any oth= er. > > But if implementations of this spec are expected to survive an algorithm > agility shift (even if we want it to be all-sha256 for now) then we need > to specify what happens when some of the known digests match and others > don't. > > consider a world where we've made sha3 available in this spec, and > someone figures out a preimage attack against sha-256. > > now, that attacker can create a match on the sha256 pin but can't create > a match on the sha3 pin. > > if we treat the sha256 pin as identical to the sha3 pin, that we've just > reduced the strength of the pin to the weakest algorithm. or am i > misunderstanding what you mean by "identical"? No, that is what I mean. It is true that there will be a window of vulnerability =E2=80=94 we can't just say, "Starting next Tuesday, you're n= ot pinned unless you're using SHA-3." There has to be a period of deprecation before we get rid of a thing completely. Hopefully, when somebody publishes a research paper showing an improved attack on SHA-256 =E2=80=94 say, preimage at a cost of 2**128 (yikes!) =E2=80=94 we s= hould immediately begin the deprecation process in anticipation of the attack improving to 2**80 soon. Conscientious site operators will observe the new spec, and update their headers, and will be ready for the time a year later when we say "...UAs MUST NOT honor SHA-256...". Honestly, that is good enough for me. Of all the problems with web PKI, the hypothetical future weakness of SHA-256 in a feature that already greatly reduces the potential for mis-issuance just doesn't rate. We're talking about, after years of unprecedentedly awesome research by brilliant cryptanalysts, an attacker who can (a) get a mis-issued certificate; (b) can do the 2**80 work to get their cert to match the good pin; and (c) even after all that can only attack (d) sites using that key that didn't start pinning with SHA-3 yet. I owe you a beer (or your flavorite beverage) anyway, and if that ever happens, I'll get you a second one. :) From nobody Mon Apr 28 16:10:50 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204DF1A700B; Mon, 28 Apr 2014 16:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdbPfRr2bbTM; Mon, 28 Apr 2014 16:10:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 134AF1A8832; Mon, 28 Apr 2014 16:10:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 16:10:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/P0Nmft3lugNW0ajCM-UNmJwNsz8 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 23:10:45 -0000 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 : Public Key Pinning Extension for HTTP Authors : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-12.txt Pages : 25 Date : 2014-04-28 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-12 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 nobody Mon Apr 28 16:51:50 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A481A8836 for ; Mon, 28 Apr 2014 16:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tblzwjzzv-Qe for ; Mon, 28 Apr 2014 16:51:47 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 760E61A6F17 for ; Mon, 28 Apr 2014 16:51:47 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rp18so1993236iec.22 for ; Mon, 28 Apr 2014 16:51:46 -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=wp9B1/9vQS8r0/llniHYVlJPBHXqG5rufAm+ypl31x8=; b=cpETbSXOolc8VMU3/7ft0ujhZWIwYFgczDP8DkYI1kLVytZMFh1pIlf3f1oFJIGsqo sHcGUb8YL4yCdGP5HXano8F70ibGCKXNmGboADVWHESZNlFtoKFijq337YpWEMK2KbIa 1n/u6ypRKe/iT43ELyz8OTIUdkRLkbtkp+4oy1mx8vO2auhsiEmbLWooHahoY3rmBJ6o LvuDO7H3cJPNa8zmEIPoWMro9ekCnB4VtaWP+KH1weSlWMmDkTeyaPQR7+jEaZVsO71V ubBQn22dAeyDtlqZNvvpSZY/gICv4+BAZ1oHO5BG6GPmhp5XUqnObYH1OmYzDJNLDZnC 3sDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wp9B1/9vQS8r0/llniHYVlJPBHXqG5rufAm+ypl31x8=; b=k9hvJRd9w/9paI0BAvm3mg+zvbN8E88ruuMrppTkxjCGep+PvgVEASpx0iydfnMHFn 9MJczY5EZsMwPfkDfXpB7h5g6cwjrFYMrsow+ypVNRZfXwf5mX57PxaQJpkWLpfvcS6/ Fw09+eeWXEMOwj3rxnlCEqHxe0l6dl0QXVAvl8QgoPlMI74Gq8Q011liGoD8+8WzicYb VqeV8/CpN3nyFHkX1lhDGpWH4YT5DyYa03loR+wHaGKVtcOVeE/Kx12q/6a63rKz0Plz l4LPOYUPvPPeBIjUAEitwZh1dwfthaKimTu1KEeAfVJoJpH4m3JRTk4V6sBcoKqxDmss cANQ== X-Gm-Message-State: ALoCoQkSQ8un4G0vzHMUEzOPnZM3gAuMy4+VsiyU0YAaIpTCTUp3TqGnNCgfS34pOuB/aNlhSyAYHMdbuCbaldm0bMc6qSDYU++eNRZy2MMVAZjA35IbvaAO7TitJ1pEjfdYzNkiEhuXY7x612WedHYgj99Xcd+BOeQzyWxVzf3/7DikBPjD6UhgfWR7oRU58pwnBkqxL3aH MIME-Version: 1.0 X-Received: by 10.50.22.37 with SMTP id a5mr27213918igf.30.1398729106492; Mon, 28 Apr 2014 16:51:46 -0700 (PDT) Received: by 10.64.165.2 with HTTP; Mon, 28 Apr 2014 16:51:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 16:51:46 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/cKH4wS-kdgCSPtDAERXLyCa32Uk Cc: IETF WebSec WG Subject: Re: [websec] First Connection Active Attack in HPKP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 23:51:49 -0000 I see your point... is the attack so marginal that it doesn't matter either way? I'm not sure I feel strongly any more on this topic. On Mon, Apr 7, 2014 at 6:29 AM, Tom Ritter wrote: > Sorry to be second guessing you Chris, but wanted to ask about this change: > https://code.google.com/p/key-pinning-draft/source/detail?r=5810662a42e56938272d9db4b2e5373914b266f4 > > Let's say an active attacker does MITM on a client. (That's the scenario > you reference, right?) The client can have pins for the server or not. > > If the client does have pins, the active attack fails and generates a report > event. The attacker knows the attack fails because a) perhaps they observe > metadata about the report event being sent right away but more concretely b) > because their attack fails. > > If the client doesn't have pins, the active attack succeeds. The attacker > knows the attack succeeded and that the pinning wasn't effective because... > it succeeded. Whether or not a report event is generated the attacker knows > it succeeded. Furthermore, if an attacker is attacking the client and wants > to learn if it supports pinning or not, it can look at the User Agent > header, TLS handshake fingerprinting, or active javascript injection. > > If the attack succeeds, and the attack already knows about it succeeding, I > don't understand the harm in generating a report event. Maybe the attack > will block it (and know it was generated), but maybe they won't and it will > get out. Maybe the report will be held for some time and sent later. > > -tom From nobody Mon Apr 28 23:25:04 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072E81A8836 for ; Mon, 28 Apr 2014 23:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pbxwNqPhK6c for ; Mon, 28 Apr 2014 23:25:02 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0D31B1A86DE for ; Mon, 28 Apr 2014 23:25:01 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f8so610049wiw.9 for ; Mon, 28 Apr 2014 23:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ofZpfxQjrzS+yJZAWbEwXD72Nth5CatD8YzCt+f9nso=; b=XExWoYcHe2xknahNBx3ougrC3PVVKu3E0UvzJC9LWKYkZXmVbT0sJxBhB7X7B3CyNk jVsKreiUeX88lxJoO6MNpHAm676Q6rcVZoOTXlmP0x6cBhUbCe3EvyW1MCleGjzzCQJ6 wNFR9mChHF7h9Qde0daDhhZzKGlAXyn2gVlVPVitE6tIQtWHFk+oxc/vCN6abqFCguuu LVN8w/6eaQE/9XAFTf8MfFtI7FMPEpPv+WUZTTBj0yJt3fYDRlDm1DZawqkkPL3kySgo NOiV/9rrbp4BTwl0T2ufK2aSyrykAdZYzKzEKEq906KqJx5TFf0ahHBNkwRi9dlc0+1m L2Vw== X-Received: by 10.194.203.42 with SMTP id kn10mr658115wjc.54.1398752700560; Mon, 28 Apr 2014 23:25:00 -0700 (PDT) Received: from [172.24.248.99] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id go20sm29533777wjc.18.2014.04.28.23.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 23:25:00 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 09:24:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <35B52561-A6B3-43F9-9291-81D46444D3D2@gmail.com> References: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> To: IETF WebSec WG X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/mmpQCoNDiB-w299AX2laaITnQ_k Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 06:25:04 -0000 Thank you Chris, Chris, and Ryan. Having reviewed this, I think this version addresses all the issues = raised during WGLC.=20 Unless someone hollers, we=92re going to send this to Barry early next = week, so please take this time to read the draft one more time. Thanks! Tobias and Yoav On Apr 29, 2014, at 2:10 AM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Public Key Pinning Extension for HTTP > Authors : Chris Evans > Chris Palmer > Ryan Sleevi > Filename : draft-ietf-websec-key-pinning-12.txt > Pages : 25 > Date : 2014-04-28 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-12 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-12 >=20 >=20 > 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. >=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 From nobody Tue Apr 29 04:29:09 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2046B1A08C4 for ; Tue, 29 Apr 2014 04:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VDWeC9HDwrY for ; Tue, 29 Apr 2014 04:29:07 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C6B431A08C2 for ; Tue, 29 Apr 2014 04:29:06 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id im17so66808vcb.14 for ; Tue, 29 Apr 2014 04:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UMmxSUMcMFROkG8mLHqJHhph74agLuzsyrro4zjztY8=; b=lt06/G7gxt2r81q0AjxHhMdgGah0axmKpU4pLxeJwIWIgo+UZBhzFKvL7s4rYgkeEG /F3L5UqT+GBCyhIrKeawjoTtle5D0jPpyzfVySP5dfd5mBQGAP+Gsq5pNUSUH4WhxUza tNBTQcAHlj/MbL9N5488eOvwT3k7tYZXHv5g4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UMmxSUMcMFROkG8mLHqJHhph74agLuzsyrro4zjztY8=; b=edNv8bhMy0bdPsahF/cN/LyZsHXznCHkU5n1s1RkIw5oeVQ3UowISurmm/JHM605W/ 8MaL9NVVg/V4YG7KmUZGsAGUbVCYmD62C0k+TS091pMD4Dhio2BldAO3S6beFRSUmfhx w0vHI07Yuj/RMsinhVssLFfcI+WqqLajsA4XIS3iQsJEBzJ+dWP0ltt+VEvkl5XPZZx/ E5F8Odkwzhj8ZxboWN/hbSzpfuKsiLlZ+IEIK3cHYNPkUp6UM00f7Xt7T7jkxxilKS+K V8pWgZ/iN58vNcWdmUuLH4cMNICfDWFHIF8FzsWbV0bATQbmdGJfdHeSzn6RHUJ5aZ+7 9Gcg== X-Gm-Message-State: ALoCoQlR6fKGYwBrDt4u38J+OBJJBLryJsOtRQZOIFPuwPRu+3LlVwBFdEND9OwdoTF2JF/Y0mis X-Received: by 10.52.12.36 with SMTP id v4mr25522288vdb.20.1398770945563; Tue, 29 Apr 2014 04:29:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.88.101 with HTTP; Tue, 29 Apr 2014 04:28:45 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Tue, 29 Apr 2014 07:28:45 -0400 Message-ID: To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/SXmhtfdRxNW3PCu1N_Cbh91hVw4 Cc: IETF WebSec WG Subject: Re: [websec] First Connection Active Attack in HPKP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 11:29:08 -0000 On 28 April 2014 19:51, Chris Palmer wrote: > I see your point... is the attack so marginal that it doesn't matter > either way? I'm not sure I feel strongly any more on this topic. I would call the difference marginal only if the we never envision the report having anything done with it except immediate sending. If it's stored for later, logged, a browser extension collects them all and sends them out through Tor or some other mechanism... then I would say it's not marginal. And since those are possibilities, I would say it would be better to remove the paragraph and not have different behavior. It would also probably make the code simpler, too. -tom From nobody Wed Apr 30 14:41:27 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1737C1A0852 for ; Wed, 30 Apr 2014 14:41:22 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jtw6GqOHG3oW for ; Wed, 30 Apr 2014 14:41:19 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8491A066A for ; Wed, 30 Apr 2014 14:41:19 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so2961063wiv.3 for ; Wed, 30 Apr 2014 14:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wN6KXuvVKSS8GadDGVprbmw36cUp2OtGd0htWDtibkc=; b=GJlRR2CWn9IfGvFWmm9fXf19UiGGNxxdBA7prw8pOSmLMTAtst/5H1o8bdycRb4nKq tEN2Ov0TiKVfItUeaMvaG27GM0GcKUw3+rhrm93bMvAtYmycMu2W+mMxM71n8OIV+Ay+ RUOeW/fJoRAPPHrzhU9wxs2/h8m2f1VbxpDz9Fuh9amSNSFS+oWi8rQbEhUBpx7PZq64 7NcrlQtKwicOHo63WSxmDH6JlKowKAWkI8TLrr/fg9RKa8A7CcIJvWzTORjrRukffylF G4XiEnt7TSWs4A1RLW3GlkpwbG32ZArv7JybNv65D91hWCMmdksyDXEVyCK6hPJLWHtI bzgg== X-Gm-Message-State: ALoCoQlnXQU9l39torTpJNxIHLklIDj1NTQNyRRItOWI7cENm89QIY5X8DZOnArkW+gfwUFRdOy7 MIME-Version: 1.0 X-Received: by 10.194.63.46 with SMTP id d14mr5881846wjs.24.1398894077384; Wed, 30 Apr 2014 14:41:17 -0700 (PDT) Received: by 10.216.155.7 with HTTP; Wed, 30 Apr 2014 14:41:17 -0700 (PDT) X-Originating-IP: [50.204.254.254] In-Reply-To: <35B52561-A6B3-43F9-9291-81D46444D3D2@gmail.com> References: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> <35B52561-A6B3-43F9-9291-81D46444D3D2@gmail.com> Date: Wed, 30 Apr 2014 14:41:17 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/IyrQXXMOxMrnQ7k6RH0QJPwN9PM Cc: IETF WebSec WG Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 21:41:22 -0000 On Mon, Apr 28, 2014 at 11:24 PM, Yoav Nir wrote: > > Having reviewed this, I think this version addresses all the issues raised during WGLC. The added sentence in 2.7 on preloaded/dynamic pins doesn't match the rest of the text, which is written to mandate specific behavior. If we're not going to discuss implementation alternatives, we should just delete most of 2.7 and let implementations do what they want. The text in 2.3.2 on PKP-RO doesn't really match the rest of the doc. Most of the draft is written as if there is a single header, set of Pinning Metadata, and "Known Pinned Host" state. But 2.3.2 doubles those things, which causes many minor ambiguities, e.g.: * 2.2.1 - "a Pinned Host SHOULD include in its response exactly one PKP header field" * 2.3.1 - "the UA MUST process only the first such header field" * 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? (or new "report-only" pins)? * 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". It's unclear whether a "report-only" pin counts as a "Pinned Host" for the purpose of other TLS errors. The draft could use an editing/cleanup pass to clarify all this. Also, some of the issues I've been bringing up since July need to be addressed: * Interaction with cookies needs discussion, at least in security considerations. 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. * "Pinning Policy" and "Pinning Metadata" are synonyms? * 2.3.1 ... "or," ... "Otherwise" is confusing * 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