Re: [TLS] Dropping "do not stick out" from ECHO

Christopher Wood <caw@heapingbits.net> Mon, 23 March 2020 02:57 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2D63A0986 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2020 19:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=gAyF1QHU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rfXPI2NR
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 Xn8JE57vUjez for <tls@ietfa.amsl.com>; Sun, 22 Mar 2020 19:57:18 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331F13A0985 for <tls@ietf.org>; Sun, 22 Mar 2020 19:57:18 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 295965C019C; Sun, 22 Mar 2020 22:57:17 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 22 Mar 2020 22:57:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= J6M857C8rEF3WOmLFRL+enASwTUx4nOoraFm95Jdw2A=; b=gAyF1QHUsAOuoBcE FhhVeinbvtk9izr9MaA6RSlpBjaQvTUTMDhRmf5Zfv98xVvipNVknK5N7GZS2TcG ldQjYZl8Bv6IR3LDtBk9PRFvNkV0mDbLw3ryNoEw7xnQPxEwQkdT8XpRvwpclU0o 2i93gHxuBUhb8sG6EwrwEQvDlsIUGFyZYE238FMMfhrAecHtr0TgfSf9QoIuEEfl EjOuEfkDdefWlpPboDKRmasK+V29yMM05lJsf9sCRkQgtNEVVX5lZBw4PBs9zdL3 +MuhzKHvHYPFEUjiBNXYM7VkOuFTWx0UT8x0hDR5w9KGe9qHoIHRvpbNAiEIqIRF tg3geQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=J6M857C8rEF3WOmLFRL+enASwTUx4nOoraFm95Jdw 2A=; b=rfXPI2NRfxOrW7fHAKJO7BrOkZ3n2wgNT0nh4XbnKaiEUw5esuZg844VM D8oUM7zvoj4MN011c80fmVLS7O5RsV+EMLIUjH7PCOhxYrZ3cszHz7IrYLWaN9gO P3sbcJeeiDje3Lul3GajsxSO8iL3Bm8OLgYsQH/UgeA3MauoUWs+F0X0HZaIQ5OT JZH6cix4OjKN3QTaXMuEGSBK+/UnmAcLOIb+z2rmi1NgTtxiNtCwAokLbUrnY2B7 barRPN+iB/JF6pegJ9ymgBLmo8t3ATa2GteuE8jOlRypK07B/8e2oTnGGzF2y1+s CBE8W4FHE2hf1QW4falEyeGJUioZw==
X-ME-Sender: <xms:jCV4XvQR2pcKzWLqCHJjTDT4nosgmk9c9Zp0QsIIyqCKmv_QtkoTbg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegjedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffoffkjghfgggtgfesthekmhdtredtjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecukfhppeejfedrledvrdeigedrudeftdenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:jCV4Xrfil5dhfMY3uhZyQJFjVLOSZlAHXPy_kYKMyejuZsh1w4ipPQ> <xmx:jCV4Xti7kWGw28RV3SwOVvqqljhiHuMptGxJb86XmIdLPc2h1CuFZA> <xmx:jCV4XmKt5q73RweO3JYXGT9o82lluI83xHw-OGotfnkLVD6GlaV1KA> <xmx:jSV4XgzhLJkdncehDyCJmVeMG2V-1-BuvKU1q7Xr6HVywDdvwtuhRQ>
Received: from [10.0.0.184] (c-73-92-64-130.hsd1.ca.comcast.net [73.92.64.130]) by mail.messagingengine.com (Postfix) with ESMTPA id 3AB093280059; Sun, 22 Mar 2020 22:57:16 -0400 (EDT)
From: "Christopher Wood" <caw@heapingbits.net>
To: "Martin Thomson" <mt@lowentropy.net>
Cc: tls@ietf.org
Date: Sun, 22 Mar 2020 19:57:14 -0700
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <2654A188-27DD-4F38-AB93-BCE47F68D2B3@heapingbits.net>
In-Reply-To: <2c2103b2-5d92-415d-88bb-1a3a6be95075@www.fastmail.com>
References: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net> <2c2103b2-5d92-415d-88bb-1a3a6be95075@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tvJx0setNnskI6eCR2Q20kcdy_M>
Subject: Re: [TLS] Dropping "do not stick out" from ECHO
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 23 Mar 2020 02:57:20 -0000

On 22 Mar 2020, at 16:10, Martin Thomson wrote:

> On Mon, Mar 23, 2020, at 03:54, Christopher Wood wrote:
>> I propose we remove this requirement and add an explicit signal in SH
>> that says whether or not ECHO was negotiated.
>
> Here's a spitball signaling option that might not stick out:
>
> Client sends (in the ECHO) a random value, N, with 32(?) < |N| << 128. 
>  And N != either of the values we reserve for signaling downgrade.
>
> Server sends that value in the ServerHello.random, in the same place 
> we signal downgrade.
>
> If the client sees that value, then it proceeds with the trial 
> encryption with an expectation that it will work.

We’ve discussed variants of this in the past. It’d work as a signal. 
However, CH modification attacks to figure out whether a connection uses 
ECHO exist. One of them, pointed out offline by David Benjamin, is to 
remove all ciphersuites from the outer CH and see what happens with the 
connection. Preventing this would likely require us to revisit the 
binder approach, which was always complex enough to beg the question: is 
the juice worth the squeeze?

Like Stephen suggests, I think working on a stealthy variant of this 
later on is probably the best path forward. (I think we’re close 
enough to the Tor and Pluggable Transports orbit as is.)

>> (This will require us to revisit GREASE.)
>
> I'm not following how this relates, sorry.

Sorry, it’s not the specific SH extension signal that would require 
this. It’s the general question of whether or not we should drop (or 
relax) this “do not stick out” requirement. As Ben pointed out, 
knowledge of valid record_digest values, which we should assume is known 
to the adversary given that these are public, makes this difficult with 
GREASE.

Best,
Chris