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

"Miller, Timothy J." <> Thu, 12 November 2015 17:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A5E351B2B05 for <>; Thu, 12 Nov 2015 09:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qcpm64P_2zlD for <>; Thu, 12 Nov 2015 09:44:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6DAF91B2AFC for <>; Thu, 12 Nov 2015 09:44:10 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id E4B5F6C00D6; Thu, 12 Nov 2015 12:44:09 -0500 (EST)
Received: from imshyb01.MITRE.ORG ( []) by (Postfix) with ESMTP id D83E46C00C3; Thu, 12 Nov 2015 12:44:09 -0500 (EST)
Received: from imshyb01.MITRE.ORG ( by imshyb01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 12 Nov 2015 12:44:09 -0500
Received: from ( by imshyb01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Thu, 12 Nov 2015 12:44:09 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.318.15; Thu, 12 Nov 2015 17:44:08 +0000
Received: from ([]) by ([]) with mapi id 15.01.0318.003; Thu, 12 Nov 2015 17:44:08 +0000
From: "Miller, Timothy J." <>
To: "" <>
Thread-Topic: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
Thread-Index: AQHRHSZik1bCWQTVykKbY4mwcvoviJ6YWKZQgAADrgCAAEbc4A==
Date: Thu, 12 Nov 2015 17:44:07 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BY2PR09MB112; 5:iEbFm3TbR9fQ18pxIaA31om2nM5/9o4Mv5BkyAhgkEeIO2gC2+PXTqv8bje0QmADXuHKhvQVGoSmog46e9T7yNYB7+VcQK7gAvLHAKUDtCCn6bz+zzcxh4wHVmn4BhGrpXYipsofyGqnTODwcTxigA==; 24:kvVa8G5fuy5+phVY55EKCy24yaowVQtikpnS9k4kvomcxWJDnfNTvD90hmGd8j8gDJVLkhd2Oh2aQ9/i5ShIy9Y2WNECh5xCIvRo5/iBGeI=; 20:cHNKuW+L0CS2RD5DxQ40YkX9rgzxBoWWvNjv2qbbRDa5cEhOTrhrO29JAv0AwsFfSoJNtO1ZYDLmb+1vW9q8ZA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB112;
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)(10201501046)(3002001); SRVR:BY2PR09MB112; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB112;
x-forefront-prvs: 07584EDBCD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(2950100001)(5004730100002)(92566002)(33656002)(76176999)(74316001)(2351001)(5003600100002)(50986999)(106116001)(66066001)(54356999)(87936001)(76576001)(101416001)(105586002)(40100003)(106356001)(11100500001)(1411001)(10400500002)(2501003)(77096005)(2900100001)(5001920100001)(5007970100001)(102836002)(5001960100002)(122556002)(5008740100001)(97736004)(99286002)(81156007)(189998001)(5002640100001)(110136002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB112;; 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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2015 17:44:07.6053 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB112
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: Thu, 12 Nov 2015 17:44:11 -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