Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Kyle Rose <> Sat, 15 July 2017 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8F4312ECCB for <>; Sat, 15 Jul 2017 06:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XAyjsw8RSQuk for <>; Sat, 15 Jul 2017 06:08:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 176BC129B4B for <>; Sat, 15 Jul 2017 06:08:37 -0700 (PDT)
Received: by with SMTP id c20so13121646qte.0 for <>; Sat, 15 Jul 2017 06:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8wkspLMMkkm3F+VMC2W38EG3lnRRTQW+CfKxkkMYIE=; b=GyRQA4x//iZDSh7sIfPQjgGpkH/XdxpGERWzvJnGa07o5GKMGNUEkfdKiq55wycF8B mML30IZjzd39tRafU2heI/7SRCImEeYYalIulA52mpay/g1DLyfGffVR1e52kycS4ejK ZNgv7pEnV5ueEs7F0E059ZtqHWZ9WHBLTNibY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8wkspLMMkkm3F+VMC2W38EG3lnRRTQW+CfKxkkMYIE=; b=pktpszRnHYHxS3N8s0KcVMH0BczoIkhgI8y3waZJSxCscI1XP12LxPbabXTMDWwh3C A5VnKEw3F0giO1k5xqvp0zxH91UWQXo0zKtzkEV/snOJF6MnmnJosRcunnyf0s6LgwYz YyBFiS+UzkWPXcF3Z926sHnXb3f/r+Gt2IEVB0soX8oK+znDqMPbj2j+FeOoQEGa9bBt Gm6E5Ba/QFw3gExT2GEI1ULaRx33nO0DEe27HOGp2VNOt64IEXBSqLPzrCLu9HfcCSEH 87+x5RvxtRZhPZpRu0dlB1EBMpsBcr/u9rqxLnj0bUyFu3p/CjcgTPOtrNYSZUKjDJ1F SCSg==
X-Gm-Message-State: AIVw111xQ8KXvS0xDxCRcgj/2ZbAts5huPacx8kJzGUZ88WuJ6uhdPbX 4m2BYDCCbZ3aZq6Y9gTJI2g2WrVbQ+xn
X-Received: by with SMTP id d40mr17210672qtb.151.1500124116027; Sat, 15 Jul 2017 06:08:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 15 Jul 2017 06:08:34 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Sat, 15 Jul 2017 09:08:34 -0400
Message-ID: <>
To: Roland Dobbins <>
Cc: Daniel Kahn Gillmor <>, Matthew Green <>, IETF TLS <>
Content-Type: multipart/alternative; boundary="001a114547be0e1f3105545addb0"
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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, 15 Jul 2017 13:08:46 -0000

I've rebased from the kernel master HEAD (4.12.0+), tested, and
force-pushed the repository.

Conveniently, it looks like, since the last time I searched for one,
someone added an ECDH implementation to the kernel. That makes this a lot


On Sat, Jul 15, 2017 at 8:18 AM, Kyle Rose <> wrote:

> On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins <>
> wrote:
>> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>> Whether it justifies a loss of security is a separate question.
>> It isn't a loss of security - it's actually a net gain for security.
> Security isn't a scalar quantity, so there's no way you can credibly
> assert this. OTOH, it's easy to point to the individual security properties
> lost by expanding the attack surface for a particular session key or by
> mandating key-reuse.
> Analyzing the impact of any particular mechanism for middlebox inspection
> is a question of tradeoffs: what are you giving up, what are you gaining,
> and is the trade worth it? The first two are questions of fact (though I'm
> under no illusion that there would even be broad agreement on those). The
> last is not: it's inherently subjective and among other things it depends
> on the threats, the alternative mechanisms available, and the value placed
> on the properties TLS provides to end users in its unadulterated form.
> Every one of your emails seems to boil down to an argument of the form
> "Organizations have infrastructure and operations set up to do inspection
> this way, so we need some way to apply that to TLS 1.3." I am unpersuaded
> by such arguments as a reason for standardizing a weakening of TLS. Given
> that, I would like to understand the origins of this approach to
> monitoring, as that may shed light on the hidden or unspecified constraints
> other than those imposed by TLS. (For example, if this approach is deemed
> to be less costly than doing endpoint monitoring, or if there are
> insufficient access controls for entry to the privileged network, or if the
> privileged network has systems that are too difficult to secure.)
> Kyle