EDM Meeting

Feb 9 2023

Thanks for finishing the work on protocol-maintenance!

Greasing

MT (Martin Thomson): There are protocols where we could have done
greasing, and knew about it, but didn't put it in, and we see atrophy.
This is the case for HTTP/2.

TP (Tommy Pauly): What specific examples?

MT: Should ignore frames you don't understand, but those are causing
some hard failures. SETTINGS do seem to work, since they were being
used.

MK (Mirja Külhewind): Doesn't maintenance say that it's better to use it
than artifical greasing?

MT: Yes, but we didn't have enough new extensions for HTTP/2 frames at
first, so it didn't have active use at first. Potentially a lesson for
greasing: we probably didn't need to grease transport parameters, since
they're being used heavily.

DS (David Schinazi): We caught bugs in apple client code by using new
TPs in QUIC (not from greasing).

MR (Michael Richardson): Would have been great to have greasing in IPv6
extension headers. Also TCP options - these get dropped by many
firewalls, etc. This is often due to "fake security" where you block
everything you don't know. Being suspicious doesn't mean dropping a
connection. Would be nice to have greasing outside of TLS/HTTP.

MK: Would greasing help for TCP options? Some will just erase the
option.

MR: Yes, but we have cases where connections are entirely dropped, which
is worse. It's OK to say no or not negotiate. We tried to have an ECN
wall of shame, and it didn't work well, and delayed us by 10 years. We
should have a "greasing is good" roadshow, and explain this to "security
professionals".

TP: What protocols beyond TLS, QUIC, Privacy Pass do greasing?

DS: Capsules (MASQUE)

MR: COAP would be a good place to do it, with interesting greasing
options (would change encoding order, etc). Would be nice for IKEv2 at
many layers, induce fragmentation every now and then.

MT: There are often applications that are sensitive to perf, that won't
like fragmentation. Most of the time, you're not greasing, and you can
attribute ossifications to transient failures.

MR: I wanted to have a "do interop" mode for IKEv1 testing back in the
day, with known transforms and keys, etc, to make a useless connection
to prove that things got across the network. So, for greasing, I want a
"test with greasing" to turn on.

TP: But if we don't grease enough, we'll not notice things.

DS: David Ben had an idea to base greasing on one machine's ID and one
origin.

MT: The user experience then would be horrible, since it would break for
one person.

TP: In testing with cloudflare quic, I see greasing a lot (on most or
all handshakes?)

LP (Lucas Pardue): Yeah, H2 shipped without greasing sadly.

DS: MLS is shipping soon and adds a bunch of registries, but doesn't
have greasing yet.

MK: What Lucas was saying made me think that we need more testing in the
first place.

DS: We won't be able to fix all the problems, though.

MR: Not everyone implements the same day and at hackathons. So greasing
is important for these uncoordinated implementations. IANA
considerations should have a subsection for greasing -- if you don't
have it, say why (like you have a really small set of codepoints). If
you have private use space, you should have room to do greasing. IKEv2
didn't coordinate private use space, so we used vendor IDs there, which
was sort of a weak way to have greasing.

MT: There's more to learn than random extension points. Ordering of
extensions matters in TLS; values in the parameters also matters, etc.
It's not just an IANA registry solution.

TP: Greasing techniques for different protocols don't need to be in the
core specs (other than registries, maybe). We could have separate docs
for how to grease protocols like MLS.

MT: There are things in QUIC that we are greasing that we don't
obviously need to. There are others that we should grease. There's a
question of "what happens next" after we find that we can't use an
extension point anymore -- you might be able to fix the one broken
implementation, or you need to move on an extend the protocol
separately. In H2, we use SETTINGS to negotiate if you can use frame
types.
As Mirja alludes to, fewer extension points is better.

MK: But then if that one breaks, then you are stuck! =)

DS: "Have one joint and oil it well", if you're forced to use the
extension point, then it won't rust shut.

MK: RFC 6709 talks about extension points, but doesn't really suggest to
use fewer extension points to avoid ossification.

MT: Making everything extensible is the way things work in TLS, and it
isn't always helpful.

LP: Consider cases where HTTP intermediaries drop things they don't know
- and so the greasing doesn't actually go end to end well.

TP: How do we know if greasing works? How do we know if we're doing it
enough to make a difference?

MK: Wait another 10 years? =)

MR: I want a technical user to be able to enable greasing, to see if it
makes a difference. We might need a logging or reporting mechanism to
make greasing visible in logs or reports.

MK: Related to how we get better logging in cases of failures.

DS: Is there such a thing as too much grease? Probably shouldn't hurt
even if it isn't necessary.

MT: Not suggesting we shouldn't do it. There are cases where it won't be
very helpful (like introducing perf hits due to fragmentation). Greasing
has limitations — it tests very specific kinds of bugs, not others. We
shouldn't fixate on one specific kind of bug.

MK: Keeping extension points alive and usable is very important, but we
should do that by using them.