From nobody Sat Mar 1 11:17:34 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 DCDCD1A0A75 for ; Sat, 1 Mar 2014 11:17:31 -0800 (PST) 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 3XVs3PaR9Onw for ; Sat, 1 Mar 2014 11:17:30 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 528851A0A5E for ; Sat, 1 Mar 2014 11:17:30 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id g10so2127930pdj.27 for ; Sat, 01 Mar 2014 11:17:28 -0800 (PST) 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=cYL1hUnctl42OayInsNTFK6B7Fqc9ZpydKfEMAZlBwQ=; b=gRZzZcTNC4O2A2Rm+DkN/O57UvkYdnxHFsqfuUhl7CZAzpCvVLILZviwMxFq/eJLj7 tNGVFYlVWhs7HVa+SdZv68/ZNMt3onGir62FX7SzkYf4g3fYXAmQlc7hjNgC+svT+CMv R8dNF27HOXltbvNyA0Z/0Gt2B1f7rFmszFpwE= 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=cYL1hUnctl42OayInsNTFK6B7Fqc9ZpydKfEMAZlBwQ=; b=I/DEdwge8S7yel3Jhmzr7Kench0rBAmPL9ZM1Bi73sa0Wmxp9dBHbfI/U8SDkL8Je1 z1x3MOOM7a6tCJJi/rj73vnxJ2lxhQcJM3Qt3n2/43KNEgCFdus/R6SKxiehSc/HNCXc +SeOJAUWAvJyc9wtNoFgpL87vqlPMU7I2yLwm/b/dQRaQkXskZCrbmUn/b6ijFwyN19r 4WIGlDQo0oXYgaWzuEGTvlgddzIBqyN4xB4hk8jqBD+5dHD/rY29POIOjECUtD573fWh ecy8J9dWP9l+r088qnf1JL44ll8269xu/ckIuiKwOLRKRBa2L2NpokB00mXzbY6w2Gka pdQA== X-Gm-Message-State: ALoCoQmHHYWANQvkIdzLvreKJ2SgkkuOaSR/hzqWr27wQ9liX1jUnnnbsGWId730/Qvm3YZStkY7 X-Received: by 10.66.151.205 with SMTP id us13mr10605118pab.93.1393701448079; Sat, 01 Mar 2014 11:17:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Sat, 1 Mar 2014 11:17:08 -0800 (PST) In-Reply-To: <530FA91B.3060307@fifthhorseman.net> References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> <2BA8C675-BB3E-4549-94FE-B0C11D112903@gmail.com> <52e668d2acf894dbf5cc6efcd3d4510e.squirrel@webmail.dreamhost.com> <530FA91B.3060307@fifthhorseman.net> From: Tom Ritter Date: Sat, 1 Mar 2014 14:17:08 -0500 Message-ID: To: Daniel Kahn Gillmor Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/2-IPlc_2-uh_R8nQYTmNhGhkjHE Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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, 01 Mar 2014 19:17:32 -0000 On 27 February 2014 16:07, Daniel Kahn Gillmor wrote: > On 02/27/2014 03:31 PM, Trevor Perrin wrote: >> 1) PKP-RO implements the full PKP semantics (i.e. is stored for max-age, >> is applied to includeSubdomains), but only generates reports instead of >> hard fails. The browser would store PKP and PKP-RO pins in >> separate/parallel stores, for example setting max-age=0 for a PKP pin would >> not clear PKP-RO pins, and vice versa. >> >> 2) PKP-RO is removed from the spec. >> >> 3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics >> (only check current connection). I'm not sure about the usefulness of >> that, and I worry site operators would be mislead by it. > > As someone who sometimes helps to operate and plan the operation of web > sites, i don't think the semantics of (3) are misleading, but they're > not particularly confidence-inspiring either. > > What is the goal of PKP-RO? Is the goal to encourage adoption by giving > site operators confidence in a proposed configuration or organizational > workflow? As I believe - this. PKP-RO doesn't enforce security for a site, and while a PKP header MAY be saved for later reporting* - an attacker performing a man-in-the-middle attack can block a PKP-RO assignment or a PKP-RO report. (At least, right now, I have a suggestion for this below.) * From http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.1.3 So I feel it's primarily for testing a configuration and gaining confidence in it before rolling it out. > The real footgunnery with PKP will come during key transition/rollover > (or switching CAs), as clients who have cached pins cope with the > changes. Using (3)-style PKP-RO to build confidence in an > organizational workflow around this kind of transition event doesn't > seem possible. I agree. So I'm for #1 - store it. I have afew suggestions around fixing up portions of the doc for this. The PKP-RO header MUST be able to be cleared out at any time by setting max-age=0 if the connection occurs over an error-free TLS connect excepting any requirement of matching a key to a PKP-RO header. Explained, I should be able to clear out an old PKP-RO header even if I set the hash to DEADBEEF and the max-age to a year. The PKP-RO header reports MAY be stored for reporting at another time. I don't think browsers will implement this right away, but down the line I think it might turn into an actual security feature. A report SHOULD be generated and transmitted (or stored) before clearing out an old policy. (So bad is I get an extra report I ignore, good is that an attacker can't definitively silence a report if it is stored for later.) When I recieve reports, I can tell what the PKP-RO policy was at the time by examining the report. Except that the report needs to have a new field in there saying if it's mode is 'enforcement' or 'report-only'. As a site operator, I can even go farther by specifying a non-hash such as sha256=policytest20140301v1 - no one will be able to gen a cert that hashes to a b64 representation of that, and it lets me track my policy deployments if I like. -tom From nobody Mon Mar 3 13:46:18 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 635AF1A0199 for ; Mon, 3 Mar 2014 13:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 KNNzJknOofhn for ; Mon, 3 Mar 2014 13:46:14 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id BA71D1A0165 for ; Mon, 3 Mar 2014 13:46:14 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id to1so539556ieb.28 for ; Mon, 03 Mar 2014 13:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bXRCMkXH2YYh5GsBHc5F6QFIaoowPnw/izhiIxp8Fz8=; b=gx3Yt7MW+yezat1r42wyFcoTUOxZFzoxcCBtqaBWkdtwdEpo3RJjHhq6HGTywYZVuH 2y+3ck4TZAxIarEjq6Rt+swZc9WrBEdKHELj2sF0E96J3Pk4w5fPX4j8H0gtntABRaLJ 8tAJelFo+OT8Op5CfmSqSR6koLDH962wdiVuyWMtgeqQ5lFUmY6KyLNZgL80o1LjAMm1 3NLW6+4iBewn1VzVBrbbWKk29yeBFfF/8Tu6KM1XUqjhw3vB+6nt3O7BoymCjZ7Ib6hO XoNlWBQ4862U2HIF81Dtd5qqptEjtLsjBaDJV1orsCwdXVJB0PJxO69coIE+cIXAP7b8 Wj2Q== 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=bXRCMkXH2YYh5GsBHc5F6QFIaoowPnw/izhiIxp8Fz8=; b=NZ1UFXljeQhbq0LsDPYp304840orwlc36jBJnRZzji4xzNYjlgJOku1WiwpcqfLK4D 1h0A8gLSzUxJwTGlyUrrE+3fNM8geSFE73hPsPwE1KlBQWfZM0aHi5wWPwyG5EEBwTNu bCgaMlIaQ5WCHsYiky4IQgIcAKa33Nmygl1anmFYuZBRvn7UdimOPzQVG92SMHLnWuHY 4yKrFMXFX0T60/REThluQI+aBF5RIuHM5uUkBKcXZRZB+EGwK8S8jdb4mzM+fbn35J+j Jqbd1bG8/W8hwwpuFyIY6p03cS9C4gmw1ss2cF2Snf/yz9eTQn/GAQoFusJtdR8F3vHm XSRQ== X-Gm-Message-State: ALoCoQl/G2DVo8viT3wno47pP+7LQfkHe9pY7wLAV+U7sGDi6ahh358jKeniFD8M4jHVOuHj6+qA4X/X/x2kByqSJTL+uEzSDzK3NtDSrX3NlK3Qwhb4DRNO6F/Vj4yGs5XIqHvHBr9Wq5tSegJgEC92VMYEXiXlU1U2pgurx1EiYPzAajfEauA44ExdtnIHWw2txiEJ6n/d MIME-Version: 1.0 X-Received: by 10.42.20.193 with SMTP id h1mr3587329icb.70.1393883171582; Mon, 03 Mar 2014 13:46:11 -0800 (PST) Received: by 10.64.165.2 with HTTP; Mon, 3 Mar 2014 13:46:11 -0800 (PST) In-Reply-To: References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> <2BA8C675-BB3E-4549-94FE-B0C11D112903@gmail.com> <52e668d2acf894dbf5cc6efcd3d4510e.squirrel@webmail.dreamhost.com> <530FA91B.3060307@fifthhorseman.net> Date: Mon, 3 Mar 2014 13:46:11 -0800 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/bNUeqjjPrMQ9b3LEfm-BEBY__Q4 Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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, 03 Mar 2014 21:46:17 -0000 Hi all, status note: I was very busy last week and I will be this week too, but I'm going to try to get another revision out late this week. But I can't promise to, unfortunately. But I am watching this thread, and not forgetting about this issue. On Sat, Mar 1, 2014 at 11:17 AM, Tom Ritter wrote: > On 27 February 2014 16:07, Daniel Kahn Gillmor wrote: >> On 02/27/2014 03:31 PM, Trevor Perrin wrote: >>> 1) PKP-RO implements the full PKP semantics (i.e. is stored for max-age, >>> is applied to includeSubdomains), but only generates reports instead of >>> hard fails. The browser would store PKP and PKP-RO pins in >>> separate/parallel stores, for example setting max-age=0 for a PKP pin would >>> not clear PKP-RO pins, and vice versa. >>> >>> 2) PKP-RO is removed from the spec. >>> >>> 3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics >>> (only check current connection). I'm not sure about the usefulness of >>> that, and I worry site operators would be mislead by it. >> >> As someone who sometimes helps to operate and plan the operation of web >> sites, i don't think the semantics of (3) are misleading, but they're >> not particularly confidence-inspiring either. >> >> What is the goal of PKP-RO? Is the goal to encourage adoption by giving >> site operators confidence in a proposed configuration or organizational >> workflow? > > As I believe - this. PKP-RO doesn't enforce security for a site, and > while a PKP header MAY be saved for later reporting* - an attacker > performing a man-in-the-middle attack can block a PKP-RO assignment or > a PKP-RO report. (At least, right now, I have a suggestion for this > below.) > > * From http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.1.3 > > So I feel it's primarily for testing a configuration and gaining > confidence in it before rolling it out. > >> The real footgunnery with PKP will come during key transition/rollover >> (or switching CAs), as clients who have cached pins cope with the >> changes. Using (3)-style PKP-RO to build confidence in an >> organizational workflow around this kind of transition event doesn't >> seem possible. > > I agree. > > So I'm for #1 - store it. I have afew suggestions around fixing up > portions of the doc for this. > > The PKP-RO header MUST be able to be cleared out at any time by > setting max-age=0 if the connection occurs over an error-free TLS > connect excepting any requirement of matching a key to a PKP-RO > header. Explained, I should be able to clear out an old PKP-RO header > even if I set the hash to DEADBEEF and the max-age to a year. > > The PKP-RO header reports MAY be stored for reporting at another time. > I don't think browsers will implement this right away, but down the > line I think it might turn into an actual security feature. A report > SHOULD be generated and transmitted (or stored) before clearing out an > old policy. (So bad is I get an extra report I ignore, good is that > an attacker can't definitively silence a report if it is stored for > later.) > > When I recieve reports, I can tell what the PKP-RO policy was at the > time by examining the report. Except that the report needs to have a > new field in there saying if it's mode is 'enforcement' or > 'report-only'. As a site operator, I can even go farther by > specifying a non-hash such as sha256=policytest20140301v1 - no one > will be able to gen a cert that hashes to a b64 representation of > that, and it lets me track my policy deployments if I like. > > -tom > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From bhill@paypal.com Fri Mar 21 12:45:43 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 C92111A07D1 for ; Fri, 21 Mar 2014 12:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.501 X-Spam-Level: X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 GEwhaec1Dszk for ; Fri, 21 Mar 2014 12:45:42 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4821A06EA for ; Fri, 21 Mar 2014 12:45:42 -0700 (PDT) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=M/F6vd+x0+i9YRa5Tp8XdyTUSsJgoyb3FgKPIpKm6D7KKTq+9tzE6SBa fvdUI5Ho1YCwKcDhSkPuFjpSEqDrf2O6rWgRmUIXV4bAZPmlL6kYNCJ9I YyIJYO39nXTVfMuqVFPUu4AC/Si/5dWZaMsLo9wrO39ClTnAMkTmslWe1 M=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1395431133; x=1426967133; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=m7avNQa47hCHQFCzrJhK/QBpKg1u084xjmsvbrgRRo8=; b=CJRqvmQ2sWdzw3wgGxTY6htpMwcee5Z2Uvqe/W9BD/wtp/5C9tKI3Tpw p3b8w4z/R6ihqTRZpY572QO/szvOEx3dj4bEWjh+R3ZzmiqAiJ9UZUR3+ SRwB3jvu4xlwLEbgpBSbrurRforPTC94ZCUxuoUpDfiUrLFvG4WiAaFBf E=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.97,705,1389772800"; d="scan'208";a="42808860" Received: from den-vteml-002.corp.ebay.com (HELO DEN-EXMHT-006.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 21 Mar 2014 12:45:32 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-006.corp.ebay.com ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.03.0174.001; Fri, 21 Mar 2014 13:45:32 -0600 From: "Hill, Brad" To: "websec@ietf.org" Thread-Topic: Last Call Announcement: UI Security at W3C WebAppSec WG Thread-Index: AQHPRT4eEFvYhe9AqkK0iew5+h9YxA== Date: Fri, 21 Mar 2014 19:45:32 +0000 Message-ID: <9895FFD1-4729-4B82-BE2D-9D5E505C0E61@paypal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.243] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned den2 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/-Xo6mRGYlOAup-JzUeMJEsdr-B0 X-Mailman-Approved-At: Mon, 24 Mar 2014 07:15:27 -0700 Subject: [websec] Last Call Announcement: UI Security at W3C WebAppSec WG 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, 21 Mar 2014 19:48:59 -0000 WebSec WG members, The WebAppSec WG at the W3C has recently announced a Last Call Working Dr= aft of "User Interface Directives for Content Security Policy". http://www.w3.org/TR/UISecurity/ This specification describes a set of policy statements and screen-shot c= omparison heuristics that web resource authors and user agents may use to p= rotect embedded or framed resources from "clickjacking" attacks. The "fram= e-options" directive, an evolution of the "X-Frame-Options" header, was bri= efly part of this spec, although now it has been moved to the mainstream CS= P 1.1 specification as "frame-ancestors". The WG would appreciate review and comments. The last call period ends 18= -June-2014, and comments can be submitted to: public-webappsec@w3.org Thank you, Brad Hill Co-chair, WebAppSec WG= From nobody Mon Mar 24 07:15:31 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 5D9E21A07D1 for ; Fri, 21 Mar 2014 12:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.501 X-Spam-Level: X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 zQpctCoHO62T for ; Fri, 21 Mar 2014 12:49:28 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 480C11A09FD for ; Fri, 21 Mar 2014 12:49:28 -0700 (PDT) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=fTXMS3lkgLfT7JHAw4BkvNeq24pcP8KZSaWmY6vVj2XLE+priOaAKLCn EyozieByu2e4HBsLO+BV1ksfJTWksZI5h/6KsjymXOAgACYofixqCxKTf wj+hq9z367YKUEzP2/udOvVL40So/kiQzv0MhP4U5wHNrgzbmnNhAlCfe w=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1395431359; x=1426967359; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=y5qvpPKFd4yNqpnEpbYlFNKZAIzOl4tqUQ4EIZEarLI=; b=rB9TL6YBGNE4jYqrD2iGBOxKFJiQZdeIQ6ILiWqbUdlRPoNabiT5lkBA HipbjiT66fvdOrnrLckpQmqWAkx4QrtQK241+q5Iop5i4zqpVOD1Gd0fw HALrRCbc/A3tMXbCT+pGtlSA2WM9rC0XlbD1l15JqHf2uDoHW271E6wdb A=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.97,705,1389772800"; d="scan'208";a="42525249" Received: from den-vteml-001.corp.ebay.com (HELO DEN-EXMHT-004.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 21 Mar 2014 12:49:18 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-004.corp.ebay.com ([fe80::a487:c570:9abc:bb59%14]) with mapi id 14.03.0174.001; Fri, 21 Mar 2014 13:49:18 -0600 From: "Hill, Brad" To: "websec@ietf.org" Thread-Topic: First Public Working Draft announcement: Subresource Integrity Thread-Index: AQHPRT6lMaYjGCZEFkKoVL8bnN/Dyw== Date: Fri, 21 Mar 2014 19:49:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.243] Content-Type: text/plain; charset="us-ascii" Content-ID: <44A4B20D3A9C644D844BD557C04F8D6B@corp.ebay.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned den1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/uP9GGb_cSqPOb8ZXuc2d9xmB3VM X-Mailman-Approved-At: Mon, 24 Mar 2014 07:15:27 -0700 Subject: [websec] First Public Working Draft announcement: Subresource Integrity 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, 21 Mar 2014 19:49:30 -0000 WebSec WG members, The WebAppSec WG at the W3C has recently announced a First Public Working= Draft for "Subresource Integrity". http://www.w3.org/TR/SRI/ This specification describes a method to add metadata about the hash iden= tity of resources (like script files and images) to HTML and specify policy= about how to verify and manage such resources before they are added to a w= eb resource's Document Object Model. The WG would appreciate review and comments. Comments can be submitted to= : public-webappsec@w3.org Thank you, Brad Hill Co-chair, WebAppSec WG= From nobody Mon Mar 24 09:15: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 3D2E01A0270 for ; Mon, 24 Mar 2014 09:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 BBfWa5NcmCmV for ; Mon, 24 Mar 2014 09:15:22 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1397D1A025D for ; Mon, 24 Mar 2014 09:14:55 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B7581F984; Mon, 24 Mar 2014 12:14:52 -0400 (EDT) Message-ID: <533059F3.20604@fifthhorseman.net> Date: Mon, 24 Mar 2014 12:14:43 -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: "Hill, Brad" , public-webappsec@w3.org, IETF WebSec WG References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oFuoiJhP8P0gPeo08OAEdNpWKobFs0QXf" Archived-At: http://mailarchive.ietf.org/arch/msg/websec/bSLFOFVdZhoNuSQmefzLHjhusIY Subject: [websec] [Integrity] [was: Re: First Public Working Draft announcement: Subresource Integrity] 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, 24 Mar 2014 16:15:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oFuoiJhP8P0gPeo08OAEdNpWKobFs0QXf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/21/2014 03:49 PM, Hill, Brad wrote: > WebSec WG members, >=20 > The WebAppSec WG at the W3C has recently announced a First Public Wor= king Draft for "Subresource Integrity". >=20 > http://www.w3.org/TR/SRI/ >=20 > This specification describes a method to add metadata about the hash = identity of resources (like script files and images) to HTML and specify = policy about how to verify and manage such resources before they are adde= d to a web resource's Document Object Model. thanks for this heads-up about this draft. I'm glad to see more work in this area. a few concerns spring to mind: handling cross-origin errors ----------------------------- section 6.3 mentions cross-origin data leakage -- i'm glad to see this discussed. However, it suggests that UAs SHOULD refuse to fire error events on cross-origin resources. This contradicts section 3.5.4, which claims that if the C-S-P of the origin page has a failure-mode of "block" or "fallback" (the only values available?) then the UA MUST report a violation. "report a violation" itself is linked to http://www.w3.org/TR/CSP11/#dfn-report-a-violation, which says the UA MUST fire a violation event. how is a UA expected to resolve these contradictions? Or am i missing some nuance that makes these non-contradictory? hash algorithm agility ---------------------- hash function agility raises questions about future interactions; I'm glad to see it mentioned in section 6.2, but i don't think the text there is sufficient. let's imagine a future where SHA-256 is deemed to be broken; how should a user-agent deal with elements with an SHA-256-based integrity attribute? should the UA treat the element as though it had no integrity tag at all (value=3D"indeterminate")? or should it treat the element as though it was compromised (value=3D"corrupt")? If we choose value=3D"indeterminate" and the origin's integrity-policy has "require-for-all", what should happen? being explicit about how we will handle algorithm deprecation in the future will make future transitions much less painful. regards, --dkg --oFuoiJhP8P0gPeo08OAEdNpWKobFs0QXf 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/ iQJ8BAEBCgBmBQJTMFnzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcEtYQAN7i4gUJNkIpUHcyYesiWgV1 q5nLSjFhYNQkP85cpE9m5bBknZqH7bKa8QXZOI2tKeMknX5GfRuRZK+uZU18A5il wMh/1dQj6h7H8ruWYsLzCmLdW6GKuwbAvFZr7D3Sw+WWfHzXaUvAAX9xBJYg4vDY 71MOQJ/3jd++MQ+d7LSQa82FDXUqo1kB7SNk3tZXCzL6UKbrzKgnI4vv7rbDxrUq hUtaf9FPhK5CgDVuuos6no3QCDD4SKVzHYTaBJdAoRzmVF8h0H8BvR8DXp4uiitq dLtoEgeKzqzPafWeDwO8BAv/Nxt3nEysCgP3i6y7q0DvI9rALBoVeG3e7ZbtPhMs Tno9vsfWnIvrWzKts06AczYPSp8rIERViETDXmUbQ8PPfHSm2IbVSDXHmJHzoXQ5 XzZzj0tacHjmGjmdSeAj3Y2h68WjOGpWHnkMvlPgH9ZX4I4JAlSXg3SfJ6kwSxvL +J/UOXYKB1omugd9HVEEiGvprRdE4zkzQ+v5mYLLR9+Q4ZWPYKlPXTT1DivO2BP1 r5D8ZNmbVS002VBO37e3xshd0arnFwlNOb8Iz+2rSkPKvrKh4PQzxahF2Wi9YLJA L0kW4HOn+lxW4q3TdqPwa5El8EOFA66GCU3zjAWeVWwrU/2oV3UzdkP0yuC11kU2 hppwvycdL4OTSrmtd7+p =SKHj -----END PGP SIGNATURE----- --oFuoiJhP8P0gPeo08OAEdNpWKobFs0QXf-- From nobody Mon Mar 24 09:44: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 79ECA1A026A for ; Mon, 24 Mar 2014 09:44:10 -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 Pn3Y6zrE9MBt for ; Mon, 24 Mar 2014 09:44:08 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E04991A0236 for ; Mon, 24 Mar 2014 09:44:07 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so4601061eei.5 for ; Mon, 24 Mar 2014 09:44:06 -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=e+EDOUI4OB8d5jeyngRvXDNUTjCBplcOoWOpjz4FsjE=; b=zJEjnTHp+A75DJv0v2jPm7/d23MN2t/chnZkmLdGto4JbhD5DHWTx5H522ZEyan3lH z1cuLL7gFnhbOby8Ecix2CPSoMT53O2bwpWoNkx6LVE1Y95Oo4/binwkrp3z2h9ih5Yo oS0useVvSwcVn4h2Mn7O3jWCx+c+voQvz7v8qopWlDWaDAYLcgO37mP1qOFxDUlwBOlz DSzVZL6igmoo3/CRheW+SUksEU7lf6hkTBHjm6xNGhvBltFCGuzU9FTHw4ywXEhWcjqx 4kpbfB3zhHKMP9DEyq17yJdYVK/6CyThbIMODNjGnzwnB+iylxigMzLIF4dBRC3M7msH VeqA== X-Received: by 10.14.246.1 with SMTP id p1mr958190eer.20.1395679446660; Mon, 24 Mar 2014 09:44:06 -0700 (PDT) Received: from [172.24.251.171] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id e42sm34229350eev.32.2014.03.24.09.44.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Mar 2014 09:44:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <9895FFD1-4729-4B82-BE2D-9D5E505C0E61@paypal.com> Date: Mon, 24 Mar 2014 18:44:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9895FFD1-4729-4B82-BE2D-9D5E505C0E61@paypal.com> To: "Hill, Brad" , public-webappsec@w3.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/30LKFvq35ScUtwZIT25KUxa4VzA Cc: "websec@ietf.org" Subject: Re: [websec] Last Call Announcement: UI Security at W3C WebAppSec WG 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, 24 Mar 2014 16:44:10 -0000 Hi, Brad Thanks for sending this, and I will review this more carefully soon, but = one thing that I noticed with a cursory look is that sections 4-7 were = probably meant to be sub-sections of section 3. Yoav On Mar 21, 2014, at 9:45 PM, Hill, Brad wrote: > WebSec WG members, >=20 > The WebAppSec WG at the W3C has recently announced a Last Call = Working Draft of "User Interface Directives for Content Security = Policy". >=20 > http://www.w3.org/TR/UISecurity/ >=20 > This specification describes a set of policy statements and = screen-shot comparison heuristics that web resource authors and user = agents may use to protect embedded or framed resources from = "clickjacking" attacks. The "frame-options" directive, an evolution of = the "X-Frame-Options" header, was briefly part of this spec, although = now it has been moved to the mainstream CSP 1.1 specification as = "frame-ancestors". >=20 > The WG would appreciate review and comments. The last call period = ends 18-June-2014, and comments can be submitted to: >=20 > public-webappsec@w3.org >=20 > Thank you, >=20 > Brad Hill > Co-chair, WebAppSec WG > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Wed Mar 26 09:53:44 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 44FB41A0386 for ; Wed, 26 Mar 2014 09:53:43 -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 UhckluLwbjNp for ; Wed, 26 Mar 2014 09:53:41 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 636761A037E for ; Wed, 26 Mar 2014 09:53:41 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B8E50F984 for ; Wed, 26 Mar 2014 12:53:38 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2BDDC1FEF6; Wed, 26 Mar 2014 12:53:39 -0400 (EDT) From: Daniel Kahn Gillmor To: websec@ietf.org 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> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Wed, 26 Mar 2014 12:53:38 -0400 Message-ID: <87ppl8kijx.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/websec/R2uDozfbdkAseXyDZ30nCkMJ_HQ Subject: [websec] forward compatibility on hash agility for key-pinning [was: Re: 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, 26 Mar 2014 16:53:43 -0000 --=-=-= Content-Type: text/plain On Sat 2014-02-22 13:49:10 -0500, Daniel Kahn Gillmor wrote: > 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. Why would you want to pin different keys with different > hash algorithms? > > 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. > > This should raise the attacker's bar to the strongest of the set of > hashes used, rather than the weakest. I haven't heard any followup on these questions about how we envision hash agility to work in practice, and they don't seem to be addressed in -11. To address (0), i recommend adding the following text after the third paragraph of section 2.4: When more than one cryptographic hash algorithm is offered for pinning, the same set of keys MUST be pinned with each algorithm. For example, if three keys are pinned with two different cryptographic hash algorithms, the header will contain six pins. To address (1), i recommend changing section 2.6 from: The UA will then check that the set of these SPKI Fingerprints intersects the set of SPKI Fingerprints in that Pinned Host's Pinning Metadata. If there is set intersection, the UA continues with the connection as normal. to: For each cryptographic hash algorithm offered by the server and supported by the UA, the UA will check that the set of SPKI Fingerprints over that algorithm intersects the set of SPKI Fingerprints over that algorithm in that Pinned Host's Pinning Metadata. If there is set intersection for all hash algorithms, the UA continues with the connection as normal. This raises one more question, which is: what should a UA do if it sees pins only of algorithms it doesn't recognize. In some imaginable future SHA256 is broken and deprecated, and servers only offer pins with some future hash algorithm. Code written today might still be running in that future, and we need to be clear what it should do if pins are present, but none of them are any supported algorithm. I think section 2.5 implies that in that case (these algorithms are considered an "unrecognized header directive"), the UA MUST NOT note the host as a pinned host, which i think is the right thing. I don't know if this needs extra clarification, but if it does, we might change: For forward compatibility, the UA MUST ignore any unrecognized Public-Key-Pins header directives, while still processing those directives it does recognize. to: For forward compatibility, the UA MUST ignore any unrecognized Public-Key-Pins header directives (including any pins made over unknown or unsupported hash algorithms), while still processing those directives it does recognize. Regards, --dkg --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTMwYSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpccWcQAIbIKyCWWPtoFmDPWCnLj4yr ICbfpr46czd1vaAte/RPOjZz1GsRE0dui76nED/NQNZeoMIoEmzpopAqaDtqkMAz W1+3kZprjyFh/q1u3EibOW6GZKc23Cf0APDvSrb0yLwUkZYNHvS9wrPc1vod9EpT DDti2rKnciOVSLMNMjrxzJdnJdb6a3UPzjTiD0L5P7Lauy0tGZBuC36ArfeKbuBt R4RjvklTOfERo8TI/i/O3rHiMKZUHrqn1W2tJprrBrtI5M1cxlorib7W9B4iC0TC dQZKDKxFNBah50L+cLR1E4x2xN2zel+x+sbcdvPZQF4fAfiP8Jrsuvs/hHBm1cW8 ulhrB0v7SbbQKMHKqONKlbh0xVn3UEkx9gVIwfigLyNMaKFmm5jW88x+d6ws2G6l MliPQNeC4lx2VOjzB1PokC5SQzJoeSDckKMYv+fnRTnRrnwte+MqB9EyYYVeQbcJ T4NiSknTcyq40MF1qq3K3pOFLpnktSF7p3poX9E4VIhTGeBmCa9eN+WodFeXpDfz YwwdYxkPQK62vzgvTCxK729SxfC93v/Zr3D5/NxDLCr9h+Ubs/cKLhWs5xXyZW/+ gb43BjEe7x4ZeaPUnFVkp8FgwYa8R3cN9lJrZaa7eUoz8w9hWNYmlB5QbM9QLCdA A++gCeKIshn1s34Oo7JW =AsTb -----END PGP SIGNATURE----- --=-=-=--