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
- [pkix] How do we differentiate authentic servers … Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Yoav Nir
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Yoav Nir
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Miller, Timothy J.
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Martin Rex
- Re: [pkix] How do we differentiate authentic serv… Miller, Timothy J.
- Re: [pkix] How do we differentiate authentic serv… Miller, Timothy J.
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Miller, Timothy J.
- Re: [pkix] How do we differentiate authentic serv… Tom Gindin
- Re: [pkix] How do we differentiate authentic serv… Miller, Timothy J.
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Yoav Nir
- Re: [pkix] How do we differentiate authentic serv… Tom Gindin
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Tom Ritter
- Re: [pkix] How do we differentiate authentic serv… Miller, Timothy J.
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Miller, Timothy J.
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Peter Bowen
- Re: [pkix] How do we differentiate authentic serv… Jeffrey Walton
- Re: [pkix] How do we differentiate authentic serv… Miller, Timothy J.