Re: [Edm] Thoughts on greasing mechanisms

> On Nov 13, 2020, at 12:34 AM, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
> 
> 
>> On 12. Nov 2020, at 23:26, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> 
>> 
>>> 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? 
> 
> I’m still hoping we can be smarter than this for new protocols… As I said greasing is a good way to detect ossification. Not sure if it really will avoid ossification.

I think if a protocol can grease (or do an equivalent) from the start, it actually does have a better chance of avoiding ossification.

Mirja, I entirely sympathize with the desire to not reserve code points forever for greasing—both for efficiency, and to avoid implementations ossifying for the non-reserved values. That’s partly why I’m trying to dig into the idea of how a new protocol would be able to design its extensibility in a way that allows “greasing" without needing to strictly reserve codepoints.

> 
>> 
>>> 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. 
> 
> The difference might be the word artificial.

Yes, I think this is what the intent of greasing is. I think what we’ve seen so far is how we fit greasing into existing protocols like TLS, but there are opportunities to have a design that bakes the principles into the protocol itself. There could still be some “artificial” exercising of the extension mechanism, without necessarily needing to pre-allocated “artificial” values.

Fundamentally, it seems like what we need to do to defend against ossifying a new extension mechanism is:

- Ensure that implementations often see and must ignore unknown values without adverse effects
- Ensure that implementations can’t simply filter out a range of unknown values and still mishandle values that will later be allocated
- Ensure that an implementation can block or filter out values it knows about that it doesn’t want to support on purpose (like deprecated older values), without allowing it to block new values it doesn’t understand

Does that seem like the right list of goals?

Tommy

> 
>> 
>> 
>> 
>>>> 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/
>> 
>> -- 
>> Edm mailing list
>> Edm@iab.org
>> https://www.iab.org/mailman/listinfo/edm
> 