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

Tom Ritter <> Tue, 17 November 2015 03:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E8CAC1ACDC2 for <>; Mon, 16 Nov 2015 19:08:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.52
X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id INljHNOAW4GR for <>; Mon, 16 Nov 2015 19:08:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7BBD1ACDBD for <>; Mon, 16 Nov 2015 19:08:12 -0800 (PST)
Received: by qgea14 with SMTP id a14so64034279qge.0 for <>; Mon, 16 Nov 2015 19:08:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=5JaXyH1aDwdNHErib5BdaSPX4bKAni7hGyqUgAsXJco=; b=ZELM2hIgfNT4Y5SjGozTza1WjLcQBcp4y4KK5qQL+z/HaXCdgPcy/FMWtJ1LbswAnr bjC4g2FMXzWGz3ZTGwUvtZzExTlMiQEIie73JjMFa96ExI/ksIq/MqRR4KZIcluWMdbi D+UM3PKudNpY5KFxDGHWNMbAeSu3gQqmY/Wxg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=5JaXyH1aDwdNHErib5BdaSPX4bKAni7hGyqUgAsXJco=; b=F8JzTXiH7XNkiNO+MnM659aLGEGMHJT/nAWBt3FyMr9xiOh+QquuLKROw/cFUmfnKG JvmEd3BgfjfIKb2aO0IPLzKzmyNbFu52Ose6u88XxuAYh7js38UMj6chpFm8d+oJAF1M 1/MRqE1hccE1SlYf5Fc32NjQky8sXSHv8+Fi+GH3bySp834QFcFBT6g1TJxcHqYzi66D I7QqXLlvWHElXNI8eveYbqh8KGyHKqdmPdza9Ypnhnr+QMxVf0C7kI9vLLXqmJ9YEHeb iEVNrQO4s8YVQmwqjNPDqAsCkiKAKJRhkSeK2ddixG+bAGfnJf6zu5SLPAKKEh96MZw7 ykog==
X-Gm-Message-State: ALoCoQk1nQjFZ1jr1tzPBV4+iSBScZgGrkU/cv+AzjMNVlYkHV1fAJHoEvkQfYtpz2uYZ3P3s3zc
X-Received: by with SMTP id t21mr39670425qgt.5.1447729692046; Mon, 16 Nov 2015 19:08:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Nov 2015 19:07:52 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Tom Ritter <>
Date: Mon, 16 Nov 2015 22:07:52 -0500
Message-ID: <>
To: PKIX <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Subject: Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Nov 2015 03:08:14 -0000

>From some of the emails, it sounds like the goal to differentiate a CA
that is going to authenticate some specific set of DNS names (a
private CA that is operating publicly) from a CA that is going to
authenticate potentially all DNS names (interception).  What is the
actual difference between those?

Obviously bad guys can lie. And putting a bit into a certificate does
not magically inform users of the risks they are taking on when they
install a CA.

It's my understanding (and I could be slightly wrong in the details
but I think I'm right in the generality) that Brazil requires you to
install a CA to do some sort of citizenship operation (get a passport?
pay taxes?).

I think the security win here is NOT to put a bit in the certificate
that says "I state I won't do interception" - but leave it perfectly
capable of doing so if it was malicious or compromised... but rather
to put a feature in clients that asks after installation: "Do you
trust [Brazilian CA] to authenticate []?   [Yes, and I trust
it for the entire Internet] [No] [Yes]"  This drives towards marking a
CA for what the user wants to trust it as.

In theory this can be done with Name Constraints, and I like those and
hope they'd be used in conjunction - but in practice constraining
certificates ahead of time in this way is difficult. Telling someone
"Nope, I can't issue a certificate for" doesn't work
out well.