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

Kyle Rose <> Sat, 15 July 2017 12:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5354131B16 for <>; Sat, 15 Jul 2017 05:18:50 -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 3tkL8LO6sGax for <>; Sat, 15 Jul 2017 05:18:48 -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 1CD291316F4 for <>; Sat, 15 Jul 2017 05:18:48 -0700 (PDT)
Received: by with SMTP id c20so13013969qte.0 for <>; Sat, 15 Jul 2017 05:18:48 -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=3SKaodYZmdAoKwwoFOe+lYDMw52EPkDFC57nO2nK2xU=; b=M3nDjhipGUx5huOn17mu7TkRYyLq8E+wQpm7SF2ESvrRjJX+q+GoVQQ0q0O4yJdylN bBMCn57OI7Y1zofTWfa+L7YmVq1M19Z3jhR2/G0tjkTMTMZPO7cCSZjVebU8XvfU0RUK lo7BHvCJceE2CDEQwc7uIRqaJ62AG9Odltxcs=
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=3SKaodYZmdAoKwwoFOe+lYDMw52EPkDFC57nO2nK2xU=; b=okvklpnhJO6gcwWIWOcWyWb0ulSPGi1JH1KJOfRn21zk4lQDHJGr4P9F9ZjK7yqopz HC55jLk9XYzdMtCg0Ej0edWFAGXopUuySH3V40pJBfdGenMe82X5tBVfesXlUts0O/cy P9mvXMxG8wOw50+NQDY4pVe/czyeqPtnsZ4rOVUn//ViDbgsdlLHpzGIROJ+5GGycFyz 9tC/l/+6g56tN/9gnTTwBYznJk2UiB1RwTuzRuOj7OE5zmYjhMixqSJ7K5mEWtWVCPHG 97qFLjwQOQj0QNSxAIWqgPccvZR9hh6OTpSqo87KxGIaY9pP3nEU55xW7r6CMfxrRF93 AiJA==
X-Gm-Message-State: AIVw113ivWS+SLlqvMfwZ5NYiw24AnrMiYFIaYL3gB/LdBeLvOK2edWA r1RFl/OSurzEI9+3L8qo5g2u5fQ8vcPs
X-Received: by with SMTP id x30mr17790039qtd.55.1500121127021; Sat, 15 Jul 2017 05:18:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 15 Jul 2017 05:18:45 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Sat, 15 Jul 2017 08:18:45 -0400
Message-ID: <>
To: Roland Dobbins <>
Cc: Daniel Kahn Gillmor <>, Matthew Green <>, IETF TLS <>
Content-Type: multipart/alternative; boundary="94eb2c00560ee5b70905545a2a32"
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 12:18:51 -0000

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.)