Re: [fetch] Request for support for certificate pinning (#98)

with my myopic, close-minded, "no is the best answer," hat on, I'm inclined to say "No, we shouldn't support this."

As @igrigorik lets on, this is rife for abuse. Some of the general limitations of this have already been discussed in past discussions related to [S-Links](http://www.secure-links.org/), but having client-specified policy for arbitrary origins is generally quite problematic (it's the SRI problem, except at a whole new level). The opportunity for misuse / improper configuration alone should doom this proposal.

But anyways, back to the abuse case. The end result of such a proposal is that pools of sockets would no longer be able to be pooled by destination origin - that is, a pool of say six sockets to (https, google.com, 443) - because it would have to consider the calling origins effective-client-policy at the time of connection. That is, it'd minimally be a tuple of (destination origin, source origin, security policy), since the entire point of such policy is that it affects connection establishment.

Now, you could say something like "Oh, no, just look at the existing sockets, and if one doesn't meet the specified policy, close one of the existing sockets and establish a new one" - except that presumes that user agents implement a 1:1 mapping of socket<->request (they don't; socket connections are vended out independently of the requests that require them), and it's really just an expression of the concept of a "shared socket pool", where you're still isolating the sockets on the axis I mentioned, it's just broken into subpools. That is, (destination orgin) is key 1, (source origin, security policy) is key 2. The disconnect&restablish just keeps the connection limits keyed off key 1, but still has to account for key 2 in the actual establishing.

It also upends a bit of the priorities of constituencies here, although in a way that I feel almost glib for using that phrase. Here, the destination-operator should be able to set their security policy as they see fit, for they're the operator. They might choose CA 1, but then later, decide for economic reasons that CA 2 is far more acceptable. By allowing source-operators to control how that security policy is applied, the source-operators can (effectively) try to interfere and prevent the destination-operator from doing that. This is by design - the source-operator wants to restrict the ability of an evil MITM to swap the certs out, but as a consequence, the source-operator end sup dictating policy for the destination-operator, forcing the destination to either accept "This is the CA we must use" or simply break those links. There's no question in my mind that source-operators are far, far less likely to update their links than destination-operators, and so this just encou
 rages ba
 d linking. This is the s-link problem.

Such pins are inherently non-static. CA lists change over time, someone will have to be curating all those outbound pin sets to reflect modern practice. That's an unusuable nightmare for outbound links; and is just sustainable enough when maintaining HPKP/HSTS.

Like I said, I understand where this is coming from, but I don't think it's good at all. I've argued against such proposals in the past (e.g. S-Links) because I think they offer even larger footguns than HPKP/HSTS.

And I'm particularly _not_ taking the time to explain why the individual directives proposed are themselves problematic, but I do want to highlight that even if these concerns are ignored in favour of exposing this (after all, I am someone who says "no" a lot), there's still real issues with the nature of what's being requested.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/98#issuecomment-129980062