Return-Path: 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 CFB493A086C for ; Sun, 22 Mar 2020 09:54:20 -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=S3iUxXb8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=M12Zt8Qc 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 io7cuIWuAGmA for ; Sun, 22 Mar 2020 09:54:18 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBD23A086A for ; Sun, 22 Mar 2020 09:54:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6575C5C0092 for ; Sun, 22 Mar 2020 12:54:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 22 Mar 2020 12:54:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=from:to:subject:date:message-id:mime-version:content-type; s= fm3; bh=MS/Wu7ZqVArW7bw8UzCs6Opg7NGy5zhBNe3cicAPQcE=; b=S3iUxXb8 0RKhkCdUTqg+Fh2juciThNM41PWvkHDJymsN3/+zhhTtHJI07CgqfKSVCITMqbHH RVSjt+Ge906A4GFHcu98PPfnXlrfsxPZwhJLZbv9zdEcaVDQTnU0xdjeBHyoFFA4 hUbJCSlelOg8Yp7tfnXtmMZjwWjmOlj98oXseSxbrotcEtSQvJwTHgHYm9Zw7eDe yn2v6V+NsC1eV4OmfceZgX6LUCbSowhDnFeLI5w20Az64mCod4QcXdUyHsNg+940 SjXt0al2m/jXNExVSL0JlRD20EDyrUgfqrU7jF/YoM5WiFoN1b2+zh+p+NnzQA+O 1NulXDwNrNvXug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=MS/Wu7ZqVArW7bw8UzCs6Opg7NGy5 zhBNe3cicAPQcE=; b=M12Zt8Qc63d8nL6t2xwqKgfcQJVIAN+ZZARN1j0OxJ/v2 PzyUaSH+omudW0vt+frM19lqcoViqgU70PpdOj2eM5cmwHfSQAsXtLW9MO1EZX9z 161EX5ULhCWQ0cHdpBjjK5aXK0jQGcVng74wYqq/cp6G3a2IM2TcuHfNneT070Le luyfRokoVzcHngO/LKufEcEZ1VcxCmOb0ggeuWQReg7yK6c/qhGF9HxyH6m1Z1eT 7PcbEAJFex4nfYlvs/wDGP8tN/bjOyzXHVkNIYnBN6rGAB8pxMEtEHk3F/1Q0h/S YSfNTvCJqFifRVtcK57XKhshBJeY5wt7x9oZCCY6w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegiedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffokfggtgesthdtmhdtre dttdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkph epjeefrdelvddrieegrddufedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: 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 8DE7A3280064 for ; Sun, 22 Mar 2020 12:54:16 -0400 (EDT) From: "Christopher Wood" To: "TLS@ietf.org" Date: Sun, 22 Mar 2020 09:54:15 -0700 X-Mailer: MailMate (1.13.1r5671) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 16:54:21 -0000 One of the original motivating requirements for ECHO (then ENSI) was "do not stick out" [1]. This complicates the current ECHO design, as clients must trial decrypt the first encrypted handshake message to determine whether a server used the inner or outer ClientHello for a given connection. It's also trivial to probe for ECHO support, e.g., by sending a bogus ECHO with the same key ID used in a target client connection and checking what comes back. I propose we remove this requirement and add an explicit signal in SH that says whether or not ECHO was negotiated. (This will require us to revisit GREASE.) What do others think? Thanks, Chris (no hat) [1] https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.4