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

Wan-Teh Chang <wtc@google.com> Thu, 26 September 2013 14:51 UTC

Return-Path: <wtc@google.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 4063311E810A for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 07:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 ED4jjz-0i-7d for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 07:51:45 -0700 (PDT)
Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFAC11E814F for <tls@ietf.org>; Thu, 26 Sep 2013 07:51:43 -0700 (PDT)
Received: by mail-oa0-f47.google.com with SMTP id i1so800835oag.34 for <tls@ietf.org>; Thu, 26 Sep 2013 07:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bqm/sIB0/m0gj488Nv3VBSYqU3R8a3R9iZIQ+oAMGb4=; b=oh5XNC+zok0y7qaDGl1bcuOAgej69IO2DqfJV/v3RabrYYdL9cmT1HAimMMTc1RgFv NlSc0J6VlrmxU7ZianKWt6P0OKIX2NeYdH+JNRVogox5g7RzPrdOHJSjN3FksEuxn8iD Qe8H+kjI8UL9kGiwcVqmx6Cc0UNUPPMEtzECgYAqWS2UGnjWQrdzzjV6cl0gjvBvhYLq qUDDDk18hJRT7pbw9YE9Cfol0turOSGaswwQuN0u2kWHlKuG8bvqq0BIbjsKPN5MbVHa zEbVEDRUN3DjjAcrDi/Wlq/xVdlE0/RMxrspnA2QvBiJror7YHBiAP4VGiGRQcX6ToZG P6MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bqm/sIB0/m0gj488Nv3VBSYqU3R8a3R9iZIQ+oAMGb4=; b=jrZnrmHPEUKD9PP5Ne3fyctOgTyotf5QwGhgccGmrjERWm090GBIw1Z6suJBbr0/+G Ho57xX9+xnvSx4qiDlmFfa4LZYZxlpnz4lxsPXysB5JW+21BtQYx+AE/YYsB0w8YjObz BzzvbGiN2aoxLm+HwN10z1jQLGo4C8jtjpCNX50nCCMTnW/OTvniThLyKUeShP5qG/SN aUobvtdGJIz2k7amx5756qwPgZkaW2tu8g1wmVrKJrS73IaR0i9tDt/W/eFmuAkWeDPA Fi8Dnb3jHKY2AHxIKP2i8D0kcyfOwEkiDaBVP0VMl07pGTi5IKr7OWQ2kcLbdFyrJRnw WE3A==
X-Gm-Message-State: ALoCoQnQ2EUqzqvl4WQ7BQNRyOcnsaPNy7SRoH+uoZ4EhpeA9bKz9OMSrvbMYRg4sSEyyZAE6ouEe3yIqJRgFVNLS7To7v04hmnSK6UAZwocXan5Ld7TYMG7tZW0La6k2GqGezl0TNQCgBT+37ylpOFOd2ERE+FDvpFiRMXyn4pjZ8cZKBe3hR4+0NvrsGB/nVkyaPE6oZ4f
MIME-Version: 1.0
X-Received: by 10.182.246.7 with SMTP id xs7mr642660obc.81.1380207103509; Thu, 26 Sep 2013 07:51:43 -0700 (PDT)
Received: by 10.182.79.105 with HTTP; Thu, 26 Sep 2013 07:51:43 -0700 (PDT)
In-Reply-To: <CAMm+Lwioy8Z+wo7czrOT+5-HOf-G=8X3MF-bEjX2L0uxsXhO8Q@mail.gmail.com>
References: <CAMm+Lwioy8Z+wo7czrOT+5-HOf-G=8X3MF-bEjX2L0uxsXhO8Q@mail.gmail.com>
Date: Thu, 26 Sep 2013 07:51:43 -0700
Message-ID: <CALTJjxHeJ8WVuaTfSa5G7xQ1F21VRpYuQ0nDsym8vGL_MOrEVQ@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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:51:55 -0000

On Thu, Sep 26, 2013 at 7:15 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> 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.

The size of ephemeral DH keys is specified by the server, and the
client must present a key of that size. (This doesn't change the
problem though.)

The client needs a way to negotiate the ephemeral DH key size (or the
DH domain parameters) with the server. This can be done by either an
extension (similar to the elliptic_curves extension of RFC 4492 for
ephemeral ECDH keys) or new cipher suites.

Wan-Teh Chang


>
> 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/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>