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

"Paul Bakker" <p.j.bakker@offspark.com> Thu, 27 March 2014 12:37 UTC

Return-Path: <p.j.bakker@offspark.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 AF51D1A0067 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 05:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.993
X-Spam-Level: *
X-Spam-Status: No, score=1.993 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] 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 W3ypJCsP6TY5 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 05:37:55 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6B1A0055 for <tls@ietf.org>; Thu, 27 Mar 2014 05:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=offspark.com; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=SX7BxpphVXTHNGIcpiz/LQMFuzk3vesqEIfS9kBRro8=; b=IMm8A0gJHNHNn3q8XtfYCr3iUxG5AQ5xnNgvHI0SJ9cVKALqVygA60rHMGQeo+wBkQtL75cq8ipWz/Y0CNxsJ+Tk0u5I0GTt1dXPKFMb8znvhsOWCsm48janau1Pl7J/uyx1QPFek2YYJOKPao7+b4wkEfGlUnZ3ZBONWLPET/w=;
Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <p.j.bakker@offspark.com>) id 1WT9Z3-0005Ri-LU; Thu, 27 Mar 2014 13:37:46 +0100
From: Paul Bakker <p.j.bakker@offspark.com>
To: 'Alyssa Rowan' <akr@akr.io>, tls@ietf.org
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>
In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com>
Date: Thu, 27 Mar 2014 13:37:43 +0100
Message-ID: <02c101cf49b9$5d080da0$171828e0$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFCyZKiN8ZEGaLHNGhiDtIsYJ3IqQINCKjVAjGxmm8CObuRPQI27ptem8hjk0A=
Content-Language: nl
X-SA-Exim-Connect-IP: 82.161.132.220
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JIqHEI0De05t4XkdJQ-Nc0GFrFw
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 12:37:56 -0000

> Suggestion: remove static RSA *and* traditional DHE and mandate ECDHE for
> key exchange in TLS 1.3. I propose,
>  curve25519 as mandatory-to-implement and secp256r1 as recommended-
> to-implement [? Also mandatory, maybe?], both in constant time, which is
> comparatively easy, especially for 25519.

Let's not do that.. The world is bigger that 'Fat clients'. Other key exchanges, such as pure PSK have their value in very-low-resource situations.
And I think it's never a good idea to depend on a single key exchange scheme, for future security robustness.

> That would simplify the protocol considerably (decreasing the code and
> protocol surface to audit), increase its baseline security well above 2048-bit
> DH, to ~3072-bit (ish) levels, reduce the size of the exchanges and massively
> reduce the CPU load on both servers and clients.

I do agree that we should make the core as secure as possible, but we should keep all kinds of clients and servers in mind..

Paul Bakker