[Edm] Thoughts on greasing mechanisms

Tommy Pauly <tpauly@apple.com> Sun, 08 November 2020 04:40 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: edm@ietfa.amsl.com
Delivered-To: edm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B3F213A03F2 for <edm@ietfa.amsl.com>; Sat, 7 Nov 2020 20:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=apple.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eCzwSYbrAip0 for <edm@ietfa.amsl.com>; Sat, 7 Nov 2020 20:40:32 -0800 (PST)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com []) (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 14E553A03EC for <edm@iab.org>; Sat, 7 Nov 2020 20:40:31 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com []) by nwk-aaemail-lapp03.apple.com ( with SMTP id 0A84eOuS036526; Sat, 7 Nov 2020 20:40:30 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=Kh4Z1jzeY+jOggRi0MoQcCn9hfdVmjbKbRKSetQMXNU=; b=Yg5/oZr9pkVq2Otz9TIp6qwoxuqPavv+qX1BOw3iA4p+ixhzJiAkipJWXiHAW4BFav2R oBXdCyn7tZvnspNGvIVZ4cmneAQ27oUuoyQXGlOrJuctvgfFa9CBOHWsZNU1g+cI44Ly DflMaSgLfR9F5hJrAFgKlu4EHu1qpRjrf8A+1PX4DMAo2KxIqlsgw5iB6vLha6WQkTk7 7zfY7YCLjd4AGayytmUP2Xc2Nhm2VA0N/gO2ktzDO2G+/YBrf3AEbpqrwuHByOZx6WW7 1rczma9z2Xjk9RynXqC478wbuXR9rRqnggtoUCWTHsv+rV+KJ19CkSo3q7wY6fItQ9k1 Ag==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com []) by nwk-aaemail-lapp03.apple.com with ESMTP id 34ns06w8gm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 07 Nov 2020 20:40:30 -0800
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com []) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 64bit (built Jul 29 2020)) with ESMTPS id <0QJG002ERNNIRW90@rn-mailsvcp-mta-lapp01.rno.apple.com>; Sat, 07 Nov 2020 20:40:30 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 64bit (built Jul 29 2020)) id <0QJG00I00MYQA000@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 07 Nov 2020 20:40:30 -0800 (PST)
X-Va-T-CD: e05e48b703e8c4fcb2d0af9a0cbbeb5a
X-Va-E-CD: c4681f1df7dfa3eb06bd286135609715
X-Va-R-CD: 60841d6209217f4e65748f4bac09fb92
X-Va-CD: 0
X-Va-ID: 0f1c6ccf-afa2-4239-bab9-ff066f802fbb
X-V-T-CD: e05e48b703e8c4fcb2d0af9a0cbbeb5a
X-V-E-CD: c4681f1df7dfa3eb06bd286135609715
X-V-R-CD: 60841d6209217f4e65748f4bac09fb92
X-V-CD: 0
X-V-ID: 455874db-77ab-482a-8b33-3c0ecbaab9f5
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-08_01:2020-11-05, 2020-11-08 signatures=0
Received: from localhost.localdomain (unknown []) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 64bit (built Jul 29 2020)) with ESMTPSA id <0QJG00MD6NN90A00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 07 Nov 2020 20:40:25 -0800 (PST)
From: Tommy Pauly <tpauly@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_3E367C50-004D-4FB0-83D6-03DF28C46429"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Message-id: <C26B3C62-D9DA-4A86-A60B-AB61A4F899C5@apple.com>
Date: Sat, 07 Nov 2020 20:40:19 -0800
To: edm@iab.org, Martin Thomson <mt@lowentropy.net>, Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.3654.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-08_01:2020-11-05, 2020-11-08 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/iG8vZWJNugfyG65iv97KkYjv6Nc>
Subject: [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: Sun, 08 Nov 2020 04:40:34 -0000

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 <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!