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

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 Jan 2019 13:44:29 -0800

Unless I am misreading this text, it seems to not provide any guidance at
all about how the pseudonyms are constructed, so I don't really see how it
addresses the issue of pseudonym collision

On Thu, Dec 20, 2018 at 9:04 PM Mark Nottingham <[email-masked]> wrote:

> See:
>   https://github.com/httpwg/http-extensions/commit/59505dbd1883
>
>
> > On 21 Dec 2018, at 3:34 pm, Adam Roach <[email-masked]> wrote:
> >
> > On 12/20/18 7:19 PM, Mark Nottingham wrote:
> >> On 21 Dec 2018, at 11:40 am, Adam Roach <[email-masked]> wrote:
> >>> I agree with EKR here. The more I think about the situation -- and
> Mark's responses in particular ("There are relatively few CDNs, and they're
> pretty aware of each other") -- the more I'm convinced that, while the
> proposed solution *probably* works in 2018, it may well fail in 2028,
> depending on how the CDN market evolves. If history is any guide, engineers
> are pretty terrible futurists. The best we can do is plan for scaling
> beyond that which we can presently imagine (cf. IPv4).
> >>>
> >>> I think some means of collision avoidance here is required prior to
> document publication.
> >> I agree engineers are terrible futurists; however (and perhaps as a
> result), we're really really good at over-engineering things for
> anticipated problems that don't eventuate. My viewpoint here is informed by
> observing how many Web-related registries operate (or fail to).
> >
> >
> > No one here is asking for a registry.
> >
> >
> >> The current specification allows us to insert more stringent
> requirements in the future if necessary. Personally, I think that's
> sufficient.
> >>
> >> However, if you insist, I think the lowest-impact way to address this
> is to adopt a structure similar to that used in Via, (hostname under
> control of the CDN or pseudonym) and encourage (but not require) use of a
> hostname.
> >
> >
> > It's probably enough to say that it has to end in a domain name under
> control of the CDN, but your proposal works as well.
> >
> >
> >> If we do that, we might want to revisit the example, since its use of
> 'host' might be confusing to readers.
> >
> >
> > I always assume that spec changes that impact examples imply changes in
> the corresponding examples, so yes. Thanks.
> >
> >
> > /a
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Jan 2019 07:08:18 +0900

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.

> On 28 Jan 2019, at 6:44 am, Eric Rescorla <[email-masked]> wrote:
> 
> Unless I am misreading this text, it seems to not provide any guidance at all about how the pseudonyms are constructed, so I don't really see how it addresses the issue of pseudonym collision
> 
> >>> I agree with EKR here. The more I think about the situation -- and Mark's responses in particular ("There are relatively few CDNs, and they're pretty aware of each other") -- the more I'm convinced that, while the proposed solution *probably* works in 2018, it may well fail in 2028, depending on how the CDN market evolves. If history is any guide, engineers are pretty terrible futurists. The best we can do is plan for scaling beyond that which we can presently imagine (cf. IPv4).
> >>> 
> >>> I think some means of collision avoidance here is required prior to document publication.
> >> I agree engineers are terrible futurists; however (and perhaps as a result), we're really really good at over-engineering things for anticipated problems that don't eventuate. My viewpoint here is informed by observing how many Web-related registries operate (or fail to).
> > 
> > 
> >> The current specification allows us to insert more stringent requirements in the future if necessary. Personally, I think that's sufficient.
> >> 
> >> However, if you insist, I think the lowest-impact way to address this is to adopt a structure similar to that used in Via, (hostname under control of the CDN or pseudonym) and encourage (but not require) use of a hostname.
> > 
> > 
> > It's probably enough to say that it has to end in a domain name under control of the CDN, but your proposal works as well.
> > 
> > 
> >> If we do that, we might want to revisit the example, since its use of 'host' might be confusing to readers.
> > 
> > 
> > I always assume that spec changes that impact examples imply changes in the corresponding examples, so yes. Thanks.
> > 
> > 
> > /a
> > 
> > 
> 
> --

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 Jan 2019 16:45:30 -0800

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 <[email-masked]> wrote:

> 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.
>
>
>
> > Unless I am misreading this text, it seems to not provide any guidance
> at all about how the pseudonyms are constructed, so I don't really see how
> it addresses the issue of pseudonym collision
> >
> > > I always assume that spec changes that impact examples imply changes
> in the corresponding examples, so yes. Thanks.
> > >
> > >
> > > /a
> > >
> > >
> >
> > --

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Jan 2019 09:51:09 +0900

Some advisory text to guide using them?

> On 28 Jan 2019, at 9:45 am, Eric Rescorla <[email-masked]> 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
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 18:13:29 -0800

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 <[email-masked]> wrote:

> > Notably, doing something like rooting product tokens in the DNS name
> space would have done *nothing* to prevent the issues we're seeing with
> > 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
> > 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.
> >
> >
> >
> > > >> However, if you insist, I think the lowest-impact way to address
> this is to adopt a structure similar to that used in Via, (hostname under
> > > > It's probably enough to say that it has to end in a domain name
> under control of the CDN, but your proposal works as well.
> > > >
> > > >

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Jan 2019 11:17:50 +0900

Adam seemed to be OK with the current text in <https://www.w3.org/mid/[email-masked]>, so I think it's just you.

> On 29 Jan 2019, at 11:13 am, Eric Rescorla <[email-masked]> wrote:
> 
> 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
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 19:09:52 -0800

On Mon, Jan 28, 2019 at 6:18 PM Mark Nottingham <[email-masked]> wrote:

> Adam seemed to be OK with the current text in <
> https://www.w3.org/mid/[email-masked]>,
> 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.

-Ekr

> > 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
> >
> >
> > > 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,
> > > 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
> > > > Unless I am misreading this text, it seems to not provide any
> guidance at all about how the pseudonyms are constructed, so I don't really
> see how it addresses the issue of pseudonym collision
> > > >
> > > > >>> I agree with EKR here. The more I think about the situation --
> and Mark's responses in particular ("There are relatively few CDNs, and
> they're pretty aware of each other") -- the more I'm convinced that, while
> the proposed solution *probably* works in 2018, it may well fail in 2028,
> > > > >> I agree engineers are terrible futurists; however (and perhaps as
> a result), we're really really good at over-engineering things for
> > > > >> If we do that, we might want to revisit the example, since its
> use of 'host' might be confusing to readers.
> > > > >
> > > > >
> > > > > I always assume that spec changes that impact examples imply
> changes in the corresponding examples, so yes. Thanks.
> > > > >
> > > > >
> > > > > /a
> > > > >
> > > > >
> > > >
> > > > --

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 29 Jan 2019 07:07:14 +0000

> 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.

---

From: Chris Lemmons <[email-masked]>
Date: Thu, 31 Jan 2019 16:21:20 -0700

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.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Jan 2019 17:06:37 -0800

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 <[email-masked]> wrote:

> > >>>> HTTP has used similar constructs for 20+ years and collisions have
> not
> > >> been an issue:
> > >>>>