IETF Logo Mail Archive

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

"Miller, Timothy J." <tmiller@mitre.org> Thu, 12 November 2015 20:10 UTC

Return-Path: <tmiller@mitre.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35E61B3443 for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 12:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O9ndLtzo_Ty for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 12:10:51 -0800 (PST)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4341B3442 for <pkix@ietf.org>; Thu, 12 Nov 2015 12:10:51 -0800 (PST)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E8726C00A6; Thu, 12 Nov 2015 15:10:51 -0500 (EST)
Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 00D096C0015; Thu, 12 Nov 2015 15:10:51 -0500 (EST)
Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 12 Nov 2015 15:10:50 -0500
Received: from na01-bl2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Thu, 12 Nov 2015 15:10:50 -0500
Received: from BY2PR09MB109.namprd09.prod.outlook.com (10.242.36.149) by BY2PR09MB111.namprd09.prod.outlook.com (10.242.36.19) with Microsoft SMTP Server (TLS) id 15.1.318.15; Thu, 12 Nov 2015 20:10:49 +0000
Received: from BY2PR09MB109.namprd09.prod.outlook.com ([10.242.36.149]) by BY2PR09MB109.namprd09.prod.outlook.com ([10.242.36.149]) with mapi id 15.01.0318.003; Thu, 12 Nov 2015 20:10:49 +0000
From: "Miller, Timothy J." <tmiller@mitre.org>
To: "noloader@gmail.com" <noloader@gmail.com>
Thread-Topic: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
Thread-Index: AQHRHSZik1bCWQTVykKbY4mwcvoviJ6YWKZQgAA+FQCAAAsmwIAADlcAgAAW2IA=
Date: Thu, 12 Nov 2015 20:10:48 +0000
Message-ID: <BY2PR09MB10945A7D32E11E8C5E74750AE120@BY2PR09MB109.namprd09.prod.outlook.com>
References: <BY2PR09MB1094EA71ADDC83440AE82F2AE120@BY2PR09MB109.namprd09.prod.outlook.com> <20151112163810.E8F351A368@ld9781.wdf.sap.corp> <BY2PR09MB109B9B70BC1746B516CB335AE120@BY2PR09MB109.namprd09.prod.outlook.com> <CAH8yC8n41uA-Aj3pLKRHgjGu1P6smwG-r-dA595rXHMjhAZC_A@mail.gmail.com>
In-Reply-To: <CAH8yC8n41uA-Aj3pLKRHgjGu1P6smwG-r-dA595rXHMjhAZC_A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tmiller@mitre.org;
x-originating-ip: [192.160.51.86]
x-microsoft-exchange-diagnostics: 1; BY2PR09MB111; 5:w6IwhX/7N+WQU9EZTUp1qzFsA4QVA0KPzYBJNOcI+2XkngH55d2xHqvZ5KF9c8M+BrAI7tqcM6A7cf1rGswINvhHwC0/+LUCj+JesO+X3Pylqf1SM15PFjE7c3rmNVo6yqtkkxqQELDZDQdwiKsvNQ==; 24:kei7SifTMejYAjs7tPuBTrU4tUV2Ph7ahWGGfWNqWHoUssYytxsweCTy73VI/Kzy6FvbBTrou/BRacKuIy/dUKVxXE8qln/qcZqvz59XTdg=; 20:OEYDfhmygMPLxBty80RHTEV+G3vdwr5EvSaO/TkztL+bwJvPQTCVNJzdhg/vBxFGL47BNzVS0KzCGfLR8EEMzw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB111;
x-microsoft-antispam-prvs: <BY2PR09MB111C80D80D8AB19D1456D72AE120@BY2PR09MB111.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:BY2PR09MB111; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB111;
x-forefront-prvs: 07584EDBCD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(105586002)(5004730100002)(11100500001)(86362001)(2900100001)(102836002)(2950100001)(77096005)(110136002)(2501003)(97736004)(1411001)(93886004)(5008740100001)(5001960100002)(5002640100001)(81156007)(5001920100001)(99286002)(106356001)(92566002)(87936001)(5003600100002)(40100003)(2351001)(122556002)(5007970100001)(189998001)(76176999)(54356999)(66066001)(74316001)(101416001)(50986999)(76576001)(10400500002)(33656002)(106116001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB111; H:BY2PR09MB109.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: mitre.org 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 20:10:48.9226 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB111
X-OriginatorOrg: mitre.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/vi_--iCLHhjkj77HOu07qvjC7S4>
Cc: PKIX <pkix@ietf.org>
Subject: Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2015 20:10:53 -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

v2.23.0 | Report a Bug | By Email