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

[Donald Eastlake <[e-mail]>]

On Sun, Dec 16, 2018 at 6:56 PM Mark Nottingham <[e-mail]> wrote:
>
> Hi Donald,
>
> Thanks for the review. Some responses below.
>
> > On 11 Dec 2018, at 10:40 pm, Donald Eastlake <[e-mail]> 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.
> >
> > 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".
>
> 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.

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
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [e-mail]

> > Nit:
> >
> > Section 2: 3rd paragraph, suggest replacing "field to all requests" with "field in all requests".
>
> Thanks.
>
> Cheers,
>
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>