Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 27 March 2014 13:17 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 840AD1A06B9 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 06:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.612
X-Spam-Level:
X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_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 07z4V7HaNyrT for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 06:17:51 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id D059E1A0055 for <tls@ietf.org>; Thu, 27 Mar 2014 06:17:50 -0700 (PDT)
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2RDHlK4022500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 09:17:47 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2RDHiLh024181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 27 Mar 2014 09:17:46 -0400
Message-ID: <1395926264.19721.25.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Alyssa Rowan <akr@akr.io>
Date: Thu, 27 Mar 2014 14:17:44 +0100
In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com>
References: <AD51D38F-2CFE-4277-854D-C0E56292A336@cisco.com> <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aNdHPnwdYZcvyZsaeGc_FZcj-UQ
Cc: tls@ietf.org
Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3
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, 27 Mar 2014 13:17:52 -0000

On Thu, 2014-03-27 at 12:27 +0000, Alyssa Rowan wrote:
> On Thu, Mar 27, 2014 at 09:55:27AM +0100, Hanno Böck wrote:
> > Appart from the other issues, I think it would make a lot of sense to
> > change DHE handling in TLS 1.3 away from "server can have arbitrary
> > parameters".
> 
> I'm wondering: why even keep DHE around at all?

Agility. I agree the DHE ciphersuites are problematic in TLS, but we
also need agility. A cryptographic advance in elliptic curves may not
translate to an advance in the "traditional" mod p fields, and in that
case it would be nice having fallback ciphersuites, rather than suffer
the issues of a monoculture.

Nevertheless, I find discussions on such details fruitless at this
point. I agree with Trevor that first it has to be discussed what
process will be followed in the TLS 1.3 process. From the current
discussions in the list it feels that TLS 1.3 will be 1.2 minus some
features.

regards,
Nikos