Re: [TLS] RFC4492bis - Removing ECDH
Michael Clark <michael@metaparadigm.com> Thu, 08 January 2015 06:41 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 E41ED1A8864 for <tls@ietfa.amsl.com>; Wed, 7 Jan 2015 22:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.023
X-Spam-Level: *
X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AvbadAfV-uKC for <tls@ietfa.amsl.com>; Wed, 7 Jan 2015 22:41:09 -0800 (PST)
Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 0A8871A885D for <tls@ietf.org>; Wed, 7 Jan 2015 22:41:08 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id t0872VDU011836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 Jan 2015 07:02:35 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1420700558; bh=K27QGVcgSzRf1kr6MW5U5NPeun9UDgvF9V8gQlFFqj4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=VQRUPZZmWT4lCaiwmnEH5n3ZssiEVzSWaWGTcDxh90Qdo1auPWCxTCjlBfXkg9CHb B0bJsWL/6azfrFNCE6apKpWWmdudV8JkWOUVSYFZ7+fdo5D1M3zTnDJzH++0RZYFuO pjGN2yXOwqJJ+FseqKDP4MCKbR1Xe6eOfa2FLMUk=
Message-ID: <54AE2676.8020709@metaparadigm.com>
Date: Thu, 08 Jan 2015 14:40:54 +0800
From: Michael Clark <michael@metaparadigm.com>
Organization: Metaparadigm Pte Ltd
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: Yoav Nir <ynir.ietf@gmail.com>
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>
In-Reply-To: <702F318A-FE04-45F7-8CA1-30256D628CF7@gmail.com>
Content-Type: multipart/alternative; boundary="------------040209040106010203070303"
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/cj5xBHTWpG0zq2eZQmtKCJdMBRc
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: Thu, 08 Jan 2015 06:41:12 -0000
Hi Yoav, On 8/1/15 12:42 pm, Yoav Nir wrote: > My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH requires the CA to embed static named or explicit points in certificates. The practice is that implementations let server administrators choose and /sign/ *somewhat* ephemeral parameters e.g. secp256r1, secp384r1 works widely, but secp521r1 failed in my tests with Win8.1 IE11; this report matches my data point: (*3). I use the word /sign/ loosely until we have a proof that handshake messages can't be replaced in situ (*4). i.e. the client and server establish a chain of trust from their first Hellos to the pre-master secret establishment; which is possible with careful refinements to the protocol (constant salt in AD across all handshake messages). This of course then pushes an integrity problem down to another layer. i.e. DNSSEC (*5). > #4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video clips with crashing planes? I watched "Non-Stop" on an Singapore Airlines flight from New Zealand to Singapore in late-October, and at the same time noticed the plane altered course at Darwin, and instead of flying direct, flew over East Timor towards West Kalimantan (Borneo), completely avoiding the Java sea. Coincidence. Likely planning. "Weather". An AirAsia plane however sadly flew straight through the Java Sea during monsoon season. They had requested for new flight path and were denied due to heavy air traffic; so they flew on straight through a storm. My partner and I were boarding an A320 to Bangkok to Singapore 2 days after on Dec 30. http://www.rottentomatoes.com/m/non_stop_2013/ "Non-Stop" was about an Air Marshall who was trying to trace an unknown device on the plane sending him hijack threat messages, now they have WiFI and GSM... The reality is anyone serious would be using LoFi. "Non-Stop" is fiction. There is no need for MiFi. It human nature that people are angry when they are denied security (physical or ephemeral). I can separate fact from fiction. Rotten Tomatos gave it the thumbs. It was an okay movie however I think I liked it more because I was watching it on a plane. I am aware in the case where the CA is not in the trust store; and this is noticeable to the user, and there are techniques such as public key pinning in HTTP headers (which relies on establishing the first connection on a trusted network as a proxy could easily re-write the pins). The security needs to go down to the next layer. I still believe there is a rationale to (not in spite of RSA and other digital signature algorithms, rather to enhance them), make the client software aware, not just the user in the case of certificate tampering. Otherwise the browser needs a database. The policy could be that the client can indicate to the user that the handshake has been tampered and an implementation chose to accept invalid tags however I suspect it might be a slippery slope towards tamper free TLS handshakes. i.e. net neutrality. packets that arrive as they were sent. Someone will like derive a closed user group derivation of TLS once they are aware of this, if this kind of strategy is not adopted (assuming it is possible). I am still reasoning about adding HMAC on handshake messages with constant (client|server)_random as AD in all handshake messages (HMAC_SHA2_𝑛). My reasoning probably has flaws or this would have been solved. The MAC from the ClientHello MAC from the client may need to be signed by the cert and returned in the Finished message from the server. We have to distinguish between the HMACs that are *sent* not *seen* and perhaps use the *sent* in key derivation or tamper detection. This allows the browser to know at the TLS level (versus via the trust store) that the handshake was modified "in flight" (no pun intended). The browser developers and therefor the user can distinguish and take appropriate action. There is a distinction between untrusted cert and a tampered handshake that isn't currently exposed to the TLS client. I'm thinking of the rewriting case and reasoning about it... The client knows the MAC of it's ClientHello so it may need to be included in the Finished message signed by the servers certificate (and a MITM would need to change it). The server *sees* the MAC of the ClientHello it receives, not necessarily the one that was sent. It's almost like an HMAC of the handshake messages (from both sides as they were *sent*) needs to contribute to the pre-master secret, and each side knows what they sent. The tamperer would need to HMAC his tampered message. I will think some more about it... My thinking may have flaws... >> It raises another question. Is DH_anon a misnomer? Should it be DHE_anon? Is it used anywhere in practice? > It is a misnomer. It is not used on the web, but it is used in some situations. For example, my company’s firewalls use it to establish the initial trust between a firewall and the management station. They will establish a TLS connection with DH_anon (should be DHE_anon, I guess), and then run certificate enrollment over that. Forward progress. It probably wasn't incorrect at the time until there was context for the distinction. 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