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

Peter Gutmann <> Sat, 19 March 2016 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB58112D5A3 for <>; Sat, 19 Mar 2016 02:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 OaRxwQVEMZgG for <>; Sat, 19 Mar 2016 02:30:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6F7112D591 for <>; Sat, 19 Mar 2016 02:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1458379857; x=1489915857; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y6rNcdFSc2DqNh8wl83qQlMY+/kwqXsXLcZK0RsfGY4=; b=pQMIlcRqbfaIvEjxFFF7JlEieRI7NlbHL1Oaq8Uxi4LGDN99Qlw3jO6x QwppaCFVjZ95gZ83pygtYVOgjTL8KTzNmfkRaQGuBZjYwjX5ynbUZe8aU UGVhkntcXArB8K3m7QpB6GqzuZKD1dowzx7sBwgJWiaonzLj8NfYKTKL/ h0dty4WwMADn92npk2TU6qLjhwzMflVG8i2jYvZhckMtyWNU/G51OCtBl GW5XbUaeCst2B34zDYdo0pFD65yjP5ZvHoqyc/WfC8mjCRClwZ+E70coF DqZ7CyjyT90c4RJcHuODK0y37FAEvDUXWYcBzyQEFaJhlbTErvKGmJsMA w==;
X-IronPort-AV: E=Sophos;i="5.24,360,1454929200"; d="scan'208";a="75186239"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 19 Mar 2016 22:30:26 +1300
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Sat, 19 Mar 2016 22:30:26 +1300
From: Peter Gutmann <>
To: Hubert Kario <>, "" <>
Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted
Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3D//9JUAIAByROr
Date: Sat, 19 Mar 2016 09:30:26 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Sat, 19 Mar 2016 09:31:03 -0000

Hubert Kario <> writes:

>also, if it really is supposed to be Long Term Support, why it doesn't say
>anything about implementation explicitly being able to handle big key sizes?
>both RSA and DHE?

I've deliberately avoided getting into that because it's such a rathole,
you've got everything from the NIST numerologists at one extreme to the "good
enough for now" folks at the other, and you'll never get any consensus because
there are completely different worldviews involved.  A possible median is:

Implementations SHOULD choose public-key algorithm key sizes that are
appropriate for the situation, weighted by the value of the information being
protected, the probability of an attack, and the ability of the hardware to
deal with large keys.  For example a SCADA system being used to switch a
ventilator on and off doesn't require anywhere near the keysize-based security
of a system used to transfer classified information.  One way to avoid having
to use very large public keys is to switch keys periodically.  This can be
done by regenerating DH parameters in a background thread and rolling them
over from time to time, or if this isn't possible, by pre-generating a
selection of DH parameters and choosing one at random for each new handshake,
or again rolling them over from time to time.

>I might have missed, but where is the specification of the acceptable
>signature algorithms (hash especially) on Server and Client Key Exchange

That's implicit in the cipher suites, RSA or ECDSA + SHA256.