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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
