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

Yoav Nir <> Sat, 15 July 2017 08:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E64B131B03 for <>; Sat, 15 Jul 2017 01:14:57 -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, FREEMAIL_FROM=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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rMRBuU_FRR5k for <>; Sat, 15 Jul 2017 01:14:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A809D131B34 for <>; Sat, 15 Jul 2017 01:14:55 -0700 (PDT)
Received: by with SMTP id 15so2487151wmm.3 for <>; Sat, 15 Jul 2017 01:14:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=V6DZQ2zCXQoKRaRmHiLqnxbmqh5yoF1+FBvhzBKvtDw=; b=AaKEE1wViCFZsdI5SgcTz6046pUEIfQ+grLfHAzZ6zHsJnlsx3SGUI55CQaXMAzMLG WmW2Fui2TLTdQyV6UkWwSdZhEk3Pa7X9b2HFivTuClMuf5KHZipsLlEeKsMFJukwEH22 GFEEHqwJ4MKHX+0hOFBF9dX9H9NIJmH9tNSF0yaVycVDCdKR8UWEq8QCd9kB3TVvASDZ hgJIqhs6jlIJEH76Ha9kCW/BVak/ToL9hhZH8TG4oK/P3yisLWABKSqJ5Ojr0q4t2s4a FBsqysnJN5GPSOaL0uCqP07bSlNXN5yy4RF306Y4YfjTNMfX4wfkv/8NnirSFe+0i4KT RE0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=V6DZQ2zCXQoKRaRmHiLqnxbmqh5yoF1+FBvhzBKvtDw=; b=qddguKnkM2Fu74l2taYEF8ycn/YjXjWjxLzyPKEK91WyG5dvh4xNamfNmNlIN1K5qQ ZhMc6hxTRJ7MqNXmEK2Y4Qfz9HYFB8uu3ijYtyhaTTxvGVb2MRIdxOziYqs/PyYr7xfE hl/ZDn6NU/SfG1rOQ5CXHu+MEZ6SzldTtfUjBlfc7vujVgbS5h5ddqdRW+0i99rKlvO+ EjwGXrN6ciHslaJfaPsYv/k4mH+yoX3wjzN5bquldc2urxjEpS6DC8yeMb0lhDaEUZMY pgGMGShUO6lehFqvpsHOo7qpcKCmWDx8vY+d0jRYQz2PfLRUZZM1Rf8UAf8lpMLYrKwo JUDA==
X-Gm-Message-State: AIVw111yei04goAZVDMvsbq2xWnRfRBwlaZxNvlvJUcPlEj341WCO0zj tu9N5Nn0twa4Jw==
X-Received: by with SMTP id p10mr9774517edc.33.1500106494255; Sat, 15 Jul 2017 01:14:54 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id l3sm4901532edc.32.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 01:14:53 -0700 (PDT)
From: Yoav Nir <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_6D17C65C-6FED-4DE1-BF26-E9FB4C79C092"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 15 Jul 2017 11:14:50 +0300
In-Reply-To: <>
Cc: Rich Salz <>, Joseph Lorenzo Hall <>, Matthew Green <>, Nick Sullivan <>, "" <>
To: Daniel Kahn Gillmor <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
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 08:14:57 -0000

> On 15 Jul 2017, at 9:12, Daniel Kahn Gillmor <> wrote:
> On Sat 2017-07-15 05:58:31 +0000, Salz, Rich wrote:
>> Unless I missed the reply, I did not see any answer to my question as
>> to why it must be opt-in.  Do we think evildoers will tell the truth
>> about what they are doing?
> Because presumably the people who do *not* want to do evil want to avoid
> specifying a mechanism that will be widely implemented that could leak
> into use outside of the intended scenario.  right?
> As far as i can tell, we're all in agreement here that:
> * This proposed TLS variant is *never* acceptable for use on the public
>   Internet.  At most it's acceptable only between two endpoints within
>   a datacenter under a single zone of administrative control.

This TLS variant is only about using the same key share for a while. This is already done for optimization (as in “use the same key share for 1 minute before generating a new one”) although I guess for decryption a key would be used for longer than a minute.

The one difference between reusing a key share for optimization and reusing a key share for decryption is whether or not the server dumps this key share to disk. That is not a difference in TLS. In fact these two are indistinguishable. And that brings us back to Rich’s question: Do we expect evildoers to signal that they’re doing this?