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

Karthikeyan Bhargavan <> Sun, 20 March 2016 12:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C398F12D559 for <>; Sun, 20 Mar 2016 05:02: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 FvC9qXyCg_zi for <>; Sun, 20 Mar 2016 05:02:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8682012D520 for <>; Sun, 20 Mar 2016 05:02:39 -0700 (PDT)
Received: by with SMTP id p65so90982310wmp.0 for <>; Sun, 20 Mar 2016 05:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j5UtiA/F3z6DX3yxfx4GACmiaPcg0b0VlOzBYVcQnk4=; b=DMKEZf+X1EjULFF+Nehw0803NF8tZ5Ih+NRdicy3/4peAK8wDTYRlrDg6CnoslSsOG C/XKlXZbHoRwkzu0y6mFt1WO5FLTcXEnBGR6PiIty/378LKL/G8h0PDHJ7WIAlVMjA9y LaohsNZ2giX9OQOOIDRd1YVTddUNk+xn4aHb8aA3caovktFtNRfvP9PYh5vnvG/ySLv2 alPPPYodZGi6WRpVAojHUJ2EXo5AKJlOQM1iK06Q8XOAzCt31Imxlb5LZxCDoGHFYbvq wT7SI+v3FgXrHOw0XZ0yKSUa5mxHUk4n/FQDtxHLUgbenwlb8nQ0DBwrxg7U4ZyDk/WL 7mLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j5UtiA/F3z6DX3yxfx4GACmiaPcg0b0VlOzBYVcQnk4=; b=UXVrCrSukqn5/eM1EkCGB+YcV+i7shtCkvT/2GyIlkNa+6t4vfq1DY9Lj2lLKcEWLq Ua+rUaX9tWL2AuDYdt17yBT7rLLzlcnpEC94eBtrJgBPI2hxbuWNK/9dVNSEn084gSIA ZeyHi/MJMCmWmsDpC2DHpiOtUnKobJ2buktQoOoi69p9jIbn+5uXtSXy//PwJCTCbNQm HDxKWn4g74VAj4cNHVgDcmBVVa0QrTq+/CEq89xN1kOgpZGD19RvFb/CGDEP2LN6tZR8 K407MTMvj/0n32/uMxASblAEf4kTL8D+2jXtiOMfu/lRVn6U1b7QCiPM9Mh++2rAR/by 4mLQ==
X-Gm-Message-State: AD7BkJJTSufrLw7gD2BEPeeqYOXbIWBZP8KLxovnCYnCLQw9KeooXUEPVEBjCMMTynlIIQ==
X-Received: by with SMTP id j16mr8624089wmj.78.1458475358011; Sun, 20 Mar 2016 05:02:38 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t8sm20391394wjy.41.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 20 Mar 2016 05:02:37 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Karthikeyan Bhargavan <>
In-Reply-To: <>
Date: Sun, 20 Mar 2016 13:02:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.3112)
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 12:02:42 -0000

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

Indeed, the hash required for EMS is usually the same as that required for client authentication,
so implementations that support client auth already support this, others may not.

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

Adding the handshake hash to the ServerKeyExchange (a la EMS) provides
some nice protections against downgrade and seems to be worth the effort.

Of course, for all of these LTS improvements, we need to assume that the
LTS extension itself cannot be deleted by the attacker. That is, we’d assume
that the client or server supports *only* LTS mode. Otherwise, we’d have
to look closer to eliminate other downgrade attacks.


>> 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
>> contexts
> 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...
> Peter.
> _______________________________________________
> TLS mailing list