Re: Eric Rescorla's Discuss on draft-ietf-httpbis-cdn-loop-01: (with DISCUSS and COMMENT)

On Thu, Dec 20, 2018 at 3:27 PM Mark Nottingham <mnot@mnot.net> wrote:

> Hello EKR,
>
> > On 21 Dec 2018, at 12:19 am, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > DETAIL
> > S 2.
> >>     header if necessary).
> >>
> >>     The token identifies the CDN as a whole.  Chosen token values SHOULD
> >>     be unique enough that a collision with other CDNs is unlikely.
> >>     Optionally, the token can have semicolon-separated key/value
> >>     parameters, to accommodate additional information for the CDN's use.
> >
> > I don't know how to understand "unique enough" as a conformance
> > requirement. I think you need to specify something specific here, like
> > "globally unique" or some other scope. I don't insist that you provide
> > a construction algorithm, though obviously that would be good.
>
> There are relatively few CDNs, and they're pretty aware of each other.


That doesn't seem like a design constraint we should start with.


I'm not convinced a strict / algorithmic means of identifying them will add
> value; consider the name spaces of things like HTTP headers, and how little
> the registry is actually used, and how few collisions problems we actually
> encounter. Also, I wanted this field to be someone flexible so that a CDN
> could choose to use multiple tokens if it wanted to; e.g., some use a
> hierarchy, others use multiple "networks" with different configurations.
>
> If this text is causing so much heartburn, I suggest we just remove the
> sentence (and probably remove "as a whole.").
>
>

I'm not going to be any happier about that. I don't think you need to
provide a construction, but if the requirement is that they be unique in
some fashion, then you need to state what that fashion is.


> S 1.
> >>     in a "loop" accidentally; because routing is achieved through a
> >>     combination of DNS and forwarding rules, and site configurations are
> >>     sometimes complex and managed by several parties.
> >>
> >>     When this happens, it is difficult to debug.  Additionally, it
> >>     sometimes isn't accidental; loops between multiple CDNs be used as
> an
> >
> > can be used
>
> Already fixed.
>
>
> > S 2.
> >>     CDN-Loop = #cdn-id
> >>     cdn-id   = token *( OWS ";" OWS parameter )
> >>
> >>     Conforming Content Delivery Networks SHOULD add a value to this
> >>     header field to all requests they generate or forward (creating the
> >>     header if necessary).
> >
> > Can this header only go in a request?
>
> Yes.
>

OK. Can you say MUST NOT in a response?


>
> > S 3.
> >>     through configuration) and servers (including intermediaries) SHOULD
> >>     NOT use it for other purposes.
> >>
> >>  3.  Security Considerations
> >>
> >>     The threat model that the CDN-Loop header field addresses is a
> >
> > As Alissa points out, this also potentially leaks the CDN you use,
> > even if that would otherwise be hidden. For instance, suppose that a
> > request goes A -> B -> C but B is hidden (doesn't add anything to the
> > headers). If you know B's token, then you can tell if this is the case
> > or not., by injecting it yourself and seeing if you get service. Seems
> > like you should document this.
>
> It leaks the CDN the origin configures to the origin -- what attack are
> you concerned about here?
>

If the client forges it, it leaks it to the client, no?

-Ekr