Re: [TLS] Consensus Call on MTI Algorithms

Nico Williams <> Thu, 02 April 2015 18:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2650A1A1A2C for <>; Thu, 2 Apr 2015 11:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id litgIbRWQRM9 for <>; Thu, 2 Apr 2015 11:48:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 665271A0687 for <>; Thu, 2 Apr 2015 11:48:51 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 3BF89160D; Thu, 2 Apr 2015 11:48:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=33sIBnjqiW7xhS YKbLf9TT9unfQ=; b=pl44cZLOo98bqH1cyHh34CmLHuiwc1Tnw9f7RvLnJ714KX f+QMSuhoyjBi+y0p0c8NiFA7se7x5uXmqBgXjNk1FKnhY0YR2sGOhyQtnjzQztW2 lH/2y7pdGDjt2BUpLm9aFhJR3PaxUBPU+nuLU0/y/Bhx1XJI5tw5d6GCNuejQ=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id E32CF160C; Thu, 2 Apr 2015 11:48:50 -0700 (PDT)
Date: Thu, 02 Apr 2015 13:48:50 -0500
From: Nico Williams <>
To: Joseph Salowey <>
Message-ID: <20150402184849.GF10960@localhost>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Cc: "" <>
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 18:48:52 -0000

On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote:
> [...]

I'd like to have at least two required algorithms for each class, at
least for the 128-bit security level.  The rationale is: to make it easy
to switch one off if it becomes a problem.

We've already had to disable broken algorithms in a hurry in several
Internet protocols including TLS.  We should learn the lesson: we should
aim to have at least one left.

In all cases recall that required-to-implement != required-to-enable.

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

I would like at least two modes for AES to be required: one AEAD
(probably GCM) and one AEAD-by-generic-construction (e.g., using HMAC).

I would like one non-AES cipher to be required.  ChaCha20-Poly1305 works
for me.

Total: three required algorithms.  Here I want three because I'm not
sure that GCM is easy enough to implement and use safely in all
environments (see Watson L.'s comments on this), and because I'd like
two ciphers just in case.

> o Hash:
>         MUST SHA-256

I would like two hash functions to be required.  I don't have a strong
preference as to the second hash function, but I like SHA-3.

> o Key Agreement: ECDH
>         MUST P-256
>         SHOULD 25519

By the rationale above I would like both of these to be required.

> o Signature:
>         MUST ECDSA P-256
>         MUST RSA

Ditto.  We won't have the luxury of waiting until CFRG blesses an ECC
signature scheme other than ECDSA, but when they do... we should add
that to the list.