From nobody Thu Sep 4 10:27: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 348571A007D; Thu, 4 Sep 2014 10:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 kH3etLRVjr_5; Thu, 4 Sep 2014 10:27:41 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CD41A00B0; Thu, 4 Sep 2014 10:27:40 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7D67F1B8900; Thu, 4 Sep 2014 10:27:40 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3813653E074; Thu, 4 Sep 2014 10:27:40 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Sep 2014 10:27:40 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 4 Sep 2014 13:27:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140807135751.6422.30957.idtracker@ietfa.amsl.com> <3B6D8F39-468E-45ED-B9AD-9FCE8F2FC55A@nominum.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/websec/fOj838gTosSSWLSM-LC4NOeSDeg Cc: draft-ietf-websec-key-pinning@tools.ietf.org, "" , websec-chairs@tools.ietf.org, The IESG Subject: Re: [websec] Ted Lemon's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS) 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, 04 Sep 2014 17:27:42 -0000 Sorry for the long delay in responding to this--I needed to do some = reading to figure out if I agreed with what you said. The piece I was missing is that I didn't realize there was a process in = place for requiring certificate transparency for any cert. The plan to = require certificate transparency in Chrome for Extended Validation certs = sounds like a good start on making this happen, and does to some extent = address my concern, although ultimately CT has to be required by the = browser for _all_ certs before it really mitigates the key pinning = attack I described. But that's a path forward that I think is = plausible. So from my perspective, if the security considerations talks about the = hostile pinning attack and suggests mandatory CT as a future way of = addressing the problem, that would satisfy my DISCUSS. I don't = entirely agree with your observations about DNSSEC--I think I failed to = effectively communicate the solution I was proposing, and so your = response isn't actually addressing what I proposed. But I don't care = as long as the problem is addressed, and I do agree that once = certificate transparency is mandatory, that will in fact be a better = mitigation strategy than the DNSSEC-based strategy I suggested. From nobody Thu Sep 4 16:03:03 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 4FECD1A01CB for ; Thu, 4 Sep 2014 16:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vQXsnHu4i0dd for ; Thu, 4 Sep 2014 16:02:59 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B771A01CA for ; Thu, 4 Sep 2014 16:02:59 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id at20so12772577iec.33 for ; Thu, 04 Sep 2014 16:02:57 -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:content-type:content-transfer-encoding; bh=hPXtWhPkvlsMMGRTHVuoHI+LJkeHDH3IkpMI9z1Snwc=; b=EbFPqgcnaxCKrvOQHBLKYvZ3peyJOKYGb5mGXBCcU0f85Zp3fZ6zdyAj1u4wiDnxWT YA7riOu0iu6C+H/8wFPAdTWREGL9ogIxTUHkZ9PgvxJlRL9C7gBKmwi0+eyass4P/u5U NQVHrjf3RkKZX+/4N9QPqwQqLPz/2/GdI0C1DLzm56zO5OfYo19z6T6yE/8Khoru4DHW S8n15snvUS1OxWeFvBrtiV+riCv2MkW/OwRdp6KlbVognVCc/HBRorp5OjnLNS7tu3Af YtQKGtevagEanVIY18o8gmRJI+LEy+fzf0XjyTo3D44AZoPm0khICEGg5FNAnWAkTvlY fZ+g== X-Gm-Message-State: ALoCoQlnckCEAU+kl8xIZSJKWYS7rEQySKrO1JOkvxQqSy9hkjuGpo8NCHASpPi0FNYD6u+XCNy9 MIME-Version: 1.0 X-Received: by 10.42.100.6 with SMTP id y6mr9527894icn.28.1409871777599; Thu, 04 Sep 2014 16:02:57 -0700 (PDT) Received: by 10.107.133.67 with HTTP; Thu, 4 Sep 2014 16:02:57 -0700 (PDT) X-Originating-IP: [66.212.64.164] In-Reply-To: References: <35F981DA-46C4-44D7-8582-25BF8BF1B31A@gmail.com> Date: Thu, 4 Sep 2014 16:02:57 -0700 Message-ID: From: Trevor Perrin To: draft-ietf-websec-key-pinning , IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/8HJm9opsH6AYJhQxfq58JeuNzqM Subject: Re: [websec] draft-ietf-websec-key-pinning 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, 04 Sep 2014 23:03:02 -0000 I agree with Eric and Joe that the current definition of PKP-RO is not that useful and potentially surprising to deployers. Ryan argues that storing PKP-RO is dangerous because a TLS MITM who could set pins for a lot of clients for a lot of sites could flood a victim with reports. Couldn't the MITM also set PKP pins with report-uri, or set cached redirects or other cached resources to generate traffic toward a victim? Ryan argues PKP-RO is worse because it's "conceptually and practically silent to the user". But once the browser has sent junk traffic to a victim, I don't really see how seeing how displaying a pinning error makes things better. Trevor On Thu, Aug 28, 2014 at 9:13 AM, Eric Lawrence wr= ote: >> testing with PKP-RO may >> be fine before first deploying PKP, but it doesn=E2=80=99t help you wher= e it=E2=80=99s >> dangerous - >> when it=E2=80=99s time to change certificates. > > In addition to raising confidence before you first deploy, PKP-RO helps w= hen > you wish to retire a pinned SPKI. > > For instance: > > 0. Acme Corp has a secure website; they=E2=80=99re using PKP with > includeSubdomains. > 1. Acme Corp currently buys its certs from Verisign and uses PKP to pin > the Verisign intermediate SPKI. > 2. Next year, Acme Corp decides that they want to buy GoDaddy certs > instead. They update their PKP header to add the GoDaddy intermediate=E2= =80=99s SPKI > to the list. > 3. Because Acme Corp is a huge enterprise, they don=E2=80=99t know if s= ome > business unit (e.g. SpecialProjects.Acme.com) didn=E2=80=99t get the memo= about the > move to GoDaddy and may still be using a Verisign cert. So, in addition t= o > the updated PKP header, they ALSO send a PKP-RO header that specifies *on= ly* > the GoDaddy SPKI and watch for any reporting failures. > 4. After an appropriate period, Acme concludes that they are safe in > replacing the PKP set of SPKIs with the set they prototyped in PKP-RO. Th= ey > do so and remove the PKP-RO header. > > -Eric > > *An aside vis-=C3=A0-vis the plausibility of #3, a site not knowing about= its own > subdomains: I recently spoke to a site (=E2=80=9Cexample.com=E2=80=9D) th= at wasn=E2=80=99t using > includeSubdomains on their HSTS header. I asked why not, since all of the > company=E2=80=99s public websites were HTTPS. It turns out that they can= =E2=80=99t use > includeSubdomains because their private Intranet uses internally-mapped > domains subordinate to their public domain name suffix. So, while > =E2=80=9Chr.example.com=E2=80=9D isn=E2=80=99t publicly reachable, browse= rs don=E2=80=99t know or care, and > HSTS+includeSubdomains will fail any insecure connection for the employee= s > inside the company. > > A similar challenge will face any such companies when they try to use PKP > with includeSubdomains. > > > From: Yoav Nir > Sent: Thursday, August 28, 2014 9:59 AM > To: Eric Lawrence > Cc: Ryan Sleevi ; Tom Ritter ; draft-ietf-websec-key-pinning ; > websec@ietf.org > Subject: Re: [websec] draft-ietf-websec-key-pinning > > Hi Eric > > Part of the issue is that PKP (and PKP-RO) follow the lead of other heade= rs > such as CSP that also have report-only alternatives, but PKP is inherentl= y > different. > > CSP has directives that relate to the content delivered, so if CSP has a > directive that says the resource cannot be displayed behind a transparent > floating frame, the content will not be displayed. If it=E2=80=99s CSP-RO= instead of > CSP, the content is displayed, but a report is also sent. That makes sens= e, > and if you see that the CSP-RO header causes reports, you can adjust it. > Once you move to CSP, you=E2=80=99re fine as long as the content does not= change, > and even if it does change, you can test it first with a test server. > > For PKP it=E2=80=99s different. The thing that changes is the certificate= presented > to the client. You can=E2=80=99t test the new certificate on a side serve= r, at least > not in a way that will fill you with confidence. And because of the way > certificates are used, there is no such thing as a static structure to th= e > site. You have to change the certificate (and usually the key) every year= , > so testing with PKP-RO may be fine before first deploying PKP, but it > doesn=E2=80=99t help you where it=E2=80=99s dangerous - when it=E2=80=99s= time to change > certificates. > > This leads some people around here to conclude that PKP-RO is not useful. > > Yoav > > > On Aug 28, 2014, at 5:26 PM, Eric Lawrence wrot= e: > > I=E2=80=99ll take one last tilt at this, because I think this spec is qui= te > important and folks aren=E2=80=99t actually very far apart on this. > > To start, I want to reiterate that Draft #20 was the first time I got > involved in PKP, so my perspective comes from that draft and not any othe= r > conversations, tribal knowledge, meetings, etc, that others in the group = may > have been a part of. > > Here=E2=80=99s how I *thought* Draft #20 specified things to work: > > 1> PKP and PKP-RO are equivalent in every way except that PKP mismatch > triggers a Report *and* fails the connection, while PKP-RO mismatch only > triggers a Report. That=E2=80=99s why PKP-RO is named =E2=80=9CPublic Key= Pins Report Only=E2=80=9D > and not =E2=80=9CSorta Like Public Key Pins But Does Not Break Connection= s And Does > Not Persist (SLPKPBDNBCADNP)=E2=80=9D > > 2> Site administrators should use PKP-RO to prototype a policy to be la= ter > deployed PKP. They use PKP-RO first to generate confidence that they will > not be self-inflicting any broad denial-of-service when enabling PKP. > > 3> When PKP and PKP-RO headers are initially encountered (pins not > previously stored), a failure to match the specified policy triggers a > Report. The mismatched policy is NOT stored, which blocks the DOS bomb > attack Ryan mentions below. > > 4> PKP and PKP-RO only exist as different headers because it allows a s= ite > to have one policy in force and also prototype proposed policy changes. > > This design made perfect sense to me, and my feedback on the draft was > primarily intended to clarify the language around this design. > > Instead, it appears that PKP-RO works dramatically differently than PKP, = in > ways that I believe are entirely non-obvious to implementers who only rea= d > the draft. While I believe it would be possible to editorially change the > language to make PKP-RO=E2=80=99s different behavior, to me, that approac= h only > seems to be codifying a more confusing, less useful design, and would > require more work on the part of the authors. > > I don=E2=80=99t believe there are any privacy or security implications in= allowing > PKP-RO to behave like PKP except that it=E2=80=99s =E2=80=9CReport Only.= =E2=80=9D Any privacy or > security implications in PKP-RO are shared by PKP. > > -Eric Lawrence > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From nobody Thu Sep 4 16:53:52 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 1A36E1A02BA for ; Thu, 4 Sep 2014 16:53:51 -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 861QIVDpKdhD for ; Thu, 4 Sep 2014 16:53:49 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947E21A02AC for ; Thu, 4 Sep 2014 16:53:49 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h15so2127179igd.8 for ; Thu, 04 Sep 2014 16:53:48 -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=vNF+2RTVFuurnZL3h2zhu6UMW0oie1pkwDZxF2mlc1o=; b=m8EQ4USMswELkeBOFCNBuJx4yaqjDWAIUEja0d9sFX5uTH34TOCLpx2+UQoTsh3Pnc EaDDlw5ry0+tlASLoxp6n/3vUkTjd/RSNpktADqD36Fn0lTl7Cwpd3Dyruhc6DyKtCuE mK7fWL7NfgF14Jkvx0nY34MRlwOoByNcoNQo3Xg4b4SuOsZR33qZULlgZWzM9taHSDxh 4f9HwroqGzMn+ycxpgKnc36eyPkvh3T1pEc7fmgAQJpK5/dvsdxs1qjDU1aIH0029kV5 ajzLAJrteLqXYY/T8zEDNacKSkGZsVmASmJ0ombEkYBNkWg2SFd+aAt5cH7L5xFqba+h j1cg== X-Gm-Message-State: ALoCoQnv1vKTPDDhb0oI+7YZhPFulprUPd+l80JnoJhDVKEtfz77PQIGX7GfNAjod2OK8HQ9fP9A MIME-Version: 1.0 X-Received: by 10.43.156.20 with SMTP id lk20mr9863599icc.17.1409874828817; Thu, 04 Sep 2014 16:53:48 -0700 (PDT) Received: by 10.107.133.67 with HTTP; Thu, 4 Sep 2014 16:53:48 -0700 (PDT) X-Originating-IP: [66.212.64.164] In-Reply-To: References: <35F981DA-46C4-44D7-8582-25BF8BF1B31A@gmail.com> Date: Thu, 4 Sep 2014 16:53:48 -0700 Message-ID: From: Trevor Perrin To: Ryan Sleevi Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/Kb8OckQb1BEouovOkWI6Iw5KY_s Cc: draft-ietf-websec-key-pinning , IETF WebSec WG Subject: Re: [websec] draft-ietf-websec-key-pinning 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, 04 Sep 2014 23:53:51 -0000 On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi wrote: > > > > On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin wrote: >> >> I agree with Eric and Joe that the current definition of PKP-RO is not >> that useful and potentially surprising to deployers. >> >> Ryan argues that storing PKP-RO is dangerous because a TLS MITM who >> could set pins for a lot of clients for a lot of sites could flood a >> victim with reports. >> >> >> Couldn't the MITM also set PKP pins with report-uri, or set cached >> redirects or other cached resources to generate traffic toward a >> victim? > > > Yes, and that's a user visible effect, rather than transparent. Hmm, there's nothing clever that can be done with cached javascript or html to also generate silent traffic toward a victim? > It also > requires that a connection be validated first, whereas the very definition > of PKP-RO is that you send it when a connection is not validated. I'd expect stored PKP-RO to follow the same rules as PKP and be stored only if it meets the bullet points in 2.5 (error-free TLS connection, backup pins, etc.). It would make sense for any report-uri header (PKP or PKP-RO) that fails the 2.5 checks, or has some other invalid syntax (eg bad base64), to *also* generate a different sort of report and not be stored. Would it be reasonable to add a reporting message for 2.5 failure or syntax failure? Otherwise, when asserting a report-uri pin you can't distinguish pin-not-stored errors from pin-stored-and-validation-successful. >> Ryan argues PKP-RO is worse because it's "conceptually and practically >> silent to the user". But once the browser has sent junk traffic to a >> victim, I don't really see how seeing how displaying a pinning error >> makes things better. > > > First, the attacker can only mount the hostile attack after having first > established a good connection. Debateable per above. > PKP-RO allows an attacker to perpetually > mount a hostile attack. > Second, the presence of a pinning error is an inherently rate-limiting > factor to the user experience. You're not going to be able to trigger 100 > reports if you're causing the user 100 error pages. Rate-limiting is already proposed: """ 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 per distinct set of declared Pins. """ Wouldn't that take care of it? > Third, it seems like you're arguing for removing report-uri altogether, > given the privacy and DoS risks identified. That is, the more that you > establish RO is similar to PKP in level of what an attacker can do, the more > it argues for removing report-URI entirely. Dunno. I'm still trying to understand these risks, whether they're really different for PKP-RO vs PKP, and for HPKP versus other web technologies. Trevor From nobody Thu Sep 4 17:23:36 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 DF3161A02E6 for ; Thu, 4 Sep 2014 17:23:33 -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 2fIkf9VztwFx for ; Thu, 4 Sep 2014 17:23:32 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B07C1A02E0 for ; Thu, 4 Sep 2014 17:23:32 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rl12so12830479iec.29 for ; Thu, 04 Sep 2014 17:23:32 -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=4jvxggc8ZWp+MSy2nV8oRTf+vAKR0Ss/+779je3k0C4=; b=ZgYX/LwZ2a6jMnGgMsWGUuBAHF4Cbzd1x31mUS48VRn2Qqpc2p4WEIG36YgaEUGFSV e9AFvfaYT+Wv+Zfg9vkRVsgbFz+dDKR3ZXUiOyDi2sHma4J0i+7CR9PbwNk+G0hQyxen Sp4oqu9fi/0BuDp1YRtS9E8qJmi/vmXfL7UouZMkKTMQXCG3kb73VElLg4xfk0yph2cg U7KcEzPnzcfldvy+Cf5V9M1DvuWPmeBGR4BI1nHpOWUbl0FFBlQtyqBZ6b4MAOyLqgQ5 TRD8BXV7pZGQCIcvVoTDI1/bSjOHwvJI8XFT4inRV2Iz6RgbvS2BWJvJKE1i9RNGNcwO RMCw== X-Gm-Message-State: ALoCoQmEE6LzSiVtvhcBPEjORnIvDNG0ohD0VPvxljdMu3ibQtdRi6HuOKFTP5RuZ6TEAgI32tse MIME-Version: 1.0 X-Received: by 10.42.227.10 with SMTP id iy10mr10185745icb.3.1409876611903; Thu, 04 Sep 2014 17:23:31 -0700 (PDT) Received: by 10.107.133.67 with HTTP; Thu, 4 Sep 2014 17:23:31 -0700 (PDT) X-Originating-IP: [66.212.64.164] In-Reply-To: References: <35F981DA-46C4-44D7-8582-25BF8BF1B31A@gmail.com> Date: Thu, 4 Sep 2014 17:23:31 -0700 Message-ID: From: Trevor Perrin To: Ryan Sleevi Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/-VjGBChL8-ZICjAYiJ4jfYQITGU Cc: draft-ietf-websec-key-pinning , IETF WebSec WG Subject: Re: [websec] draft-ietf-websec-key-pinning 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, 05 Sep 2014 00:23:34 -0000 On Thu, Sep 4, 2014 at 5:06 PM, Ryan Sleevi wrote: > I wish you would have raised this during WGLC, which would have benefited > from the review and discussion now being paid. I did raise this in response to the February Last Call, and multiple times later. There was some very light discussion which favored storing PKP-RO, the draft was edited in the opposite direction, and it was sent on while we were still discussing (with no additional WGLC). But I agree that we're now having the discussion this issue deserves (and which we never had earlier). > That is, my understanding is that this is a bit like discovering a possible > issue after you've shipped your gold master to 100K stores. I don't see how we've shipped anything to anyone, so I don't see why this is so painful to discuss. But I'm just a random security nerd, the opinions of browsers and websites are what matter here, so I'll defer to those. Trevor From nobody Fri Sep 5 02:20: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 ABD4F1A0267 for ; Thu, 4 Sep 2014 16:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 Gl_tme2pjr6v for ; Thu, 4 Sep 2014 16:09:07 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514A71A023E for ; Thu, 4 Sep 2014 16:09:07 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hq11so11568964vcb.14 for ; Thu, 04 Sep 2014 16:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H5ofHEGipBhPp9r/7KxUdoQSqeQNXuOtXFsmvwvtFRk=; b=N0o1riEXqHIDfQkflenAznM449H55sz78uxYR16gHiBoxMyBhQD4Ta4Wy3o9h2tkt4 qUFstwYFknmgrTkOj/RfG75iyymeSuAuKeBr6X8Mycb71AT6RAtYe+6K/A4fhg9ozxiW Y+fow5Q7ddbYRMbBWqNwTMPiBtjr5AJo55S5PwCu3SxmuzdNUAznkDg2Rz+EPa9J6Svc kECspMmCi4NJuZFEcNnjHT3hH71OlbWRUXaowo5cymOiOsi368PzdnyeubzEtMQIJQo9 DJC1NEbi1vVcOuF67ledN5ydgCWT9lbnBlaWLdm/cmAXAwCrtU9j2G/+TRtNwzIQ5t+e PmwQ== 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=H5ofHEGipBhPp9r/7KxUdoQSqeQNXuOtXFsmvwvtFRk=; b=Cb5JUXjtReaDhqIIoyP5dft99sLEnBy74fcXAI9KNeBVGMZ7WuneA7WrOC0Av0f476 AWicnzzNSC6orpL2uGHqRQFzlITcUNNOe7yWYg4a84WeQK+yweE1NbhVmb5/MQvPIGx1 Ii+dvYma8fPZTl0QTPfWR1GI8RX+HByE+Lhy/u/5dj7Thkl/dvJKV4TePrhyfo0H0Vi7 l5VXbJuwW3CsjgV4UIGxP6w9qQ+vqh1HlZh3YPUZcjVMN5jMCzDxVSKxYTS1UEaNaBaa O2pmtKHpbib7UEo3OUrxgYmFCrighkXmodeM+/4VD2BPQIu05JsrOqxAHhF5vSioXBxl e3kg== X-Gm-Message-State: ALoCoQmLuoM9Jjmi2v8L79UP/kCcwn4n9xO5wcmFKeK6zadig5/hiVVAHwW55rCf5QP8pry+RWkx MIME-Version: 1.0 X-Received: by 10.53.5.163 with SMTP id cn3mr5996229vdd.3.1409872146104; Thu, 04 Sep 2014 16:09:06 -0700 (PDT) Received: by 10.52.146.4 with HTTP; Thu, 4 Sep 2014 16:09:05 -0700 (PDT) In-Reply-To: References: <35F981DA-46C4-44D7-8582-25BF8BF1B31A@gmail.com> Date: Thu, 4 Sep 2014 16:09:05 -0700 Message-ID: From: Ryan Sleevi To: Trevor Perrin Content-Type: multipart/alternative; boundary=001a1133ce6e72a47f05024570b5 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/0kAclevLK8uy7X2UXcbuhHgzqaU X-Mailman-Approved-At: Fri, 05 Sep 2014 02:20:28 -0700 Cc: draft-ietf-websec-key-pinning , IETF WebSec WG Subject: Re: [websec] draft-ietf-websec-key-pinning 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, 04 Sep 2014 23:09:10 -0000 --001a1133ce6e72a47f05024570b5 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin wrote: > I agree with Eric and Joe that the current definition of PKP-RO is not > that useful and potentially surprising to deployers. > > Ryan argues that storing PKP-RO is dangerous because a TLS MITM who > could set pins for a lot of clients for a lot of sites could flood a > victim with reports. > Couldn't the MITM also set PKP pins with report-uri, or set cached > redirects or other cached resources to generate traffic toward a > victim? > Yes, and that's a user visible effect, rather than transparent. It also requires that a connection be validated first, whereas the very definition of PKP-RO is that you send it when a connection is not validated. > > Ryan argues PKP-RO is worse because it's "conceptually and practically > silent to the user". But once the browser has sent junk traffic to a > victim, I don't really see how seeing how displaying a pinning error > makes things better. > First, the attacker can only mount the hostile attack after having first established a good connection. PKP-RO allows an attacker to perpetually mount a hostile attack. Second, the presence of a pinning error is an inherently rate-limiting factor to the user experience. You're not going to be able to trigger 100 reports if you're causing the user 100 error pages. Third, it seems like you're arguing for removing report-uri altogether, given the privacy and DoS risks identified. That is, the more that you establish RO is similar to PKP in level of what an attacker can do, the more it argues for removing report-URI entirely. --001a1133ce6e72a47f05024570b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <= ;trevp@trevp.net&g= t; wrote:
I agree with Eric and Jo= e that the current definition of PKP-RO is not
that useful and potentially surprising to deployers.

Ryan argues that storing PKP-RO is dangerous because a TLS MITM who
could set pins for a lot of clients for a lot of sites could flood a
victim with reports.=C2=A0

Couldn't the MITM also set PKP pins with report-uri, or set cached
redirects or other cached resources to generate traffic toward a
victim?

Yes, and that's a user visi= ble effect, rather than transparent. It also requires that a connection be = validated first, whereas the very definition of PKP-RO is that you send it = when a connection is not validated.
=C2=A0

Ryan argues PKP-RO is worse because it's "conceptually and practic= ally
silent to the user".=C2=A0 But once the browser has sent junk traffic = to a
victim, I don't really see how seeing how displaying a pinning error makes things better.

First, the attacke= r can only mount the hostile attack after having first established a good c= onnection. PKP-RO allows an attacker to perpetually mount a hostile attack.=
Second, the presence of a pinning error is an inherently rate-li= miting factor to the user experience. You're not going to be able to tr= igger 100 reports if you're causing the user 100 error pages.
Third, it seems like you're arguing for removing report-uri altogether= , given the privacy and DoS risks identified. That is, the more that =C2=A0= you establish RO is similar to PKP in level of what an attacker can do, the= more it argues for removing report-URI entirely.=C2=A0
--001a1133ce6e72a47f05024570b5-- From nobody Fri Sep 5 02:20:36 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 2CD601A02E9 for ; Thu, 4 Sep 2014 17:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 tRSv1qqQW4sX for ; Thu, 4 Sep 2014 17:06:11 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911911A02E6 for ; Thu, 4 Sep 2014 17:06:11 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id le20so196226vcb.17 for ; Thu, 04 Sep 2014 17:06:10 -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=8MLeMgEJv6Nr9p3ZSrUzN1adTJEgU1hhcsteTUUvFvE=; b=n0JW2a+X2uZNVCYQtcTVD+6w2RbFBbiOmPvDT29FWWNM3nuwhY3GJgYQcyKtPcwjYx k+NndxruW0tTcqnDeEIFTKl5VVJA1UtlEX+qIZpbrQhmDFYOANNbdjCFgNwFLUSI7XAI Q+6MEntX8JQjrfJUqr+xiy1O+PsV6Sy38ri0uB/Wi9z9yI+qPkrh0G+RH+0Jq8IrXqic qW/kVYqSMxQLvdS4nAkl35uzvtZWehSLiH2BPWdWx/2kAb7sJqqu0h0L9EIdkRFQZq+a TKJkfDlDqS9Vv6wdbd3AU5wQDCx8sMM+qvE0cB8jbNie0v5r8hiLiAtzTOPduUZyi9Fs Imxw== 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=8MLeMgEJv6Nr9p3ZSrUzN1adTJEgU1hhcsteTUUvFvE=; b=mYhqNKJTF6+NsqgScmjdLycdN4TgkXJQfV9zjm4GAcQMA1nKX9HKvuNwdkAqpOyl0V YJWb2edzU9i7GSqsEQdfHfdakQEIdC7UcoLfk6j3GapSINV5JrijwKd4114s6efRDBzg r3t0Dw915JmnwhaCb/c1sX2QIZM2m333kqKxFc6aa3qYApiBdfL3qW68BQuwg1qgvrhP 1ZzEM81f4XhtTzt5Dm3vlA8pRKYQXH2IlTesmM+UprJjSmyAYx0OvF7Y6f8NXMNn9JJy pPfs2BpSL7yFWapApLyPtw+WB978i9iZA+oPdsMbEY7EcmkCZ7dQwU4IUz60fjCE3K7y L3zw== X-Gm-Message-State: ALoCoQnDekQ4CxHLHC6l0tK0zDrUA+wLq08a+Usu88CHAZ8McBBe6rGESso+xPZ61hJ1EbuJd6wf MIME-Version: 1.0 X-Received: by 10.52.27.16 with SMTP id p16mr6257502vdg.14.1409875570444; Thu, 04 Sep 2014 17:06:10 -0700 (PDT) Received: by 10.52.146.4 with HTTP; Thu, 4 Sep 2014 17:06:10 -0700 (PDT) In-Reply-To: References: <35F981DA-46C4-44D7-8582-25BF8BF1B31A@gmail.com> Date: Thu, 4 Sep 2014 17:06:10 -0700 Message-ID: From: Ryan Sleevi To: Trevor Perrin Content-Type: multipart/alternative; boundary=20cf307d05808de8df0502463c3f Archived-At: http://mailarchive.ietf.org/arch/msg/websec/iPFq7j6BkRmJy16g_WV5NRjvN00 X-Mailman-Approved-At: Fri, 05 Sep 2014 02:20:29 -0700 Cc: draft-ietf-websec-key-pinning , IETF WebSec WG Subject: Re: [websec] draft-ietf-websec-key-pinning 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, 05 Sep 2014 00:06:14 -0000 --20cf307d05808de8df0502463c3f Content-Type: text/plain; charset=UTF-8 I wish you would have raised this during WGLC, which would have benefited from the review and discussion now being paid. I guess echoing Yoav's earlier remarks that: "At this stage, we can make editorial changes, but we cannot make > significant changes on our own. We can withdraw the request to publish, and > take it back to the working group, but I think that would be inadvisable. > I think we should proceed, making only editorial changes, and changes > resulting from discussion with IESG members." that it's probably not worth discussing much further. If the WG feels strongly about this, we can certainly withdraw from publication. If so, I think the Chris' and myself would need to recuse ourselves from being able to edit this document any further, so the WG would need to find a new set of editors to proceed with this draft. Other than that, either we accept these as ERRATA, or we accept them as being what they are. That is, my understanding is that this is a bit like discovering a possible issue after you've shipped your gold master to 100K stores. Yes, it's awful, but either it's a recall or you fix it in post. My gut is that it's for post. However, based on Yoav's remarks, I'm not sure that there's very much we can do editorially to address these. It appears my proposed suggestion does not address your concerns, so I will not be added it to the next (and hopefully final) draft. On Thu, Sep 4, 2014 at 4:53 PM, Trevor Perrin wrote: > On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi wrote: > > > > > > > > On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin wrote: > >> > >> I agree with Eric and Joe that the current definition of PKP-RO is not > >> that useful and potentially surprising to deployers. > >> > >> Ryan argues that storing PKP-RO is dangerous because a TLS MITM who > >> could set pins for a lot of clients for a lot of sites could flood a > >> victim with reports. > >> > >> > >> Couldn't the MITM also set PKP pins with report-uri, or set cached > >> redirects or other cached resources to generate traffic toward a > >> victim? > > > > > > Yes, and that's a user visible effect, rather than transparent. > > Hmm, there's nothing clever that can be done with cached javascript or > html to also generate silent traffic toward a victim? > > > > It also > > requires that a connection be validated first, whereas the very > definition > > of PKP-RO is that you send it when a connection is not validated. > > I'd expect stored PKP-RO to follow the same rules as PKP and be stored > only if it meets the bullet points in 2.5 (error-free TLS connection, > backup pins, etc.). > > It would make sense for any report-uri header (PKP or PKP-RO) that > fails the 2.5 checks, or has some other invalid syntax (eg bad > base64), to *also* generate a different sort of report and not be > stored. > > Would it be reasonable to add a reporting message for 2.5 failure or > syntax failure? Otherwise, when asserting a report-uri pin you can't > distinguish pin-not-stored errors from > pin-stored-and-validation-successful. > > > >> Ryan argues PKP-RO is worse because it's "conceptually and practically > >> silent to the user". But once the browser has sent junk traffic to a > >> victim, I don't really see how seeing how displaying a pinning error > >> makes things better. > > > > > > First, the attacker can only mount the hostile attack after having first > > established a good connection. > > Debateable per above. > > > > PKP-RO allows an attacker to perpetually > > mount a hostile attack. > > Second, the presence of a pinning error is an inherently rate-limiting > > factor to the user experience. You're not going to be able to trigger 100 > > reports if you're causing the user 100 error pages. > > Rate-limiting is already proposed: > """ > 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 per distinct set of declared Pins. > """ > > Wouldn't that take care of it? > > > > Third, it seems like you're arguing for removing report-uri altogether, > > given the privacy and DoS risks identified. That is, the more that you > > establish RO is similar to PKP in level of what an attacker can do, the > more > > it argues for removing report-URI entirely. > > Dunno. I'm still trying to understand these risks, whether they're > really different for PKP-RO vs PKP, and for HPKP versus other web > technologies. > > Trevor > --20cf307d05808de8df0502463c3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wish you would have raised this during WGLC, which would= have benefited from the review and discussion now being paid.

I guess echoing Yoav's earlier remarks that:

"At this stage, we can make editorial changes, but we cannot make s= ignificant changes on our own. We can withdraw the request to publish, and = take it back to the working group, but I think that would be inadvisable.
I think we sho= uld proceed, making only editorial changes, and changes resulting from disc= ussion with IESG members."

that it= 's probably not worth discussing much further.

If the WG feels strongly about this, we can certainly withdraw from public= ation. If so, I think the Chris' and myself would need to recuse oursel= ves from being able to edit this document any further, so the WG would need= to find a new set of editors to proceed with this draft.

Other than that, either we accept these as ERRATA, or we accept the= m as being what they are.

That is, my understandin= g is that this is a bit like discovering a possible issue after you've = shipped your gold master to 100K stores. Yes, it's awful, but either it= 's a recall or you fix it in post. My gut is that it's for post. Ho= wever, based on Yoav's remarks, I'm not sure that there's very = much we can do editorially to address these. It appears my proposed suggest= ion does not address your concerns, so I will not be added it to the next (= and hopefully final) draft.


=

On Thu, Sep 4, 20= 14 at 4:53 PM, Trevor Perrin <trevp@trevp.net> wrote:
On Thu, Sep 4, 2014 at 4:09 PM, = Ryan Sleevi <sleevi@google.com&= gt; wrote:
>
>
>
> On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <trevp@trevp.net> wrote:
>>
>> I agree with Eric and Joe that the current definition of PKP-RO is= not
>> that useful and potentially surprising to deployers.
>>
>> Ryan argues that storing PKP-RO is dangerous because a TLS MITM wh= o
>> could set pins for a lot of clients for a lot of sites could flood= a
>> victim with reports.
>>
>>
>> Couldn't the MITM also set PKP pins with report-uri, or set ca= ched
>> redirects or other cached resources to generate traffic toward a >> victim?
>
>
> Yes, and that's a user visible effect, rather than transparent.
Hmm, there's nothing clever that can be done with cached javascr= ipt or
html to also generate silent traffic toward a victim?


> It also
> requires that a connection be validated first, whereas the very defini= tion
> of PKP-RO is that you send it when a connection is not validated.

I'd expect stored PKP-RO to follow the same rules as PKP and be = stored
only if it meets the bullet points in 2.5 (error-free TLS connection,
backup pins, etc.).

It would make sense for any report-uri header (PKP or PKP-RO) that
fails the 2.5 checks, or has some other invalid syntax (eg bad
base64), to *also* generate a different sort of report and not be
stored.

Would it be reasonable to add a reporting message for 2.5 failure or
syntax failure?=C2=A0 Otherwise, when asserting a report-uri pin you can= 9;t
distinguish pin-not-stored errors from
pin-stored-and-validation-successful.


>> Ryan argues PKP-RO is worse because it's "conceptually an= d practically
>> silent to the user".=C2=A0 But once the browser has sent junk= traffic to a
>> victim, I don't really see how seeing how displaying a pinning= error
>> makes things better.
>
>
> First, the attacker can only mount the hostile attack after having fir= st
> established a good connection.

Debateable per above.


> PKP-RO allows an attacker to perpetually
> mount a hostile attack.
> Second, the presence of a pinning error is an inherently rate-limiting=
> factor to the user experience. You're not going to be able to trig= ger 100
> reports if you're causing the user 100 error pages.

Rate-limiting is already proposed:
"""
UAs SHOULD limit the rate at which they send reports.=C2=A0 For example, =C2=A0 =C2=A0it is unnecessary to send the same report to the same report-u= ri more
=C2=A0 =C2=A0than once per distinct set of declared Pins.
"""

Wouldn't that take care of it?


> Third, it seems like you're arguing for removing report-uri altoge= ther,
> given the privacy and DoS risks identified. That is, the more that=C2= =A0 you
> establish RO is similar to PKP in level of what an attacker can do, th= e more
> it argues for removing report-URI entirely.

Dunno.=C2=A0 I'm still trying to understand these risks, whether= they're
really different for PKP-RO vs PKP, and for HPKP versus other web
technologies.

Trevor

--20cf307d05808de8df0502463c3f-- From nobody Fri Sep 5 05:08: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 CAD3F1A06DC for ; Fri, 5 Sep 2014 05:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.322 X-Spam-Level: X-Spam-Status: No, score=-97.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 eqdulwasKvl5 for ; Fri, 5 Sep 2014 05:08:29 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB411A06D9 for ; Fri, 5 Sep 2014 05:08:28 -0700 (PDT) Received: from [192.168.0.13] (5ec3983d.skybroadband.com [94.195.152.61]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id BA1B362D14; Fri, 5 Sep 2014 14:08:23 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=w+xuFdrh7uwfrhxA6KLM0FIW93Rl8BeIO1cWe2+rHq44GRr7eDq7GVVLCZKxDeeuX8epkE2IL07Fae1HHdiuR/qgMtIThDmjMf22/ss5di/iO1CpSz3aZbMFdZ+fNlYgBHvVXBiVHMPz8jkr0lFW6h5qWoRUh1ZMtICKXHmexmc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Message-ID: <5409A7B7.5040206@gondrom.org> Date: Fri, 05 Sep 2014 13:08:23 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: sleevi@google.com, trevp@trevp.net References: <35F981DA-46C4-44D7-8582-25BF8BF1B31A@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010203050207060607000906" Archived-At: http://mailarchive.ietf.org/arch/msg/websec/YkrRqYmaZGuTZqasPAKSXWi_7QE Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org Subject: Re: [websec] draft-ietf-websec-key-pinning 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, 05 Sep 2014 12:08:32 -0000 This is a multi-part message in MIME format. --------------010203050207060607000906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Ryan, just to balance this: yes, we are in IESG review and we should focus on giving the draft the last touches. With one remark: even in IESG review, if we find a major security problem, we need to go back to WGLC. But so far I am not convinced that this problem is that big in this case here and had the perception that we had a WG discussion about this before with rough WG consensus (albeit quite rough) as is. (And I admit, the long latency times in the WG discussions between emails and draft iterations did not make things easier.) But if anyone thinks this problem will be major, please say so now and we could have a quick (5-day) discussion window in the WG whether this needs to go back to the WG or whether the chairs did misjudge WG consensus. Just my personal view, but with hat of WG chair on. Best wishes, Tobias On 05/09/14 01:06, Ryan Sleevi wrote: > I wish you would have raised this during WGLC, which would have > benefited from the review and discussion now being paid. > > I guess echoing Yoav's earlier remarks that: > > "At this stage, we can make editorial changes, but we cannot make > significant changes on our own. We can withdraw the request to > publish, and take it back to the working group, but I think that > would be inadvisable. > I think we should proceed, making only editorial changes, and > changes resulting from discussion with IESG members." > > > that it's probably not worth discussing much further. > > If the WG feels strongly about this, we can certainly withdraw from > publication. If so, I think the Chris' and myself would need to recuse > ourselves from being able to edit this document any further, so the WG > would need to find a new set of editors to proceed with this draft. > > Other than that, either we accept these as ERRATA, or we accept them > as being what they are. > > That is, my understanding is that this is a bit like discovering a > possible issue after you've shipped your gold master to 100K stores. > Yes, it's awful, but either it's a recall or you fix it in post. My > gut is that it's for post. However, based on Yoav's remarks, I'm not > sure that there's very much we can do editorially to address these. It > appears my proposed suggestion does not address your concerns, so I > will not be added it to the next (and hopefully final) draft. > > > > On Thu, Sep 4, 2014 at 4:53 PM, Trevor Perrin > wrote: > > On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi > wrote: > > > > > > > > On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin > wrote: > >> > >> I agree with Eric and Joe that the current definition of PKP-RO > is not > >> that useful and potentially surprising to deployers. > >> > >> Ryan argues that storing PKP-RO is dangerous because a TLS MITM who > >> could set pins for a lot of clients for a lot of sites could > flood a > >> victim with reports. > >> > >> > >> Couldn't the MITM also set PKP pins with report-uri, or set cached > >> redirects or other cached resources to generate traffic toward a > >> victim? > > > > > > Yes, and that's a user visible effect, rather than transparent. > > Hmm, there's nothing clever that can be done with cached javascript or > html to also generate silent traffic toward a victim? > > > > It also > > requires that a connection be validated first, whereas the very > definition > > of PKP-RO is that you send it when a connection is not validated. > > I'd expect stored PKP-RO to follow the same rules as PKP and be stored > only if it meets the bullet points in 2.5 (error-free TLS connection, > backup pins, etc.). > > It would make sense for any report-uri header (PKP or PKP-RO) that > fails the 2.5 checks, or has some other invalid syntax (eg bad > base64), to *also* generate a different sort of report and not be > stored. > > Would it be reasonable to add a reporting message for 2.5 failure or > syntax failure? Otherwise, when asserting a report-uri pin you can't > distinguish pin-not-stored errors from > pin-stored-and-validation-successful. > > > >> Ryan argues PKP-RO is worse because it's "conceptually and > practically > >> silent to the user". But once the browser has sent junk > traffic to a > >> victim, I don't really see how seeing how displaying a pinning > error > >> makes things better. > > > > > > First, the attacker can only mount the hostile attack after > having first > > established a good connection. > > Debateable per above. > > > > PKP-RO allows an attacker to perpetually > > mount a hostile attack. > > Second, the presence of a pinning error is an inherently > rate-limiting > > factor to the user experience. You're not going to be able to > trigger 100 > > reports if you're causing the user 100 error pages. > > Rate-limiting is already proposed: > """ > 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 per distinct set of declared Pins. > """ > > Wouldn't that take care of it? > > > > Third, it seems like you're arguing for removing report-uri > altogether, > > given the privacy and DoS risks identified. That is, the more > that you > > establish RO is similar to PKP in level of what an attacker can > do, the more > > it argues for removing report-URI entirely. > > Dunno. I'm still trying to understand these risks, whether they're > really different for PKP-RO vs PKP, and for HPKP versus other web > technologies. > > Trevor > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------010203050207060607000906 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Ryan,

just to balance this:
yes, we are in IESG review and we should focus on giving the draft the last touches.

With one remark: even in IESG review, if we find a major security problem, we need to go back to WGLC.
But so far I am not convinced that this problem is that big in this case here and had the perception that we had a WG discussion about this before with rough WG consensus (albeit quite rough) as is. (And I admit, the long latency times in the WG discussions between emails and draft iterations did not make things easier.)

But if anyone thinks this problem will be major, please say so now and we could have a quick (5-day) discussion window in the WG whether this needs to go back to the WG or whether the chairs did misjudge WG consensus.

Just my personal view, but with hat of WG chair on.

Best wishes, Tobias




On 05/09/14 01:06, Ryan Sleevi wrote:
I wish you would have raised this during WGLC, which would have benefited from the review and discussion now being paid.

I guess echoing Yoav's earlier remarks that:

"At this stage, we can make editorial changes, but we cannot make significant changes on our own. We can withdraw the request to publish, and take it back to the working group, but I think that would be inadvisable.
I think we should proceed, making only editorial changes, and changes resulting from discussion with IESG members."

that it's probably not worth discussing much further.

If the WG feels strongly about this, we can certainly withdraw from publication. If so, I think the Chris' and myself would need to recuse ourselves from being able to edit this document any further, so the WG would need to find a new set of editors to proceed with this draft.

Other than that, either we accept these as ERRATA, or we accept them as being what they are.

That is, my understanding is that this is a bit like discovering a possible issue after you've shipped your gold master to 100K stores. Yes, it's awful, but either it's a recall or you fix it in post. My gut is that it's for post. However, based on Yoav's remarks, I'm not sure that there's very much we can do editorially to address these. It appears my proposed suggestion does not address your concerns, so I will not be added it to the next (and hopefully final) draft.



On Thu, Sep 4, 2014 at 4:53 PM, Trevor Perrin <trevp@trevp.net> wrote:
On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
>
> On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <trevp@trevp.net> wrote:
>>
>> I agree with Eric and Joe that the current definition of PKP-RO is not
>> that useful and potentially surprising to deployers.
>>
>> Ryan argues that storing PKP-RO is dangerous because a TLS MITM who
>> could set pins for a lot of clients for a lot of sites could flood a
>> victim with reports.
>>
>>
>> Couldn't the MITM also set PKP pins with report-uri, or set cached
>> redirects or other cached resources to generate traffic toward a
>> victim?
>
>
> Yes, and that's a user visible effect, rather than transparent.

Hmm, there's nothing clever that can be done with cached javascript or
html to also generate silent traffic toward a victim?


> It also
> requires that a connection be validated first, whereas the very definition
> of PKP-RO is that you send it when a connection is not validated.

I'd expect stored PKP-RO to follow the same rules as PKP and be stored
only if it meets the bullet points in 2.5 (error-free TLS connection,
backup pins, etc.).

It would make sense for any report-uri header (PKP or PKP-RO) that
fails the 2.5 checks, or has some other invalid syntax (eg bad
base64), to *also* generate a different sort of report and not be
stored.

Would it be reasonable to add a reporting message for 2.5 failure or
syntax failure?  Otherwise, when asserting a report-uri pin you can't
distinguish pin-not-stored errors from
pin-stored-and-validation-successful.


>> Ryan argues PKP-RO is worse because it's "conceptually and practically
>> silent to the user".  But once the browser has sent junk traffic to a
>> victim, I don't really see how seeing how displaying a pinning error
>> makes things better.
>
>
> First, the attacker can only mount the hostile attack after having first
> established a good connection.

Debateable per above.


> PKP-RO allows an attacker to perpetually
> mount a hostile attack.
> Second, the presence of a pinning error is an inherently rate-limiting
> factor to the user experience. You're not going to be able to trigger 100
> reports if you're causing the user 100 error pages.

Rate-limiting is already proposed:
"""
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 per distinct set of declared Pins.
"""

Wouldn't that take care of it?


> Third, it seems like you're arguing for removing report-uri altogether,
> given the privacy and DoS risks identified. That is, the more that  you
> establish RO is similar to PKP in level of what an attacker can do, the more
> it argues for removing report-URI entirely.

Dunno.  I'm still trying to understand these risks, whether they're
really different for PKP-RO vs PKP, and for HPKP versus other web
technologies.

Trevor



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

--------------010203050207060607000906-- From nobody Sat Sep 6 02:39: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 9CDA21A01FF for ; Sat, 6 Sep 2014 02:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 AlYaEWdvGuGM for ; Sat, 6 Sep 2014 02:39:09 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B54F1A0201 for ; Sat, 6 Sep 2014 02:39:09 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id w62so12777075wes.13 for ; Sat, 06 Sep 2014 02:39:08 -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=5Hu+5HzEOZ6hUBP/kzdUCW1D612ZU8GnpIZ9lq/qr3c=; b=jawAqqHcROmOjxkG6JlSoh4/F2Z4knlB7ZhCLZLjwHRf06DIl1/krUBKOU+LOdHllq cAWuY2Vqnebt6JR8m3/PzgE0ZBABVq4YiY4kZbPr7RUrUX50mc008cZ/X5A48cfi9keY dHOHHVbNIwof0RIyt3qmbo2rXsJmKnj1BSUTLbjtvKsdDFayNqLXmryCPCBv0TkSQos2 8+btlnvaM0OFLAUnqr52zkq4MSeL51eohGZpuyQZxxLtNP96r+kvZHfqy3TsKqrdsTz3 c3jliRDEhzv4/gpxG2Zq3gCudjLYVxcHd0Gy92VTzQ4YS4HyiOp297xoDvRoCB4iVOAS DwGQ== X-Received: by 10.180.38.84 with SMTP id e20mr8969453wik.43.1409996348005; Sat, 06 Sep 2014 02:39:08 -0700 (PDT) Received: from [192.168.1.100] (IGLD-84-228-139-90.inter.net.il. [84.228.139.90]) by mx.google.com with ESMTPSA id xn15sm4590672wib.13.2014.09.06.02.39.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Sep 2014 02:39:07 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <5409A7B7.5040206@gondrom.org> Date: Sat, 6 Sep 2014 12:39:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54CD99ED-CC3C-41A8-AEBC-C35B64232B32@gmail.com> References: <35F981DA-46C4-44D7-8582-25BF8BF1B31A@gmail.com> <5409A7B7.5040206@gondrom.org> To: Ryan Sleevi X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/B6fOGA6K4KOOAXru5E-7Zvo6554 Cc: draft-ietf-websec-key-pinning , "" Subject: Re: [websec] draft-ietf-websec-key-pinning 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, 06 Sep 2014 09:39:17 -0000 Hi I agree with Tobias. The attack that Trevor describes is done by a TLS MitM. TLS MitM can be = either trusted or not trusted.=20 Non-trusted MitM is not a problem. Even if the user is allowed to click = through the interstitial and get the page, the browser still considers = the connection insecure (red slash in the UI of Chrome) and the draft = says not to note a pin in that case (Section 2.5: "It received the PKP = response header field over an error-free TLS connection.=94) Trusted MitM are a bigger issue. I know that Google=92s implementation = disables pinning for trusted MitM, but even UAs that won=92t make a = distinction between regular trusted CA and MitM CA won=92t pin the data, = because the pins (that come from the origin server) will not match the = public keys (that come from the proxy). The only issue is if the MitM is = malicious and stores its own pins via the PKP-RO headers, causing the UA = to be tracked by sending reports to the attacker whenever they access = the website. I think it=92s important in this case that the MitM is trusted, meaning = that the user (or their IT department) installed that root trust anchor. = In that case the user has to trust that this root CA won=92t do harm. = That=92s part of the trust. This scenario may deserve a sentence or two = in the security considerations, not a change in the protocol. Yoav (with chair and shepherd hat on) From nobody Tue Sep 16 12:46:24 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 E734A1A8856 for ; Tue, 16 Sep 2014 09:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 qjxTjTGBwSZe for ; Tue, 16 Sep 2014 09:57:52 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23601A884F for ; Tue, 16 Sep 2014 09:57:51 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j5so183709qga.22 for ; Tue, 16 Sep 2014 09:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=EJhVB7w/U6Q5pCelWY7aL9cSk3O/M6AiY9tDGUM22ZY=; b=EcHMnEFYhEFmuH5tlviaSahVhv8ZcXQ8HapIN9ArP7qpsJqe6vwCPhLPeku3WAEMFY UAv7/1biIcQtTReaW8UW2yEJH0ostCK5erKLynVcLURrOrw5Xxrz2WvHLl+LM8BelTpP 42uWpJOmt478J+LCr9ANdvknH1uj+l2APFh0kUviljUFX19zaJPKRrS8FwBcIksfZts3 fB50FyoNb3/g/3EjbRzcRtVYJ/aokrrGnoLk+UGuv9UgHMXp34E2XPsCn9TDE01wc8f3 OyZKVsggUIYv920JRZXQ96Or4srrnaMb/biPfIEggrnzctIWvEaWpNeu/EdC+nE3/jPH X0og== MIME-Version: 1.0 X-Received: by 10.140.48.203 with SMTP id o69mr17462192qga.102.1410886670926; Tue, 16 Sep 2014 09:57:50 -0700 (PDT) Sender: annevankesteren@gmail.com Received: by 10.229.179.200 with HTTP; Tue, 16 Sep 2014 09:57:50 -0700 (PDT) Date: Tue, 16 Sep 2014 18:57:50 +0200 X-Google-Sender-Auth: kxs3cYg4EezU2IT8QY__rb3Ls0U Message-ID: From: Anne van Kesteren To: websec Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/z7x_LvtmPMPNATrUHfSlW_CGcK4 X-Mailman-Approved-At: Tue, 16 Sep 2014 12:46:23 -0700 Cc: Ian Hickson Subject: [websec] HSTS and subdomains 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, 16 Sep 2014 16:57:59 -0000 If example.com serves up a policy with includeSubdomains. And sub.example.com serves up a policy without includeSubdomains, max-age=0, and redirects to http://sub.example.com. I first visit example.com. And then I visit sub.example.com. What happens and where is this defined? -- https://annevankesteren.nl/ From nobody Tue Sep 16 14:08:52 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 567261A03A3 for ; Tue, 16 Sep 2014 14:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 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, RCVD_IN_SORBS_WEB=0.77, 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 I1p3QcHs3f9h for ; Tue, 16 Sep 2014 14:08:49 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 0C2601A03AF for ; Tue, 16 Sep 2014 14:08:48 -0700 (PDT) Received: (qmail 2306 invoked by uid 0); 16 Sep 2014 21:08:46 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 16 Sep 2014 21:08:46 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id rx8e1o00e2UhLwi01x8heM; Tue, 16 Sep 2014 15:08:45 -0600 X-Authority-Analysis: v=2.1 cv=e5mVF8Z/ c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=-KpzFdj539cA:10 a=S2JtE8X_p4UA:10 a=3NT3xRclEPMA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=vS7MmSmxvPQA:10 a=A1X0JdhQAAAA:8 a=48vgC7mUAAAA:8 a=TVMCqI-tnDLech9wEIMA:9 a=QEXdDO2ut3YA:10 a=e1i35A98MB8A:10 a=4rq7TwIXcRUA:10 a=Y6qChIQXU1wA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=85bb8X96BpsmGzZ24tycqzwF19n3TV4/4vmUpJIDWbY=; b=K+fEsIUvkeN7V0RctC28+iePAJWRnonua1TCa6KbzWOFdkH0CFHbE1rK6J5cB/XxR/YgUKmcOZEDly7YoHqUd51aHfUiUesl14EwE6QPmnMxvsSmXFrUhhlL3xEz1ygZ; Received: from [216.113.168.128] (port=30646 helo=[10.244.137.98]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTzzL-0005AI-Dz; Tue, 16 Sep 2014 15:08:39 -0600 Message-ID: <5418A6D5.50705@KingsMountain.com> Date: Tue, 16 Sep 2014 14:08:37 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Anne van Kesteren Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Archived-At: http://mailarchive.ietf.org/arch/msg/websec/zLp6iQ-ap_PupiZDhQiLT2NpkpI Cc: Ian Hickson , websec Subject: Re: [websec] HSTS and subdomains 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, 16 Sep 2014 21:08:50 -0000 > If example.com serves up a policy with includeSubdomains. And > sub.example.com serves up a policy without includeSubdomains, > max-age=0, and redirects to http://sub.example.com. > > I first visit example.com. And then I visit sub.example.com. What > happens and where is this defined? Ok, good question, I'll try to tease this apart a bit... 1. "load" of https://example.com yields, say,.. Strict-Transport-Security: max-age=31536000; includeSubdomains note: receipt of the above HSTS Policy denotes example.com as an Known HSTS Host (with includeSubdomains asserted) if it was not already so noted [1]. 2. if a subsequent "load" of https://sub.example.com [0] (sub.example.com is not as yet noted as an HSTS Host) yields.. Strict-Transport-Security: max-age=0 Location: http://sub.example.com ..then, this newly-asserted HSTS Policy (for sub.example.com) ought to be "noted" per the HSTS storage model [2] since its domain name is not a "congruent match" for "example.com" [3] -- but it is declaring a max-age of zero, which would imply not noting it due to the NOTE in [5]. Regardless, due to the "URI Loading and Port Mapping" algorithm [4], example.com's HSTS Policy will override sub.example.com's declared policy (if it is noted by some errant UA). Thus the subsequent load of the Location-specified resource ("the redirect") will have it's URI scheme translated to "https" per [4], and the redirect will be essentially idempotent. This will continue to be the situation until and if example.com rescinds it's assertion of includeSubdomains or it's entire HSTS Policy. I.e., sub.example.com may declare an HSTS Policy, and it will be duly noted by UAs, but it will be overruled by example.com's policy (until the latter is altered per the foregoing). This situation is implicated in the discussions in [6], but not explicitly explained. If anyone finds bug(s) in this analysis, please raise them. HTH, =JeffH [0] or of http://sub.example.com which will become https://sub.example.com per [4] due to the HSTS Policy established above. [1] Strict-Transport-Security Response Header Field Processing https://tools.ietf.org/html/rfc6797#section-8.1 [2] Noting an HSTS Host - Storage Model https://tools.ietf.org/html/rfc6797#section-8.1.1 [3] Known HSTS Host Domain Name Matching https://tools.ietf.org/html/rfc6797#section-8.2 [4] URI Loading and Port Mapping https://tools.ietf.org/html/rfc6797#section-8.3 [5] The max-age Directive https://tools.ietf.org/html/rfc6797#section-6.1.1 [6] Implications of includeSubDomains https://tools.ietf.org/html/rfc6797#section-11.4 end From nobody Wed Sep 17 14:35:23 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 D2DB91A6F59; Wed, 17 Sep 2014 14:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 AVUdT8dzvWTA; Wed, 17 Sep 2014 14:35:14 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923E41A6EE8; Wed, 17 Sep 2014 14:35:14 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id x19so2551331ier.8 for ; Wed, 17 Sep 2014 14:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4RFZzKX/+e1KOM2E9Q6dci/cyL5DvThW+Egj3hn2WeI=; b=RLqpe7MR/nY/im4qxHPQPi7m2lxMx1zWjVvMedPTFsvXeiJjCCD6IZGB4KONOV7DP+ Qwd1m/zBU2pxyqGyYKtselqoZKGVAlo6tiw1IGvU5GWVkbpyUCTmx72DybdX4eIy4lk0 tVVbnF7loQDHEiS4FGjShqCBtf9490TiMJIEV31y9wMYaWfiW/0iEeC4xBPm07L08nHo mvpgKIr9JiQHPWUyQ75TENOCp3WF1Jyh79qcJG5jC5rCNHw6en+qqEBQsQ1gxWnqPg/f yLP8RCMWAyVxIHjYnroRwbystg86Oiq3dMzacLlPjG5ksNJCJuxJJFGHhCgC6drC/ZTk jUCg== MIME-Version: 1.0 X-Received: by 10.50.80.116 with SMTP id q20mr43181846igx.22.1410989713808; Wed, 17 Sep 2014 14:35:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.170.160 with HTTP; Wed, 17 Sep 2014 14:35:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Sep 2014 00:35:13 +0300 X-Google-Sender-Auth: Yw3p23z8DQUlKuUFIe2PrTfxgS0 Message-ID: From: Barry Leiba To: IETF WebSec WG , draft-ietf-websec-key-pinning.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/y7Mb5gNCrdGhPAXVd0nUa9w46ms Cc: IESG Subject: Re: [websec] DISCUSS positions on draft-ietf-websec-key-pinning 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, 17 Sep 2014 21:35:19 -0000 How are we doing with this document? Any progress on dealing with the DISCUSSes and other comments? Barry On Thu, Aug 14, 2014 at 6:47 PM, Barry Leiba wrote: > Websec folks, and especially the document authors: > We have several DISCUSS ballots on the key-pinning doc (from Stephen, > Kathleen, and Ted): > > http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ballot/ > > ...and I have seen no response from the authors on them. Please > respond soonest, and have the necessary discussions to resolve them. > Please also consider and respond to the non-blocking comments from > Alissa, Pete, and Richard. > > Yoav, please stay on top of this and do the necessary prodding to keep > this moving. > > Thanks, > Barry From nobody Wed Sep 17 18:53:07 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 6FA751A6FC3; Wed, 17 Sep 2014 18:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 ConKsm8umYTk; Wed, 17 Sep 2014 18:53:00 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557E71A6FBF; Wed, 17 Sep 2014 18:53:00 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F1C9F1B85F2; Wed, 17 Sep 2014 18:52:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B4F5D53E074; Wed, 17 Sep 2014 18:52:59 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Sep 2014 18:52:59 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Wed, 17 Sep 2014 21:52:57 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/websec/7hTh9X5YV2RWxOoGhCodMiynOqc Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, IETF WebSec WG , IESG Subject: Re: [websec] DISCUSS positions on draft-ietf-websec-key-pinning 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, 18 Sep 2014 01:53:01 -0000 On Sep 17, 2014, at 5:35 PM, Barry Leiba = wrote: > How are we doing with this document? Any progress on dealing with the > DISCUSSes and other comments? I think I at least reached a satisfactory solution with the authors, if = they agree with what I asked to do, but I haven't heard back yet. From nobody Wed Sep 17 21:12:26 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 DD6D41A7006; Wed, 17 Sep 2014 21:12:23 -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 JgaY35ZlhuXm; Wed, 17 Sep 2014 21:12:22 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F5D1A7003; Wed, 17 Sep 2014 21:12:21 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id z12so246468wgg.28 for ; Wed, 17 Sep 2014 21:12:20 -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=Yr88ldAXAIILt4Ts8GqA3sruOGtcWCWC6+h7l45WjYw=; b=H/fHBccdyb9Ab1PzFVc42LYV7k4feE5eiVkDmFX0SP4mjPNth49ipDnj98RlgSax5P BEp/+RaeHQyADH0caySEUq3SfeFmt4fTqqBzp3Wk5R0vDSLJn52kdvCkRB+DqblPxwzQ hISkylxetSEnEG28o+GZqmuNM6o30qmghmDOju21ontpnsPSKq4iHqOx7DEt0uLk4CmJ vrW2OuHG63ZDpt1xBlR4A69bmzB0eLInFy/lQ7980/cEthnEVWk1Mcadvb4ewVegLBOn My7t6euVo42ahHR7AbDrCET8LSfpiHqrWcrQJ0PmGbFK2NoXq71hRBBz3xd5i6Z8QMSB R2yQ== X-Received: by 10.194.161.231 with SMTP id xv7mr1891267wjb.78.1411013540119; Wed, 17 Sep 2014 21:12:20 -0700 (PDT) Received: from [192.168.1.103] (IGLD-84-228-221-198.inter.net.il. [84.228.221.198]) by mx.google.com with ESMTPSA id h4sm1339489wib.24.2014.09.17.21.12.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Sep 2014 21:12:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 18 Sep 2014 07:12:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7E8E7D4E-61D0-4C6B-B5CC-FFAE1BF80699@gmail.com> References: To: Ted Lemon X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/2__nuxBPflNntA4L48CNCH9w2BE Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, Barry Leiba , IETF WebSec WG , IESG Subject: Re: [websec] DISCUSS positions on draft-ietf-websec-key-pinning 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, 18 Sep 2014 04:12:24 -0000 I have heard from them. They said that they will finish the revision = this week or on the weekend. Yoav On Sep 18, 2014, at 4:52 AM, Ted Lemon wrote: > On Sep 17, 2014, at 5:35 PM, Barry Leiba = wrote: >> How are we doing with this document? Any progress on dealing with = the >> DISCUSSes and other comments? >=20 > I think I at least reached a satisfactory solution with the authors, = if they agree with what I asked to do, but I haven't heard back yet. >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Fri Sep 19 10:13: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 26B091A03C4 for ; Tue, 16 Sep 2014 14:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.602 X-Spam-Level: X-Spam-Status: No, score=-20.602 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 cAKDBlWg5Qm5 for ; Tue, 16 Sep 2014 14:09:07 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F45E1A0383 for ; Tue, 16 Sep 2014 14:09:07 -0700 (PDT) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:Received: From:To:CC: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:Return-Path:X-CFilter-Loop; b=dRE2arUy5cZHvv46kaFctM3m4LXoLoNfy++1cwXr/+Rp7ZyEzem/aUry sq7aRJoFY/Wnwvad4Y8C/Yw6brxUZeG1Ry8qpqCeHCc6AKfUh5ANhuHW1 7WbiVCYCMBOg8EKWkMlvBtDFVUj/xeIy0CxlD6GMvMAOcj6t6s9uvxg8N s=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1410901747; x=1442437747; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=7SIXowVr0HnsQjJTn5dt1teqFvaqMY5o2lzcs9ycpuo=; b=g+KvkveQakoygdQiUKGlsUdUGGocGErWT/bJdm9SIZ4m6IPFyY5gjjSI 6QH0Ib9d+IWbAaDMJAwBOAJv+gLUNmTlsAiVUbO1v/ZSy/lxDlzpAjvWe VxWFSFBc/oj4xJNjQQ2y3mB4f6poG6GRnQrJ1yXA/pAo6c6OKG7SZgDkb g=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="5.04,536,1406617200"; d="scan'208";a="68320177" Received: from den-vteml-003.corp.ebay.com (HELO DEN-EXMHT-003.corp.ebay.com) ([10.101.112.119]) by den-mipot-002.corp.ebay.com with ESMTP; 16 Sep 2014 14:09:07 -0700 Received: from DEN-EXMHT-010.corp.ebay.com (10.241.52.135) by DEN-EXMHT-003.corp.ebay.com (10.241.17.150) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Sep 2014 15:09:06 -0600 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-010.corp.ebay.com ([10.241.52.135]) with mapi id 14.03.0195.001; Tue, 16 Sep 2014 15:09:06 -0600 From: "Hill, Brad" To: "websec@ietf.org" Thread-Topic: Review request for a few WebAppSec specs. Thread-Index: AQHP0fJymUN9kxagLE6paPw3EKRu5w== Date: Tue, 16 Sep 2014 21:09:05 +0000 Message-ID: <3372A5C3-5F06-4F3D-BB85-889EB112313B@paypal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.19.133.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <71CCD28A29E90F4A86CBFC83C3EABA2B@corp.ebay.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/websec/vy0XvXuNHxNYoVQ7E8M56tUcmB0 X-Mailman-Approved-At: Fri, 19 Sep 2014 10:13:23 -0700 Cc: Joel Weinberger , Frederik Braun , Jochen Eisinger , Mike West , Adam Barth Subject: [websec] Review request for a few WebAppSec specs. 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, 16 Sep 2014 21:09:09 -0000 BCC: public-webappsec@, FYI. CC: Hello IETF WebSec folks, The WebAppSec WG over at the W3C has a few specifications in flight for whi= ch we're actively seeking feedback. One or more of them might be interestin= g to you; if you have some spare time, we'd very much appreciate your feedb= ack: CSP2: https://w3c.github.io/webappsec/specs/content-security-policy/ Mixed Content: https://w3c.github.io/webappsec/specs/mixedcontent/ Referrer Policy: https://w3c.github.io/webappsec/specs/referrer-policy/ Subresource Integrity: https://w3c.github.io/webappsec/specs/subresourceint= egrity/ The first three are in pretty good shape both in terms of the spec text and= implementations. The last (SRI) would be more of a pre-review, but would s= till be helpful for us. Thanks! Brad Hill= From nobody Thu Sep 25 17:33:46 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 E0C091A00AB for ; Thu, 25 Sep 2014 17:33:43 -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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, 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 516vP_a6SBjr for ; Thu, 25 Sep 2014 17:33:43 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FCF1A008B for ; Thu, 25 Sep 2014 17:33:42 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id ty20so1064202lab.26 for ; Thu, 25 Sep 2014 17:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=8j9RU8pXClHMyhg0cV65nrH6GZCwqGXhy5UQm6oCs2A=; b=G5rmOCmI9RSOIb2dGD8QckC9gaa1fydv3VJ/7wyGr+IeTBsHZUAsXKeDB60FP1GxLc 8STa2Xocoe0jH6GFHf/v9Ow7FIauROqRtRWCxGnCFZvVyYETVkpDyN+sLPYeo7WOcMwg Qo0p6l6lFhrJS8BjIZ6jzub5sNnJytLTtwmSx5D5lf7s6+sOcM/vYixiK5CghWcAaom/ Qv6n4y8n/v/mGHlem1Kcheq6FsKSq1kT84eLMEkrs3uiOLeTKS2xq5kRl+3lrklXHEsT bQu51BrwTh6z8iN6MyMAuBNvn1AtQOJhCBs+CDtD86YLH1UZyphmSaFtXQoLfLPkQNAh HkaQ== MIME-Version: 1.0 X-Received: by 10.152.23.69 with SMTP id k5mr16976966laf.70.1411691621154; Thu, 25 Sep 2014 17:33:41 -0700 (PDT) Received: by 10.25.135.66 with HTTP; Thu, 25 Sep 2014 17:33:41 -0700 (PDT) Date: Fri, 26 Sep 2014 08:33:41 +0800 Message-ID: From: Nazmul Bablu To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/TIIaRhD7mudvnp7EoEHTRDJBOYM Subject: [websec] networking X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bablukhuki@yahoo.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 00:33:44 -0000 pray for rebecca meius