Re: [TLS] Consensus Call on MTI Algorithms
Hanno Böck <hanno@hboeck.de> Thu, 02 April 2015 17:16 UTC
Return-Path: <hanno@hboeck.de>
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 9BEA21AD05C for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 10:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 BH0uW3uT8zsI for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 10:16:47 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3CD1ACDFA for <tls@ietf.org>; Thu, 2 Apr 2015 10:16:47 -0700 (PDT)
Received: from pc1.fritz.box (x4d06ffff.dyn.telefonica.de [::ffff:77.6.255.255]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 02 Apr 2015 19:16:45 +0200 id 000000000000005A.00000000551D797D.00005C37
Date: Thu, 02 Apr 2015 19:16:57 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20150402191657.43cd35ee@pc1.fritz.box>
In-Reply-To: <CAOgPGoBk+E=cNV1ufBaQ0n7=CJQ34zukPixKCEdpmMLBX=Kg_w@mail.gmail.com>
References: <CAOgPGoBk+E=cNV1ufBaQ0n7=CJQ34zukPixKCEdpmMLBX=Kg_w@mail.gmail.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-23607-1427995006-0001-2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/M72e3wYguGsK9AixU9tcy8bVtgk>
Subject: Re: [TLS] Consensus Call on MTI Algorithms
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, 02 Apr 2015 17:16:49 -0000
Hello, I have a number of issues with these algs, but I think these touch some fundamentals. Given that TLS 1.3 should get "things right" for a long timeframe I think we shouldn't shrink back from bigger decisions however. On Wed, 1 Apr 2015 11:12:19 -0700 Joseph Salowey <joe@salowey.net> wrote: > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 GCM: I have the feeling word of mouth in the crypto community is that nobody really likes GCM. The only reason it gained so much popularity is because it was "the only thing left" in TLS after CBC (in the MtE variant) and RC4 got under attack. I would like to discuss if this word of mouth is based on hard and if we come to the conclusion that GCM is not a particularly good cipher mode then I ask: Why should it be part of TLS 1.3 at all? Especially I hear again and again people have concerns that it's close to impossible to implement GCM timing-safe if there is no hw instruction support. That leaves the question what is better. One could of course say "go with chacha/poly as the default", because it seems to be popular. Arguments against: AES has widely hardware support and it's a well-respected standard. Other options: AES-CBC with EtM (Peter Gutmann just claimed here he thinks its less brittle than GCM) or other block modes (OCB?). > o Hash: > MUST SHA-256 Fine with that. > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 It's a bit similar to the issue above: It seems nobody really likes the NIST curves. Claims that it's almost impossible to implement them timing-safe. Even NIST doesn't seem to like the curves that much any more and they want to move on. And we had this painful discussion on 25519 now for such a long time and most crypto people seem to like it. Did we do that just to make it the second-best option? If there is agreement that curve25519 is superior to the nist curves then why keep the latter? (There's of course also this "issue" with the NIST curves and their random numbers of unknown origin, but it seems right now majority opinion is that it is highly unlikely this is a sign of a backdoor.) > o Signature: > MUST ECDSA P-256 > MUST RSA It pretty much follows from above: If we agree people don't like the NIST curves very much and every one likes curve25519 then ecdsa with p256 should go away. However there's even a stronger argument: ECDSA isn't that popular either. (RNG failures.) I'd like to add that RSA should preferrably be RSA-PSS (if we're talking about the connection handshake sigs - for the certificate sigs this is a different issue, for backwards compatibilty reasons it seems hard to require pss here). Conclusion: There seem to be a number of options in this MTI list that are algorithms that many crypto experts think aren't that good. I don't like that. I want TLS 1.3 to be based on algorithms people think are the best of their kind. (And add to that that I'm in full support of everyone saying that we should also try to not have too many options - just causing confusion, more attack surface and more complexity. One or two algs each and be done with it.) Hanno -- Hanno Böck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42
- [TLS] Consensus Call on MTI Algorithms Joseph Salowey
- Re: [TLS] Consensus Call on MTI Algorithms Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Consensus Call on MTI Algorithms Dave Garrett
- Re: [TLS] Consensus Call on MTI Algorithms Russ Housley
- Re: [TLS] Consensus Call on MTI Algorithms Dan Harkins
- Re: [TLS] Consensus Call on MTI Algorithms Aaron Zauner
- Re: [TLS] Consensus Call on MTI Algorithms Kurt Roeckx
- Re: [TLS] Consensus Call on MTI Algorithms Brian Smith
- Re: [TLS] Consensus Call on MTI Algorithms Dave Garrett
- Re: [TLS] Consensus Call on MTI Algorithms Stephen Checkoway
- Re: [TLS] Consensus Call on MTI Algorithms Sean Turner
- Re: [TLS] Consensus Call on MTI Algorithms Yoav Nir
- Re: [TLS] Consensus Call on MTI Algorithms Yaron Sheffer
- Re: [TLS] Consensus Call on MTI Algorithms Martin Thomson
- Re: [TLS] Consensus Call on MTI Algorithms Watson Ladd
- Re: [TLS] Consensus Call on MTI Algorithms Aaron Zauner
- Re: [TLS] Consensus Call on MTI Algorithms Rob Stradling
- Re: [TLS] Consensus Call on MTI Algorithms Yaron Sheffer
- Re: [TLS] Consensus Call on MTI Algorithms Stephen Farrell
- Re: [TLS] Consensus Call on MTI Algorithms Yaron Sheffer
- Re: [TLS] Consensus Call on MTI Algorithms Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Consensus Call on MTI Algorithms Russ Housley
- Re: [TLS] Consensus Call on MTI Algorithms Hubert Kario
- Re: [TLS] Consensus Call on MTI Algorithms Hanno Böck
- Re: [TLS] Consensus Call on MTI Algorithms Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Consensus Call on MTI Algorithms Salz, Rich
- Re: [TLS] Consensus Call on MTI Algorithms Rick Andrews
- Re: [TLS] Consensus Call on MTI Algorithms Nico Williams
- Re: [TLS] Consensus Call on MTI Algorithms Nico Williams
- Re: [TLS] Consensus Call on MTI Algorithms Nico Williams
- Re: [TLS] Consensus Call on MTI Algorithms Salz, Rich
- Re: [TLS] Consensus Call on MTI Algorithms Nico Williams
- Re: [TLS] Consensus Call on MTI Algorithms Christian Huitema
- Re: [TLS] Consensus Call on MTI Algorithms Nico Williams
- Re: [TLS] Consensus Call on MTI Algorithms Yoav Nir
- Re: [TLS] Consensus Call on MTI Algorithms Aaron Zauner
- Re: [TLS] Consensus Call on MTI Algorithms Nico Williams
- Re: [TLS] Consensus Call on MTI Algorithms Dave Garrett
- Re: [TLS] Consensus Call on MTI Algorithms Nico Williams
- Re: [TLS] Consensus Call on MTI Algorithms Eric Rescorla
- Re: [TLS] Consensus Call on MTI Algorithms Dave Garrett
- Re: [TLS] Consensus Call on MTI Algorithms Yoav Nir
- Re: [TLS] Consensus Call on MTI Algorithms Nico Williams
- Re: [TLS] Consensus Call on MTI Algorithms Dave Garrett
- Re: [TLS] Consensus Call on MTI Algorithms James Cloos
- Re: [TLS] Consensus Call on MTI Algorithms Peter Gutmann
- Re: [TLS] Consensus Call on MTI Algorithms Peter Gutmann
- Re: [TLS] Consensus Call on MTI Algorithms Aaron Zauner
- Re: [TLS] Consensus Call on MTI Algorithms Watson Ladd
- Re: [TLS] Consensus Call on MTI Algorithms Dave Garrett
- Re: [TLS] Consensus Call on MTI Algorithms Eric Rescorla
- Re: [TLS] Consensus Call on MTI Algorithms Russ Housley
- Re: [TLS] Consensus Call on MTI Algorithms Daniel Kahn Gillmor