Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

mrex@sap.com (Martin Rex) Thu, 19 September 2013 02:06 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA7811E8170 for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 19:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.196
X-Spam-Level:
X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWIXxZ8zJQtv for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 19:06:52 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4B211E80D7 for <tls@ietf.org>; Wed, 18 Sep 2013 19:06:52 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8J26gIE020554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 04:06:43 +0200 (MEST)
In-Reply-To: <20130919013304.1D5EB1A983@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Thu, 19 Sep 2013 04:06:42 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130919020642.8F5621A983@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2013 02:06:57 -0000

Following up to myself:

> 
> The TLS WG could have easly provided an adequate PFS solution
> many years ago that could be trivially enabled for all existing
> implementations.  Ephermeral RSA.  99% of the code is already
> present in all implementations, because this is used in the
> RSA_EXP cipher suites.
> 
>   http://www.ietf.org/mail-archive/web/tls/current/msg01541.html
> 
> (EC)DHE is a mess, because both, servers and clients will regularly
> have to regenerate new keys, and there are going to be severl 
> different keys necessary for the preferences of various servers
> and sometimes, the client-side key generation will have to be
> performed inline.  How many different keys will clients need
> for ECDHE?
> 
> With Ephemeral RSA, only the server has to generate the temporary
> RSA keypair, and can *ALWAYS* generate the ephemeral RSA keypair out-of-band.

What I had not remembered from the past discussion, and just
found in a later reply from EKR:
   http://www.ietf.org/mail-archive/web/tls/current/msg01556.html

was the design "feature" (I believe it is a defect), that
the ephemeral key exchange in the server key exchange handshake
message exists only in a an exteremely paranoid variant, requiring
an additional private key operation for every handshake.

It would really help if client and server could negotiate the use
of alternative "signed parameters format" for ephemeral (RSA) keys
that do not require a seperate signature (=private key operation)
for each handshake, but where the signed parameters could be reused
for several hours, maybe using a time-based indicator for the
freshness of the ephemeral keypair.


-Martin