[TLS] New Algorithm identifier for EDH > 1024 bits?

Phillip Hallam-Baker <hallam@gmail.com> Thu, 26 September 2013 14:15 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9065B21F9346 for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 07:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DHIVQDK9e54V for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 07:15:08 -0700 (PDT)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id ECA1C11E80D2 for <tls@ietf.org>; Thu, 26 Sep 2013 07:15:07 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id x18so1114604lbi.38 for <tls@ietf.org>; Thu, 26 Sep 2013 07:15:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TELM+kWDtXgi5SjcqiiwmFDEeXcKNjtr3RDFNu8+bBE=; b=AHZzZTN/BOmFX7wWSc5jZs3n6BhWurGd4yfkpMHUrxd4XVPzwwtSZ20xcVA9WgUuWE oFWa3pFMcuuRhfnmas4IQlb4gqyqClkaPZJ39ArB93H1FhXL9b0Tk+Jh8v5e+Z8Fn8K7 o56qmdU/GIVnbeRuffDAOsK/b1yi0ygsGwovZsATwQwK19KlIgHdQttLd92D84FPeTcj kHM55vc/zchFN465c2Y49rUtzVME/E7midgz4EpWOgevKNv0Lu5DGJdceSqbTdihFaVn x9P7CpzHXMXjEyX9obdGBuIk/HJe0/Z4HGGoBXrFLusMgYBc5/tWc8x5j+hFYp0xs1TO zq3g==
MIME-Version: 1.0
X-Received: by with SMTP id vt7mr4057771lbb.29.1380204902221; Thu, 26 Sep 2013 07:15:02 -0700 (PDT)
Received: by with HTTP; Thu, 26 Sep 2013 07:15:02 -0700 (PDT)
Date: Thu, 26 Sep 2013 10:15:02 -0400
Message-ID: <CAMm+Lwioy8Z+wo7czrOT+5-HOf-G=8X3MF-bEjX2L0uxsXhO8Q@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e0112c136ea0cb704e749fe09
Subject: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 26 Sep 2013 14:15:14 -0000

My understanding of the 1024 bit Ephemeral DH key issue is that it is not
currently possible to use longer keys because a certain number of deployed
Web servers will abort the connection if a client presents a longer key.

Hmmm, wonder who made that decision...

Regardless, this is not a problem that will solve itself. Even if
presenting a longer key will cause a connection to abort in 0.1% of cases,
browsers are not going to make the attempt. So if nothing is done the
legacy servers will prevent use of longer DH keys for the next 20+ years.

I don't think a TLS version number upgrade is the solution either. It is
just a bad idea for an algorithm suite identifier to mean one thing in TLS
1.2 and another in TLS 1.3.

The simple solution to this problem in my view is to specify a new
algorithm suite identifier for DH larger than 1024 and use that in
parallel. That might get us to a point where 25% of Web Servers are using
very strong EDH within 12-24 months.

Website: http://hallambaker.com/