Re: [TLS] RFC4492bis - Removing ECDH
Michael Clark <michael@metaparadigm.com> Wed, 14 January 2015 12:03 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 9BDEA1B2C6D for <tls@ietfa.amsl.com>; Wed, 14 Jan 2015 04:03:01 -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 4l187mdGwM9P for <tls@ietfa.amsl.com>; Wed, 14 Jan 2015 04:03:00 -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 322C91B2C6C for <tls@ietf.org>; Wed, 14 Jan 2015 04:03:00 -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 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; d=metaparadigm.com; 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: <54B65ADF.5020506@metaparadigm.com>
Date: Wed, 14 Jan 2015 20:02:39 +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>
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 klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rLNglg5866Fy9DX1izUL5QOg85c>
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: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... Michael
- [TLS] RFC4492bis - Removing ECDH Yoav Nir
- Re: [TLS] RFC4492bis - Removing ECDH Yoav Nir
- Re: [TLS] RFC4492bis - Removing ECDH Michael Clark
- Re: [TLS] RFC4492bis - Removing ECDH Yoav Nir
- Re: [TLS] RFC4492bis - Removing ECDH Michael Clark
- Re: [TLS] RFC4492bis - Removing ECDH Nikos Mavrogiannopoulos
- Re: [TLS] RFC4492bis - Removing ECDH Michael Clark
- Re: [TLS] RFC4492bis - Removing ECDH Michael Clark
- Re: [TLS] RFC4492bis - Removing ECDH Ilari Liusvaara
- Re: [TLS] RFC4492bis - Removing ECDH Nikos Mavrogiannopoulos
- Re: [TLS] RFC4492bis - Removing ECDH Yoav Nir
- Re: [TLS] RFC4492bis - Removing ECDH Michael Clark
- Re: [TLS] RFC4492bis - Removing ECDH Michael Clark
- Re: [TLS] RFC4492bis - Removing ECDH Ilari Liusvaara
- Re: [TLS] RFC4492bis - Removing ECDH Michael Clark