Re: [xri] Designating DNS discovery for non-HTTP URIs

[Eran Hammer-Lahav <eran@hueniverse.com>]

Title: Re: [xri] Designating DNS discovery for non-HTTP URIs

We are talking about different things: authority and trust, and it is more philosophical than practical.

The claim made was that an HTTP server cannot speak authoritatively for SMTP resources (mailto URI). Technically, of course it can (you can even do ‘GET mailto:user@example.com HTTP/1.1’). So this is about the authority of an HTTP server to offer metadata about resources it does not manage directly.

We can argue that we should simply ignore this position and within XRD define that when you perform XRD discovery on a mailto URI, the XRD is authoritative for the XRD-based discovery metadata. But we can also add a simple step that solves the authority question. DNS has the most authority over any domain-level services. So if we allow DNS to state that HTTP has authority over non-HTTP URIs, we solve the authority problem.

None of this addresses or solves trust (i.e. I trust Google to keep my email private, but Google has no authority to speak on my behalf). The case in which the HTTP admin gains control over the SMTP area isn’t a security threat but an issue of organizational authority and expectations.

Again, this is all very philosophical and not very technical, so most people find it a waste of time. But reducing philosophical disagreements can help get technical specifications moving forward. There was nothing technical wrong with the XRI 2.0 spec, but it still failed a standard vote because of philosophical disagreements... If you write applications and don’t care about authority, just trust, this will not make and difference to you.

But if you care about both, you are right that we do not have a way to trust such a statement by DNS at this point. So the proposal is still incomplete if you want to have both.

EHL

On 1/8/09 1:41 PM, "Brian Eaton" <beaton@google.com> wrote:

> On Thu, Jan 8, 2009 at 8:44 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> > This is one of the options (see my reply to Peter). But it has to be "Add
> > DNS record to authorize" and not "Add DNS record to forbid". The real
> > problem is that an eager HTTP admin will be able to hijack an organization
> > identity services or other sensitive discovery-based data without anyone
> > having any control over it. In most companies, there is a clear separation
> > between the postmaster and webmaster and we need to make sure not to
> > introduce security issues.
>
> Hrmm.  I thought I understood where you were going with this thread,
> until I read that you considered the DNS and HTTP check security
> relevant.  DNS as used and deployed today does not offer useful
> security, so "Add DNS record to authorize" is not a particularly
> meaningful security check.
>
> Going back to square one... you mention "an eager HTTP admin will be
> able to hijack an organization identity services... without anyone
> having any control over it."  I think the focus on "eager HTTP admin"
> is where the threat model is broken.  You should worry about "a
> motivated attacker who controls the network and has hacked the web
> server will be able to hijack an organizations identity services."
>
> DNS doesn't help with that threat model.  Out of band key exchange
> (like most SAML deployments) does.
>
> Cheers,
> Brian