Re: [Edm] Thoughts on greasing mechanisms

Mark Nottingham <mnot@mnot.net> Thu, 12 November 2020 22:26 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: edm@ietfa.amsl.com
Delivered-To: edm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B573A0A06 for <edm@ietfa.amsl.com>; Thu, 12 Nov 2020 14:26:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=SAmRO9k5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ByB+Bfk5
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 vI9Hve5hs33E for <edm@ietfa.amsl.com>; Thu, 12 Nov 2020 14:26:17 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CF73A0E72 for <edm@iab.org>; Thu, 12 Nov 2020 14:26:17 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 75A05ED6; Thu, 12 Nov 2020 17:26:16 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 12 Nov 2020 17:26:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=t mkGGrpVePLBUu8Oi65eIBkoXzP3tow866NkViAqHbE=; b=SAmRO9k5JST6XNuWD TGsf+gHw4DgG+GPgW5eAonK7g8CV1d0RsRXLH9nZnJkL5/mbTL1f2WRvm4iny0PU w8qtccTLdXQ8sns3R8jDn2ra6nw5oFzGpduvoLkTcxN6u7bDtE26tWKN0vk+11Sb e8xhBZj4CB1BbchX8kUwHl7DRwzd1A8zjmdyeGPGSJzb+p64oEVTHbAv01YLtCkL jnILjFdPUME+BmOxu7pZ6XLaK+c1KJKeA8NFAkNWjZC2DkfzYataasRbu7b7NqcZ JlptewMOPqKkdOjdoXXLUO52qhf4dQeFeaXDLc3okQZ1pI/HbffmJtNOWG3OzA97 m1+4g==
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=fm1; bh=tmkGGrpVePLBUu8Oi65eIBkoXzP3tow866NkViAqH bE=; b=ByB+Bfk5NJkSJZoasjVxpqybRaMtD7oAh5EeOiPByXnh0rjErsBfenImq mlUb8LddtJH8dQhYXcy3FRvbpi5hf2jnd7ZjtPrdxGKoNghvKZQXykmiH/IaTrUi ihYWbjC8lLr1QoUqm8PHDtlwkM7keAzeOyFBKBhnzyLGG5ycVXfffRH6FjCp/CHn qxbEUxWNysn5S2d/hGjOv80GiRao19VkpLz9UtMvxd7EWJ7Jbi3WDdFdI8UIiX6N pgThOfr1hPi+BLAYRX8ehuKAKbHgm8O3LXeUyJOnwZNYKGHJwUuNX+6nM09a+d8s KnJ4hD7hoxpUJR/rbvWwCK0jH+hZA==
X-ME-Sender: <xms:hratX7ElBctZZAfudhdM91A-lNVGzGpIgWs5VdXOEKXEUfO2dU1jgA> <xme:hratX4UuMJYezrPeQvEdg9QnPDoeeoCak5TrbOANVp9rzMTorgScDNtZySr1BtsTe UCyy8inDUASO4sVsw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvfedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpegtggfuhfgjfffgkfhf vffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomh hnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepheetvdejjefgfeffgfet iedtgfevhfekgfdvgeehvdejffeufeegudeguefhudeinecuffhomhgrihhnpehgihhthh husgdrtghomhdprhhftgdqvgguihhtohhrrdhorhhgpdhgihhthhhusgdrihhopdhivght fhdrohhrghdpihgrsgdrohhrghdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrud ehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:hratX9KkS2xCP7ee3Gxnp9kQ9Y1zoNxeXuJlf8tMbxeMPWysQqRmug> <xmx:hratX5FFxWToiLhDxjaBr_FABNBJO-Si9TlwiQU4sdMkePrFqUCUBA> <xmx:hratXxWpbkAHVDe9090Zau9z6nZCzVBN0HhsVOHFn0thm_wyt8X-1g> <xmx:iLatX3ybVwZVrBk8m3ruSSoLSF1UGVDtmiX7LhPTIuCuVV7Iqi_e1Q>
Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 95CE93068FC8; Thu, 12 Nov 2020 17:26:12 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <FDDC396D-8712-4995-9C47-D0E630E90BF0@kuehlewind.net>
Date: Fri, 13 Nov 2020 09:26:10 +1100
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, edm@iab.org, Martin Thomson <mt@lowentropy.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <515CABD7-FC05-443E-8DB1-8C34DB47A394@mnot.net>
References: <C26B3C62-D9DA-4A86-A60B-AB61A4F899C5@apple.com> <FDDC396D-8712-4995-9C47-D0E630E90BF0@kuehlewind.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/Nz8KWYrFnkrzZc9QPUsRmPqWXmw>
Subject: Re: [Edm] Thoughts on greasing mechanisms
X-BeenThere: edm@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" <edm.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/edm>, <mailto:edm-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/edm/>
List-Post: <mailto:edm@iab.org>
List-Help: <mailto:edm-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/edm>, <mailto:edm-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 22:26:20 -0000


> On 13 Nov 2020, at 6:06 am, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
> Hm… I guess I have to say I’m not the biggest greasing “fan”. Greasing has proven a really useful mechanism, e.g. in the case of TLS to actually detect broken systems, however, I’m a bit sad that we need to build in the same hack into brand new protocols as it feels to me like a waste to reserve codepoints for that (as a German always looking for efficiency ;-) ). And what you propose maybe feels like you just add more bits to it.

Why are new protocols different? Once they get deployed, they become not-new protocols, so why should our expectations change regarding ossification? 

> Maybe we need to consider better in protocol design that we not only make sure extension mechanisms are available but also frequently used and tested? Just a though…

I think that's exactly what greasing is -- exercising extension points artificially to assure that they maintain flexibility. 



>> On 8. Nov 2020, at 05:40, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>> 
>> One of the items I’d like to get kicked off for our work in the EDM program is updating and working on draft-iab-use-it-or-lose-it, which analyzes some problems with extension point use and makes recommendations. One of the newer approaches it covers is “greasing”. I filed the following issue for discussion, and would like to hear the input of the people on this list.
>> 
>> https://github.com/intarchboard/edm/issues/7
>> 
>> Can greasing mechanisms avoid reserving or coordinating "fake" values?
>> 
>> In TLS, GREASE (https://www.rfc-editor.org/rfc/rfc8701.html) reserves several values in different extension code point spaces to be used for greasing—that is, endpoints will randomly select some of the reserved values to send to the peer in order to ensure that the peer can handle unknown values.
>> 
>> This is also described in the use-it-or-lose-it draft which EDM is looking at (https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose-it.html#rfc.section.4.3). The description here also refers to the approach of reserving these values.
>> 
>> For existing protocols like TLS, reserving values seems to be the safest option. The downside is that these values represent only a finite subset of possible values; it is possible to still ossify to allow reserved greased values, but not allow others (if your implementation is particularly obstructive). It is also necessary to choose a wide distribution of values that ensure that the entire range of possible values is kept from ossifying.
>> 
>> Reservation of values is harder for other kinds of extension points. For example, the proposed HTTP greasing (https://tools.ietf.org/html/draft-nottingham-http-grease-01) discusses greasing header names and values. Since these are strings and other arbitrary values, simply reserving these ahead of time doesn't make sense. The proposal here is to have a coordination effort where greased values are agreed upon by the community.
>> 
>> If we are looking at recommendations for new protocol design, I wonder if we can come up with recommendations that achieve the goals of greasing without needing to rely on either reservation or coordination.
>> 
>> A goal we could have is that an endpoint can (and would) generate random or unknown values for various extension points to prevent ossification; but not risk causing a peer that actually does understand and handle that value to think that the endpoint is trying to use a protocol feature. Put another way, the random value should be indistinguishable from a valid value to the receiver of the value that doesn't support the valid version of the value; but a receiver that does understand the valid version of the value should be able to distinguish a greased/random value from an intentional value.
>> 
>> Consider an extension point like the ones that are greased in TLS, where the values are numbers within a range (say, 16-bit integers). Rather than just using these as Types in a Type-Length-Value scheme, the encoding could also include a value that proves if the sender is using a type based on a given version of a standard, or is just sending random data. Call this Type-Length-Hash-Value. In this case, when a given type is reserved, it could also define a unique pattern that can be hashed with something that changes in a message where the extension appears (like a nonce). If the receiver also knows the same unique pattern, it could confirm that the sender has the same understanding of the type by calculating the hash. A receiver that doesn't understand the type wouldn't be able to tell whether or not this was greased or valid.
>> 
>> A similar approach could be taken when the extensible values are strings, etc, allowing implementations to send random values without coordination.
>> 
>> Curious to hear people’s thoughts!
>> 
>> Best,
>> Tommy
>> -- 
>> Edm mailing list
>> Edm@iab.org
>> https://www.iab.org/mailman/listinfo/edm
> 

--
Mark Nottingham   https://www.mnot.net/