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

Jeffrey Walton <noloader@gmail.com> Thu, 12 November 2015 18:09 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 32E4B1B2C0B for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 10:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hsnQqJGSujsf for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 10:09:25 -0800 (PST)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 83A0E1B2BEB for <pkix@ietf.org>; Thu, 12 Nov 2015 10:09:25 -0800 (PST)
Received: by igl9 with SMTP id 9so102992142igl.0 for <pkix@ietf.org>; Thu, 12 Nov 2015 10:09:25 -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=XJh1Hj9QU9XrVZqzO7CyocFaHyjVs7w2miIf4VghgRA=; b=DRnbL8m4nMbp4LnJzuTTDJywYmr9mKYtcep5ksdKwdColpxRuw8Vl+1K9ZGZIigdLl vxVarD/4j+IIZ/5/dvtxZ3tSAvJF/D/4slWdNy4fp/1fuHeD/BLmG3Zcj63QLQlDFh7H 5uoTFL0HphtS5ISw1KbJalzXJ3x7ZGzgWCEOpMkN4l+LltQUNfpcInuYFl/GYOxCrW5v 28UU6PGPm73a97lMCLwL/naz9IdQdEcJZCHiRmaaI+ZiCi4tjlVAAuLTdEHsDkGE5PzE ZN9XMRE57pHNiDq4FUOYQSMIcQL92hyY+iPl9gsISGcJ+QXE5Buay9gq3MdEvNmeoU5m 9GBQ==
MIME-Version: 1.0
X-Received: by 10.50.30.73 with SMTP id q9mr5440752igh.46.1447351764963; Thu, 12 Nov 2015 10:09:24 -0800 (PST)
Received: by 10.36.108.3 with HTTP; Thu, 12 Nov 2015 10:09:24 -0800 (PST)
In-Reply-To: <BY2PR09MB109B9B70BC1746B516CB335AE120@BY2PR09MB109.namprd09.prod.outlook.com>
References: <BY2PR09MB1094EA71ADDC83440AE82F2AE120@BY2PR09MB109.namprd09.prod.outlook.com> <20151112163810.E8F351A368@ld9781.wdf.sap.corp> <BY2PR09MB109B9B70BC1746B516CB335AE120@BY2PR09MB109.namprd09.prod.outlook.com>
Date: Thu, 12 Nov 2015 13:09:24 -0500
Message-ID: <CAH8yC8n41uA-Aj3pLKRHgjGu1P6smwG-r-dA595rXHMjhAZC_A@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: "Miller, Timothy J." <tmiller@mitre.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/MEh-o9why258bNJltSTCBIfNz-c>
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: Thu, 12 Nov 2015 18:09:27 -0000

On Thu, Nov 12, 2015 at 12:21 PM, Miller, Timothy J. <tmiller@mitre.org> wrote:
>> 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.
>
> 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