From nobody Thu Feb 19 09:43:58 2015 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 09A571A0158 for ; Thu, 19 Feb 2015 09:43:58 -0800 (PST) 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 iLJ10inDZtKe for ; Thu, 19 Feb 2015 09:43:51 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D060C1A0019 for ; Thu, 19 Feb 2015 09:43:50 -0800 (PST) Received: by iecrd18 with SMTP id rd18so1711426iec.5 for ; Thu, 19 Feb 2015 09:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=7eg7mMEtMECtWzBOH4Tj3PI8X6ZSgUl6NQWFQMrdbA8=; b=aTCXAhvLkwwzfB7+Out4sE+8BVf4SKl3++2Hd/rdr2SNnv2f6AxzQQt5I/CYs045IW sf6OvtiNxYvGIYy5U9RufUF+41zVh6BXCrtYpg5FhZyPUrgPW/Th3jpWw33k0Hbcf2v/ SJ7f0TbDjlwjho8DCZ0QthmZIquzVIeEWsfE6iWgPWp7hQQAafTFQ9/WzurJrKG/SsiS T/lv8bKnfWQ9OB0oBeO47G0eXFJ2Il846MjwiFKkTKDNSK5vJduRVvMYv8z2Os8g2Ywy 7rldDBQOJEwqSdoA4xsIj5vVIh8E6EQ+YDfm6mdcZgTutjhPYA/rabv8vpfb686Ae34g jYJw== MIME-Version: 1.0 X-Received: by 10.50.32.33 with SMTP id f1mr9004246igi.9.1424367829862; Thu, 19 Feb 2015 09:43:49 -0800 (PST) Received: by 10.36.81.15 with HTTP; Thu, 19 Feb 2015 09:43:49 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2015 12:43:49 -0500 Message-ID: From: Jeffrey Walton To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:43:58 -0000 Quod erat demonstratum: http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-mid= dle-adware-that-breaks-https-connections/ This proposal needs to be revisited. It has serious defects. On Fri, Jan 2, 2015 at 12:21 AM, Jeffrey Walton wrote: > I'd like to share some comments on > https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21. > > Pubic key pinning is an effective security control and I'm glad to see > the IETF moving forward with it. And I'm especially thankful to Palmer > and Sleevi for taking the time to put it together and shepherd it > through the process. > > ***** (1) ***** > > The title "Public Key Pinning Extension for HTTP" seems overly broad > and misses the mark a bit. The Abstract states its for User Agents, > but the title does not narrow focus. > > There are different problem domains where public key pinning can be > utilized. Painting with a broad brush, I categorize them as "the > general problem" where no 'a priori' knowledge exists, and various > specific "instance problems", where 'a priori' does exits and can be > leveraged. An example of the general problem is browsers, and an > example of the instance problem is any custom software deployed by an > organization. > > Suggestion: change the title to "Trust on First Use Pinsets and > Overrides for HTTP" or "Pinsets and Overrides for HTTP in User > Agents". > > There are a few reasons for the suggestion. First, the abstract > effectively states its. Second, the proposed standard is a TOFU scheme > used for the general problem. Third, the Introduction recognizes the > two classes of problems when it discusses the pre-shared keys. Fourth, > the embodiment described in the proposed standard is not a preferred > solution for the many instances of the specific problems. Fifth, the > overrides need to be highlighted since they are an integral and high > impact part of the proposed standard. > > Above, when I said the "=E2=80=A6 is not a preferred solution for the man= y > instances of the specific problems", I'm referring to pinning as > described in Gutmann's Engineering Security [1], OWASP [2] or by Moxie > Marlinspike [3] and others. > > ***** (2) ***** > > I think the document could benefit from a more comprehensive > discussion of the goals. The abstract states "=E2=80=A6 [some] > man-in-the-middle attacks due to compromised Certification > Authorities". That wet my appetite and I'd like to read more. > > I think it would be more helpful to state what is trying to be > achieved in terms of both operational goals and security goals. For > example, I don't see any operational goals, like business continuity > behind a proxy. And "some man-in-the-middle attacks due to compromised > Certification Authorities" seems to be a somewhat underspecifed > security goal. > > ***** (3) ***** > > I think the document could benefit from an enumeration of the threats > the security control is intended to defend against (or a normative > reference to the "Pinning Threat Model" stated in [4]). > > Taken in its totality (pinning + overrides), its not clear to me what > the proposed standard defends against. > > The Abstract mentions it could defend against "[some] > man-in-the-middle attacks due to compromised Certification > Authorities." Because we don't know what the control is intended to > protect against, we can't measure its effectiveness. > > Additionally, when public key pinning is used in a more traditional > sense (like Gutmann's Engineering Security [1], OWASP [2] or Moxie > Marlinspike [3]), then pinning defends against some things the > proposed standard appears to allow. > > The lack of clarity means there are some significant operational > differences between customary expectations and the proposed standard. > The misunderstood differences will clearly lead to confusion, > unexpected results and a false sense of security. > > ***** (4) ***** > > From the 1. Introduction: > > Key pinning is a trust-on-first-use (TOFU) mechanism. > > That may be true for the general problem, but its completely untrue > when 'a priori' knowledge exists for a specific instance of the > problem. Gutmann's Engineering Security [1], OWASP [2] or Moxie > Marlinspike [3] have been providing the counter examples for years. > > ***** (5) ***** > > From the 1. Introduction: > > A Pin is a relationship between a hostname and a cryptographic > identity (in this document, 1 or more of the public keys in a chain > of X.509 certificates). Pin Validation is the process a UA performs > to ensure that a host is in fact authenticated with its previously- > established Pin. > > I was a little confused the first time I read this because I parsed it > incorrectly. Here's how I parsed the first time: only the server or > end-entity certificate has a hostname, so only that certificate can > contribute a public key to a pinset. The other certificates > (intermediate and ca) can't contribute to a pinset because they don't > have a hostname. > > Perhaps something like "A Pin is a mapping of a hostname to a set (one > or more?) of public keys that can be used to cryptographically certify > the site's identity... The public keys can be any of (1) the host's > public key (2) any intermediate or ca public key...". > > Also, 2.4 Semantics of Pins, offers a slightly different definition > (it includes an algorithm, which appears to be missing from this > definition). So maybe the definition above should be expanded to > include "contextual information" that can later be ratified. > > ***** (6) ***** > > The document might also consider introducing the term "Pinset". I > think Kenny Root or the Android Security Team introduced the term at > Google I/O a couple of years ago. They were probably using the term > internally before then. > > ***** (7) ***** > > From the 1. Introduction: > > ... UAs apply X.509 certificate chain validation in accord > with [RFC5280].) > > Typo: accord -> accordance. > > ***** (8) ***** > > From 2.1. Response Header Field Syntax: > > The "Public-Key-Pins" and "Public-Key-Pins-Report-Only" header... > > The naming of the fields appear to indicate they are mutually > exclusive (Report Only seems to indicate anything other than reporting > is prohibited). But 2.3.2 allows them both, so it might be a good idea > to make a quick statement that both are allowed in 2.1, and then > detail it in 2.3.2. Or drop the "Only" from > "Public-Key-Pins-Report-Only". > > ***** (10) ***** > > From 2.2.2. HTTP Request Type: > > Pinned Hosts SHOULD NOT include the PKP header field in HTTP > responses conveyed over non-secure transport. UAs MUST ignore any > PKP header received in an HTTP response conveyed over non-secure > transport. > > There could be some confusion here. What about anonymous protocols > that provide confidentiality only? Is it allowed or not allowed? > > ***** (11) ***** > > From 2.3.3. Noting a Pinned Host - Storage Model: > > Known Pinned Hosts are identified only by domain names, and never IP > addresses. > > This is kind of interesting. This document specifies behavior for > browsers and other UAs, but browsers follow the CA/B. The CA/B does > not prohibit a CA from issuing certificates for an IP address except > in the case of an an IANA reserved address (see the Baseline > Requirements, section 11.1.2 Authorization for an IP Address). > Additionally, RFC 5280 allows IP addresses in section 4.2.1.6 Subject > Alternative Name. So its not clear to me why a more restrictive policy > is called out. > > I also understand an IP address for a host can change. But in the case > a public IP address has been previously bound to a public key by way > of an authority, it again seems more restrictive. > > *If* the proposed standard is trying to guard against some threats > posed by the Domain Name System, IANA reserved addresses, RFC 1918 > addresses and similar, then that should be listed under Goals and/or > Threats. > > ***** (12) ***** > > From 2.6. Validating Pinned Connections: > > =E2=80=A6 It is acceptable to allow Pin > Validation to be disabled for some Hosts according to local policy. > For example, a UA may disable Pin Validation for Pinned Hosts whose > validated certificate chain terminates at a user-defined trust > anchor, rather than a trust anchor built-in to the UA (or underlying > platform). > > OK, this is the reason for the proposed title change in (1). This is > also the reason for the list of goals and threats in (2) and (3). Its > just not clear to me (at the moment) how a known good pinset can be > broken to facilitate proxying/interception in a proposed standard for > a security control that's supposed to stop that kind of funny > business. > > Also, as far as document flow is concerned, I think the sentences > quoted above should be removed from the second paragraph and placed as > the last stand alone paragraph in that section. I think it should be > moved because it breaks the flow of the discussion of "what to do" > with a discussion of the related topic of "not doing what you should > be doing". > > ***** (13) ***** > > From 2.6. Validating Pinned Connections: > > UAs send validation failure reports only when Pin Validation is > actually in effect. Pin Validation might not be in effect e.g. > because the user has elected to disable it, or because a presented > certificate chain chains up to a user-defined trust anchor. In such > cases, UAs SHOULD NOT send reports. > > If I am reading/parsing this correctly: adversaries want to be able to > surreptitiously MitM the channel, and they don't want a spotlight > shone on them while doing it. > > As worded, the last two sentences are a tremendous blow to > transparency. The users and the site owner who are being > proxy'd/intercepted have a right to know what's occurring on his/her > [supposed] secure channel. In addition, the community has a right to > know how widespread potential problems are. > > Users and sites have a right to know because non-trivial data is > sometimes traversing the channel, like site passwords and confidential > company information. Some organizations and verticals have auditing > and compliance requirements, so reporting a breach/loss of that data > is required. The community has a right to know so the breadth of the > problem can be ascertained, and plans of action can be formulated and > action taken. > > Some proxying/interception performed by third parties or externalities > could be illegal in some jurisdictions, so the user or site will need > the evidence if they desire to have it addressed more formally. In the > US, I believe the law is the Computer Fraud and Abuse Act. > > The perceived risk of a lawsuit could help stop some of the > unauthorized proxying/interception because some organizations will > weigh the risk with the reward. Considering this proposal is a > security control to stop unauthorized proxying/interception, that's a > win-win. > > IETF leadership: Carl Sagan once asked, who speaks for the Earth. Who > here speaks for the users and sites? Does it *really* sound like a > good idea to suppress evidence of validation failures and unauthorized > overrides for a security control that's specifically designed to > contend with the threats? > > ***** (14) ***** > > 2.7. Interactions With Preloaded Pin Lists: > > The effective policy for a Known Pinned Host that has both built-in > Pins and Pins from previously observed PKP header response fields is > implementation-defined. > > In the name of transparency, the site should receive at least one > report detailing the issue. The site should be able to specify the > frequency of the reports so it can assess the breadth of the reported > issue. > > ***** (15) ***** > > 2.8. Pinning Self-Signed End Entities > > Kudos for this section. I think it fits nicely with Viktor Dukhovni's > Opportunistic Security. > > ***** (16) ***** > > Overrides are mentioned once in section 2.7. They effectively allow an > adversary to break known good pinsets and subvert the secure channel. > Section 4. Security Considerations does not discuss the impact of an > override. > > The impact of overrides should be discussed so that sites and software > architects can ensure the security control meets expectations and > properly assess risk. > > In addition, for browsers (which the proposed standard appears to > target), discarding the user's wishes is a violation in Priority of > Constituencies [5]; and violates the user and site's expectation of > Secure By Design [6]. So its not clear to me how useful the proposal > will be for browsers and other UAs that follow the W3C's Design > Principles. But I think things can be improved so that the proposed > standard does satisfy them. > > In the above, I claim the user typing HTTPS (or a site redirecting to > HTTPS) is an indicator that a secure connection to a site is desired, > and not a connection to folks who would like to proxy the connection > for them. By not delivering what they asked, the proposal falls short > of both Priority of Constituencies and Secure By Design. > > ***** (17) ***** > > There is no consideration for a site to set policy on overrides. That > is, a site should be able to determine whether it wants to allow > proxying/interception, and not an externality. Sites offering HTTPS, > and other security controls like HSTS or CSP, are strong indicators > that sites care about these things. > > Sites should be allowed to set policy on overrides, just like they can > set HSTS or CSP policy. > > IETF leadership: Who here speaks for the users and sites? > > *************** > > Sorry for the long post, and thanks for taking the time for consideration= . > > Jeffrey Walton > > *************** > > [1] https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf > [2] https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning > [3] http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-yo= ur-app-ha/ > [4] https://www.ietf.org/mail-archive/web/websec/current/msg02261.html > [5] http://www.w3.org/TR/html-design-principles/#priority-of-constituenci= es > [6] http://www.w3.org/TR/html-design-principles/#secure-by-design From nobody Thu Feb 19 10:01:13 2015 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 3DB1D1A1EEF for ; Thu, 19 Feb 2015 10:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 HzDxw_zFs7-Z for ; Thu, 19 Feb 2015 10:01:09 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93C31A1B7D for ; Thu, 19 Feb 2015 10:01:08 -0800 (PST) Received: by lbvp9 with SMTP id p9so1477993lbv.3 for ; Thu, 19 Feb 2015 10:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SMHWrs0wxcdQuIgjErO9yacoVoOwrxKhPO864Z5HWA0=; b=q8xjhKIwCao3v9VDy4xb5s6WET3OHuTqEcGvgeeBhPwNAcxHRmwWp7jo11aorqS1ls bkH58B3URNV2BR8k1cNzHRIT4OTuJlmPEZEeHymMIu8lnlNTmlTKROsf9D/xSYG71bmB +dTs/MlqpaeC6jVyXFfCWEXSn1P5KFBp7YutJWLXoQpqtX/put3sGfDRlUvmQUUxOq05 gBAnSQtH5d22pHXBkxS2GoKPDdk1L6nKX42IbKIzaEWUWgmWwahilYfNOigl/CCgBcM3 zT53N3XmPr2E6E6XvpyaNW69Pf4TOzGZQq9JNOmPflsN4sF3uy2u1X5WbuwiWwWLj1ZE 6USQ== X-Received: by 10.152.2.227 with SMTP id 3mr4841901lax.85.1424368867280; Thu, 19 Feb 2015 10:01:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.227.102 with HTTP; Thu, 19 Feb 2015 10:00:47 -0800 (PST) In-Reply-To: References: From: Joseph Bonneau Date: Thu, 19 Feb 2015 10:00:47 -0800 Message-ID: To: noloader@gmail.com Content-Type: multipart/alternative; boundary=089e013c6bc05d0bab050f74b876 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] Comments 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, 19 Feb 2015 18:01:11 -0000 --089e013c6bc05d0bab050f74b876 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 19, 2015 at 9:43 AM, Jeffrey Walton wrote: > Quod erat demonstratum: > > http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/ > > This proposal needs to be revisited. It has serious defects. Ryan's previous post already covered the reasons for disabling pin validation for user-defined trust anchors, which still hold even though Superfish did their superfish thing. If the spec did not allow this behavior, the next Superfish would probably just configure local UAs to launch with pinning disabled completely. I don't think their recklessness would somehow stop short of overriding the browser's pinning policy. --089e013c6bc05d0bab050f74b876 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 19, 2015 at 9:43 AM, Jeffrey Walton <noloader@gmail.com&g= t; wrote:
Quod erat demonstratum:
htt= p://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle= -adware-that-breaks-https-connections/

This proposal needs to be revisited. It has serious defects.

Ryan's previous post already covered the reasons for = disabling pin validation for user-defined trust anchors, which still hold e= ven though Superfish did their superfish thing.

If= the spec did not allow this behavior, the next Superfish would probably ju= st configure local UAs to launch with pinning disabled completely. I don= 9;t think their recklessness would somehow stop short of overriding the bro= wser's pinning policy.
--089e013c6bc05d0bab050f74b876-- From nobody Thu Feb 19 11:38:40 2015 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 C2A051A0062 for ; Thu, 19 Feb 2015 11:38:38 -0800 (PST) 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 Kkpt26fxvbtJ for ; Thu, 19 Feb 2015 11:38:37 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCB21A0117 for ; Thu, 19 Feb 2015 11:38:25 -0800 (PST) Received: by iecrp18 with SMTP id rp18so2626655iec.1 for ; Thu, 19 Feb 2015 11:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=K6YzyeEDlbjSetXmakQCJaQWS+K9ZiXRBiFGOlPecNg=; b=W9xCt1JizY198CIBXQU+5JTiV7hT6/9DX2dQ7dhQ6PD4uqmS+kDItgUuvFOmeVUtW2 a3M7FjKro/bw6cpi7w8AT84tpKIGLGwPqV7HhkrX3kCxRho0wGKNCRxDjVpIbzdhBQK3 kJ7+/MIyBoujB9yqI02ZYHJMBuFIDoO7ZMXxcm/VNM6f8fSktnyb7uti5hNNUDofPzn1 m65p86X2uAy6cOpgUPrnzIVki4aCxyuIbJzlIa3LXNh+faCPtXBg0DIHv7nuKlHs42Vm ur+aud7vwq4ymFH0Eq3PMyK9fYmulYN0EIaHBeqbuyGqlQNjcMyNz0mOljb/HxB1wYZj A49g== MIME-Version: 1.0 X-Received: by 10.42.201.78 with SMTP id ez14mr8071232icb.22.1424374704508; Thu, 19 Feb 2015 11:38:24 -0800 (PST) Received: by 10.36.81.15 with HTTP; Thu, 19 Feb 2015 11:38:24 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2015 14:38:24 -0500 Message-ID: From: Jeffrey Walton To: Joseph Bonneau Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:38:38 -0000 > Ryan's previous post already covered the reasons for disabling pin > validation for user-defined trust anchors, which still hold even though > Superfish did their superfish thing. That's not acceptable for two reasons. First, the user did not take an administrative action. Second, pinning is a control we use to stop that sort of thing. We also don't have an audit trail because the IETF thought it was wise for the user agents to be complicit in the cover up. I don't believe this proposal - in its current form - will prove effective in the canonical cases: (1) CA failure like Diginotar; and (2) MitM attacks like Superfish. Are there other obvious cases I missed that this control will be effective? Jeff On Thu, Feb 19, 2015 at 1:00 PM, Joseph Bonneau wrote: > > On Thu, Feb 19, 2015 at 9:43 AM, Jeffrey Walton wrote: >> >> Quod erat demonstratum: >> >> http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/ >> >> This proposal needs to be revisited. It has serious defects. > > > Ryan's previous post already covered the reasons for disabling pin > validation for user-defined trust anchors, which still hold even though > Superfish did their superfish thing. > > If the spec did not allow this behavior, the next Superfish would probably > just configure local UAs to launch with pinning disabled completely. I don't > think their recklessness would somehow stop short of overriding the > browser's pinning policy. From nobody Thu Feb 19 19:42:21 2015 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 4D1D91A1EF6 for ; Thu, 19 Feb 2015 19:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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_DNSWL_NONE=-0.0001] 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 51-3vBtXSC9M for ; Thu, 19 Feb 2015 19:42:19 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFB71A1BE9 for ; Thu, 19 Feb 2015 19:42:18 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id D4099674058; Thu, 19 Feb 2015 19:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=bcMZDQ8O6kdiZfMP98lKyXZ5sPE=; b=mjmMGrI6KIVj9aTz7 2wqUNJLh3Ch0i89xxp+mrs38Ada+QzbjXfg9K/NMmq1GW6/KKvB2t2vhDJ0G2hd+ wP3ieJGN5Ur5lw7yaxOnx59m30WP54hDkv3/xl6VmFSO0qq768bGrCIvdBWnachl k/D9I3crTjrwJ767d+4fzVk6LA= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id AC416674057; Thu, 19 Feb 2015 19:42:17 -0800 (PST) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 19 Feb 2015 19:42:17 -0800 Message-ID: <5bd1e5f598ebde476bfdefa8993b8dc1.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Thu, 19 Feb 2015 19:42:17 -0800 From: "Ryan Sleevi" To: noloader@gmail.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 03:42:20 -0000 On Thu, February 19, 2015 11:38 am, Jeffrey Walton wrote: > I don't believe this proposal - in its current form - will prove > effective in the canonical cases: (1) CA failure like Diginotar; and > (2) MitM attacks like Superfish. Are there other obvious cases I > missed that this control will be effective? > > Jeff You're factually wrong in cases like (1), and woefully misguided in cases like (2) if you believe _any_ software, on a general purpose operating system with 1-layer security principals (such as Windows and OS X), can defend against a program with same-or-higher privileges. That's like complaining a program with root access can interfere with you= r usermode application. Well, yes, that's exactly correct, that's how it's supposed to work. If you can conceive a model where a super-user process would not be able to circumvent, then congrats, you've solved one of the most vexatious problems in computer security, and I know a dozen of anti-virus and anti-malware companies that will let you name your price if only you shar= e your solution with them. Consider the following ways that an application like Superfish could have dealt with this (courtesy of a colleague far brighter than I) - PTRACE_POKETEXT a code modification at runtime - LD_PRELOAD a shim that intercepts strcmp and returns false for "Strict-Transport-Security" - Patch GTK+ (or equiv) so that the lock icon always appears on the omnib= ox - Rebuild a version of the browser with the code to disable such pinning commented out. There is no sane world in which anything in the HPKP spec can or should deal with this. It's doubly true and hopefully self-evident that "raising the bar" is not at all an acceptable, or even reasonable, justification. Malicious actors have every reason to escalate to more nefarious means (whether for profit or interception), while legitimate actors get shut ou= t or, equally, burrow further into internals and cause worse experiences fo= r everyone. I understand that you disagree. But you're also wrong if you think HPKP can or should have dealt with this. Best regards, Ryan From nobody Sat Feb 21 18:38:25 2015 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 75F011A0263 for ; Sat, 21 Feb 2015 18:38:24 -0800 (PST) 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 qiLj6RdGFBZd for ; Sat, 21 Feb 2015 18:38:22 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30FD1A037F for ; Sat, 21 Feb 2015 18:38:21 -0800 (PST) Received: by ierx19 with SMTP id x19so16307529ier.3 for ; Sat, 21 Feb 2015 18:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mCMTvlkKa+1b6smLqjNJAzgDSxRE+6Smwu+ET9X3PCo=; b=e/et0M4uTwS2w28zxOnrf9aL0nwLQgIH/UfXnn/hjOSlOMPO0EYUa515rxUdAAYyPc mUdb5lmwh5B9gqAoBRhposGdyeWMXOgrJVBff4bbUQsVmYOIa8thMbhvAJsLbgBnW3jK tU0cQBCgIO3gyJ50jfK2tpsq8xQXfwNEC2Gz4pHIgDKI6MEU4mNwULIkMdjG/cwLTD51 AhwqWIg4AA4icr9UVP9Pxe9Qo2ul8z+hYBt5g4/RHiH7lviXBW5S3Xjt+FNqCy0yY/dE vrKoakNaZorvPZ4a1Db8wdDERbydgZyIyqlIzhxQb6kkysTBf58r/EIf9HyeKhRPVvqE mO7Q== MIME-Version: 1.0 X-Received: by 10.42.112.199 with SMTP id z7mr5291498icp.46.1424572700965; Sat, 21 Feb 2015 18:38:20 -0800 (PST) Received: by 10.36.81.15 with HTTP; Sat, 21 Feb 2015 18:38:20 -0800 (PST) In-Reply-To: <5bd1e5f598ebde476bfdefa8993b8dc1.squirrel@webmail.dreamhost.com> References: <5bd1e5f598ebde476bfdefa8993b8dc1.squirrel@webmail.dreamhost.com> Date: Sat, 21 Feb 2015 21:38:20 -0500 Message-ID: From: Jeffrey Walton To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 02:38:24 -0000 Thanks Ryan. >> I don't believe this proposal - in its current form - will prove >> effective in the canonical cases: (1) CA failure like Diginotar; and >> (2) MitM attacks like Superfish. Are there other obvious cases I >> missed that this control will be effective? > > You're factually wrong in cases like (1), and woefully misguided in cases > like (2) if you believe _any_ software, on a general purpose operating > system with 1-layer security principals (such as Windows and OS X), can > defend against a program with same-or-higher privileges. You'll have to forgive my ignorance because the document states its use to defend against some MitM attacks. The two canonical cases are (1) Diginotar and (2) Superfish. We can defend against them with pinning, so its not clear to me why browsers are having such trouble with it. Please humor me: what are the cases this security control defends against? Again, please forgive my ignorance. The document does not lists the cases it defends against, so I had to ask. That points to a gap in the document that needs to be improved. If HPKP can't handle (1) Diginotar and (2) Superfish, then it looks like a placebo to me. Its does a disservice by providing a false sense of security. But I'm probably wrong and I'd like to understand what security benefits HPKP provides. For completeness, I have not explored how HPKP interacts with self signed certificates. If it only serves to bar them, then I'd say the authors managed to get the CA/B Forum agenda furthered at the IETF. I think they call that "confused deputy" in computer security circles. But again, I could be wrong. > That's like complaining a program with root access can interfere with your > usermode application. Well, yes, that's exactly correct, that's how it's > supposed to work. Not exactly. These are two userland programs. One is not in a more privileged position than the other. > There is no sane world in which anything in the HPKP spec can or should > deal with this. Disagree. We use pinning to control that risk. The pain point for browsers seems to be they want strong authentication assurances while accommodating interception. That's a self made problem. > It's doubly true and hopefully self-evident that "raising > the bar" is not at all an acceptable, or even reasonable, justification. > Malicious actors have every reason to escalate to more nefarious means > (whether for profit or interception), while legitimate actors get shut out > or, equally, burrow further into internals and cause worse experiences for > everyone. Wow, I can't believe you're begging that argument. If I apply that thinking, then there's no need for HPKP in the first place. Or Secure Cookies, HTTP Only, HSTS, CSP, HTTPS (and friends) for that matter. > I understand that you disagree. But you're also wrong if you think HPKP > can or should have dealt with this. Again, disagree. We use pinning to control that risk. Again, the pain point for browsers seems to be they want strong authentication assurances while accommodating interception. That's a self made problem. ***** >> IETF leadership: Carl Sagan once asked, who speaks for the Earth. Who >> here speaks for the users and sites? Does it *really* sound like a >> good idea to suppress evidence of validation failures and unauthorized >> overrides for a security control that's specifically designed to >> contend with the threats? > > This spec speaks for the users, by ensuring that local privacy rights > trump remote server policy. Reporting and logging needs to be fixed. One report per origin does not facilitate tracking. By definition, you need more than one report to "track". If browsers were really interested in fixing tracking and addressing anonymity, then "Do Not Track" would be default out of the box; Google would honor "Do Not Track"; Google would not be subverting "Do Not Track" with tracker-breaking tricks; and ETAGS would be addressed. Or, pick your poison: if "Do Not Track" is not sent, then send the report. If "Do Not Track" is sent, then don't send the report. You guys have painted yourself into a corner with that one because you're insecure out of the box and you want to be part of the cover up. Until your cause is just, you're going to fall into simple traps like that. And I might as well hit the obvious: the user gave up expectations of anonymity with their first TCP SYN. If a user wants anonymity, then they need to use a suitable technology like Tor. ***** One of the things that's clear/evident is the browser architects are having troubles because they want strong server authentication and accommodate interception. They are competing goals and something has to give (they may even be diametrically opposed). I think browser architects and the security community need a Key Usage of INTERCEPT to help differentiate the cases. It will help browsers and other user agents differentiate the "good" bad guys from "bad" bad guys. It will also help them determine when its OK to break a known good pinset. CAs surely won't issue INTERCEPT certificates and (I believe) most folks won't declare INTERCEPT, so you've avoided the problem for a majority of the use cases (over 90%?). That's a huge step forward in helping browsers and other UAs differentiate the "good" bad guys from "bad" bad guys. The "good" bad guys will honor it and you'll know you're dealing with a "good" bad guy. The "bad" bad guys will not honor it and you'll know you're dealing with a "bad" bad guy. In this case of a "bad" bad guy, UAs should refuse to break the pinset. And UAs won't fall victim to the Diginotar and Superfish cases. Organizations that install a CA to perform device management or facilitate browsers and email programs can side step the whole interception problem by not declaring them in the first place. Browsers and users will not be put in the middle, and the problem will be avoided. That's a huge step forward in helping UAs differentiate the "good" bad guys from "bad" bad guys. UAs won't fall victim to Diginotar and Superfish in its current rendition because they lack the declaration. In the future, it will be easily auditable by security software so the Superfishes cannot fly under the radar. And if a CA is compromised and starts issuing INTERCEPT certificates, then alarm bells will go off. The audits and alarm bells will elicit so much negative press and publicity that something will bend or break somewhere. That's Palmer's "shame as a security control" and its a wonderful application of it because its proactive (and not reactive). Users like me who want nothing to do with interception can use a different media (like switching to 3G/4G from Wifi) or will move the INTERCEPT certificates to the Untrusted Store. I'd rather fail the connection, but you've taken that choice away from me. Now, if browser architects want to continue the surreptitious interception and help in the cover up, then that's a different problem. I suspect that's the agenda, and now is your opportunity to prove folks like me wrong. Jeff From nobody Sat Feb 21 21:47:58 2015 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 299E11A1A62 for ; Sat, 21 Feb 2015 21:47:57 -0800 (PST) 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 6sPeyagv1Lcg for ; Sat, 21 Feb 2015 21:47:54 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6E11A1AAC for ; Sat, 21 Feb 2015 21:47:53 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id B4FABF984; Sun, 22 Feb 2015 00:47:51 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3C8921FFDD; Sun, 22 Feb 2015 00:47:59 -0500 (EST) From: Daniel Kahn Gillmor To: noloader@gmail.com, ryan-ietfhasmat@sleevi.com In-Reply-To: References: <5bd1e5f598ebde476bfdefa8993b8dc1.squirrel@webmail.dreamhost.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 22 Feb 2015 00:47:59 -0500 Message-ID: <87pp9233ao.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] Comments 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: Sun, 22 Feb 2015 05:47:57 -0000 Hi Jeffrey-- I share your concerns about MitM attacks on the web, and I'm also not happy about the compromises made in HPKP about "locally-installed" trust roots, fwiw. But i don't think your arguments are helping. On Sat 2015-02-21 21:38:20 -0500, Jeffrey Walton wrote: > You'll have to forgive my ignorance because the document states its > use to defend against some MitM attacks. The two canonical cases are > (1) Diginotar and (2) Superfish. We can defend against them with > pinning, so its not clear to me why browsers are having such trouble > with it. I believe pinning *would* prevent Diginotar misissuance, unless the origin server had pinned to the diginotar CA itself. All origin servers that had pinned to something other than the Diginotar CA would have their users reject any cert issued by Diginotar. Pinning doesn't defend against Superfish because Superfish is malware installed at system initialization time. It could have been a lookalike version of a popular browser, or just a replacement of a system library involved in certificate validation. The only technical defense against this kind of thing is to wipe your brand new system down as close to the bare metal as you can go and install it properly from known-good sources. Most people are not capable of doing this on most computers, though, so as a society our recourse against future Superfishes may need to be something beyond just the technical. > I think browser architects and the security community need a Key Usage > of INTERCEPT to help differentiate the cases. It will help browsers > and other user agents differentiate the "good" bad guys from "bad" bad > guys. It will also help them determine when its OK to break a known > good pinset. > > CAs surely won't issue INTERCEPT certificates and (I believe) most > folks won't declare INTERCEPT, so you've avoided the problem for a > majority of the use cases (over 90%?). That's a huge step forward in > helping browsers and other UAs differentiate the "good" bad guys from > "bad" bad guys. > > The "good" bad guys will honor it and you'll know you're dealing with > a "good" bad guy. The "bad" bad guys will not honor it and you'll know > you're dealing with a "bad" bad guy. In this case of a "bad" bad guy, > UAs should refuse to break the pinset. I can't tell if you're being serious here or not. It sounds like you're endorsing something very similar to: https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01 Which i think is a terrible idea. > And UAs won't fall victim to the Diginotar and Superfish cases. I'm quite certain that in your scenario, Superfish would have set themselves up as a "good" bad guy and the overwhelming majority of users would be none the wiser. --dkg