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

Peter Gutmann <> Sun, 20 March 2016 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D5FA12D751 for <>; Sun, 20 Mar 2016 05:37:19 -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 KmwFFuzJQWQG for <>; Sun, 20 Mar 2016 05:37:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1A1412D6FB for <>; Sun, 20 Mar 2016 05:37:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1458477438; x=1490013438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aaVZtAGQRBIRRnPrjLxJkp/tDp70gUpV+x2UpEJaTRs=; b=Gqn2YN+nohLBUHegpICn8H18rfJYLc/7RJ+e9D0rMkgPcapYcXzR+wxn JRQcQKwOQW6hI6PQzvkNRYz0XEzndB3YjGvwAdSHZFxgvYXfP0zRAWRZe CmWOa2DkMWquF3RaYF2vstWaNY2Iu5KkbbwKUm+VYWpxEI6PvyE+8QtHG u0OveCqfdpJ/5GUxpGvSsdKVmCaKq2rIc9U8EZeoJh4/AQtMENcSkx4B5 ZgO63m0oNU0PbmYvcs9BCSxflyy7eZcdjArjDCGYSWqSKAIG0kSKMplPI 3PBr8JHgEaTVPF7eWjnU51fz10IxLMh6Ws2afyZW16nowUR7GeP4DGAGP w==;
X-IronPort-AV: E=Sophos;i="5.24,365,1454929200"; d="scan'208";a="75319752"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 21 Mar 2016 01:37:16 +1300
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Mon, 21 Mar 2016 01:37:15 +1300
From: Peter Gutmann <>
To: Karthikeyan Bhargavan <>
Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted
Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egCSfaaAACoKC6r//3MHgIAA5Mgg//8p5wCAAOOLTw==
Date: Sun, 20 Mar 2016 12:37:15 +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="Windows-1252"
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 12:37:19 -0000

Karthikeyan Bhargavan <> writes:

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

My only real concern with this is that if you've got an API that doesn't allow
forking, you're now running three hashes in parallel.  Still, for everything
else it'd be pretty straightforward, fork once after Server Hello for the
Server Keyex sig and a second time after Client Keyex for EMS.

So presumably instead of hashing the bare nonces for the keyex sig you'd hash
the entire hello message that contains them?

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

There's an SCSV-shaped hole in the draft for that :-).