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

Stephen Farrell <> Tue, 11 July 2017 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 075911316D0 for <>; Tue, 11 Jul 2017 05:49:44 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zCvrkh7fRxeR for <>; Tue, 11 Jul 2017 05:49:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 388261200B9 for <>; Tue, 11 Jul 2017 05:49:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E0E2BF74; Tue, 11 Jul 2017 13:49:39 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BEv4iAKxYbXu; Tue, 11 Jul 2017 13:49:39 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 5E91BBF2E; Tue, 11 Jul 2017 13:49:39 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1499777379; bh=ZYY8PdhgvVg28ncXi+atveSboxHUaILuqU5aGk8POCw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=C3R57OMol/a612i8w0ya+SSOT16Q8UjxVIf1y4kO8Sfp9KHXnbcAh9BlZ93Ol1Par MvEQzJ2us31lQyIrYaOMJi+zh63Mtia7RbtpMsPtAIeuo6rGFbj12RdVyvw8yVdGmg +c7lqLasV2WhlciqGgNFkgNLejA0WlegJFJiQuTI=
To: Ted Lemon <>
Cc: Russ Housley <>, "Polk, Tim (Fed)" <>, IETF TLS <>
References: <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Tue, 11 Jul 2017 13:49:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ORO6d4IGmEkuuaa9lKD9Qfso1O2IXVGa6"
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 12:49:44 -0000


On 11/07/17 12:02, Ted Lemon wrote:
> On Jul 10, 2017, at 5:35 PM, Stephen Farrell
> <>; wrote:
>> Consider SMTP/TLS. Where one MTA on the path supports this. Say
>> it's one operated by an anti-spam company for example. That is
>> clearly not the sender nor recipient.
>> That meets all 4 points in 2804, right?
> I don't buy this, Stephen.   The anti-spam company is not an
> eavesdropper.

This draft proposes a way for an eavesdropper who recorded
the cihphertext packets from anywhere to use a standardised
interface to get a small package of key material from the
anti-spam company (via coercion or collusion), that allows
the eavesdropper to decrypt all the TLS protected email
traffic sent via the anti-spam company. Looked at one way,
tt amounts to standardising a key exfiltration attack.

> What I don't understand about your approach to this draft is that it
> seems to me that the draft is obviously describing an exploit in TLS
> 1.3, for which a mitigation exists: remember keys, and refuse to
> communicate with an endpoint that presents a key you've seen before.

The TLS server doesn't need to do things in a way that
a TLS client can detect.

> So rather than opposing the publication of the static keys draft, why
> not work on mitigating the attack it describes?   This attack exists
> whether the static keys draft is published or not.

Good/better TLS1.3 forward secrecy is being discussed as
part of the normal work in the WG. It is for sure always
possible to manage keys badly, but this draft proposes
an API to expose private key materials which is not the
same thing as bad implementation or management at all.