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

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

Relaying for Mark.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net]
Sent: Thursday, January 15, 2009 10:11 PM
To: Eran Hammer-Lahav
Cc: John Bradley; David Orchard; Peter Davis; xri@lists.oasis-open.org; Jonathan Rees
Subject: Re: [xri] Designating DNS discovery for non-HTTP URIs

Catching up with e-mail after extended holiday, apologies for the
silence.

I'm not comfortable having extensive discussion of this on a limited-
access list; most of my concern around expanding the scope of
authority of site-meta is that it's setting a very large precedent
that can have serious impacts on other protocols, so the people behind
those protocols really need to be involved in the discussion.

So, I'm going to summarise the issues that I'm concerned about on the apps-discuss@ietf.org
  list (see <https://www.ietf.org/mailman/listinfo/apps-discuss>);
this is the centre of knowledge for people who develop application-
layer protocols in the IETF.

Cheers,


On 13/01/2009, at 4:17 AM, Eran Hammer-Lahav wrote:

> I am starting to form the opinion that the DNS section should be
> dropped altogether, and that a new section on authority should be
> added to discuss the various views and potential issues here. Then
> the spec should bounce this issue right back to the application
> owner asking: is an "HTTP-based Resource Descriptor Discovery"
> appropriate for your application? I think the issue has been
> resolved simply by including "HTTP-based" in the name. If an HTTP-
> based solution is not suitable for an SMTP-related application, a
> different discovery workflow is needed. Now, this different workflow
> can be the same with the addition of the DNS idea we are tossing
> around, or it can be the PKI idea below.
>
> This thought is still forming so I am very much open to other views.
>
> EHL
>
>
> From: John Bradley [mailto:jbradley@mac.com]
> Sent: Monday, January 12, 2009 8:58 AM
> To: Eran Hammer-Lahav
> Cc: David Orchard; Peter Davis; xri@lists.oasis-open.org; Jonathan
> Rees; Mark Nottingham
> Subject: Re: [xri] Designating DNS discovery for non-HTTP URIs
>
> Eran,
>
> I have been thinking about this issue of using DNS for a DNS
> authority based scheme to delegate responsibility for mapping meta-
> data about its resources.
>
> I feel torn between the practical issues of just doing it in a way
> that people will be able to use most easily, and the overall design
> principal of authority hierarchy in URIs.
>
> I agree with some that probably the worst consequence is setting a
> bad example for others.
>
> If I step back a bit and ask the question is DNS the only way a
> organization can assert it's authority outside of a scheme,  it
> struck me that perhaps there is another way that sidesteps the DNS
> issue.
>
> A signing cert from Verisign etc states that you have control over a
> domain.  Not a URI not a particular scheme like https: for that host
> or domain, but the domain itself.
>
> Given the relative insecurity of DNS (leaving dnssec aside for this
> conversation)  I would rather trust site-meta if it has been signed
> by the domain cert indicating it is authoritative for mailto and or
> xmpp rather than looking to DNS.
>
> I think if site-meta is signed by the cert of the domain then we
> maintain the authority chain though PKI rather than resolution.
> I am OK with that.  (Mark please speak up if you find this an awful
> principal)
>
> So all schemes SHOULD check the detached sig for site meta, and site-
> meta is considered authoritative for all the schemes it has maps for
> as long as the authority segment of the scheme matches the CN of the
> cert.  (Yes we may need to include subjectAltNames where the value
> is a DNS name or some other matching rule)
>
> An alternative though weaker option for the RP is to retrieve the
> site-meta over https:.  That however is much weaker as an attacker
> replacing a single text file on a site is a much easier thing to do
> than getting the private key for a site to generate the sig.
>
> It would be up to the needs of the RP software to choose the
> appropriate security.
>
> If we did something like that I could be persuaded to drop the DNS
> check from your proposal.
>
> Peters DNS resolution proposal is a separate issue.
>
> Regards
> =jbradley
>
> On 9-Jan-09, at 8:56 PM, Eran Hammer-Lahav wrote:
>
>
> I am happy to adjust it to "some hesitation"... :-)
>
> I added a new section to my draft last night explaining the reasons
> for this DNS workaround. I decided to promote a position I am still
> not fully sold on as a way to solicit feedback. I am actually hoping
> everyone will ask to drop it, but at least it is explicitly
> acknowledged as something people have expressed reservations for.
>
> EHL
>
>
> On 1/9/09 3:33 PM, "David Orchard" <orchard@pacificspirit.com> wrote:
> (note, my response will not make it onto the XRI list, hopefully
> JohnB will forward it).
>
> Usually () in TAG minutes indicate side comments that generally are
> informative and to be captured but not formal.  It's interesting
> that Dan did not want to make his comment formally.  And if you
> interpret his comment formally, I wonder if adding DNS doesn't solve
> his concern.
>
> I'm not convinced that the TAG comments can be called "strong
> resistance".  Frankly, I'd give another couple kicks at the can
> before adding such a complex optional feature.  I do appreciate your
> sensitivity to pushback and trying to ensure a smooth passage.
>
> Dave
>
> On Fri, Jan 9, 2009 at 3:01 PM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
> From: http://www.w3.org/2001/tag/2008/12/10-minutes
>
> DO: I think the TAG could talk about the issue with Authority. Eran
> has asked me and Jonthan to think about whether the TAG has anything
> to say about whether a file like this can speak >authoritatively<
> for, e.g. a mailto: URI.
>
> <ht> HT acknowledges that his suggestion has a huge problem in the
> legacy/name squatting
>
> <Zakim> skw2, you wanted to suggest that jar also mention the
> metadata-discovery googlegroup
>
> JR: Don't think I want to.
>
> SW: Should we point out the Google Group?
>
> <DanC_lap> (if you want to speak authoritatively for a mailto: URI,
> you have to be the SMTP server. or edit the SMTP standard)
>
> ---
>
> From: http://lists.w3.org/Archives/Public/www-talk/2008NovDec/
> 0012.html
>
> From: Mark Nottingham <mnot@mnot.net <http://mnot@mnot.net> >
> Date: Wed, 3 Dec 2008 11:24:04 +1100
>
> ...
>
> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make
> any authoritative assertions about mailto:dirk@foobar.com; even though
> the authority is the same, the URI scheme is different.
>
> I know this particular issue is an important one to the OpenID folks,
> but there needs to be a very careful and broad discussion of allowing
> policy and metadata from HTTP to be considered *automatically*
> authoritative for other protocols.
>
> ---
>
> So there seems to be some resistance to the idea that an HTTP server
> will be used as the generic provider of discovery information for
> non-HTTP resources. That is what this whole DNS proposal is about.
> Personally, I think the "lack of authority" argument is not very
> interesting, and that it is up to applications to decide if they
> want to accept what an HTTP server has to say about a non-HTTP URI.
> But I rather include something like this and make the discovery flow
> completely generic across URI scheme, than limit it to HTTP/S URIs
> only.
>
> EHL
>
>
>
>
> On 1/9/09 1:27 PM, "David Orchard" <orchard@pacificspirit.com <http://orchard@pacificspirit.com
> > > wrote:
>
>
> On Thu, Jan 8, 2009 at 5:17 AM, Peter Davis <peter.davis@neustar.biz
> <http://peter.davis@neustar.biz> > wrote:
> On Jan 7, 2009, at 6:40 PM, Eran Hammer-Lahav wrote:
> There seems to be strong resistance in various communities to the
> idea that
> an HTTP server can speak authoritatively for non-HTTP URIs. There is
> also
> strong resistance to using DNS as the entry point for resource
> discovery. At
> the same time, it is clear we need to support non-HTTP URIs and
> there is
> strong desire to include a DNS flavor.
>
> Can you provide any references to where this resistance is occurring?
>
> I would also like to see references for such resistance.  I think as
> soon you as you go from HTTP to HTTP + DNS, people are rightfully
> going to start asking about their favourite protocol, such as XMPP,
> BEEP, WS-*, SIP, etc.
>
> I think there needs to be compelling evidence to support such a
> complication.  Every thing we can possibly remove from V1 only helps
> achieve interoperability by reducing features, especially optional
> ones.
>
> Cheers,
> Dave
>
>
>


--
Mark Nottingham     http://www.mnot.net/