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

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/

Received on Monday, 4 February 2019 03:44:15 UTC