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

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

>
>
> > On 21 Dec 2018, at 10:45 am, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > 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.
>
> I was saying that we should remove the requirement. This is similar to
> Via's ability to use a pseudonym; there is no uniqueness requirement there
> (we trust that the motivation of the party generating it to make it useful
> is sufficient).
>

I'm not persuaded this true. Collisions here seem to create an obvious
interop problem, and so the specification should tell you how to avoid them.


> > 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?
>
> It's explicitly called out as a request header. We don't place such
> requirements on many other request-only headers (e.g., Host).
>

All right.


> > 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?
>
> Can you be more specific -- what do you mean by "client" and "it" here?
>

We have a situation with two alternate topologies:

1.  A -> B -> Origin
2.  A ->  Origin

The original HTTP client (i.e., an external attacker on the Internet) sends
a request with a CDN-Loop header containing B. In topology (1) this causes
some kind of failure and in topology (2) it does not, thus leaking the
topology.

-Ekr


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