Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?

["Miller, Timothy J." <[e-mail]>]

>> E.g., Microsoft has an extensive set of permissions associated with each trust anchor (in the certificates mmc snap-in, drill down to a root cert, right-click Properties, and you'll see them on the General tab).  "Trusted MitM" could be added to that set.
> 
> I don't believe this is a viable solution. There's at least five
> reasons it has opportunities for improvement.

PKI-related UIs all stink.  See all the variations on "Why Johnny Can't Encrypt" papers running back to 1999, or spend some quality time talking to people like Simson Garfinkel.  However, the fact that the UI sucks today doesn't mean the UI will always suck.  I remain hopeful.

My point was that not that this particular UI was the right answer, but that it represents a mechanism for client-side fine grained usage control that's not dependent on certificate extensions.  If you can think of a better way to do it, by all means, carry on.

> Also, Microsoft did not reuse exiting bits like PKIX has promoted.
> Microsoft provide policy extensions, which PKIX does not have.

The MS certificate permissions list is not dependent on MS proprietary policy extensions.  It can be set even for certificates that don't carry any.

> We are trying to prevent it, or at least give the user a choice, in
> the common use case. Users currently don't have a choice because
> groups like the web browsers and PKIX have ensured they don't get one.

Again, an optional certificate extension doesn't do diddly for this problem.  

You need to bind authorities to names, and that is not a certificate problem.  Certificates allow authorities to bind keys to names and that's all.  We can argue about whether or not this concept is still safe given the absence of the X.500 global directory, but frankly that's an academic discussion--interesting, but won't make a whit of practical difference. 

The fact remains that you can't bind authorities to names in a manner compatible with X.509.  There is no "in band" mechanism in the certs or the path that can accomplish what you want--the path itself can't communicate the *context* of the path.

> I fail to see how declarative security and in-band signalling is *not*
> the most direct path here.

In band signalling of what?  If CA A and CA B claim authority of the name foo.com (by dint of there being a valid chain from a cert asserting the name foo.com), how do you know--absent any other context--which is correct?  The longer path?  The shorter one?  

Simply putting a marker in the cert is useless--if one of those claims is fraudulent, that marker can be forged and you're back to square 1.  

If you put something verifiable in the cert--say, a signature from a DNSSEC key--you have to go out of band to verify it anyway, so why bother signaling in band?  

> And in-band signalling is surely least disruptive since it does not
> affect Public CAs or existing middleware boxes that perform it.

No, the least disruptive option is to leverage existing standards without modification to implement both the signal and the verification.  Frex., adding a DANE record check to TLS server authN verification.  

-- T