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, 2 Apr 2015 19:16:57 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= <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