Re: [Gen-art] Genart last call review of draft-ietf-httpbis-cdn-loop-01

["Joel M. Halpern" <[e-mail]>]

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 <[e-mail]> 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/
>