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

Jeffrey Walton <noloader@gmail.com> Fri, 20 November 2015 15:15 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 31AAE1B327B for <pkix@ietfa.amsl.com>; Fri, 20 Nov 2015 07:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 L9gG-iSQzlIw for <pkix@ietfa.amsl.com>; Fri, 20 Nov 2015 07:15:53 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 222971B3265 for <pkix@ietf.org>; Fri, 20 Nov 2015 07:15:53 -0800 (PST)
Received: by igcph11 with SMTP id ph11so12640894igc.1 for <pkix@ietf.org>; Fri, 20 Nov 2015 07:15:52 -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:content-transfer-encoding; bh=BsPl1gzyYBuomrIAEFHhYdEQj4OZIGVxS4wP984qXCQ=; b=GB+tnba1dKLxsn392R0ApjXO8YzRXUitApU0l/6US+HH+z1siLRMwrX+39TAfOQoIC o4EQyYldRCLxhSa2rQ3ijjEr8ht3Q6BSvuRqKtUAcNtyXx6ovGNaJfoHXXRB6Ow3o//y 8YqmSx2K9ZqiOwiAtVSrp1Xm9plY1iK83SyuK2zGGl1gg/3EjAjf/nHDlV8LVmzTJk+e c/jUlpVqx59dIYG+5kjpjtpuEPI7CpxwX2Xi4R54r0cvsCi3RnT7siDzx3jSnlF8YHb8 z0ifB3Jontc/r6gjJe9jwUOxBF/bafT4UDeVh7kIo4XI27a7jBcx2kgJ+rPsvjsNBjT+ lHeQ==
MIME-Version: 1.0
X-Received: by 10.50.155.106 with SMTP id vv10mr2147116igb.36.1448032552312; Fri, 20 Nov 2015 07:15:52 -0800 (PST)
Received: by 10.36.108.3 with HTTP; Fri, 20 Nov 2015 07:15:52 -0800 (PST)
In-Reply-To: <5E42AC43-684C-4CCE-900C-1CD20E88267F@mitre.org>
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> <5E42AC43-684C-4CCE-900C-1CD20E88267F@mitre.org>
Date: Fri, 20 Nov 2015 10:15:52 -0500
Message-ID: <CAH8yC8mk7MnFa34507-z_ERZFba675bQ+VR-wrreC8w2O=-LHg@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: "Miller, Timothy J." <tmiller@mitre.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/9Oiy3uHPQd1KmRDp9WXdWgnrKoQ>
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: Fri, 20 Nov 2015 15:15:55 -0000

On Mon, Nov 16, 2015 at 11:33 PM, Miller, Timothy J. <tmiller@mitre.org> wrote:
>> You will have to forgive my ignorance... For user agents and other
>> software that conforms to RFC 7469 and provides the overrides, how are
>> they supposed to know when to break a known good pinset if its not
>> signaled? That is, how do they differentiate between the "good" bad
>> guys and the "bad" bad guys.
>
> That would be a user agent problem, solved by user agent configuration.

I agree its a problem that can mostly be solved by the user agent.

(And I agree its a problem that users create or contribute to).

> 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.

(1) Most users likely won't be able to do this. Typical users can
answer YES/NO questions after some basic training. For example,
corporate training teaches "Answer NO to the question, do you want to
proxy the connection". Many users will be able to do this.

(2) Typical users will not be able to configure a trust store because
its too complex a task. Where do they find the information to do it?
Should they be running RegEdit on Windows
(https://support.microsoft.com/en-us/kb/256986)? Or maybe Plist editor
on OS X (https://support.apple.com/en-us/HT202292)? What do they have
on their SmartPhone? Do they have to buy an app?

(2) Some manufactures can't get the trust stores and entitlements
right. If I enforce key usage constraints on my OS X key chain, then
my code signing infrastructure breaks. That is, my Apple developer
account breaks, and other apps ditributed by other developers break.
The best I can tell Apple does not care about fixing it because I
filled the RADAR years ago, yet I experience the same problems today.

(3) PKIX does not provide policy extensions, so there's nothing to add
at the policy level in the context of PKIX. This is a false choice.

(4) Different OIDs will be used by each organization that performs
proxying or interception. There' no way for a "properly configured"
user agent to safely utilize a foreign network (for some reasonable
definition of "properly configured" and "safely"). An example of this
(and the mess it creates) is OIDs identifying EV certificates.

(5) As a standards body, the IETF should provide something standard to
avoid the situation described in (4). That is, after all, one of the
missions of the organization.

> Should I point out the obvious here--that list is MUCH longer than the list of KUs and EKUs put together, yet MS doesn't come looking for a new extension every time they want to restrict use.

Its also obvious that the distinction between "genuine" server
authentication and "proxied" or "intercepted" server authentication is
substantial, and and not trivial. Its about as distinct as Sever
Authentication and Code Signing. (I'm not sure " "intercepted" server
authentication" is a real thing. Its a lot like "encrypting with the
private key" many novices try to do in cryptography).

Also, Microsoft did not reuse exiting bits like PKIX has promoted.
Microsoft provide policy extensions, which PKIX does not have.

> I also find it odd that advocates for this extension are uncomfortable with the idea of any active MitM, but are perfectly OK with a commercial issuer controlling whether or not your client accepts a cert they issue for active MitM purposes.

Actually, NO. The commercial CAs governance does *NOT* allow them to
issue such certificates, and its codified in their Certification
Practice Statement (CPS). I'm told the CPS is legaly binding in some
jurisdictions.

There is some hand waiving, however. A company that's part of a Root
CA program could do it as a Subordinate because the RA was discarded
(i.e., the independent, third party auditor). The net effect is
relying parties have lost all practical assurances.

> If you're going to require UA configuration to accept the active MitM...

The status quo, which PKIX is a part of, ensures a user and their
agent are subject to unwanted proxying and interception. Just about
anything we do is an improvement over what's happening now.

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.

> then it's far easier to mark the user agent's trust store than it is to add an optional extension to the certificate *AND* require the user agent to process, track, and add a UI for the user when it's found.

I fail to see how declarative security and in-band signalling is *not*
the most direct path here.

Declarative security and in-band signalling ensures the user and his
software know what to expect in the common case, which means a user
can make an informed choice.

And in-band signalling is surely least disruptive since it does not
affect Public CAs or existing middleware boxes that perform it. Public
CAs will do nothing (they don't issue them); and those using
middleware boxes will only need to generate a new CA or intermediate
that get installed or served with the chain (middleware boxes don't
interpret the bits).

I also understand the "bad" bad guys will move to declaring the usage,
too - just like they adapted to HTTPS from HTTP. But again, they have
been moved from the shadows into the light, and they will be easier to
contend with. You have a lot of good ideas to further reduce the risk.

Jeff