Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Dave Garrett <> Thu, 17 March 2016 08:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9412A12D8C0 for <>; Thu, 17 Mar 2016 01:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S-o74EsfEbMJ for <>; Thu, 17 Mar 2016 01:00:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FFD912D552 for <>; Thu, 17 Mar 2016 01:00:39 -0700 (PDT)
Received: by with SMTP id y89so66189732qge.2 for <>; Thu, 17 Mar 2016 01:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=Y7IO2omxnuUP9MWMcridbLgp3aACdqIKwX5oKL7F1Xg=; b=uLpJrEBhznyhR/pmppo+UVPSBPbym2FZmw89gcKuMH8NqI+w1VkJKd5p3VhD89p7TH XLEQyLc6DJhuTDj5Aj0D8nxYlvu+j/YCZ3XrNGWmcSuTQgfY6u1Pc1fMZNqIDMoOwith vuzt04jGpzmZ3mpOY/4pG6WTFWP4B7k5h0/EjClIjmkfIT8tqauHG0O5+fJwQWeWIaUj qKD7cWjInl/ooEgwtctEcuz3GvTPPA46vl5ZCmu/Js6JJQ7gkYPW87bjJ/2dmqy0W+aq NGIX8UKJiJ7TA7eU4yrYV6z/EItAWTNGaTOVkj3KcAwTwgGM7GhMJ/95tGT/LRmg09F7 Pa1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=Y7IO2omxnuUP9MWMcridbLgp3aACdqIKwX5oKL7F1Xg=; b=B/Bu3QJ6st+manhYwpPAh/SFjdyvy8UzZo01SHtSmDWxNG31q4azq4ZsWLtFqqm6FM nBBuaH66AwfvNZIqNrAg6IH5XqUVyQkdzflK+fN0KbUdYcAwpSFqY4tL6jlOIEURShYp 3i2fhMmWq0i9GlpwAmBo6HQxYuesfPyVWrQ96TjCmI8IV7QBV6fpfv7E4aIOCBd7gQhP IW38QAbgHKOuzGTMf3FNeZ+kGuigp3UowGmo0gU8LG4ygBEz9TCraTGoQdkxWtVdfH2O Tc50YLoHnZ703TjNAXyAfwyfONype+NUARbSMMO/rFzS+mjaqz4hTeD/sFCgdz1darb7 KBOg==
X-Gm-Message-State: AD7BkJLmNK5s+CQD1pqEGkJ5lNER+pvnOROhhUGMdf8dmrPrfHI0Sj9QlPYF47U6xCtclA==
X-Received: by with SMTP id o133mr12957373qhb.33.1458201638189; Thu, 17 Mar 2016 01:00:38 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id b24sm3306201qkj.31.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 17 Mar 2016 01:00:37 -0700 (PDT)
From: Dave Garrett <>
To:, Peter Gutmann <>
Date: Thu, 17 Mar 2016 04:00:35 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
X-Mailman-Version: 2.1.17
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, 17 Mar 2016 08:00:41 -0000

On Wednesday, March 16, 2016 08:36:05 am Peter Gutmann wrote:
> After a number of, uh, gentle reminders from people who have been waiting for
> this, I've finally got around to posting the TLS-LTS draft I mentioned a while
> back.  It's now available as:

Allowing CBC+encrypt-then-MAC seems like a messy route when AEAD is already available and deployed more widely. If you want to permit it, please make it optional and only have AEAD ciphers as MTI.

Also, you should add a recommendation/requirement of ChaChaPoly support in there so that there will be a backup in the long-term in the event of the need to panic disable AES under TLS 1.2 for some unforeseen reason. This is aiming to be an LTS, after all.

The big glaring problem, however, in multiple places, are the statements that something is "implicit in TLS-LTS, there is no need to signal it" via its designated extension. No! These features MUST be implemented in full, according to their specifications, such that they will work fully with servers that support them but not this new LTS proposal. Skimping on this just makes this messy situation even messier, which is the opposite of what you're trying to do here.