Re: [arch-d] Treating "private" address ranges specially

[Spencer Dawkins at IETF <[e-mail]>]

I shouldn't ask, but I'd feel worse if I didn't.

On Wed, Mar 31, 2021 at 6:53 PM Martin Thomson <[e-mail]> wrote:

> Thanks everyone for the insights.
>
> I'll reply to Ted as he hit the crux of the issue most adroitly...
>
> On Wed, Mar 31, 2021, at 20:07, Ted Hardie wrote:
> > What I think this proposal would actually like to do is to determine
> > whether a resource referenced by a specific web server would also be
> > reachable by that server.
>
> That's exactly it.
>
> Brian's point about the inherent folly of making such guesses is well
> taken.
>
> It's quite clear that it is generically bad to make these sorts of
> inferences from addresses.  That's good information.
>
> The question I'm now interested in answering is whether using these as
> part of a heuristic in order to limit the scope of a change like the
> proposed is tolerable.
>
> The goal here is to close off a security loophole in how browser make
> request for a tiny slice of the total set of requests that are made.  The
> ultimate goal might be to remove the loopholes uniformly.  However, that
> would break so much stuff that a change like that would never stick.  This
> is a more narrowly-scoped approach that tries to identify conditions where
> the requests are a) more dangerous in general, and b) rare enough that any
> breaks would not be widely felt.
>
> I've pointed out some of the limitations of this approach (and several
> more have been identified, thanks!), but I haven't seen reasons here why a
> heuristic like that proposed would be strictly problematic.  Assuming that
> these shortcoming are acknowledged properly (they are not currently) is
> there any reason not to use some sort of address-based heuristic for this
> sort of purpose?
>
> I can see how building on top of this simplistic base for other purposes
> might be harmful, but is the specific action being taken inherently bad, or
> is it just not very good?  It not being very good is a totally fair
> criticism, but that will be balanced against the apparent utility here.
> This design protects the badly-secured router provided by my ISP from
> requests from the big bad Internet.  That is a tangible outcome against
> which "addressing is more complex than this design allows for" doesn't
> weigh very heavily.
>
> > First, I'm not a huge fan
> > of "ask the user" in decisions that rely on an understanding of opaque
> > inner workings of the net, and this runs that risk.
>
> I made the same comment myself.  "Not a huge fan" doesn't really cover it
> :)  I think that the "ask the user" provisions here are entirely
> misguided.  Thankfully, my understanding is that this might be implemented
> without any such controls, which would be good - at least to the extent
> that you are not happy with "ask the user" as a component in any design.
>
> Eliot raised the converse question about consent, which is to say, is
> there an override so that users can enable access to stuff that doesn't
> provide consent on its own, such as old gear.  I agree that this would be
> desirable and made similar comments; I don't know what provision is being
> made there though.
>
> > Second, I don't understand the intended client behavior
> > here if it accesses web resources via a proxy, and I didn't find any
> > mention of proxy behavior in the text.  Text about this in the final
> > document would be useful.
>
> Good point; I had not considered that, but I believe that this does not
> make special provisions for proxies.  This protection would apply if proxy
> configuration says not to use a proxy, I think.  However, this could not
> apply if the vulnerable server were contacted via proxy, that is true.
>
> > This is especially true in the
> > unfortunately large number of organizations who have repurposed
> > unrouted addresses as "extra" private address space
> > (https://teamarin.net/2015/11/23/to-squat-or-not-to-squat/ is old, but
> > the practice is far from dead).
>
> Oh yeah, I had forgotten about that.  Another good point to add to those
> Brian makes.
>

Those notes are destined to go to W3C, in some way?

I had the privilege of including "The People Who Were Unable to See the
Elephant" in
https://datatracker.ietf.org/doc/html/draft-dawkins-quic-multipath-questions-01#section-1.1
last year, and that's what this conversation feels like - I wouldn't mind
seeing the final list of comments ("this is what the private addressing
elephant looks like") after everyone finishes reporting on what they know.

There seems to be a lot to report, and the discussion seems to be jogging
the understanding of some pretty experienced people.

Best,

Spencer