Re: [TLS] Consensus Call on MTI Algorithms

"Blumenthal, Uri - 0553 - MITLL" <> Thu, 02 April 2015 17:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 487931A014D for <>; Thu, 2 Apr 2015 10:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P5jq4Yfkq72M for <>; Thu, 2 Apr 2015 10:28:09 -0700 (PDT)
Received: from (MX1.LL.MIT.EDU []) by (Postfix) with ESMTP id 5AE0D1A006B for <>; Thu, 2 Apr 2015 10:28:06 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id t32HRVmu012686; Thu, 2 Apr 2015 13:27:31 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "''" <>, "''" <>
Thread-Topic: [TLS] Consensus Call on MTI Algorithms
Thread-Index: AQHQbKdrrgxSnl5sOUuqebcfK2nw3Z06O2SA//+/2f8=
Date: Thu, 02 Apr 2015 17:27:31 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-02_06:2015-04-02,2015-04-02,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504020165
Archived-At: <>
Subject: Re: [TLS] Consensus Call on MTI Algorithms
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Apr 2015 17:28:12 -0000

Well, I for one do like GCM (the fact that more platforms now provide hardware acceleration makes me like it even more :), and I like NIST curves (and already have the code to deal with them). 

I guess those who dislike either one (or both) are just more vocal. 

P.S. I also like OCB, especially considering the license Phil Rogaway granted OpenSSL (or was it to TLS protocol at large? :). 

Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

MIT LL Root CA:  <>

----- Original Message -----
From: Hanno Böck []
Sent: Thursday, April 02, 2015 01:16 PM
To: <>
Subject: Re: [TLS] Consensus Call on MTI Algorithms


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

On Wed, 1 Apr 2015 11:12:19 -0700
Joseph Salowey <> wrote:

> o Symmetric:
>         MUST AES-GCM 128
>         SHOULD ChaCha20-Poly1305

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 Böck