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

From: Joel Halpern <[email-masked]>
Date: Mon, 03 Dec 2018 10:45:42 -0800

Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-cdn-loop-01
Reviewer: Joel Halpern
Review Date: 2018-12-03
IETF LC End Date: 2018-12-11
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard RFC
                    There are two issues that I think should be addressed
                    before publication

Major issues: N/A

Minor issues:
    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.

    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.

Nits/editorial comments:  N/A

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 17 Dec 2018 15:23:41 -0500

Joel, thanks for your review. I have entered a No Objection ballot and flagged your review there since there has been no response.

Alissa

> On Dec 3, 2018, at 1:46 PM, Joel Halpern <[email-masked]> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Dec 2018 10:53:44 +1100

Hi Joel,

Thanks for the review.

> On 4 Dec 2018, at 5:45 am, Joel Halpern <[email-masked]> wrote:
...
>    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.
"""

>    of producing a loop.  If I have inferred this correctly, it seems useful to

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/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Dec 2018 21:16:33 -0500

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Dec 2018 14:26:43 +1100

> On 18 Dec 2018, at 1:16 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> 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.

I've rewritten to:

"""
Note that a CDN that allows customers to remove or modify the CDN-Loop header field (i.e., they do not implement this specification) remains an attack vector against both implementing and non-implementing CDNs.
"""

> 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.

s/cache/intermediary/, but yes -- there isn't any (or at least significant) amplification.

Cheers,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Dec 2018 22:56:00 -0500

Thanks for the rewrite on the first one.

I can live without adding the comment on the second.  I think the 
security folks will wonder and have to reproduce the reasoning as to why 
it is a non-issue.  (But if you add that disclaimer, they will probably 
just come up with another one.)

Yours,
Joel