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

Yoav Nir <> Sat, 08 July 2017 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D28D12EBF6 for <>; Sat, 8 Jul 2017 09:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 BYUwLqiGt54U for <>; Sat, 8 Jul 2017 09:31:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F10A412EB43 for <>; Sat, 8 Jul 2017 09:31:04 -0700 (PDT)
Received: by with SMTP id 77so14602388wrb.3 for <>; Sat, 08 Jul 2017 09:31:04 -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=nqAfTkQUb4IkwtXHpOLIxi2BvKYh/usqnf0VFBJl24I=; b=Osw1fugy69vgp2N+VKUyPHkHzzOxNMW2aFP4Cplsb5URLO2D9U4wMrKpON6dxtozRS HGHuqYD11YR9lPQbgTa1/Q8NO5XKfJLAyaQWqlXoMvtLNwL8oYA0aSoGn0JVaK8A+Hdl Up8BsOAoZu00E6A6ZI5gh82b1VxYI7KVxUVA0zVVeCZjW0msI9x1C1+RDHYOaui4uvDF gGgDFR6Jx+MloSSr/Kh54GL76Fl9MtIR5fbaC/LsndTzBleFDT1EZzjsYGJSYw3YygCv OKk4IDixGK+RHurSGrQvVK5CLGyj2Ii7pQMlgRgQEyWt1ipsUdHkYGvjS+pd3+EHytXu ZR6Q==
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=nqAfTkQUb4IkwtXHpOLIxi2BvKYh/usqnf0VFBJl24I=; b=f7t7SH0Vj24c6NhnSNBze5x3NHJhekvwA+7UT7wmK3xWSHNYVvGHvC7a1HZR1qy9D3 mSBOaV1mYpSAvc31Muuwb6eI+S6U1jYr603TIyYixHkKzlCERfB7uYH7jy1vTAqQrjiJ tmanTNSRFF7wlwPV10OjQNa9FGFPINUJ278fyLtownfbw0lt/S1a1oee8mC/x2hZx9LG 7xE2kJotqNQGNgGXUoBFJoQWGtmj6MBjlyaXy3GZ0sCKi0e4/pPTUwEvy+DTi91Kwfiw xiR5LGK01q79CN3kIiDAI7Do1YThkGmKjmDriKJHD1CD6Dhu7FIivvdChGvCriqP6gHI 7jog==
X-Gm-Message-State: AIVw110Fj2u9vJw78hFU8bqhW3FuB5k4WV1jXXfryS9RxfzYakNGIyA7 hWRRrm2uhNsRRliyCYY=
X-Received: by with SMTP id v13mr3585936edl.36.1499531463439; Sat, 08 Jul 2017 09:31:03 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id p49sm5483426edc.47.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 09:31:02 -0700 (PDT)
From: Yoav Nir <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_21B1F608-226E-49AC-B331-4D671DF18DBF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 8 Jul 2017 19:31:00 +0300
In-Reply-To: <>
Cc: Stephen Farrell <>, "" <>, tls chair <>
To: Tony Arcieri <>
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: Sat, 08 Jul 2017 16:31:07 -0000

> On 8 Jul 2017, at 18:39, Tony Arcieri <>; wrote:
> I was one of the people arguing my hardest against the BITS Security proposal to continue to (ab)use RSA static keys to allow passive MitM, even though TLS 1.3 had already moved forward on what I would call a more modern protocol design of the sort I believe payments companies should embrace to improve their security.
> That said, if people do want to MitM themselves, I would rather there be a single, easily detectable and very explicit way of doing so, as opposed to sketchy, incompatible, ad hoc mechanisms.

But all the MITM solutions, whether proxies or static DH are not easily detectable. Client-side proxies - the kind deployed by enterprises - are visible to clients (by the CA signing the proxy certificates) but not to the servers. This is implemented on the server, but is invisible to the client.  Even if the client rapid-fires several handshakes to see if the public key does not change, this is indistinguishable from the optimization of using the same key-pair for several seconds (without saving the private key).

> Furthermore, it would be nice to have a clear answer for these users, less they continue to make (bad) arguments that there is something fundamentally wrong with the design of TLS 1.3 that makes it incompatible with "industry requirements".
> Clearly there are echoes of the scary protocols of yesteryear, i.e. Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the image header you will discover he is quite familiar with these things, and my personal presumption would be he is not displaying this image to show his undying love of the Clipper chip, although perhaps he's an especially crafty and duplicitous NSA sleeper agent.

It’s not about the reputations or motivations of the impressive list of authors. It’s about having the capability built into widely used products and libraries.

Suppose you have an Internet-facing server with TLS 1.2 and an ECDSA certificate and all supported ciphersuites are ECDHE-ECDSA.Suppose further that your server is using the ever popular Apache/modssl/openssl stack.

If you want to disable forward secrecy you have to either replace the certificate with an RSA certificate and move to all static RSA ciphersuites, or you need to replace your stack with something that does what this draft describes.

With this draft widely implemented it’s just a matter of turning the capability on.

We can’t really stop people implementing it, It’s not detectable by the client and an implementation would seem to be fully compliant with TLS 1.3.  And I don’t know how to implement this in such a way that it would work for “good” purposes but not for “bad” purposes, however one defines good and bad here.