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

Stephen Farrell <> Wed, 25 October 2017 02:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01D08139438 for <>; Tue, 24 Oct 2017 19:13:29 -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 F5e0yp5hNmxe for <>; Tue, 24 Oct 2017 19:13:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 023B613942F for <>; Tue, 24 Oct 2017 19:13:26 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0152BE4C; Wed, 25 Oct 2017 03:13:25 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id naqBigp41Nq5; Wed, 25 Oct 2017 03:13:24 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 41720BE47; Wed, 25 Oct 2017 03:13:24 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1508897604; bh=6qzQeaEFyIHlj2biksnjKnZWInfjNRzfi/o/rjDm2EY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=0JqTitmYIqlh/86m4RQ8HCL1Y7jstg/82ClDUc8rC1en1dmHMUs48VIWI16pWTE33 uhOK3T63RFE6YZ3seYcl6DFdxPy42kX+hYgpL3I6fSGKjSQAjEQ8np4GIPvkwPppVU 4kqGPPCxmpj4k2onW6S0+R3osJpgX+vRq+vUvpzA=
To: "David A. Cooper" <>, "" <>
References: <> <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 25 Oct 2017 03:13:23 +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="DAdOLWqluNrfkUF1SWSMgD5Dm6IWp6NWP"
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 02:13:29 -0000


I'll go back over your mails tomorrow but was struck by this...

On 24/10/17 23:39, David A. Cooper wrote:
> I haven't even gotten into the question of what does it mean for a connection to 
> be MiTM'd. If Company X decides to have its web site operated by Hosting 
> Provider Y is the connection between the client and Company X being MiTM'd? The 
> client might think it has a secure end-to-end connection with Company X, but in 
> reality its data is being intercepted and read by Hosting Provider Y, without 
> the client's permission (and most likely without the client's knowledge). How 
> does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be 
> standardized until it can be proven that such a scenario is impossible?

That strikes me as an incredibly nihilist approach you
(or NIST?) appear to be espousing, which is surprising.

As a question back to you: would it be ok if NIST were
to reinstate Dual-EC? If not why not? After all, (based
on the above), all that'd happen is someone could do
stuff that everyone knows (since 2008) can happen. (And
no, with the current draft, the client does NOT know who
the snooper is - it could be the NSA or the FSB and the
client can't tell - and all that was already discussed
on the list.)

I suspect you'll say that it's better that NIST do not
add Dual-EC back, (and I agree) because we're better off
with honest crypto. And the same is true of TLS - it's
a 2 party protocol and adding additional parties breaks
all the trust models based on TLS. So it'd be equally
good if NIST didn't espouse breaking TLS, at least IMO.

If you can show me where you (or NIST or anyone) analysed
all of the uses of TLS to check that there are no bad side
effects, I'll be interested in reading that analysis. In
the meantime, your personal evaluation of your risk is not
something that I find convincing, sorry.