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

Stephen Farrell <> Fri, 07 July 2017 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A31EB131678 for <>; Fri, 7 Jul 2017 13:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Status: No, score=-4.302 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] 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 PxfBaoPO58e1 for <>; Fri, 7 Jul 2017 13:18:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A12B124217 for <>; Fri, 7 Jul 2017 13:18:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 157CCBDF9; Fri, 7 Jul 2017 21:18:46 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PlKf3nkrbrus; Fri, 7 Jul 2017 21:18:44 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id AF67DBDD8; Fri, 7 Jul 2017 21:18:44 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1499458724; bh=tmvQ33bSBPGaPaaiSa6V/mC7EcMqneTrJvlR/u3RpvU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=W7qL74k9WJ+BtMQroIRrMiyRwkvkedaa5qNBhrgN8aIl43tZlguErEiR6oscU4GiS lcLrXOUNJ5SO1gwABMpHYIOcYjhZXdeURYplDQSs6ctl2YzjujIaatxTy2WfdoIXJT NunJaq46DtRnv/NlI7ZhOvYnR3NapuyGbSAPwSMc=
To: Russ Housley <>
Cc: IETF TLS <>, Matthew Green <>
References: <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Fri, 7 Jul 2017 21:18:43 +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="IPKjRPDAT2S3KB3Oh2HWVVadVWeSclrrN"
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: Fri, 07 Jul 2017 20:18:51 -0000


You didn't refer to 2804 and the standards track. As an
author do you really think this can be on the standards
track and yet not obsolete 2804?

If you do, then I don't understand that. (And would argue
you are holding a counter-factual opinion.)

If you do not, then why does the draft say "standards


PS: I disagree with other assertions below but the above
has to come first as we need to know if the authors are
or are not asking the IETF to change a major policy.

On 07/07/17 21:04, Russ Housley wrote:
> Stephen:
>> On 07/07/17 19:40, Kyle Rose wrote:
>>> an informational draft submitted via the ISE
>> ...has nothing to to with this WG and ought consume
>> no cycles on this list or in meetings.
>> Yes, the ISE is the route 2804 envisages for documenting
>> wiretapping schemes such as this.
>> The authors of this draft however chose to put "standards
>> track" in the header and some of those authors are very
>> very well aware of all the nuances here so that was not
>> a mistake is my conclusion. So I stand by my statement
>> that 2804 says no to this.
> As Kyle quoted, RFC 2804 says that we should be talking about the design.  It seems to me the only way to make this proposal more secure is to talk about it.  And, the TLS WG has the people with the proper expertise for that discussion.
> The enterprise wants forward secrecy on the public Internet. Terminating the TLS session at the load balancer preserves forward secrecy on the public Internet.
> We already had a discussion on this list about requiring a fresh ephemeral DH key for every session.  The consensus was not to require it.  I understand that there are already servers that use the same "ephemeral" DH key for more than one session.  I gather that this is done for performance reasons.  
> The conventions described in draft-green-tls-static-dh-in-tls13-01 for using non-ephemeral DH keys has no impact on interoperability.  Discussion of that topic could easily go in an Informational RFC.  Many Informational RFCs describe crypto algorithms.  On the other hand, the protocol between the key manager and the server for installing the non-ephemeral DH key has an impact on interoperability, so it could be in a standards-track document.
> In your response, you ignored a fairly significant point in my previous post.
> 	In some industries, there are regulatory requirements that cannot be
> 	met without access to the plaintext.  Without some authorized access
> 	mechanism, the enterprise will be forced to use plaintext within the
> 	datacenter.  That seems like a worse alternative to me.
> From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating outdated crypto, like RC4 or MD5.  Instead, it is using exactly the same crypto algorithms and key sizes as draft-ietf-tls-tls13.  Again, this seems like a much better way forward than plaintext throughout the datacenter.
> Russ