Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 11 November 2014 09:00 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 0C5DB1AD611 for <tls@ietfa.amsl.com>; Tue, 11 Nov 2014 01:00:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 jEUru-C5RJb2 for <tls@ietfa.amsl.com>; Tue, 11 Nov 2014 01:00:44 -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 CC7851A8549 for <tls@ietf.org>; Tue, 11 Nov 2014 01:00:44 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAB90ega031323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 11 Nov 2014 04:00:40 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAB90cvO027987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 04:00:39 -0500
Message-ID: <1415696437.1938.6.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Sean Turner <turners@ieca.com>
Date: Tue, 11 Nov 2014 10:00:37 +0100
In-Reply-To: <AA93BAA4-5C5F-4969-8DF6-A83287D80F6D@ieca.com>
References: <AA93BAA4-5C5F-4969-8DF6-A83287D80F6D@ieca.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/epspzve6RwbgZ58JAJqARqMpZUM
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
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: Tue, 11 Nov 2014 09:00:51 -0000

On Mon, 2014-11-10 at 17:17 -1000, Sean Turner wrote:
> All,
> 
> This message is confirming the WG consensus we reached in Toronto about producing an updated RFC4492 that is bound for standard track.* Yoav has produced an individual draft that can be found here:
> 
> http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/
> 
> that we would like the WG to consider adopting.  Please let us know by November 18th whether you object to adopting Yoav’s draft (and why).

Two points:
1. This document includes fixed ECDH ciphersuites (ECDH_RSA,
ECDH_ECDSA). Given they have 0 deployment on the internet, the question
is why? What are the practical use cases of these ciphersuites and why
should they be defined in a standards track document.

2. This document includes arbitrary curve support. What is the rationale
for including that as no implementations support that [0], and even for
DH we are switching from arbitrary to named groups as well (I also
ignore the known attacks for this option).

Unless there is sufficient argumentation and applicability for the
above, I support the document only with the above removed.

regards,
Nikos

[0].
http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves