Re: [TLS] Confirming Consensus on supporting only AEAD ciphers (Martin Rex) Tue, 29 April 2014 18:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 005101A093E for <>; Tue, 29 Apr 2014 11:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yDsIAiJnUQMw for <>; Tue, 29 Apr 2014 11:27:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4721A1A091D for <>; Tue, 29 Apr 2014 11:27:53 -0700 (PDT)
Received: from by (26) with ESMTP id s3TIRit9002232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Apr 2014 20:27:45 +0200 (MEST)
In-Reply-To: <>
To: Fedor Brunner <>
Date: Tue, 29 Apr 2014 20:27:44 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers
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: Tue, 29 Apr 2014 18:27:55 -0000

Fedor Brunner wrote:
> The Mandatory Cipher Suite for TLS 1.2 was TLS_RSA_WITH_AES_128_CBC_SHA.
> What is the mandatory cipher in TLS 1.3 ?
> Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for

Support for ECC is/was a mere option in TLSv1.2.
The specification of Curve25519 for use with rfc4492 is not yet
standardized, same for ChaCha and Poly1035.

What you're asking for is something that has very little in common
with any prior version of TLS, and in particular ZERO interop with
the currently installed base.

TLSv1.2 (rfc5246) had the intention to be backwards-interoperable
with the installed base (otherwise they would have not added the
silly definition of an (md5,rsa) digital signature to TLSv1.2
(you may want to remove that bogosity from the v1.3 draft),
but the amount of interoperability problems with the installed
base was significantly enough to deter adoption of the protocol
for >4 years.

Looking at the amount of changes that are being considered and
discussed here for TLSv1.3, I would not be surprised if the
resulting adoption rate for TLSv1.3 would make the IPv6 adoption rate
appear blazing fast...