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

"Paul Bakker" <p.j.bakker@offspark.com> Thu, 27 March 2014 13:14 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 426941A06EE for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 06:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.094
X-Spam-Level:
X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AB6Lj_bvegTq for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 06:14:07 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 166FA1A0055 for <tls@ietf.org>; Thu, 27 Mar 2014 06:14:07 -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=jYcTQ1hrsP9e6bt1gkVTYb9+C96Ecqw+ehXZAE1H9mY=; b=UP/NTMfUhSPNiyNrpCN8N2VRX1capQowsa3WC1egrn5PDzNOMktLnoASjVFa4QzLK7Mzg0hxXh+OcQ5Z6KptFVW+MPXkRMI5vTiB0/pj0W6LSmvrHP9mRR3ZIpEyi4arfPUJDDLh0IfbtPDeFvpkx4KWWUofmdjvz6m9FSWFCgg=;
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 1WTA82-0005ZN-56; Thu, 27 Mar 2014 14:13:56 +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> <02c101cf49b9$5d080da0$171828e0$@offspark.com> <3d2bb399-b932-4bc1-89d0-848260e0036d@email.android.com>
In-Reply-To: <3d2bb399-b932-4bc1-89d0-848260e0036d@email.android.com>
Date: Thu, 27 Mar 2014 14:13:51 +0100
Message-ID: <02e401cf49be$698ff650$3cafe2f0$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFCyZKiN8ZEGaLHNGhiDtIsYJ3IqQINCKjVAjGxmm8CObuRPQI27pteAt/6p9AAgmRGqZutWZjA
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/pXSvq0vVaejSFRlL-0llrHbNwTY
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:14:08 -0000

> Maybe, if you're that constrained, you don't *really* want TLS and its
x.509
> luggage at all: AES-GCM or ChaCha20-Poly1305 and a monotonic counter
> nonce? And if you want forward security, and you probably should, then you
> probably want... curve25519.

I don't think my advice to those developers would be to 'invent' their own
security channels. Most of them don't have the experience to do it right.
And they're bound to make mistakes that have been fixed or mitigated in TLS.
TLS as a whole is low-footprint enough with the right conditions.

Of course, the pure PSK suite does not have X.509 luggage. But that's beside
the point.

And most developers don't have a choice. While I agree that some could
better do something else, certain standards and / or certifications require
usage of TLS.

> I certainly don't see how that's a good argument for keeping DHE around,
> which is the fattest of the key exchanges. Seems rather like the opposite,
> actually.

I never said we should keep DHE around! Just that we should not mandate a
single other key exchange mechanism. I agree that DHE is fat and is not the
best of the available choices.

But things like PSK and PAKE-based key exchanges have their merits as well..

Paul Bakker