Re: [TLS] RFC4492bis - Removing ECDH

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 08 January 2015 09:04 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC41ACCDF for <tls@ietfa.amsl.com>; Thu, 8 Jan 2015 01:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRydHHWHfNmg for <tls@ietfa.amsl.com>; Thu, 8 Jan 2015 01:04:41 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192CB1ACCDC for <tls@ietf.org>; Thu, 8 Jan 2015 01:04:40 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0894cMX025588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 8 Jan 2015 04:04:38 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0894Za8032764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2015 04:04:37 -0500
Message-ID: <1420707875.11993.4.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Michael Clark <michael@metaparadigm.com>
Date: Thu, 08 Jan 2015 10:04:35 +0100
In-Reply-To: <54ADE9B6.4080700@metaparadigm.com>
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> <CA5F50E8-9FEE-481D-85B5-9DEAB333F4A8@gmail.com> <54ADE9B6.4080700@metaparadigm.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kRtRMikawv7Fn09t6HZIPg7byRo
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Jan 2015 09:04:43 -0000

On Thu, 2015-01-08 at 10:21 +0800, Michael Clark wrote:
> Hi,
> It raises another question. Is DH_anon a misnomer? Should it be
> DHE_anon? Is it used anywhere in practice?

That's a nice question. No DH_anon and ECDH_anon was not a misnomer.
They are often (or always?) used with ephemeral keys, but some other use
of them is with static non ephemeral keys, which will be used to verify
the server's identity on reconnect. Pretty much, no authentication, but
key continuity. That was never documented in the text though, but I
remember seeing it in mailing list discussions. I think that's the
reason of the missing 'E'.

regards,
Nikos