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

Jeffrey Walton <noloader@gmail.com> Thu, 12 November 2015 10:47 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 6CF901B2EED for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 02:47:57 -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 DbklKTyS1Glu for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 02:47:56 -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 E9E541B2EEB for <pkix@ietf.org>; Thu, 12 Nov 2015 02:47:55 -0800 (PST)
Received: by igcph11 with SMTP id ph11so90814712igc.1 for <pkix@ietf.org>; Thu, 12 Nov 2015 02:47:55 -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=/ThOoD8Zk5GTM9DtGDmSFw0HkduuH4zjwyZjy53W5Vk=; b=P+s1wxf0wXPGafvplsb197tgrc14GNanVTV+T+zsvhaJh1rT3vy7kOUKwKHKOohnIG +qPiYW0pmDuxNSNvrsBEWRTvmK3Ukg6RHarNgmRKlv8ZPY+4ZQhKIi1nXKeeWdiXqqan nPtdDxa05dlA9hO3LiE0MaIIHzSdiGzb19FuDHUm5IJXSseyAFApnC6Du6Cr+5+rRnME B25SaIg7So6Wc92xx7GmqEHxwj2+lasolQBlXL0LvWTg2wVxjVIbUXlto9Xk3F6x2lY4 kGmURdwHfnsKlTNAaGcfCzl01UuhRjmKA02ttB3uPomx/AHdLV7543ewUPLdWOxzp731 d5nA==
MIME-Version: 1.0
X-Received: by 10.50.155.41 with SMTP id vt9mr34208176igb.22.1447325275318; Thu, 12 Nov 2015 02:47:55 -0800 (PST)
Received: by 10.36.108.3 with HTTP; Thu, 12 Nov 2015 02:47:55 -0800 (PST)
In-Reply-To: <B5236D74-4492-4B9E-9A0D-EBC48EA12A0D@gmail.com>
References: <CAH8yC8=7YP-p=fEL4nFdemiiqU7wm=y7Um=PGgR0=ZbH=mNemQ@mail.gmail.com> <B5236D74-4492-4B9E-9A0D-EBC48EA12A0D@gmail.com>
Date: Thu, 12 Nov 2015 05:47:55 -0500
Message-ID: <CAH8yC8nw-7nZfxv=UhzGxfGfYfDKDJFQUp0pNQ8auEFzdby5BA@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/OC9YhCKKFLhhJYoTa6WmLhYrux4>
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 10:47:57 -0000

>> I've been through RFC 5280 and 6125 looking for a treatment of the
>> subject matter, but I could not find it. I would expect it to show up
>> somewhere, like KU or EKU, but the bits appear to be missing.
>>
>> How do we differentiate authentic servers from proxies performing TLS
>> interception?
>
> There is no way to mark a certificate as an “interception" (or “proxy” or “fake”) certificate. Attempts to mark either the certificate or the TLS handshake were not successful in the IETF, because we do not facilitate interception in protocols, lawful or otherwise.

Thanks Yoav, that's interesting. I thought that too until RFC 7469
came along and got approved with the overrides.

Now that the IETF has provided a standard with the overrides, maybe
its time to revisit the previous decision. There are a few reasons:

* The dominate RFC 7469 players claim "interception is a valid use
case" (citing the W3C's Priority of Constituencies)
* Its a real-life problem, and not a theoretical one. It can't be
ignored as if it does not exist.
* Reusing key bits for both server authentication and
proxying/interception violates secure design and architecture. Its a
deep, fundamental flaw.

I'm particular bothered by the third item. Reusing the KU/EKU bits
violates at least three of the secure design principals outlined by
Saltzer and Schroeder's "The Protection of Information in Computer
Systems". More informed readers (like you, DKG, Guttman, etc), can
probably find more violations.

> The heuristic employed by some browsers and alluded to in section 2.6 of RFC 7469 is to treat certificates that chain to a trust anchor that did not come pre-installed with the operating system or browser as interception certificates, but this heuristic is only valid in the context of key pinning - it would generate too many false positives in general use.

It almost sounds like they are trying to get half pregnant...

Regarding false positives, I've found the opposite. We have
implemented Guttman's security diversification techniques in a few
libraries and products, and they are almost always spot-on. The trick
is we need a secure distribution channel to keep a handful of security
parameters up-to-date. All the App stores claim to have one, so we are
in a good position (and side-loading is trivially secure because it
provides a location limited channel).

Why was the word "override" removed from RFC's 7469 Draft 21? It
appears the effect was to make the interception more obscure. I would
have expected it to go the other way - make it more pronounced to
ensure the risk is noted by architects evaluating the standard.
Putting the word "override" in the title seemed like a more
appropriate action because it has such a negative effect on the
security of the system.

Jeff