Re: [TLS] TLS@IETF101 Agenda Posted

Stephen Farrell <> Thu, 15 March 2018 00:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 337D912D7F5 for <>; Wed, 14 Mar 2018 17:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 edSj9aVf7nNg for <>; Wed, 14 Mar 2018 17:58:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2487A12D7E5 for <>; Wed, 14 Mar 2018 17:58:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9957BBE51 for <>; Thu, 15 Mar 2018 00:58:11 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GeGna2Yb-0jD for <>; Thu, 15 Mar 2018 00:58:10 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 56D6ABE4C for <>; Thu, 15 Mar 2018 00:58:10 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1521075490; bh=/o1NR+9KLljOuGOVHifG/hXfaOVQ7G+9S4aDwfC0Kfc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Mz/j3rUsnZqrbmkacYLRyeuvZ5Cs78Xq//EoQP0RLJAs7XNZ3Jbjqe89dnpX97QXs hnVsQpo1uqGysBTYkLOxaoPLNQqSaO2xSJsyo+mPW9G6SeXNINbnoXvsrtz+XJLTmn 5foR8qbOhLFLM8NTUW/IwpPHaA009qYbr9cpvGrk=
To: "<>" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <>
Date: Thu, 15 Mar 2018 00:58:09 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KFVU89KZw9HuCoICKfnOD1iJ6rYBI4fkh"
Archived-At: <>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
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: Thu, 15 Mar 2018 00:58:16 -0000

On 14/03/18 23:16, Stephen Farrell wrote:
> Of course some people who are used to MitMing connections will
> have problems and will have to change.

I got an offlist message correcting me about the above.

I do agree that it's odd to describe post-facto decryption
of a TLS session that used RSA key transport (via a copy of
the RSA private key) as a MitM. (The off list message didn't
say "odd" - it said "wrong":-)

It'd have been better if I'd said that all these approaches
*enable* MitM rather than *are* MitMing - even if the holder
of the copy of the RSA private key might never actually mount
an MitM, they always do have the capability to MitM whenever
they choose to do that. The same is true of Russ and Ralph's
draft as well, though of course the on-path nature of that
proposal makes an actual MitM attack more likely I'd guess,
given it requires both the cryptographic and the topological
capability to MitM whereas RSA based schemes only have to
provide the cryptographic capability.

So I accept the correction, it's a fair cop.

That said, I find using the term MitM as a shorthand for all
of the above to be waaaay more accurate than abusing the word
"visibility" to describe standardising a MitM capability.