W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

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

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Tue, 29 Jan 2019 07:07:14 +0000
To: Eric Rescorla <ekr@rtfm.com>, Mark Nottingham <mnot@mnot.net>
CC: Adam Roach <adam@nostrum.com>, "draft-ietf-httpbis-cdn-loop@ietf.org" <draft-ietf-httpbis-cdn-loop@ietf.org>, "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>, Patrick McManus <mcmanus@ducksong.com>, The IESG <iesg@ietf.org>, Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <cc60f573-8093-b6fb-d8ee-e50d45b6f2b4@it.aoyama.ac.jp>
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.
Received on Tuesday, 29 January 2019 07:07:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 January 2019 07:07:44 UTC