Re: Benjamin Kaduk's No Objection on draft-ietf-httpbis-cdn-loop-01: (with COMMENT)

Hi Ben,

> On 21 Dec 2018, at 12:48 am, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> Section 1
> 
>   This specification defines the CDN-Loop request header field for HTTP
>   to enable secure interoperability of forwarding CDNs.  Having a
>   header that is guaranteed not to be modified by other CDNs that are
>   used by a shared customer helps give each CDN additional confidence
>   that any purpose (debugging, data gathering, enforcement) that they
>   use this header for is free from tampering due to how that customer
>   configured the other CDNs.
> 
> Per some of the other discussions on this document, I don't think that
> "guaranteed" is the best description here; the property that we are hoping
> to get is more that we have a well-known place to store loop-prevention
> state, and it is documented as being a header field that should not be
> removed by cooperating implementations.  There is no "guarantee" so long as
> implementations that do not support CDN-Loop are in play, but the field of
> play should improve over time as CDN-Loop support increases.

The current text is at:
  https://httpwg.org/http-extensions/draft-ietf-httpbis-cdn-loop.html#introduction


> (Ben's comment about the "MUST NOT remove this header field" apparently
> applying to even intermediaries that do not implement this spec is also
> relevant.)
> 
> I see that this Section 2 text is already slated for edits, but I might
> make a bigger change than just s/MUST NOT/must not/, maybe something like:
> 
> The effectiveness of this mechanism relies on all intermediaries preserving
> the header field, since removing (or allowing it to be removed, e.g., by
> customer configuration) would prevent downstream CDNs from using it to
> detect looping.  In general, unknown header fields are not removed by
> intermediaries, but there may be need to add CDN-Loop to an
> implementation's list of header fields that are not to be removed under any
> circumstances.

I like that; thanks. 


> Section 3
> 
> If we're going to talk about the potential for signing the header field's
> contents (nit: the new text just talks about "the header" with no "field"),

fixed 

> do we need to say how the signature validation would be affected by another
> intermediary adding to the CDN-Loop header field's value?

This specification doesn't define that mechanism; only notes its possibility. 

Cheers,

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

Received on Thursday, 20 December 2018 23:26:30 UTC