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

Tony Arcieri <> Sat, 08 July 2017 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3043312EB97 for <>; Sat, 8 Jul 2017 10:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 cZKe7CZ2p2gp for <>; Sat, 8 Jul 2017 10:34:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 800E5129B04 for <>; Sat, 8 Jul 2017 10:34:12 -0700 (PDT)
Received: by with SMTP id l21so23323117ywb.1 for <>; Sat, 08 Jul 2017 10:34:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FC9oYzysq5KL8yqgpyC6pmE/h8XTYFPq+FX4PeLoovk=; b=GIWD34m7dKMTBX00t84mKYPZjjOujtGcrNBl08/euX5Ld6t9XZpH7bJY7opOfqO3Ui ImSx/bE2L3go+b1qRZiDicAsbNWf3a54ms0K5cyV71nEQ2QpSXlIfg/yPBJwmNWzltHS Kw/v+ISHpUMddAsqHvKsmNDy8ZcE74MSU3XZEa5gYFo8xr3uVU+kz0SYBOZaIcy+yRmg rTaQj8fWJdYIE/INjcZ6MLxANTf2WxKOMIPLpVs7gzj5RSp5MmzBXEW5RmIhIPYYj75Q gGtgi3d8c7g2rLqzNwHhWUAqY7eOVZaBmONA98lxEg+X+5pzFvOSi1KsAbxiCF0XB7tT c4Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FC9oYzysq5KL8yqgpyC6pmE/h8XTYFPq+FX4PeLoovk=; b=Yl8lcICdSXbukGWKvbYtOUEkgsbqlzbfG228rojruK2UMpnR8Pl70k0hctSzwVoWFk NQ55PvQl3+8swhH+SWYBSs4xoJQDCjAyC4wCT8+Ivi+lP/vyW/xq+EsRiVoYak0hZzj6 pwe/ba/pbLLqI9vyF6iRsIebkD0QFhTl4TjI/DkeVjm6AoOszGJ59sIqBXoW0Z16zz2O 89qVS2dwT5415U4g8lh+jqv/ODX94rEWfFE2uXqGQExVzJLwLfQGfXMVZvD1bmAOl6yL MIwY9D/HgTC4wYLhW1w/7C9g5cnCc0cHaaAv+dyUlAcGqteqTcHiBKg/RbPiEGFLb42k UyKA==
X-Gm-Message-State: AIVw111jmul+hsCUUh4yn84OEbjdjjCMDnq+clvJmsha9r+Q+NlfAZsh ydm278OV3XLeQ6ut7QoqHI191oYmBg==
X-Received: by with SMTP id a124mr5927672ywh.138.1499535251681; Sat, 08 Jul 2017 10:34:11 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tony Arcieri <>
Date: Sat, 08 Jul 2017 17:34:00 +0000
Message-ID: <>
To: Russ Housley <>
Content-Type: multipart/alternative; boundary="94eb2c115e340138cd0553d1c2d5"
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 17:34:14 -0000

On Sat, Jul 8, 2017 at 11:17 AM Russ Housley <>; wrote:

> I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not
> enable MitM.  The server does not share the signing private key, so no
> other party can perform a valid handshake.

This method allows a middlebox to recover the plaintext of a TLS session.
While I took issue with Stephen's attempts to shut down conversations this
line of inquiry, I have a much, much stronger objection to downplay the
fact that this is still a self-inflicted MitM attack.

Let me be very clear: full plaintext recovery by a passive middlebox
absolutely is "MitM". Just because it does not allow full impersonation of
the server does not make it MitM. It is MitM, and we should be very clear
it is MitM.

Further, the server is choosing to use a (EC)DH key that was generated by
> the key manager, so it is quite different than the mandatory key escrow used
> in the Clipper Chip.

It enables the same ends: recovery of session plaintexts, and as I stated
on other threads I would personally prefer a more explicit key escrow
mechanism implemented as a TLS extension, which to some degree would
actually look a bit more like LEAP.

> --
Tony Arcieri