Thank you Mark.
On the first item, please look carefully at the use of pronouns. It
took me several readings to realize which CDNS "they" referred to.
On the second item, it was not TLS protection I was referring to.
Rather, I was imagining one bad cache stripping the loop prevention. I
think the real answer to that is that it is no worse than such a cache
originating bad requests.
Yours,
Joel
On 12/17/18 6:53 PM, Mark Nottingham wrote:
Hi Joel,
Thanks for the review.
On 4 Dec 2018, at 5:45 am, Joel Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
...
This depends upon CDNs which have not been upgraded not stripping this
header. While I can believe that is a reasonable assumption, it seems that
a paragraph explaining that it is the case, and if possible what experience
leads us to think it is the case, would be helpful.
I've added:
"""
Note that if a CDN that does not implement this specification allows customers to remove or modify the CDN-Loop header field, that CDN could become an attack vector against other CDNs, even if they do implement it.
"""
This document says that it is to protect against attackers causing loops.
If the attacker is an external customer, the advice in the security
considerations section makes sense. The other apparent attack would be an
attacker in the network who strips the information each time it comes past.
I believe the reason this is only an apparent attack is that such an
attacker could almost as easily simply generate additional messages instead
of producing a loop. If I have inferred this correctly, it seems useful to
state it.
CDN back-end connections are increasingly protected by HTTPS. Also, most back-end connections are over transit that's unlikely to meddle in these ways (unless a state actor is involved).
Even so, the spec already says:
"""
The threat model that the CDN-Loop header field addresses is a customer who is attempting to attack
a service provider by configuring a forwarding loop by accident or malice.
"""
.... which seems to address your concern. I'm wary of enumerating the attacks which this header doesn't prevent, since it's a necessarily open list. Inserting requirements like "back-end connections SHOULD be over HTTPS" are more appropriate for a general spec defining what a CDN is (and we're not there yet; this spec is a baby step towards that :).
Cheers,
--
Mark Nottingham https://www.mnot.net/
