Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 02 December 2014 18:19 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 780AB1A6F27 for <tls@ietfa.amsl.com>; Tue, 2 Dec 2014 10:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=0.6] autolearn=no
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 NMB5hLewxnWF for <tls@ietfa.amsl.com>; Tue, 2 Dec 2014 10:19:58 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA641A3BA2 for <tls@ietf.org>; Tue, 2 Dec 2014 10:19:58 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 40B1D282FD0; Tue, 2 Dec 2014 18:19:57 +0000 (UTC)
Date: Tue, 02 Dec 2014 18:19:57 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20141202181956.GX285@mournblade.imrryr.org>
References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> <547DC339.80800@streamsec.se> <20141202174033.GW285@mournblade.imrryr.org> <547DFF6F.6080505@streamsec.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <547DFF6F.6080505@streamsec.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Lmi_d-XH9euNzhDDqCDz2c3ch_0
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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, 02 Dec 2014 18:19:59 -0000

On Tue, Dec 02, 2014 at 07:05:35PM +0100, Henrick Hellstr?m wrote:

> On 2014-12-02 18:40, Viktor Dukhovni wrote:
> >Given the far from universal support for ECDSA by clients, a server
> >that wants to use ECDSA when possible, but still wants to interoperate
> >with more than just a select few clients really SHOULD have both
> >ECDSA and RSA certificates.
> 
> Fair enough, but is it really an acceptable outcome that a fully conformant
> server (that is deployed with only RSA certificates) and a fully conformant
> client (that only implements one of the mandatory ECDSA cipher suites) will
> not be able to negotiate a connection?

This document does not replace the mandatory to implement cipher
suites in TLS 1.x.  So the client and server MUST still both offer
the usual (RSA-based) MTI cipher suites for each version of TLS
they support.

The text in question provides additional ciphersuites that conformant
implementations SHOULD support.  So in your example, a client that
suports ECDH(E) only with ECDSA, will employ neither EC based key
agreement nor EC based authentication.  The various MTI cipher
suites don't require either.

This said, perhaps the asymmetry between the client and server
requirements deserves more explanation.

-- 
	Viktor.