Subject: [secdir] SECDIR review of draft-ietf-httpbis-cdn-loop-01

From: Donald Eastlake <[email-masked]>
Date: Tue, 11 Dec 2018 06:40:05 -0500

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

The summary of the review is Ready with issues.

This document specifies a new "CDN-Loop" HTTP header field to detect
Content Delivery Network loops. Such loops can be caused by
misconfiguration or as part of a denial of service attack.

Security:

It is slightly misleading that in Section 1 the draft says how valuable an
HTTP header "guaranteed not to be modified" would be but then the draft
does not provide such a header. Maybe instead say "should normally be
unmodified".

I believe this document should RECOMMEND that CDN-Loop headers include some
sort of MAC (Message Authentication Code) covering the header so a CDN node
can reliably recognize CDN-Loop headers that it has added. Since it need
only recognize its own headers, the MAC need not be further specified or
interoperable. (CDN-Loop information in an HTTP message can grow by the
appending of entries or by additional of another CDN-Loop header. Since I
have little confidence in the stability of header order, I would suggest
MACs added as a parameter to a CDN-Loop header by the last parameter for
that entry and sign that entry and all previous entries in that CDN-Loop
header.) This could be done by modifying the 3rd paragraph of the Security
Considerations section.

Nit:

Section 2: 3rd paragraph, suggest replacing "field to all requests" with
"field in all requests".

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Dec 2018 10:56:06 +1100

Hi Donald,

Thanks for the review. Some responses below.

> On 11 Dec 2018, at 10:40 pm, Donald Eastlake <[email-masked]> wrote:
> 
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  Document editors and WG chairs should treat these comments just like any other last call comments.
> 
> This document specifies a new "CDN-Loop" HTTP header field to detect Content Delivery Network loops. Such loops can be caused by misconfiguration or as part of a denial of service attack.
> 
> Security:
> 
> It is slightly misleading that in Section 1 the draft says how valuable an HTTP header "guaranteed not to be modified" would be but then the draft does not provide such a header. Maybe instead say "should normally be unmodified".

Agreed; we'll adjust this language.

> I believe this document should RECOMMEND that CDN-Loop headers include some sort of MAC (Message Authentication Code) covering the header so a CDN node can reliably recognize CDN-Loop headers that it has added. Since it need only recognize its own headers, the MAC need not be further specified or interoperable. (CDN-Loop information in an HTTP message can grow by the appending of entries or by additional of another CDN-Loop header. Since I have little confidence in the stability of header order, I would suggest MACs added as a parameter to a CDN-Loop header by the last parameter for that entry and sign that entry and all previous entries in that CDN-Loop header.) This could be done by modifying the 3rd paragraph of the Security Considerations section.

The authors have discussed this, and we don't see much utility in this; a MAC would protect against the modification of the key/value pairs, but they're not crucial to the functionality of the header. If an attacker were able to modify header values, something much more than a MAC would be needed. Also, as you note, interoperability isn't necessary here. So, while I think we're fine with mentioning in Security Considerations that parameters can be used to secure the field, I for one would be wary of going any further than that in this specification.

> Nit:
> 
> Section 2: 3rd paragraph, suggest replacing "field to all requests" with "field in all requests".

Thanks.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 19 Dec 2018 18:18:14 -0500

> The authors have discussed this, and we don't see much utility in this; a MAC would protect against the modification of the key/value pairs, but they're not crucial to the functionality of the head…

Well, OK I guess. It just seems so easy to add a MAC in the header
covering the preceding part of that header that I would do it. And it
would help rule out certain causes when debugging problems. But if the
WG has decided not to recommend this, so be it.

Thanks,
Donald

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Dec 2018 16:11:24 +1100

> On 20 Dec 2018, at 10:18 am, Donald Eastlake <[email-masked]> wrote:
> 

Just to make sure you saw it, Security Considerations already includes:

"""
It is possible to sign the contents of the header (either by putting the signature directly into
the field's content, or using another header field), but such use is not defined (or required) by
this specification.
"""

Cheers,