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

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Apr 2021 10:36:50 +0100

I've snipped almost everything to give a narrow response to your follow-up
question.

On Thu, Apr 1, 2021 at 12:53 AM Martin Thomson <[email-masked]> wrote:

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

My personal take is that this does not do what it says on the tin, and that
deploying a security mitigation that doesn't do what it says it does is
inherently bad.

As Toerless pointed out, the simple designations tell you whether something
is *potentially* globally routable or *potentially* private.  In
organizations that got lots of globally routable space, parts of it were
carved into limited reachability domains.  Those are just as private for
those organizations as those marked in the IANA registry.  They are not
protected by this, but in the presence of this method, the organizations
might assume those private addresses were (and the number of organizations
with sufficient address space to do this in IPv6-land is not small).  There
are lots of other organizations that have deployed methods to make IP
address space that is nominally private actually have a greater scope.
They would lose the ability to reference resources that should be
reachable.  That breaks the character of the web.

Mapping the reachability overlap of two hosts on the network is,
unfortunately, a complex problem in the current Internet.  I don't think
that this registry-based approach is a sound basis for tackling the
problem.

Just my two cents,

Ted Hardie

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Apr 2021 10:30:52 -0500

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

On Wed, Mar 31, 2021 at 6:53 PM Martin Thomson <[email-masked]> 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.
>
> > 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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Apr 2021 12:15:28 -0400

Toerless Eckert <[email-masked]> wrote:
    > c) There is actually (IMHO) a good discussion that should be had abouut
    > how browser security could
    > better support the needs of limited domains (rfc8799), but i fear the mayority of contributors
    > to w3c / browser security in ietf still think everything required is just what fits the global
    > Internet web-pki and Internet cloud services centric browser security
    > architecture we have today.

There is a SIG of IOTSecurityFoundation called manysecured, which is
attempting to have this conversation.

   https://manysecured.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 02 Apr 2021 07:28:41 +1100

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

This is in response to a request from the TAG for consideration.  It's part of a review they are conducting here: https://github.com/w3ctag/design-reviews/issues/572

I've referenced Ted's recent summary in that thread, so I think that the feedback thus far has been received.

I don't think that the TAG would object to receiving more comments there if they add new information, but it seems like most of the key points have been covered already.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 8 Apr 2021 01:01:14 -0500

Martin,

My apologies for not hitting "send" sooner, but I wanted to thank you for
this answer. It was helpful.

Best,

Spencer

On Thu, Apr 1, 2021 at 3:29 PM Martin Thomson <[email-masked]> wrote:

> This is in response to a request from the TAG for consideration.  It's
> part of a review they are conducting here:
> https://github.com/w3ctag/design-reviews/issues/572
>
> I don't think that the TAG would object to receiving more comments there
> if they add new information, but it seems like most of the key points have
> been covered already.
>

---

From: "Olaf Kolkman" <[email-masked]>
Date: Thu, 08 Apr 2021 10:25:28 +0200

Christian wrote:
> I found a copy of the SOHO Pharming paper at http://courses.isi.jhu.edu/netsec/papers/Driveby_Pharming.pdf.

That is the DRIVE-BY-PHARMING reference.

I think that [this is](https://331.cybersec.fun/TeamCymruSOHOPharming.pdf) the Team Cymru paper on Soho Pharming that us referred to as SOHO-PHARMING in the paper.

(Public service msg)

—Olaf