Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Stephen Farrell <> Wed, 25 October 2017 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D53CE13F475 for <>; Wed, 25 Oct 2017 14:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bIlNHAmszpxo for <>; Wed, 25 Oct 2017 14:32:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DAE513A102 for <>; Wed, 25 Oct 2017 14:32:29 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 320FFBE58; Wed, 25 Oct 2017 22:32:27 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I9-sROuK4pBj; Wed, 25 Oct 2017 22:32:25 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 51A32BE53; Wed, 25 Oct 2017 22:32:25 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1508967145; bh=ZljPEeX3JGHc7Jq6nkqipalYbP3VGX4MekBtgN5MhgI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FOJbAyg9TlAZATlM2Yhcu/0OJX7LOUpoLS66TE8ixZo831ibUnZzCKBj+BrNkTunb RvmPsfg5UXyUplFSutNvAi/xk/pk3aVTj1ky3U20EgJRwXGY7WY4feuxjZDR0nOtms z4zjBCcqc8BL4+KljZlZWTS42D9Whp+jZuO7I7fg=
To: Nick Sullivan <>, "Salz, Rich" <>
Cc: Paul Turner <>, "" <>
References: <> <> <> <> <000501d348e5$1f273450$5d759cf0$> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 25 Oct 2017 22:32:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IionCPSCEcNBwQsQ1OoM18xNet7DHBmqn"
Archived-At: <>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Oct 2017 21:32:32 -0000

Thank you Nick.

On 25/10/17 20:34, Nick Sullivan wrote:
> On that note, so what if some browsers opt in? Servers need to also opt-in
> to setting visibility keys.

It is good to see the discussion move on from the proponents'
seeming inability to envisage that anything bad could possibly
happen here;-)

I believe you are right that if we standardise this, it is
reasonably likely to end up in some browser. (I've no idea
how to estimate that probability, so we're all guessing

As you might expect, I disagree with your analysis as to the
consequences if browsers did support this.

Just as one example, I read today of reports that some people
have been arrested/accused partly on the basis that they downloaded
some software [1] so it is sadly far too easy to imagine that
some regime somewhere would arrest people for having a browser
that does not support this "standard" feature. Note, I'm not
saying I accept all details of the story in [1] as such things
are often badly reported, but I do assert that such issues are
ones we ought be seriously considering.

For me, us defining a feature like this that could be mandated,
for wiretapping, or the absence of which could get folks into
that kind of trouble, is just not something we ought be risking,
regardless of our inability to estimate the probabilities