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

Jeffrey Walton <noloader@gmail.com> Mon, 16 November 2015 03:54 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 0D52C1B2B1D for <pkix@ietfa.amsl.com>; Sun, 15 Nov 2015 19:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.499
X-Spam-Level:
X-Spam-Status: No, score=0.499 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, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no
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 WqIpL1n4Nw0N for <pkix@ietfa.amsl.com>; Sun, 15 Nov 2015 19:54:04 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 B8FA21B2B1C for <pkix@ietf.org>; Sun, 15 Nov 2015 19:54:04 -0800 (PST)
Received: by igcph11 with SMTP id ph11so49527432igc.1 for <pkix@ietf.org>; Sun, 15 Nov 2015 19:54:04 -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=3NQ091AfRnU4B+ckXYbQ7JGzr2Sctgyyb5ftCwa7wFw=; b=ateI7xY7f1dxwnQMUPGKptm4st3I88HBuIVlp9UBNkuhjth5WqPqghJMFbrQKm/2E4 YBCnsWftb0p0eqO5M8LebZYWVHvINxt9/Xax37UT5z0VES/5LtFlvXK5qvFuLNjLMTlE x6fgMma5lps04//XnsbTvN2i/t/WkK8vOkUnikabx8Vc8rD7L9I+TDWizGwhk97J27hj 0ehBx7jhkHv2xGJVXlnDiEDoKvxhBIePL2uuOkR+JHG50CSoSXx5oB9fkgwZ/UTOEHfY GhoK9rqHungU3GKlrCM8pmrrrYglHfsAE+wzaUSBDC/lw9bnij8I4hPz8mw4scyshWnb mYDQ==
MIME-Version: 1.0
X-Received: by 10.50.59.211 with SMTP id b19mr11295780igr.36.1447646044040; Sun, 15 Nov 2015 19:54:04 -0800 (PST)
Received: by 10.36.108.3 with HTTP; Sun, 15 Nov 2015 19:54:03 -0800 (PST)
In-Reply-To: <6ADE63A8-8B81-48F5-BF37-F91B734935C3@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>
Date: Sun, 15 Nov 2015 22:54:03 -0500
Message-ID: <CAH8yC8=XK12R=ox=Uw2jYyk_z0ukB4nbpeVbiyb-ZGOKMSskFQ@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/u31tWl0d6Hros_Aqp87GUcfhe1A>
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: Mon, 16 Nov 2015 03:54:06 -0000

> No certificate marking is needed, though.  Clients could invoke alternative certificate processing when a certificate name match fails but the certificate chains to a trust anchor marked as "trusted for proxy."
>
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.

Examples:

  Corporate DLP - ACME, LLC sets Proxy key usage for subordinate
      and server certificate. User agent allows an override to the Pinset
      in accordance with RFC 7469 because they declared the intent and
      confirmed with the user.

  Diginotar - Bad guy starts minting server certificates. Proxy is
      not set in subordinate CA or server certificate. The user agent
      refuses to break the known good pinset according to RFC 7469.

And RFC's 7469 {SHOULD NOT|MUST NOT} logging requirement can be lifted
or refined so the failures can be reported instead of making user
agents complicit in the cover-up.

RFC 7469's overrides opened a can of worms, but its probably best in
the big picture. This stuff has always been going on and allowed to
fester behind the scenes in a "don't ask don't tell" fashion. Now that
its been brought to the fore-front, it can be dealt with accordingly.

Jeff