Subject: [Dbound] Can/should organizational boundaries include URIs? [x-post from websec]

From: Chris Hartmann <[email-masked]>
Date: Tue, 3 Feb 2015 10:45:56 -0800

Hello All,
A few weeks back a posed a problem statement to the websec list for
what I believe to be a fairly universal security/trust problem. I was
referred to dbound as a potential home for it. In some ways the
problem aligns with trying to better define and discover
'organizational boundaries', and resonates very well with the 'About
Dbound' blurb:

"Both users and applications make inferences from domain names, usually
in an effort to make some determination about identity or the correct
security stance to take."

However I was going down the path of including URI's as part of the
boundary definitions because I'm thinking these types of, perhaps
lesser formal but abundant, relationships wouldn't be integrated
through DNS, as they seem to not be today - consistently (ie: SaaS).
Which raises the question of how do we define an organizations
boundaries in "the cloud" (sorry had to say it) and importantly, how
can they be authenticated ?

Anyway, just wanted to toss this over the fence to confirm if:
a) Is this a valid problem ?
b) Appropriate and/or intersecting with dbound ?

Keep in mind I was unaware of dbound at the time.

Here is my problem statement snippet and thread:
https://www.ietf.org/mail-archive/web/websec/current/msg02286.html

1) Bob trusts and does personal business with a.com.

2) a.com forms a business relationship with b.com to perform a
business function on its behalf (payment processor, blog, whatever).
The landing page is b.com/a

3) Bob visits b.com/a and notices that the page claims to be
affiliated and owned by a.com

4) How can Bob, in absolute terms, trust that b.com/a is affiliated
and a delegated service by a.com? (say, prior to submitting sensitive
information)

Is this a security problem? I think so.

Cheers,
Chris

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 03 Feb 2015 14:26:25 -0500

> b) Appropriate and/or intersecting with dbound ?

You say URIs, but i think you mean http or https URIs in particular,
and not all possible URIs.  All possible URIs would wildly complicate
the arguments you're trying to make.

And even bringing in only http or https URIs to dbound would wildly
complicate the dbound problem space, which is already difficult enough.
Several of the dbound use cases involve things that have nothing to do
with http or https (e.g. choice of names in an X.509 certificate; e-mail
domain policies) which wouldn't be enriched at all by this expansion.

And dragging in http or https URIs inevitably starts picking at the
edges of the (conceptual) web browser itself, which is such a larger
problem space than DNS alone that i can't imagine the discussion process
terminating.

The place to set https URI-to-URI relationship policy is via http
mechanisms themselves -- see for example the ongoing discussion about
content-security-policy and CORS headers over in the w3c.

I'd really like to see dbound itself limited in scope to DNS.

    --dkg

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Feb 2015 16:59:39 -0500

> complicate the dbound problem space, which is already difficult enough.

Indeed, when I produced my first draft on this topic (now 3 or 4 years
ago, IIRC), I asked some web security people about it, because of the
single origin policy.  I got quite brusque responses to the effect
that it was useless and stupid because it didn't contain scheme and
port, and you coouldn't do anything without that.

Well, I tried.  Boy, that sucked.  (I am not afraid of putting my bad
ideas in public repositories, it turns out.)  Also, it received the
somewhat plausible feedback that we had pretty much always (pace
NAPTR) kept those kinds of things out of the DNS and used the DNS to
describe the thing to connect to, not the details of the service
there.  And none of the people who'd commented so strongly about the
first proposal would say boo about the second.

Finally, the more I thought about this, the more I realised that the
existing arrangements _already_ all depend on the name, and only the
name.  Therefore, it seems to me, to get something that anyone has a
hope of understanding, we need to follow the same approach.  Really,
if you need to differentiate so strongly, then there's an available
answer: use a new host-part in your URI.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Feb 2015 14:09:28 -0800

> ago, IIRC), 
...
> answer: use a new host-part in your URI.

I don't recall seeing a non-technical, non-acronym description of what
the desired user-level functionality is, that drives wanting to store
URIs or the like.  Can someone either proffer or point to some text of
that sort?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Feb 2015 17:38:40 -0500

> URIs or the like.  Can someone either proffer or point to some text of

I doubt it.  I tried, though not hard enough, in
https://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02.
The history of that document might be useful (and I freely admit might
not be).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Chris Hartmann <[email-masked]>
Date: Tue, 3 Feb 2015 15:23:30 -0800

> I'd really like to see dbound itself limited in scope to DNS.

I agree with your points here. The problem perhaps aligns in spirit
(somewhat), but by definition it doesn't fit entirely in DNS either.
Thanks for the feedback. Any feedback on the problem by itself would
be appreciated as well (perhaps off thread if that is more
appropriate)

Thanks,
Chris