Re: [TLS] chairs - please shutdown wiretapping discussion...

Yoav Nir <> Tue, 11 July 2017 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E72D3127735 for <>; Tue, 11 Jul 2017 15:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HR2JE3P8UrIe for <>; Tue, 11 Jul 2017 15:09:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA4EA12ECB3 for <>; Tue, 11 Jul 2017 15:09:07 -0700 (PDT)
Received: by with SMTP id 77so8048733wrb.1 for <>; Tue, 11 Jul 2017 15:09:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0+36Vun9A2Cl/lBGHdLIi55bxYrrpRHPjfLuXkRWbGA=; b=gpdntCBiIeZUuWHzfE7bvWLYZPo3SfqcTRLnXzMVDAEfX77gM8XSBpwLRaPd6RkSr6 znMXR2AMHkAp1BZ3YWWeRDC3srGhNyu81THdW1e9DJ1W0yGhECxDamkGrdLGQCEsB4QE JBGIeYGfSAyJJMJ9QTrqvrHsPMCAuM5C5/JRf/KdFoaYZjFaKwOBrsEOkYfGDPnRvQYn m3j3EzSd7B3llfbeD8LEERaQ+M8L6oRPX2D5xwxoHIipw3ylqQh2hB8Baj9pNLQvTA9h IAPd/iizxHutisOFdvrrBwL4/IC4fgAaLE92Va2iqhfg05k8jfCRwVuKLySHsV/tOlBc gQ2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0+36Vun9A2Cl/lBGHdLIi55bxYrrpRHPjfLuXkRWbGA=; b=dNsJSo9HzmdZcE4kKCDxq5T1bBfB6KtQ82RpFCT/A83kJS7JNYetG0dZaEOENhyOQr mhRzhB664exiTWNXrwr4v0YQVOqzGP2M9Ziq44tI8woH9vyBQUr78afD3qc2eiQ5u+0O 5o4+aMM4PoRScCDFIM237TZJLJfVKw/QOFrkGri+HssUEKJXmQAKS0rEYd1guwfY1TbD sMHjwhg57IEFdB8lR23PDZ+58quFz1ECty0IpXICtENs7tGyNkj9qNYFb7Ca3B8pt9ri pwZdR+rD/QJ1BdGb0vxOmXfewGcwNmY9p7Z19IwM5tSUVUiLK7KQtDLv30tfM1r0tREX om/w==
X-Gm-Message-State: AIVw110bNCd+yCryBn+A8ShEdU8JFynSVc+gLCae2bQOZjtY005ZN41k JaXjIIJYoWtKuA==
X-Received: by with SMTP id i31mr3913754edi.119.1499810946521; Tue, 11 Jul 2017 15:09:06 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id a25sm229241eda.44.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 15:09:05 -0700 (PDT)
From: Yoav Nir <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_C53FEFAD-201F-4922-8E45-17E8BE2E635A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 12 Jul 2017 01:09:02 +0300
In-Reply-To: <>
Cc: Christian Huitema <>, Ted Lemon <>, TLS WG <>
To: Stephen Farrell <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
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: Tue, 11 Jul 2017 22:09:10 -0000

> On 12 Jul 2017, at 0:21, Stephen Farrell <>; wrote:
> On 11/07/17 22:10, Yoav Nir wrote:
>> If one of the parties to a conversation cooperates with the wiretap,
>> this isn’t an attack.
> Lemme try on this one again from a different angle.
> In classic telephony wiretaps the carrier does the
> tap. There are similar situations with TLS...
> In hosted platforms (e.g. and many
> others) where the senders and receivers (or publishers
> & readers) have read and write access via PHP code
> and not via a shell, and cannot therefore control web
> or TLS configuration, the platform would be doing a
> wiretap if it turned this on, whilst colluding with
> or being coerced by some other entity that collects
> and later decrypts the ciphertext and packets.
> Are we agreed that that use-case is wiretapping via
> this mechanism?
> There are many millions of people who use such
> constrained hosted environments. <> is a party to the session. It has access to the plaintext and could deliver it to whatever third party whenever they wanted. This draft may be an optimization, but the plaintext was always theirs to give.

I might be deluding myself that I’m sending this email to you over TLS. In fact I’m only uploading it to <> who will forward it to TCD’s server. Both servers will have access to the plaintext. Both servers can send it to a third party, or share session keys or share ECDHE private keys.

Whether one party to a conversation (phone or IP) has the right to share private contents with a third party is a legal matter that varies from country to country and from state to state. I only claim that this draft does not change the fact that is true for PFS suites in TLS 1.x and for all suites in TLS 1.3, that it’s impossible to decrypt a recorded session without cooperation from either party, and that cooperation has to start *before*  the session is recorded.

That is not the case for POTS wiretap or for the RSA key exchange.