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

From: Jeffrey Walton <[email-masked]>
Date: Thu, 12 Nov 2015 03:43:40 -0500

Hi Everyone,

I've been through RFC 5280 and 6125 looking for a treatment of the
subject matter, but I could not find it. I would expect it to show up
somewhere, like KU or EKU, but the bits appear to be missing.

How do we differentiate authentic servers from proxies performing TLS
interception?

Thanks in advance.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Nov 2015 12:12:46 +0200

> On 12 Nov 2015, at 10:43 AM, Jeffrey Walton <[email-masked]> wrote:
> 
> Hi Everyone,
> 

There is no way to mark a certificate as an “interception" (or “proxy” or “fake”) certificate. Attempts to mark either the certificate or the TLS handshake were not successful in the IETF, because we do not facilitate interception in protocols, lawful or otherwise.

The heuristic employed by some browsers and alluded to in section 2.6 of RFC 7469 is to treat certificates that chain to a trust anchor that did not come pre-installed with the operating system or browser as interception certificates, but this heuristic is only valid in the context of key pinning - it would generate too many false positives in general use.

Yoav

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 12 Nov 2015 05:47:55 -0500

> There is no way to mark a certificate as an “interception" (or “proxy” or “fake”) certificate. Attempts to mark either the certificate or the TLS handshake were not successful in the IETF, because…

Thanks Yoav, that's interesting. I thought that too until RFC 7469
came along and got approved with the overrides.

Now that the IETF has provided a standard with the overrides, maybe
its time to revisit the previous decision. There are a few reasons:

* The dominate RFC 7469 players claim "interception is a valid use
case" (citing the W3C's Priority of Constituencies)
* Its a real-life problem, and not a theoretical one. It can't be
ignored as if it does not exist.
* Reusing key bits for both server authentication and
proxying/interception violates secure design and architecture. Its a
deep, fundamental flaw.

I'm particular bothered by the third item. Reusing the KU/EKU bits
violates at least three of the secure design principals outlined by
Saltzer and Schroeder's "The Protection of Information in Computer
Systems". More informed readers (like you, DKG, Guttman, etc), can
probably find more violations.

> The heuristic employed by some browsers and alluded to in section 2.6 of RFC 7469 is to treat certificates that chain to a trust anchor that did not come pre-installed with the operating system or…

It almost sounds like they are trying to get half pregnant...

Regarding false positives, I've found the opposite. We have
implemented Guttman's security diversification techniques in a few
libraries and products, and they are almost always spot-on. The trick
is we need a secure distribution channel to keep a handful of security
parameters up-to-date. All the App stores claim to have one, so we are
in a good position (and side-loading is trivially secure because it
provides a location limited channel).

Why was the word "override" removed from RFC's 7469 Draft 21? It
appears the effect was to make the interception more obscure. I would
have expected it to go the other way - make it more pronounced to
ensure the risk is noted by architects evaluating the standard.
Putting the word "override" in the title seemed like a more
appropriate action because it has such a negative effect on the
security of the system.

Jeff

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Nov 2015 13:39:48 +0200

> On 12 Nov 2015, at 12:47 PM, Jeffrey Walton <[email-masked]> wrote:
> 

But as you note, the overrides are obscured.

> case" (citing the W3C's Priority of Constituencies)

“consider users over authors over implementors over specifiers over theoretical purity.”
But what are the interests of the users? Many would claim that not having their traffic intercepted is a higher priority. Unfortunately the users don’t participate in either W3C or IETF, so we have others make claims on their behalf.

> ignored as if it does not exist.

But what is the problem? That proxying is possible? That proxying is not visible to the user? That proxying is not visible to the server?  Modifying the certificate does not solve that last one anyway.

> probably find more violations.

Perhaps, but they all boil down to your subject line, that the browser/client cannot tell that the proxy is there without heuristics.

> provides a location limited channel).

What I meant by false positives is that some organizations (corporate, educational or government networks as well as others) deploy their own CA, add this CA to the trust anchor store of devices, and use certificates from this CA for internal servers. A heuristic that marks all certificates not from the public web PKI as “proxied” will inevitably misidentify such internal servers as proxied.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 12 Nov 2015 13:00:46 +0000

> How do we differentiate authentic servers from proxies performing TLS

What would be the point?  You're going to accept a legitimate MitM (e.g., corporate security) and a malicious MitM won't use the extension.

It's more productive to attack the problem of binding *authorities* to sites--e.g., DANE, pinning, &etc.--because that addresses both cases and provides information a client can intelligently act upon.

-- T

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 12 Nov 2015 08:03:28 -0500

> But what are the interests of the users? Many would claim that not having their traffic intercepted is a higher priority. Unfortunately the users don’t participate in either W3C or IETF, so we have…

+1. And I still can't figure out how some in the W3C think its a good
decision to throw away a specific security context, like a known good
pinset, in favor of a less specific security context, like a trust
store override. I argue they are violating the W3C's when they move
from specific to specific to general since the user wanted the more
specific security context.

> But what is the problem? That proxying is possible? That proxying is not visible to the user? That proxying is not visible to the server?  Modifying the certificate does not solve that last one any…

Data has three state: data at rest, data on display, and data in
motion. Interception in general, and PKP overrides in particular,
destroys the third state of data security. The system is no longer
secure, and it likely no longer adheres to its security requirements.

The fact that the app no longer meets requirements is not always a
death knell. Its is probably OK for some applications in some
circumstances, like Gmail. Its probably also OK for financial
transactions in the US because legislation shifted risk off the
user/consumer. Financial institutions are aware of the risk and they
accept it.

But the loss of security is not acceptable in other contexts. The
other contexts include systems handling medium and high value data
(for organizations that classify their data), like executive
compensation, mergers and acquisitions, pending litigation, corporate
strategies, etc. And it is an unacceptable risk for users in countries
like Iran, where dissidents get put to death or are tortured.

The web security folks don't seem to get the last point: the risk
model changed, and the risk is not acceptable for some. One size does
not fit all. Personally, I don't know what I would do if I condoned
the web security model and someone died because of it. I probably
could not bear it - it would eat me up internally until I died.

> Perhaps, but they all boil down to your subject line, that the browser/client cannot tell that the proxy is there without heuristics.

Right, but that's because we don't have what we need to make the
decision. And its only going to get worse with Secure Origins. That's
where the W3C is using Authentication as Authorizations. But the
interception disgorges the assurances provided with the CA/RA vetting,
so there are no assurances that remain in practice. (I'm side stepping
the whole Authentication is not Authorization foasco. The W3C folks
seem set on traveling down the Java Applet path).

Providing addition information would make the heuristics more
accurate, and lead to a better security posture. Here are the use
cases:

   (1) NOT proxied
   (2) Proxied and advertised as proxied
   (3) Proxied and NOT advertised as proxied

(1) is what everyone hopes for.

(2) allows us to make more informed decisions, and allows us to teach
users with simple rules. (2) could become a simple platform wide
policy setting applied to all browser based applications.

If I had (2), then I could tell my mother or brother to forgo the
guest Wifi network and hop on 3G/4G. But that decision has been taken
away from us in pursuit of the "interception is a valid use case"
goal.

(3) is a red herring, and its a sure sign something is wrong, if
detected. if it goes undetected, then we are at the status quo.

The folks who seem to resist providing more information, allowing user
agents to make better decisions and allowing users to make more
informed decisions are those who are promulgating the "interception is
a valid use case" goal. The NSA, GCHQ and friends does not need to
infiltrate an organization since it has unwitting co-conspirators

Or maybe they are the same folks (they say the devil's greatest
deception was convincing folks he does not exist).

Jeff

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 12 Nov 2015 08:09:08 -0500

> What would be the point?  You're going to accept a legitimate MitM (e.g., corporate security) and a malicious MitM won't use the extension.

Actually, I don't. I fail the connection. But I understand your point,
and many folks chose to be intercepted so the ad can get through...

> It's more productive to attack the problem of binding *authorities* to sites--e.g., DANE, pinning, &etc.--because that addresses both cases and provides information a client can intelligently act u…

Actually, the use case I most often encounter is the one where "a
priori" knowledge exists, and we don't really need to turn to DANE,
TOFU pinsets and the like. However, we have to re-use existing
infrastructure, like a TLS channel and web services.

But sure, I'll take whatever security controls I can get my hands on.
As long as they don't provide overrides so the attacker can control
critical security parameters.

Jeff

---

From: [email-masked] (Martin Rex)
Date: Thu, 12 Nov 2015 17:38:10 +0100 (CET)

Miller, Timothy J. wrote:
> What would be the point?  You're going to accept a legitimate MitM
> (e.g., corporate security) and a malicious MitM won't use the extension.

Just for the record, corporate security performing MitM on TLS connections
of human user's browsers is *NOT* legitimate in Europe, it is clearly
*OUTSIDE* of the legal wiggle room of 2002/58/EC for EU member states,
and it has been a criminal offense (up to 5 years in prison)
in Germany since 2004.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 12 Nov 2015 17:21:21 +0000

> and it has been a criminal offense (up to 5 years in prison) in Germany since
> 2004.

Irrelevant; a criminal MitM *still* isn't going to use an extension to identify himself.  

Binding the issuing authority to the name is what's needed, and that's not a certificate content problem.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 12 Nov 2015 17:44:07 +0000

> Actually, the use case I most often encounter is the one where "a priori"
> knowledge exists, and we don't really need to turn to DANE, TOFU pinsets
> and the like. However, we have to re-use existing infrastructure, like a TLS
> channel and web services.

Your original three operative conditions actually degenerates to two:

(1) There's no MitM.
(2) There's a MitM.

Binding authorities to names by any means--including out-of-band--gives you the information to decide which condition you're in.  After that point you have to decide what to do about it.  Binding authorities to names could be addressed in TLS (or HTTP or DNS), but it's not a PKIX problem.  PKIX only addresses namespace restrictions when cross-certification use cases (though MS has adapted those mechanisms for qualified subordination). 

Legitimacy of the MitM is irrelevant at the technical level; legitimacy is a human decision that varies by jurisdiction.  *Identity* of the MitM is relevant because it informs how you would respond.  That's part of the reason why RFC 7469 permits an escape in Sec 2.6 using user-defined trust as the example (which, it should be noted, is exactly how Chrome currently behaves).

-- T

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 12 Nov 2015 13:09:24 -0500

> Irrelevant; a criminal MitM *still* isn't going to use an extension to identify himself.

That's a behavior I would count on to detect them. The one thing these
folks don't want is a spotlight on them. They want to continue to
surreptitiously engage in their practices. Sunlight is the best
disinfectant, as they say.

> Binding the issuing authority to the name is what's needed, and that's not a certificate content problem.

It seems like that's putting the cart before the horse. Getting the
certificate bits right is a Security Engineering 101 issue. Have
whomever declare their intents in advance, and then enforce it. Don't
allow certificates to be arbitrarily re-purposed or used outside their
design parameters. Presuming someone has accepted the risk of
conferring trust to a CAs, then all these problem reduce to (1)
getting the CA installed into a trust store by any means (OEM
preinstall, phishing a user, etc) and then (2) abusing the certificate
bits (operating the system outside its design parameters). We only
need to stop one or the other to break the chain.

Declaring intentions might be as simple as a CA issuing a certificate
with a PROXY usage/bit (if one existed), or it might be an end entity
certificate with the PROXY bit set (if one existed). That could even
include the binding you are talking about - make them declare the
names they are going to proxy in advance. Or it might be something
else.

The system can built upon with higher level logic, like where an
administrative boundary lies, once the foundation is laid. but you
have to have the foundation first. The Red Herrings are all there,
from Saltzer and Schroeder's paper, to Anderson's book, to Guttman's
book. Fix the fundamental problems first and then re-evaluate. Or, fix
the fundamental problems and add the name bindings. Heck, provide all
the names from Zooko's triangle. That gives me 2x or 3x the tools for
my warchest.

One thing I would not count on any time soon is a recommendation on
administrative and/or domain boundaries (and other goodies, like a
list of actionable items). I've been lurking on that list for a year
or two, and it does not feel like something will be delivered in the
near future.

Jeff

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 12 Nov 2015 20:10:48 +0000

> It seems like that's putting the cart before the horse. Getting the certificate
> bits right is a Security Engineering 101 issue. Have whomever declare their
> intents in advance, and then enforce it. Don't allow certificates to be
> arbitrarily re-purposed or used outside their design parameters. 

Nothing about TLS interception is using certs outside their design parameters, or re-purposing a cert.  An intercept MitM creates a valid cert binding a specific name under a new authority.  Whether that authority has the right to claim that name is not something PKIX addresses--that's an enrollment problem and is outside the certificate specification.

You can't fix trust by twiddling certificate bits.

-- T

---

From: "Tom Gindin" <[email-masked]>
Date: Sun, 15 Nov 2015 17:27:21 -0500

Tim:

        One good reason for a separate EKU value for proxies might be to 
let the client invoke a different name matching algorithm, although I see 
no case for changing KeyUsage bits here.  It is reasonable for a client 
inside a proxied network to configure a single proxy name + issuer chain 
that will be accepted in advance.
        Making certificates for this purpose distinguishable from ordinary 
TLS server certificates seems unlikely to encourage the use of such 
proxies in countries where they are forbidden by law.

Tom Gindin, CISSP
P.S.    The opinions above are mine and not necessarily those of my 
employer

From:   "Miller, Timothy J." <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Cc:     PKIX <[email-masked]>
Date:   11/12/2015 03:11 PM
Subject:        Re: [pkix] How do we differentiate authentic servers from 
proxies performing TLS interception?
Sent by:        "pkix" <[email-masked]>

> It seems like that's putting the cart before the horse. Getting the 
certificate
> arbitrarily re-purposed or used outside their design parameters. 

Nothing about TLS interception is using certs outside their design 
parameters, or re-purposing a cert.  An intercept MitM creates a valid 
cert binding a specific name under a new authority.  Whether that 
authority has the right to claim that name is not something PKIX 
addresses--that's an enrollment problem and is outside the certificate 
specification.

-- T
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Miller, Timothy J." <[email-masked]>
Date: Sun, 15 Nov 2015 23:24:07 +0000

>         One good reason for a separate EKU value for proxies might be to let the client invoke a different name matching algorithm, although I see no case for changing KeyUsage bits here.  It is reasonable for a client inside a proxied network to configure a single proxy name + issuer chain that will be accepted in advance.

You'd only need alternative name matching if the proxy actually substitutes its own certificate.  Alternatively the proxy acts as a CA and signs a new certificate on the fly--though they don't typically generate a key--containing the origin server's name and some other specific details from the origin server's certificate.  Implementations I'm familiar with can do either, but usually are deployed as a CA to avoid name matching problems.  

No certificate marking is needed, though.  Clients could invoke alternative certificate processing when a certificate name match fails but the certificate chains to a trust anchor marked as "trusted for proxy."  

-- T

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 15 Nov 2015 22:54:03 -0500

> No certificate marking is needed, though.  Clients could invoke alternative certificate processing when a certificate name match fails but the certificate chains to a trust anchor marked as "truste…
You will have to forgive my ignorance... For user agents and other
software that conforms to RFC 7469 and provides the overrides, how are
they supposed to know when to break a known good pinset if its not
signaled? That is, how do they differentiate between the "good" bad
guys and the "bad" bad guys.

Examples:

  Corporate DLP - ACME, LLC sets Proxy key usage for subordinate
      and server certificate. User agent allows an override to the Pinset
      in accordance with RFC 7469 because they declared the intent and
      confirmed with the user.

  Diginotar - Bad guy starts minting server certificates. Proxy is
      not set in subordinate CA or server certificate. The user agent
      refuses to break the known good pinset according to RFC 7469.

And RFC's 7469 {SHOULD NOT|MUST NOT} logging requirement can be lifted
or refined so the failures can be reported instead of making user
agents complicit in the cover-up.

RFC 7469's overrides opened a can of worms, but its probably best in
the big picture. This stuff has always been going on and allowed to
fester behind the scenes in a "don't ask don't tell" fashion. Now that
its been brought to the fore-front, it can be dealt with accordingly.

Jeff

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Nov 2015 07:25:34 +0200

> On 16 Nov 2015, at 5:54 AM, Jeffrey Walton <[email-masked]> wrote:
> 

Before RFC 7469 (pins in HTTP) there were pre-loaded pins for a select group of servers. The policy of Chrome at the time was to allow “wrong” keys whenever the root of trust was not part of the default set that comes with the operating system. This allowed for trust anchors installed specifically for proxy to sign certificates for mail.google.com. The unfortunate side-effect was that it allowed any corporate CA to also sign such certificates, which it shouldn’t. 

It would be nice if a trust anchor could be marked as “for proxy” vs “just another CA”, but no OS or browser provides that distinction.

Yoav

---

From: "Tom Gindin" <[email-masked]>
Date: Mon, 16 Nov 2015 21:28:58 -0500

You're correct that RFC 5280 section 6 doesn't consider 
extendedKeyUsage as an anchor parameter in the way that it considers 
policies, and that RFC 5914 section 2.5 doesn't either.  However, it's 
probably desirable for the client to specify the issuer level that must be 
within the proxy's chain separately from his primary set of anchors.  If 
my employer has a proxy certified by an intermediate under a large 
commercial CA, I'd rather require that my proxy be certified by my 
employer's intermediate rather than by "some descendant of TrustUS", even 
though my browser trusts any descendant of TrustUS as a server 
certificate.  Being a proxy or an MITM is more intrusive.

Tom Gindin

From:   Yoav Nir <[email-masked]>
To:     [email-masked]
Cc:     PKIX <[email-masked]>
Date:   11/16/2015 12:25 AM
Subject:        Re: [pkix] How do we differentiate authentic servers from 
proxies performing TLS interception?
Sent by:        "pkix" <[email-masked]>

>> No certificate marking is needed, though.  Clients could invoke 
alternative certificate processing when a certificate name match fails but 
the certificate chains to a trust anchor marked as "trusted for proxy."
> its been brought to the fore-front, it can be dealt with accordingly.

Before RFC 7469 (pins in HTTP) there were pre-loaded pins for a select 
group of servers. The policy of Chrome at the time was to allow ?wrong? 
keys whenever the root of trust was not part of the default set that comes 
with the operating system. This allowed for trust anchors installed 
specifically for proxy to sign certificates for mail.google.com. The 
unfortunate side-effect was that it allowed any corporate CA to also sign 
such certificates, which it shouldn?t. 

It would be nice if a trust anchor could be marked as ?for proxy? vs ?just 
another CA?, but no OS or browser provides that distinction.

Yoav

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 16 Nov 2015 21:38:29 -0500

> employer has a proxy certified by an intermediate under a large commercial
> CA, I'd rather require that my proxy be certified by my employer's
> intermediate rather than by "some descendant of TrustUS", even though my
> browser trusts any descendant of TrustUS as a server certificate.  Being a
> proxy or an MITM is more intrusive.

That's not supposed to happen. For the folks that participate in the
CA/B Forums, governance prohibits it.

That's one of the win/win's here. The public CAs are already
conforming, so they don't have to make any procedural or operational
changes.

The proxy bits that show up in a chain will be from a non-public CA,
like an organization's internal PKI. Or an adversary, in which case
its still a win since they have been forced from the shadows. Sunlight
is the best disinfectant.

Jeff

---

From: Tom Ritter <[email-masked]>
Date: Mon, 16 Nov 2015 22:07:52 -0500

>From some of the emails, it sounds like the goal to differentiate a CA
that is going to authenticate some specific set of DNS names (a
private CA that is operating publicly) from a CA that is going to
authenticate potentially all DNS names (interception).  What is the
actual difference between those?

Obviously bad guys can lie. And putting a bit into a certificate does
not magically inform users of the risks they are taking on when they
install a CA.

It's my understanding (and I could be slightly wrong in the details
but I think I'm right in the generality) that Brazil requires you to
install a CA to do some sort of citizenship operation (get a passport?
pay taxes?).

I think the security win here is NOT to put a bit in the certificate
that says "I state I won't do interception" - but leave it perfectly
capable of doing so if it was malicious or compromised... but rather
to put a feature in clients that asks after installation: "Do you
trust [Brazilian CA] to authenticate [taxes.br]?   [Yes, and I trust
it for the entire Internet] [No] [Yes]"  This drives towards marking a
CA for what the user wants to trust it as.

In theory this can be done with Name Constraints, and I like those and
hope they'd be used in conjunction - but in practice constraining
certificates ahead of time in this way is difficult. Telling someone
"Nope, I can't issue a certificate for taxes.brazil.com" doesn't work
out well.

-tom

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 17 Nov 2015 04:33:08 +0000

> guys and the "bad" bad guys.

That would be a user agent problem, solved by user agent configuration.  

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.  

Should I point out the obvious here--that list is MUCH longer than the list of KUs and EKUs put together, yet MS doesn't come looking for a new extension every time they want to restrict use.

I also find it odd that advocates for this extension are uncomfortable with the idea of any active MitM, but are perfectly OK with a commercial issuer controlling whether or not your client accepts a cert they issue for active MitM purposes.

If you're going to require UA configuration to accept the active MitM, then it's far easier to mark the user agent's trust store than it is to add an optional extension to the certificate *AND* require the user agent to process, track, and add a UI for the user when it's found.

Take the path of least resistance (and smallest code change), people.

-- T

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 20 Nov 2015 10:15:52 -0500

> That would be a user agent problem, solved by user agent configuration.

I agree its a problem that can mostly be solved by the user agent.

(And I agree its a problem that users create or contribute to).

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

I don't believe this is a viable solution. There's at least five
reasons it has opportunities for improvement.

(1) Most users likely won't be able to do this. Typical users can
answer YES/NO questions after some basic training. For example,
corporate training teaches "Answer NO to the question, do you want to
proxy the connection". Many users will be able to do this.

(2) Typical users will not be able to configure a trust store because
its too complex a task. Where do they find the information to do it?
Should they be running RegEdit on Windows
(https://support.microsoft.com/en-us/kb/256986)? Or maybe Plist editor
on OS X (https://support.apple.com/en-us/HT202292)? What do they have
on their SmartPhone? Do they have to buy an app?

(2) Some manufactures can't get the trust stores and entitlements
right. If I enforce key usage constraints on my OS X key chain, then
my code signing infrastructure breaks. That is, my Apple developer
account breaks, and other apps ditributed by other developers break.
The best I can tell Apple does not care about fixing it because I
filled the RADAR years ago, yet I experience the same problems today.

(3) PKIX does not provide policy extensions, so there's nothing to add
at the policy level in the context of PKIX. This is a false choice.

(4) Different OIDs will be used by each organization that performs
proxying or interception. There' no way for a "properly configured"
user agent to safely utilize a foreign network (for some reasonable
definition of "properly configured" and "safely"). An example of this
(and the mess it creates) is OIDs identifying EV certificates.

(5) As a standards body, the IETF should provide something standard to
avoid the situation described in (4). That is, after all, one of the
missions of the organization.

> Should I point out the obvious here--that list is MUCH longer than the list of KUs and EKUs put together, yet MS doesn't come looking for a new extension every time they want to restrict use.

Its also obvious that the distinction between "genuine" server
authentication and "proxied" or "intercepted" server authentication is
substantial, and and not trivial. Its about as distinct as Sever
Authentication and Code Signing. (I'm not sure " "intercepted" server
authentication" is a real thing. Its a lot like "encrypting with the
private key" many novices try to do in cryptography).

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

> I also find it odd that advocates for this extension are uncomfortable with the idea of any active MitM, but are perfectly OK with a commercial issuer controlling whether or not your client accepts…

Actually, NO. The commercial CAs governance does *NOT* allow them to
issue such certificates, and its codified in their Certification
Practice Statement (CPS). I'm told the CPS is legaly binding in some
jurisdictions.

There is some hand waiving, however. A company that's part of a Root
CA program could do it as a Subordinate because the RA was discarded
(i.e., the independent, third party auditor). The net effect is
relying parties have lost all practical assurances.

> If you're going to require UA configuration to accept the active MitM...

The status quo, which PKIX is a part of, ensures a user and their
agent are subject to unwanted proxying and interception. Just about
anything we do is an improvement over what's happening now.

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.

> then it's far easier to mark the user agent's trust store than it is to add an optional extension to the certificate *AND* require the user agent to process, track, and add a UI for the user when it's found.

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

Declarative security and in-band signalling ensures the user and his
software know what to expect in the common case, which means a user
can make an informed choice.

And in-band signalling is surely least disruptive since it does not
affect Public CAs or existing middleware boxes that perform it. Public
CAs will do nothing (they don't issue them); and those using
middleware boxes will only need to generate a new CA or intermediate
that get installed or served with the chain (middleware boxes don't
interpret the bits).

I also understand the "bad" bad guys will move to declaring the usage,
too - just like they adapted to HTTPS from HTTP. But again, they have
been moved from the shadows into the light, and they will be easier to
contend with. You have a lot of good ideas to further reduce the risk.

Jeff

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 23 Nov 2015 02:17:17 +0000

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

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

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

> 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?  

> 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

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 24 Nov 2015 13:04:06 -0500

> 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 veri…

OK, thanks Tim.

So let me wrap this up... What is the IETF and/or PKIX going to
provide us with to discern between authentic servers and
proxied/intercepted connections now that Public Key Pinning with
Overrides is here?

What do I tell my developers?

Jeff

---

From: Peter Bowen <[email-masked]>
Date: Tue, 24 Nov 2015 12:40:54 -0800

> What do I tell my developers?

I'm a little lost.  What are you trying to achieve?  Assuming your
developers are writing a client app, I see several scenarios:

1) You have a client application relying on a shared trust store.  The
proxy is configured to issue certificates signed by something in the
trust store.  In this case validation works as normal.

2) Validation passes, but there are additional post-validation
constraints validation info (e.g PKP).  The constraints fail. In this
case, you check the trust store to see if the CA signing the cert is a
"system" CA or a "user" CA.  If user, ignore PKP.

3) You have a client app that has its own trust store.  The proxy's
certificate is not signed by a CA in your list.  Validation fails.

4) The proxy is signing with an unknown certificate.  Validation fails.

In none of the scenarios does it help to have a flag for 'this is a
proxy'.   The only place it would help is if you wanted to only allow
overrides where the User CA explicitly indicated it was trying to
override.  However I can't imagine when the CA would not set this.

Thanks,
Peter

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 24 Nov 2015 17:35:55 -0500

> developers are writing a client app, I see several scenarios:

We are trying to determine when to break a known good pinset for those
who provide a conforming user agent.

Its still not clear to me how to determine the "good" bad guys from
the "bad" bad guys.

Jeff

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 30 Nov 2015 13:26:03 +0000

> Its still not clear to me how to determine the "good" bad guys from the "bad"
> bad guys.

You can't.  That's not information you can encode because the definitions change with different perspectives.  Consider an intercept performed by a government agency: a government supporter may consider this acceptable, whereas a political dissident may consider it unacceptable.  

Your choices are to either fail closed, i.e., don't allow breaking the pinset under any conditions, or to pick some rubric by which breaking a pinset is allowed. Chrome's current implementation--discarding a pinset when the presented certificate chains to a locally installed trust anchor--is one example but by no means the only possibility.

If I were to offer any advice, I would urge you to implement a clear UI that informs the user when a pinset bas been discarded no matter what other choice you make.

-- T