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

Peter Gutmann <> Sun, 20 March 2016 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CC1F12D6D3 for <>; Sun, 20 Mar 2016 04:49:32 -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 2ZguTmb64sML for <>; Sun, 20 Mar 2016 04:49:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74BF412D6BC for <>; Sun, 20 Mar 2016 04:49:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1458474569; x=1490010569; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zUOW6mNAae2akBItv6ucW85uskj4FE5RvHJ7YiLiPhM=; b=4g4DQjp0Yy9+ZSuqaIh0WmMZLnK2sKEJ9KIpZvHoXkyOGRmvt3s0lA6r Soe9PAaTvp1onO0KWo+JRMxKSxOJMUmDJE4Xs1T92y8jvQsavoYn4iUIM QFmAJ4r2bc6qv7/jAAh8G80fLZ8JHxu5yKhs/bMG6TdcxxKrtsFVyiqjI fiAiS/V3vjLW/jy3l/X4LPqOO8toFnX0RPN04QoyV2fXo1e8V68seLxuT rDCviHEXvtR35Vdw9plYemFEraDE9BqoDBX3IEdQnq1wzWgLPjxYX2Ehi tcsq9e9gbr9P7xTbUvEO3ARk8CSpxvfIgAVpPq9sRKbRCgx3ZqmCmCewv Q==;
X-IronPort-AV: E=Sophos;i="5.24,365,1454929200"; d="scan'208";a="75314470"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 21 Mar 2016 00:49:25 +1300
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Mon, 21 Mar 2016 00:49:24 +1300
From: Peter Gutmann <>
To: Ilari Liusvaara <>
Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted
Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egCSfaaAACoKC6r//3MHgIAA5Mgg
Date: Sun, 20 Mar 2016 11:49:23 +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: Sun, 20 Mar 2016 11:49:32 -0000 <> writes:

>Well, if you have suitable implementation for it, the hash in EMS is over
>prefix of what hash in Finished is over (so if you can finalize multiple
>times, you can get away with just one computation).

The problem with this is that the standard hash API is { Init, [ Update,
Update, ... ], Final }, so this only works if you've got access to a custom
API that allows you to fork the state so one branch goes to Final and the
other continues with Update.  It's good if you've got it, but a lot of
implementations don't.

>Also, TLS 1.2 ServerKeyExchange signature is not taken over ClientHello and
>ServerHello. This was famously exploited for FREAK and LOGJAM (and then there
>is the DHE vs. ECDHE issue). Sadly, this was found out too late for changing
>EMS extension to extend the signature.

Hmm, what do people feel about adding this as a fix?  Given that the attacks
were based on implementations supporting crippled crypto when they shouldn't
have and accepting an export cipher suite when they shouldn't have (i.e. they
were pretty broken to begin with), is it worth the compatibility-breaking
change to try and address this?

>Then there is the problem that DHE parameter sizes are not negotiated. This
>is severe enough problem that it renders DHE effecively unusable in some

That's such a can of worms there that I don't really want to get into it in 
-LTS, unless lots of people really want to see it addressed...