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

Hubert Kario <> Mon, 21 March 2016 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D948812D641 for <>; Mon, 21 Mar 2016 07:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DHVBa6ygYkkZ for <>; Mon, 21 Mar 2016 07:38:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70ADC12D520 for <>; Mon, 21 Mar 2016 07:38:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id E2293B8939; Mon, 21 Mar 2016 14:38:50 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u2LEcn4o004180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 10:38:50 -0400
From: Hubert Kario <>
To: Peter Gutmann <>
Date: Mon, 21 Mar 2016 15:38:43 +0100
Message-ID: <>
User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4232841.RrqJr5uJ9M"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
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 14:38:59 -0000

On Monday 21 March 2016 12:35:25 Peter Gutmann wrote:
> 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.

even 10 seconds to establish a session that is then kept up for days 
and/or uses session resumption is something many environments would be 
able to handle.

If your hardware really can't do anything better than 2048 bit RSA, it's 
not LTS, it's a crippled embedded system, and it definitely shouldn't 
get a stamp of approval "good for next X0 years" or anything similar 
like a LTS moniker would imply.

Also, you're explicitly saying that this proposal is limiting the TLS 
parameter set to "known-good subset". 1024 bit RSA and DHE are not 
known-good, if Cortex M3 really can't handle RSA-2048, for crypto it's 
as good as a coaster already.

the system is only as strong as the weakest link

> 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 similar.

there's a similar limit in NSS with client certificates, although I 
don't remember the exact number now, I'm quite sure that a 8k key would 
get rejected.

> >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?

it doesn't explain where this "RSA-SHA-256" is used. IMHO it is 

The "no MAC truncation" is also not explicit about what the sizes should 

> >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.

my point is, that the code path of the tls-lts extension should check 
the sanity of extensions passed and abort if anything is not according 
to the LTS when LTS is supposed to be enforced.

in other words, LTS should be an addition to already existing code, not 
a replacement.

You may be dealing with hardware that often requires careful pruning of 
code base to make it fit. Thing is, that there are also millions of 
devices which can handle full OpenSSL/PolarSSL/etc. just fine. And for 
those it's better if the code paths used are the same or as similar as 
possible in all situations. Any other approach leads to subtle and hard 
to find bugs. Exactly what we don't want to see in LTS code.

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic