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

Jeffrey Walton <noloader@gmail.com> Tue, 17 November 2015 02:38 UTC

Return-Path: <noloader@gmail.com>
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 9EF7A1ACD57 for <pkix@ietfa.amsl.com>; Mon, 16 Nov 2015 18:38:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 fNnDnCyVy3Sp for <pkix@ietfa.amsl.com>; Mon, 16 Nov 2015 18:38:30 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7534F1ACD54 for <pkix@ietf.org>; Mon, 16 Nov 2015 18:38:30 -0800 (PST)
Received: by igvi2 with SMTP id i2so88608612igv.0 for <pkix@ietf.org>; Mon, 16 Nov 2015 18:38:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pewajvr3Tgc88RP/B45lQdS2HQbgG36kV4dwYw1Z7Mw=; b=qGYGANKAx/FSLPHjdq7dkt6mcRYYiDYOJmuGGObkB+lLp9rSq8Z/z/Idmyc+xe6V2N mOSvvW4lLhPJwxyvB5Noqw6whwUYopcuJAJIGCRmsOfxSyNRuYY0cS0QlfXsm3B/bKvn YxNEFXyL++eVMxGXvpedEyZRFJFeKdYiTUoXUyFVeNhCjL9ZIK6blWRU6uux6CsksAh6 ktfdGlNCLs9PsJ3S6OoEK22SE7xBEeZO4lBdQjQBqfCyHSCISjfazSx3XKZAdB4jpZvc jLd2rTI0gx0387+u4eTNjV+RrVXmrspMHvk9ZpGUZnvINeU9ioCdguJZIlAlsLPFg3Vz 4/iw==
MIME-Version: 1.0
X-Received: by 10.50.155.106 with SMTP id vv10mr18153442igb.36.1447727909879; Mon, 16 Nov 2015 18:38:29 -0800 (PST)
Received: by 10.36.108.3 with HTTP; Mon, 16 Nov 2015 18:38:29 -0800 (PST)
In-Reply-To: <201511170229.tAH2T5WK014541@d03av03.boulder.ibm.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> <BY2PR09MB10945A7D32E11E8C5E74750AE120@BY2PR09MB109.namprd09.prod.outlook.com> <201511152227.tAFMRTjH000463@d01av04.pok.ibm.com> <6ADE63A8-8B81-48F5-BF37-F91B734935C3@mitre.org> <CAH8yC8=XK12R=ox=Uw2jYyk_z0ukB4nbpeVbiyb-ZGOKMSskFQ@mail.gmail.com> <C4D1A2CB-4CF1-4E4F-A0BC-6417634F100F@gmail.com> <201511170229.tAH2T5WK014541@d03av03.boulder.ibm.com>
Date: Mon, 16 Nov 2015 21:38:29 -0500
Message-ID: <CAH8yC8kMwmz_w1Y-Tz6B_0ia5wyoVeti3sLwr_2mmRKAOMFPww@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Tom Gindin <tgindin@us.ibm.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/1B-rC9ICWeml9edlUVkdbIsrEzc>
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
Reply-To: noloader@gmail.com
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: Tue, 17 Nov 2015 02:38:31 -0000

> 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