Re: [TLS] Consensus Call on MTI Algorithms

Brian Smith <> Wed, 01 April 2015 19:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 554F51A9044 for <>; Wed, 1 Apr 2015 12:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AZ-G1-x6Hl07 for <>; Wed, 1 Apr 2015 12:56:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF7321A9041 for <>; Wed, 1 Apr 2015 12:56:46 -0700 (PDT)
Received: by obbgh1 with SMTP id gh1so90998586obb.1 for <>; Wed, 01 Apr 2015 12:56:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Yt7H7qcVqT0p+GWC4bVIZbDffGJsu7P6lE7OJ5wubD8=; b=DQhfkneGtpOVG8J+6ipusC555Gs4fuayW9qTwMn/OAXg+U2DS5twlTM+U95njxc2nr MQ7s0Ffb5AfRAnagJ0AG2UzhXSksijxlTbECeX02PQPSlXtSIzi/iqbHm2leM18dLIwp dXSRin+nKet0xiKnzLSIQ5dQ48CvWjCEu5HIFlOJe7Ohe83aEFSVhRAYFqmGwmT0GB3n xkq1tbSh4eSpp/1BYq+wVd0CW2LiQs2w038DV6kXSXznEuthE8xN2km+kheEy8OaYGsj iUfT1tB18H9Dfny6uixuBFnfDlV7t0tWJS2BWSWSFC9kCEWGPKIxM/AvzLYZdrgpN3Ar gr/Q==
X-Gm-Message-State: ALoCoQmwIs8M3+ltADCbwjYlHaDd1CaQLvhXxkzX809GnJ81Djuz5b9XyXZxMwRcLN/leU/8C5aA
MIME-Version: 1.0
X-Received: by with SMTP id qu1mr42419228oeb.83.1427918206275; Wed, 01 Apr 2015 12:56:46 -0700 (PDT)
Received: by with HTTP; Wed, 1 Apr 2015 12:56:46 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 01 Apr 2015 09:56:46 -1000
Message-ID: <>
From: Brian Smith <>
To: Joseph Salowey <>
Content-Type: text/plain; charset="UTF-8"
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: Wed, 01 Apr 2015 19:56:48 -0000

Joseph Salowey <> wrote:
> o Symmetric:
>         MUST AES-GCM 128
>         SHOULD ChaCha20-Poly1305

Like others, I think that ChaCha20-Poly1305 should be MUST. It uses
256-bit keys and so it better protects against future quantum and
square-root attacks compared to AES-GCM 128. Also, it is easy to make
a constant-time implementation of ChaCha20-Poly1305 that runs on a
wide variety of hardware, but it is not to easy to do so for AES or
GCM on many times of hardware.

Accordingly, I suggest instead that ChaCha20-Poly1305 MUST be
implemented unless AES-128 GCM *and* AES-256 GCM are implemented in a
constant time manner.

> o Hash:
>         MUST SHA-256

AFAICT, it is not necessary to specify a mandatory-to-implement hash
function separately from the mandatory-to-implement cipher suites and
mandatory-to-implement signature algorithms, because the hash function
to use is always a function of the cipher suite or signature algorithm
in TLS 1.2 and later.

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

"RSA" is ambiguous. For RSA, please specify which padding scheme(s)
and which parameters must be supported. I would recommend "MUST
implement RSA PKCS#1 using the same digest function used in the PRF of
the selected cipher suite."

Similarly, "MUST ECDSA P-256" should be changed to "MUST ECDSA P-256
using the same digest function used in the PRF of the selected cipher

If the requirements for mandatory-to-implement signature algorithms
are intended to also apply to certificates and certificate
verification, then ECDSA P-384 and SHA-384 MUST be implemented. The
reason is that CAs often choose algorithms for signing certificates.