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

"Miller, Timothy J." <> Mon, 23 November 2015 02:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 80C8A1B2D84 for <>; Sun, 22 Nov 2015 18:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.886
X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hPyi1wBSdVvL for <>; Sun, 22 Nov 2015 18:17:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A74681B2D82 for <>; Sun, 22 Nov 2015 18:17:21 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id F0ECD6C08FC; Sun, 22 Nov 2015 21:17:20 -0500 (EST)
Received: from imshyb02.MITRE.ORG ( []) by (Postfix) with ESMTP id E22296C08FB; Sun, 22 Nov 2015 21:17:20 -0500 (EST)
Received: from imshyb01.MITRE.ORG ( by imshyb02.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sun, 22 Nov 2015 21:17:20 -0500
Received: from ( by imshyb01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Sun, 22 Nov 2015 21:17:20 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 23 Nov 2015 02:17:17 +0000
Received: from ([]) by ([]) with mapi id 15.01.0331.019; Mon, 23 Nov 2015 02:17:17 +0000
From: "Miller, Timothy J." <>
To: "" <>
Thread-Topic: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
Date: Mon, 23 Nov 2015 02:17:17 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BY2PR09MB109; 5:30S771Yd2KQSNE2TTSSX+R5JBEjOpBMaOJDDZbpPdcDk1fmAi8yqwT/my0oir1SabSOrRRACg9uS0kMLmGMcySNj6JAZgnnH+Vq5zGvTsfIZUOd0KkHq5TW34IHvMl7RBYJUN4U7k+Bq7OchqVHyaw==; 24:T3oxrLAqNdJYkBiK9LtUKG6Kt7Iog8l29NWmPsy3l+8r/jpx5y46+FfsYhPbjqN5wC7V4jrXAPxdGYZfv653kc8LL6BlT2OfmOsiYX0JwBY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB109;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BY2PR09MB109; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB109;
x-forefront-prvs: 07697999E6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(52314003)(189002)(199003)(33656002)(93886004)(10400500002)(5007970100001)(2501003)(5002640100001)(5004730100002)(97736004)(110136002)(11100500001)(5001920100001)(99286002)(5001960100002)(106116001)(5008740100001)(19580395003)(105586002)(50986999)(66066001)(106356001)(76176999)(87936001)(81156007)(102836003)(2950100001)(77096005)(2900100001)(54356999)(86362001)(40100003)(36756003)(101416001)(92566002)(6116002)(586003)(83716003)(3846002)(122556002)(1411001)(189998001)(82746002)(2351001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB109;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2015 02:17:17.0536 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB109
Archived-At: <>
Cc: PKIX <>
Subject: Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Nov 2015 02:17:23 -0000

>> 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 (by dint of there being a valid chain from a cert asserting the name, 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