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

LGTM

On Sun, Feb 3, 2019 at 7:43 PM Mark Nottingham <mnot@mnot.net> wrote:

> Yes, that's correct. I've made this commit --
>
> """
> The cdn-id identifies the CDN using either a hostname under its control or
> a pseudonym. Hostnames
> are preferred, to help avoid accidental collisions. If a pseudonym is
> used, unintentional collisions are more likely, and therefore values should
> be carefully chosen to prevent them; for example, using a well-known value
> (such as the recognized name of the CDN in question), or a generated value
> with enough entropy to make collisions unlikely (such as a UUID
> {{?RFC4122}}).
> """
>
> Happy to adjust that if need be.
>
> Cheers,
>
>
>
> > On 1 Feb 2019, at 12:06 pm, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > 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.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>