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.
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 "… 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
