Re: [Edm] Thoughts on greasing mechanisms

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