IETF Logo Mail Archive

Re: [TLS] RFC4492bis - Removing ECDH

Michael Clark <michael@metaparadigm.com> Wed, 14 January 2015 12:22 UTC

Return-Path: <michael@metaparadigm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F7E1B2C79 for <tls@ietfa.amsl.com>; Wed, 14 Jan 2015 04:22:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoqnIJi7kQ7a for <tls@ietfa.amsl.com>; Wed, 14 Jan 2015 04:21:59 -0800 (PST)
Received: from tlsx.org (tlsx.org [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352111B2C78 for <tls@ietf.org>; Wed, 14 Jan 2015 04:21:59 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t0EChRaX001215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 12:43:30 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1421239412; bh=R14rErxXCA14Gl+bkQ2CGsbV4GaZOSTZ5/eLf1Q5VF4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=MsuZWU/zegbl0qF6Qa/huCxZRZKZbEYRrBVivTRHrfbjyWygFOrip/lqWdSCHqvpw GutqC3m2cEgvQLCbl/4Ccyol5ldoliXKbOTotODH+g4hryadYpQxYnCqfjrhOQiyQl htFHIL2XdnP/MZ1t0GO0wQhkUAZLRal35xMY78kc=
Message-ID: <54B65F52.6040707@metaparadigm.com>
Date: Wed, 14 Jan 2015 20:21:38 +0800
From: Michael Clark <michael@metaparadigm.com>
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 <ilari.liusvaara@elisanet.fi>
References: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> <CA5F50E8-9FEE-481D-85B5-9DEAB333F4A8@gmail.com> <54ADE9B6.4080700@metaparadigm.com> <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com> <54B1DD25.8090305@metaparadigm.com> <20150111051421.GA32295@LK-Perkele-VII> <54B65ADF.5020506@metaparadigm.com>
In-Reply-To: <54B65ADF.5020506@metaparadigm.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CKJTXvxM1eTMnwBuwaFJDRTs61o>
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] RFC4492bis - Removing ECDH
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jan 2015 12:22:00 -0000

> On 11/1/15 1:14 pm, Ilari Liusvaara wrote:
>> - 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.

*as* Windows XP.

> I'm trying to find where the 12 octet 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...

sorry garbled. I meant construct 96-bit collision to forge verify_data.

v2.23.0 | Report a Bug | By Email