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

Mark and I met last night and came to the conclusion that it would be
acceptable to document the risk of collision and say that people should
choose strings in such a way that they have a very high probability of
non-collision and suggest a few ways.

Mark, does this match your memory of our discussion?
-Ekr


On Thu, Jan 31, 2019 at 3:21 PM Chris Lemmons <alficles@gmail.com> wrote:

> It's worth noting that it's possible that this header, at some point
> in the future, could be used in situations where DNS isn't even
> applicable. (Consider a hypothetical CDN whose edges are found via
> some distributed mesh system. Or even some more esoteric and creative
> situation.) As far as I can tell, there's no particularly compelling
> reason to require a DNS registration for CDN-Loop to operate
> correctly.
>
> In fact, if each host in a CDN simply picked a fairly long random
> string at boot time, it would still prevent non-terminating loops. (I
> wouldn't advise this generally, of course, since a request could still
> "bounce" a little before terminating.)
>
> CDNs aren't useful if they don't deliver content. Mark is exactly
> right that the natural incentives will lead CDN operators to choose
> values that are very unlikely to collide. I like the advice provided
> that encourages the use of DNS names, since it's an easy way to pick a
> non-colliding name and it works very well in today's Internet
> landscape.
>
> Regarding the other point, most (all?) CDNs have the concept of
> "Delivery Lanes" for groups of content managed by a single person or
> group. Some CDNs may want to use different tokens for each Lane,
> effectively treating each Lane as a unique CDN. This can be used to
> mitigate the topology discovery attack Eric was discussing by making
> the token used for a given lane difficult to determine without control
> of the lane or its origin. (Consider: <random-string>.lane.cdn.example
> .) Now, that doesn't directly conflict with the "identifies the CDN as
> a whole" text, but the text does imply a different implementation.
> Clarification on this sort of usage might be useful... or it might
> obscure more than it clarifies.
>
> On Tue, Jan 29, 2019 at 12:10 AM Martin J. Dürst <duerst@it.aoyama.ac.jp>
> wrote:
> >
> > On 2019/01/29 12:09, Eric Rescorla wrote:
> > > On Mon, Jan 28, 2019 at 6:18 PM Mark Nottingham <mnot@mnot.net> wrote:
> > >
> > >> Adam seemed to be OK with the current text in <
> > >>
> https://www.w3.org/mid/00331e00-e1a5-e12a-6462-826033dcad6b@nostrum.com>,
> > >> so I think it's just you.
> > >>
> > >
> > > 1. I'd like to hear Adam comment after reading my note below.
> > > 2. I'm not sure how this changes the points I'm making.
> >
> > I think on the other side, it's not just Mark, but it's Mark, the WG,
> > and, as Mark has described again recently (still included below),
> > between 20 and 30 years of deployment experience with similar headers.
> >
> > Regards,   Martin.
> >
> > >
> > > -Ekr
> > >
> > >
> > >>
> > >>> On 29 Jan 2019, at 11:13 am, Eric Rescorla <ekr@rtfm.com> wrote:
> > >>>
> > >>> I feel like we're talking past each other a bit.
> > >>>
> > >>> The original text just has some opaque string and then assumes there
> > >> will be no collisions, but doesn't provide any mechanism for
> preventing
> > >> them. Saying that people should use DNS-based names is a mechanism of
> > >> preventing them, but if you also allow opaque strings then there's
> still no
> > >> mechanism for preventing them from colliding. So, either we believe
> that
> > >> arbitrarily chosen opaque names have a nontrivial chance of collision
> (in
> > >> which case we need to provide a mechanism about how to not have that
> > >> happen) or we believe they don't, in which case no text is needed. It
> seems
> > >> to me that Adam and I think there is a nontrivial chance, and Mark
> doesn't,
> > >> but that's the point to resolve.
> > >>>
> > >>> -Ekr
> > >>>
> > >>>
> > >>> On Sun, Jan 27, 2019 at 4:51 PM Mark Nottingham <mnot@mnot.net>
> wrote:
> > >>> Some advisory text to guide using them?
> > >>>
> > >>>
> > >>>> On 28 Jan 2019, at 9:45 am, Eric Rescorla <ekr@rtfm.com> wrote:
> > >>>>
> > >>>> Well, this argument has some force, but my point is that this isn't
> > >> substantively different from the initial version of the draft in this
> > >> respect.
> > >>>>
> > >>>> -Ekr
> > >>>>
> > >>>>
> > >>>> On Sun, Jan 27, 2019 at 2:10 PM Mark Nottingham <mnot@mnot.net>
> wrote:
> > >>>> HTTP has used similar constructs for 20+ years and collisions have
> not
> > >> been an issue:
> > >>>>
> > >>>> https://httpwg.org/specs/rfc7230.html#header.via
> > >>>> https://httpwg.org/specs/rfc7231.html#header.user-agent
> > >>>> https://httpwg.org/specs/rfc7231.html#header.server
> > >>>>
> > >>>> All of them address the issue of pseudonym collision by recognising
> > >> that implementers have an interest in distinguishing their
> implementations
> > >> from others if they want to rely upon a field for debugging (as all of
> > >> these are, effectively). None of them addresses the case of an active,
> > >> *intentional* collision (as we see sometimes with User-Agent), because
> > >> doing so would require far too much infrastructure, compared to any
> benefit
> > >> seen.
> > >>>>
> > >>>> Notably, doing something like rooting product tokens in the DNS name
> > >> space would have done *nothing* to prevent the issues we're seeing
> with
> > >> User-Agent. Doing so would have also brought about the usual questions
> > >> around whether something needs to listen at that hostname, whether it
> needs
> > >> to resolve, and what happens when a name changes hands.
> > >>>>
> > >>>> The failure case of a collision is also pretty straightforward; if I
> > >> run a CDN and another CDN usurps my value, they're only shooting
> themselves
> > >> in the foot, because it'll look like they're in a loop if I'm
> configured to
> > >> forward traffic to them, and they'll start refusing requests --
> thereby
> > >> screwing their customers. Their natural incentive is to avoid this
> > >> situation.
> > >>>>
> > >>>> So, the properties you're looking for are already naturally emergent
> > >> from the documented protocol. While we could require a hostname, I
> think
> > >> doing so is effectively cargo-cult protocol design; it won't actually
> > >> improve collision avoidance in practice.
>