Re: [TLS] RFC4492bis - Removing ECDH

Michael Clark <> Wed, 14 January 2015 12:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9BDEA1B2C6D for <>; Wed, 14 Jan 2015 04:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4l187mdGwM9P for <>; Wed, 14 Jan 2015 04:03:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 322C91B2C6C for <>; Wed, 14 Jan 2015 04:03:00 -0800 (PST)
Received: from monty.local ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4) with ESMTP id t0ECOS5O001057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 12:24:31 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=klaatu; t=1421238273; bh=jyk2gZIEtCnVSMles2ASWNuPKAjzgbNuwhEHKXFzLyI=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=SP4rKaOB9J7RGR57vP6UGAyAuYqh4RtELJQRdNrS53MAYs1PkQiGLduDFk1bGaRLc +IY6XCA+58GN1Fti7MJq1hAUyICLtWjEq1m9aVCQnEptH0Tmu+e8gcCEReQmBnjD/2 WbPzl07slfcD5PFnHi0TAa7ahza7MYRKXj/rTjjM=
Message-ID: <>
Date: Wed, 14 Jan 2015 20:02:39 +0800
From: Michael Clark <>
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ilari Liusvaara <>
References: <> <> <> <> <> <20150111051421.GA32295@LK-Perkele-VII>
In-Reply-To: <20150111051421.GA32295@LK-Perkele-VII>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at
X-Virus-Status: Clean
Archived-At: <>
Cc: " (" <>
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-Mailman-Version: 2.1.15
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: Wed, 14 Jan 2015 12:03:02 -0000

On 11/1/15 1:14 pm, Ilari Liusvaara wrote:
> On Sun, Jan 11, 2015 at 10:17:09AM +0800, Michael Clark wrote:
>> There is a more subtle pass through case where handshake messages can be
>> tampered with (without access to a CA, just an Internet coffee bucks
>> WiFi tap). Allows attacks such as editing cipher lists and any other
>> associated handshake metadata (curve format extensions, switching on
>> compression) that are not properly authenticated. Until I am certain
>> they are completely mitigated I remain skeptical.
> This attack won't work.
> - TLS 1.3: The messages are hashed into hMS, so you can't decrypt the
>   rest of the handshake due to having wrong keys.

This was my thinking however I could not read this clearly in the text
as the record protection for handshake was stated as NULL NULL AEAD.

I am still looking for clear text in {{key-calculation}} that describes
that a strong authenticator of all sent handshake messages are returned
to each end signed in the Finished message.

Can we differentiate a tamper from garbled data?

Anyway it offers no protection against the yellow patch cable to the
grey box. There are many CA certs in the vendor trust stores. If you
sent 3 certs from CAs with no relationships then you could eliminate
this kind of tampering. multi-rooted. Verify is only a cost for 24H
(given session caching and ticket timeout is sorted).

> - TLS 1.0-1.2 w/o false start: The Finished values will fail to verify.
> - TLS 1.0-1.2 /w false start: The selected crypto must be strong, or
>   endpoints won't enage in false start.

OK In TLS 1.2 the spec states there is no record protection for
handshake messages. I see verify_data field in Finished. It is vaguely
specified in RFC5426 and RFC5288 (AES-GCM) makes no reference to it.

However I am still skeptical as there is no record protection for
handshake messages so I don't know what is preventing the proxy from
returning illegal_parameter to the client hello until the client does a
TLS1.0 ClientHello and then edit the cipher list remove SCSV and cause
client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

I'm trying to find where the 12 octect verify_data is specified. If
*all* of the the handshake payload is in a MAC in verify data then you
could generate still generated ignored extensions to get a 96-bit hash
collision. Still reasoning about it...