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

mrex@sap.com (Martin Rex) Thu, 19 September 2013 01:33 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 0BBAA11E81DE for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 18:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.192
X-Spam-Level:
X-Spam-Status: No, score=-10.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 lOEkH0V43g5e for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 18:33:20 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8211E81E1 for <tls@ietf.org>; Wed, 18 Sep 2013 18:33:20 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8J1X4mh001184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 03:33:04 +0200 (MEST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Thu, 19 Sep 2013 03:33:04 +0200 (CEST)
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: <20130919013304.1D5EB1A983@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
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 01:33:25 -0000

Peter Gutmann wrote:
> Yaron Sheffer <yaronf.ietf@gmail.com>; writes:
> 
> >Please see the later discussion, in particular
> >http://www.ietf.org/mail-archive/web/tls/current/msg09924.html.
> 
> I've been following the discussion, but none of it really supports going to
> 2048 rather than just 1280 or 1536.  In addition, as Yoav pointed out, there's
> a big different between solving the DLP in 1024 bits and stealing an any-size-
> you-want long-term RSA key.


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.


I'm not a cryptographer, but I'm actually not convinced that
counter modes of AES are a road I want to travel.  (I'm wondering:
do we actually know the length of the cycles of AES in counter mode?
Is there a paper describing what assumption the security of counter
modes are based on, and formal proofs that AES actually has all
these properties?)

I have not yet seen anything worrisome about AES-CBC.  And the
CBC padding oracle that Vaudenay complained about could have
trivially been fixed in TLSv1.1 already, since the problem, and
its solution, were described in Vaudenay's paper.  We can still
fix it with Peter's proposal. 


-Martin