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

Yoav Nir <> Mon, 10 July 2017 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2D661274D2 for <>; Mon, 10 Jul 2017 10:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 WkgzfvjsLcvu for <>; Mon, 10 Jul 2017 10:01:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C5D31317D3 for <>; Mon, 10 Jul 2017 10:01:36 -0700 (PDT)
Received: by with SMTP id h22so66993872lfk.3 for <>; Mon, 10 Jul 2017 10:01:36 -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=GfTDIXka1nSqMyRuLyDxHEy4M6/i87iWc7m7E/DtiYI=; b=BFe9Bqp/JWE5zpRV0S7aH/uEjtGeI4PG1OoAnPdEdstErwHBms04pKfSt08fNiEc+V ye4d0mP4huDbdNj98WYogU3JE+vVJmWh2SrSEbHS+GdjFAJYtiRE4nvQuIj5C69fASPg 5p1L+9YYsDaJJW4nrh+fSEMo+KcycpR9YTblod8DdLMB9MZhy00tFEAuFBTGmb3vWq5u t+1gfZTvivzGAWlZE36RcI1PTlBCfi1/aCKbuabtz8xgj9lfRFcvNQ8TR8SBgeU17ZMl NZBq5lkbxJfOo05vb7zufqc3bCrgeZhjg3zdvQQ496/vcH2gvuAfoQ7oeIx25v0kZAys S/lQ==
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=GfTDIXka1nSqMyRuLyDxHEy4M6/i87iWc7m7E/DtiYI=; b=QM+XTuepfoxsqOWoF06+1BKpJ36mXSXMxRx3gYaOjsLteQfvk7aCCeFP4cpMvsbDvb Nu5jGzj8fnZS8mLxweCMZmxhhm0PGHq0PQCNN0mvqStUL9uZf8blmqqDVxDL+m9Sl/xP +QjMHnEJN84MP+neTjmhWHpcIxHaRylZT0yx7IHIncVoIuj/P8Bn70mpGeOcaD6QJxyj ezO2hx4vn2xqOqbcVZFLLOfRBSF4zm93IywtMYprScsfrCZ7Bw77UFBaH3zdlSOmGGZe ht9SdwWaAjctmN3R/Azru7U6QUnSHSzy/1qOoTkjyJ6w2TRXWz4vjNQof60pBffAPzxr oIKA==
X-Gm-Message-State: AIVw112sgelGr3YJb6Wj+jb4LsZ/5dS5PybyWafQjc/zdljObJjPMIUS eiDGN+k6Ma6GLGmjSso=
X-Received: by with SMTP id 25mr12307240edu.73.1499706094402; Mon, 10 Jul 2017 10:01:34 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id g24sm5487561edh.20.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 10:01:33 -0700 (PDT)
From: Yoav Nir <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_980B561B-2E0A-4BCA-B737-326C868F1DFA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 10 Jul 2017 20:01:32 +0300
In-Reply-To: <>
Cc: "Polk, Tim (Fed)" <>, "" <>
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: Mon, 10 Jul 2017 17:01:39 -0000

> On 10 Jul 2017, at 17:16, Stephen Farrell <>; wrote:
>> 2.  this proposal offers
>> significantly better security properties than current practice
>> (central distribution of static RSA keys)
> I fail to see any relevant difference in security properties
> between those two, never mind a significant improvement.

I can see one way in which it is worse.

With static RSA keys, you can configure the server to use only PFS ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS, you need to switch to RSA ciphersuites, and that would be obvious to any client.  In fact, I think today a server would stick out if it only supported RSA ciphersuites.

There is no way to know that a server is doing what it says in the draft. It’s completely opaque to the client.

However, in both cases the server does get FS. As long as the server has not enabled RSA ciphersuites or exportable private key shares, any recorded TLS stream is safe even if the attacker later gets the private key.