Re: [websec] Comments on draft-ietf-websec-key-pinning
Yoav Nir <ynir.ietf@gmail.com> Fri, 02 January 2015 12:26 UTC
Return-Path: <ynir.ietf@gmail.com>
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 822231A1A51 for <websec@ietfa.amsl.com>; Fri, 2 Jan 2015 04:26:43 -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 qLuNSf23mU-A for <websec@ietfa.amsl.com>; Fri, 2 Jan 2015 04:26:40 -0800 (PST)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CE31A1A22 for <websec@ietf.org>; Fri, 2 Jan 2015 04:26:39 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id w61so4410229wes.7 for <websec@ietf.org>; Fri, 02 Jan 2015 04:26:38 -0800 (PST)
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=HsS7OmpJlg5gWYPnqp+60cFaeYq49uGg71htofqQtlg=; b=v5d2v3KsL1bmxu2sfoR4mqbOcgCXkj5Jugskrp//+A7Db6qHcxqI4oQJwqfzEBHCyD TlkH8pfuoMjRF99FFXQEKChGCIDgxOLrb72vPq/l7gWpGvJXNL9Tsozsc4poPwViUJ5v cIEywTNZ5P478qbQE9erwzzJ35pKc5brrWZoKDe4Uas1nrho+SrxTEJgrJqPcSm39DuR fMqPMtxo2u+OBFsJWKDTEXUkGUqkvZOhMSzSzaiKncxxZQdI+KqxgLlUsmq9ptAODuB9 pnk/GSoDvHXTRRpIjhzLXNfn2HPzIWxkHia5cVwSlfSDmwiSrgzC/dDLMTACvvR6ngpq l/EQ==
X-Received: by 10.180.98.42 with SMTP id ef10mr62185923wib.46.1420201598665; Fri, 02 Jan 2015 04:26:38 -0800 (PST)
Received: from [192.168.1.102] (IGLD-84-228-227-214.inter.net.il. [84.228.227.214]) by mx.google.com with ESMTPSA id qd2sm53960109wic.19.2015.01.02.04.26.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Jan 2015 04:26:38 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAH8yC8=XEr9q8VHarucKa0rVqSPt3=oDzDRWXA3_u4rkhpZmoQ@mail.gmail.com>
Date: Fri, 02 Jan 2015 14:26:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E436DD1-8EFB-4270-81CA-717B0FDD9A4F@gmail.com>
References: <CAH8yC8=XEr9q8VHarucKa0rVqSPt3=oDzDRWXA3_u4rkhpZmoQ@mail.gmail.com>
To: noloader@gmail.com
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/s6dkqfdxbZsDn_K7At_juWTeKFQ
Cc: IETF WebSec WG <websec@ietf.org>
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 <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jan 2015 12:26:43 -0000
Hi, Jeffrey Thanks for the review. However, if you look at the datatracker link ([1]), you’ll see that this draft has been approved by the IESG 2.5 months ago. Its publication as RFC is only waiting for a referenced document to be published. I’m afraid it’s too late now. Yoav [1] https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/history/ > On Jan 2, 2015, at 7:21 AM, Jeffrey Walton <noloader@gmail.com> 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 "… is not a preferred solution for the many > 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 "… [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: > > … 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-your-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-constituencies > [6] http://www.w3.org/TR/html-design-principles/#secure-by-design > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec
- [websec] Comments on draft-ietf-websec-key-pinning Jeffrey Walton
- Re: [websec] Comments on draft-ietf-websec-key-pi… Yoav Nir
- Re: [websec] Comments on draft-ietf-websec-key-pi… Ryan Sleevi
- [websec] Sites with Key Pinning Headers (not prel… Martin J. Dürst
- Re: [websec] Sites with Key Pinning Headers (not … Joseph Bonneau
- Re: [websec] Sites with Key Pinning Headers (not … Pawel Krawczyk
- Re: [websec] Comments on draft-ietf-websec-key-pi… Jeffrey Walton
- Re: [websec] Comments on draft-ietf-websec-key-pi… Joseph Bonneau
- Re: [websec] Comments on draft-ietf-websec-key-pi… Jeffrey Walton
- Re: [websec] Comments on draft-ietf-websec-key-pi… Ryan Sleevi
- Re: [websec] Comments on draft-ietf-websec-key-pi… Jeffrey Walton
- Re: [websec] Comments on draft-ietf-websec-key-pi… Daniel Kahn Gillmor