[Http-grease] Brief review of Greasing HTTP (draft-nottingham-http-grease-00)

[Christian Folini <[e-mail]>]

Hi there,

The Summer holidays kept me from reviewing this draft document earlier, but
here we go.

Link and version: https://mnot.github.io/I-D/http-grease/ v00, July 7, 2020.


I'm taking the perspective of a co-lead of the OWASP ModSecurity Core Rule Set
project (CRS), a popular WAF rule set used by quite a few vendors for their
offerings.

Intro:

The high-flying explanation of what "greasing" actually means, could be a bit
more explicit. Maybe even a section "What is greasing?"  It would help with
the readability (-> and consequently adoption) of the document.

I read the doc several times and I got it the 2nd time I read it. But it was
all a bit puzzling at first sight.


What to Grease?

The doc explains how HTTP response headers are greased daily by the various
server implementations themselves.

The argumentation is a bit thin in this regard, since there is an equally
large number of custom HTTP request headers being sent across the wire. One
would need to explain why the situation with these request headers is
different from the situation with the response headers.



How to Grease?

There is this passage "an implementation determined to control input values
can anticipate grease values and allow them, ...". I think it is very
important to see and anticipate this.

This is especially true when you read it together with the non-idempotency
restriction in the chapter about the greasing process. It's very attractive
to focus on idempotent methods with the restrictive rules and to ignore
everything else.

CRS does not do this, but I reckon several vendors have such rules in place in
order to reduce false positives already. The grease process described makes
such a behavior even more attractive. Fighting this from the start will be
important.


Security considerations

I like this section a lot. These considerations are real and even naming them
adds to the quality of the document.


Appendix A. Bootstrapping the HTTP Grease Process

"Broadly speaking, HTTP servers accept these extensions, unless they have a
Web Application Firewall (WAF) installed."

This depends on the rule set.

Proposed better wording: 
"Broadly speaking, HTTP servers accept these extensions, unless they have a
Web Application Firewall (WAF) installed, which denies them."

"WAF vendors" 

The CRS project does not necessarily see itself as a "vendor".  I reckon we 
see ourselves as WAF developers. A more inclusive wording would help to
address everybody.

"Therefore, a successful greasing strategy needs to include
most or all major clients, and their actions need to be
coordinated."

This makes a lot of sense, but if you look at it in a practical way, then it
means that a coordinated greasing effort affects users of different clients in
a similar way. That could mean that users from client A migrate to B and users
of client B migrate to A.  This gives the clients an incentive to minimize the
impact of the greasing effort.  The process described above allows the clients
to make several decisions.  They could be tempted to minimize the greasing for
minimal impact on their users.  That would undermine the effectiveness of the
greasing process.

"As a a result, when greasing begins, it will be necessary to have long lead
times between announcement and sending.  Likewise, initial grease values are
more likely to succeed (building confidence and engagement) if they are static
and simple."

This is very good.  It may be worthwhile to do a new CRS (point-)release
between announcement and sending.  This would give deployers an incentive to
update quickly, which would be beneficial for our project and maybe others
too.



All in all I like the document, its brevity and the direction it is taking.
I find it a wee bit odd that it describes a process and then also its
first exercise. But I reckon that's no big deal.

Best regards,

Christian Folini


-- 
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra