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

Peter Gutmann <> Mon, 21 March 2016 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A61D612D770 for <>; Mon, 21 Mar 2016 05:43:21 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QML2XKkyXiyC for <>; Mon, 21 Mar 2016 05:43:21 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B5F4012D748 for <>; Mon, 21 Mar 2016 05:35:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1458563729; x=1490099729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HmKpoMpO9UNzcP04iRCfz/R/LyDE5SSE8u1S4Stm9Bg=; b=RE4w0j1exPphH68/5jcMdpY2BCFkPHXWDfKTsVcObVjmgP7annRmgo56 WHzrXwuZvDjz2cIt/qPi8sNcNilPIkgE5HTWi40OcH9o9N/kUR1RCW6O6 n8BSAuzf75U/LTH9ns7VVYiuwvwWmr+y5PR7H/Pt2EmYh9K6q5Gr02v7c AyZ2XFkGMYw31+vJwwwTHOdbGxrlk0KNpmC0slr7NaFbCrXVA4ttudx5O iPZ7PkSmss3VD6iwOtYsisVz8fCg5CX3YZzpslNHoR823ijEg3CQ0dPRg lM46XmjwctKgGgLjHddWD0DqG610iVM1zIJZ0rAv5PRPelF9AK0KTxQLw A==;
X-IronPort-AV: E=Sophos;i="5.24,372,1454929200"; d="scan'208";a="75556981"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 22 Mar 2016 01:35:27 +1300
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Tue, 22 Mar 2016 01:35:25 +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//9JUAIAByROrgAJscYCAAOwz3w==
Date: Mon, 21 Mar 2016 12:35:25 +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: <>
Cc: "" <>
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: Mon, 21 Mar 2016 12:43:21 -0000

Hubert Kario <> writes:

>Note that I asked for "being able to handle", not "selects and uses".

The issue here is that a Cortex M3 isn't going to be able to handle RSA-2048,
no matter what an RFC says :-).  That's what the "ability of the hardware to
deal with large keys" was meant to say.

When I've run into upper limits, it's almost always because the hardware can't
go much beyond the given upper-limit value (Sun's Java implementation with its
braindamaged 1024-bit upper limit for DLP keys was a notable exception).  So I
could perhaps say something like "implementations SHOULD handle key sizes of
up to 2048 bits, and MAY expect to see key sizes up to 4096 bits" or something

>no, it's not, not in TLSv1.2. If it does override section of RFC
>5246, you need to be explicit about it.

Maybe I'm missing something here, but the text that refers to signing with
"RSA-SHA-256" and "ECDSA-P256-SHA-256" seems to be pretty unambiguous.  Is
there something else I need to add there?

>The implementation will need to interoperate with normal (i.e. already
>deployed) TLS 1.2 implementations anyway, why prevent code reuse?

Right, and if you need that you can include all the extensions you want.  If
you only need TLS-LTS, you can leave them out.