Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments

From: Michael Jones <[email-masked]>
Date: Sun, 11 Nov 2012 12:58:57 -0800

Hi Blaine,

Thanks for writing.

The problem with SRV records is they aren’t ubiquitously
accessible.  Some Web development platforms don’t support direct DNS
queries.  For instance, I don’t believe that there are JavaScript
functions available for doing DNS queries.  Likewise, I’ve been told that
some web hosting companies don’t expose a function to write SRV record values.

Here’s my thoughts about your tumblr example.  The root of
the problem you’re describing is that the party in control of the subdomain may
not be the same as the party in charge of the domain.  (An amusing related
anecdote told to me is that early in the web, an enterprising MIT student
registered his machine with the name “www”.  Apparently for years www.mit.edu went to his personal machine, whereas
web.mit.edu was the university web site.  Eventually the administration
decided to assert its control over the name www.mit.edu.)

Here’s reasons I don’t think your tumblr example is that
damning:

1.     
Most domains do not allow creation of arbitrary subdomains by
third parties.

2.     
If example.com is using SWD and has a web site, it will normally
have an https://example.com/.well-known/simple-web-discovery
endpoint and so it won’t matter whether there’s also an endpoint at https://simple-web-discovery.example.com/.well-known/simple-web-discovery
(unless example.com is down or unreachable).

3.     
Unless the party in control of the content at
simple-web-discovery.example.com also has the authority to install a TLS
certificate for https://simple-web-discovery.example.com/,
an SWD query would fail.

4.     
When a site decides to start using SWD, if it doesn’t already
control the subdomain, it can reclaim it at that time.

All that said, I do appreciate you pointing this out so we can
be conscious of the possible attack.

I understand your suggestion to always do the lookup at the
subdomain.  The practical problem with that is that it effectively
mandates purchasing a second TLS certificate to implement SWD.  That’s a
big adoption blocker.  It’s fine as a workaround when necessary, but
shouldn’t be the default.

Best wishes,

-- Mike

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Blaine Cook

Sent: Monday, November 05, 2012 11:56 AM

To: Paul E. Jones

Cc: [email-masked]

Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling
Hosted Deployments

To continue with the "simplicity is the goal"
theme, if it turns out that people are happier to use DNS records for
discovering the Webfinger/SWD endpoint, then the host-meta lookup should be
dropped entirely in favour of DNS lookups (or vice versa).

If we're going to go the DNS route (and require it as a
mandatory fallback), then it seems like following normal DNS semantics and
making the lookup behave like MX or SRV records would be sensible. Rather than
having a fallback, just have all lookups go immediately to the agreed-upon
domain prefix / SRV record (I would express a slight bias towards SRV record,
simply because the mechanism as specified is trivially vulnerable to attack on
numerous existing platforms. E.g., http://simple-web-discovery.tumblr.com/
)

b.

On 5 November 2012 13:44, Paul E. Jones <[email-masked]>
wrote:

FYI

From: Mike Jones <[email-masked]>

Sent: Mon Nov 05 07:55:14 EST 2012

To: "Paul E. Jones" <[email-masked]>

Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments

Paul,
could you do me a favor and forward this note to the apps-discuss list so
people have context on why I updated SWD?  For some reason, the list
doesn’t appear to be accepting my message.

              
Thanks,

-- Mike

From: Mike Jones 

Sent: Sunday, November 04, 2012 9:21 PM

To: [email-masked]

Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments

I’ve updated the Simple Web Discovery (SWD) specification to incorporate a
means of performing discovery on domains for which it may not be possible to
create a .well-known endpoint.  This can often be the case for hosted
domains, where it is common for e-mail to be provided but no web server. 
This solution was developed in discussions by the OpenID Connect working
group.

This draft is being
published now to facilitate discussions of the need to enable discovery for
hosted domains and possible solutions for doing so at the IETF Applications
Area working group meeting at IETF 85 in Atlanta.

The updated specification is
available at:

·       
http://tools.ietf.org/html/draft-jones-simple-web-discovery-04

Changes made were:

·       
Specified that the SWD server for a domain may be located at the simple-web-discovery subdomain
of the domain and that SWD clients must first try the endpoint at the domain
and then the endpoint at the subdomain. 

·       
Removed the SWD_service_redirect response,
since redirection can be accomplished by pointing the simple-web-discovery subdomain
to a different location than the domain's host. 

·       
Removed mailto: from examples in favor of bare e-mail address syntax. 

·       
Specified that SWD servers may also be run on ports other than 443,
provided they use TLS on those ports.

An HTML formatted version is
available at:

·       
http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html

(This notice was also posted
to http://self-issued.info/?p=891.)

-- Mike

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 12 Nov 2012 06:55:01 +0100

On 11 nov 2012, at 21:58, Michael Jones <[email-masked]> wrote:

> The problem with SRV records is they aren’t ubiquitously accessible.  Some Web development platforms don’t support direct DNS queries.  For instance, I don’t believe that there are JavaScript functions available for doing DNS queries.  Likewise, I’ve been told that some web hosting companies don’t expose a function to write SRV record values.

It is about time to:

a) Stop referring to myths

b) Fix the broken software in the cases there is

SRV records (and similar new RR types added now more than 10 years ago) MUST be possible to be used.

It is time IETF says STOP to these arguments for non-evolution of the protocols and standards IETF develop.

   Patrik Fältström

---

From: Michael Jones <[email-masked]>
Date: Sun, 11 Nov 2012 22:08:54 -0800

Hi Patrik, I don't believe that this is a myth.  For instance, can you point me to the API I would use from JavaScript to query for a SRV record?  And is it available on all the modern browsers?  If it's not, can you demonstrate agreement of all the major browser vendors to implement it and give me data on the expected time for deployment of the new API to reach 90+% penetration in the installed browser base? The goal for the discovery specs is enabling ubiquitous deployment, where discovery is needed.  Saying "fix the software" effectively means that the problem will not be solved for many many years. (No, I don't love the domain prefix solution either.  It's just the least bad of those that have been explored that are actually workable today.  If you have another solution that's ubiquitously deployable across all widely used web development tools, by all means, please give us a better alternative.  I put this one out there hoping someone would come up with a better one!) Best wishes,-- Mike
 > Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments
> From: [email-masked]
> Date: Mon, 12 Nov 2012 06:55:01 +0100
> CC: [email-masked]; [email-masked]
> To: [email-masked]
> 
>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 12 Nov 2012 07:32:27 +0100

On 12 nov 2012, at 07:08, Michael Jones <[email-masked]> wrote:

> I don't believe that this is a myth.  For instance, can you point me to the API I would use from JavaScript to query for a SRV record?

First, this is definitely not a complaint on you or your view. This what I write is a generic statement that I think IETF should take on, and resolve.

Java Script is one of the things that can be fixed. And my view is that that will be fixed when the browsers do start to use SRV records in their resolution chain.

> And is it available on all the modern browsers?

Available on browsers? What do you mean? Of course browsers are not looking up SRV records as that is not part of the resolution mechanism to use for resolution of HTTP scheme URIs.

But also see the discussions around future versions of HTTP where new algorithms are necessary regardless of what happens, and it would be sad if not more modern DNS resolution is included in that upgrade.

   Patrik

---

From: Michael Jones <[email-masked]>
Date: Sun, 11 Nov 2012 22:39:31 -0800

I completely agree with you that the IETF should take this on so that it eventually gets fixed.  And I agree that in the case of JavaScript, the opportune time window in which to do it is probably when HTTP 2.0 is deployed. 
 Best wishes,-- Mike> Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments
> From: [email-masked]
> Date: Mon, 12 Nov 2012 07:32:27 +0100

---

From: Ned Freed <[email-masked]>
Date: Mon, 12 Nov 2012 00:03:08 -0800 (PST)

> It is time IETF says STOP to these arguments for non-evolution of the protocols and standards IETF develop.

I emphatically agree with every point you make here. It's one thing for
individual vendors to make consessions to the failure of other vendors to do
things correctly; it's quite another for standards bodies to take (or not take)
actions that harm the evolution of the Internet.

				Ned

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Nov 2012 09:07:51 -0800

> b) Fix the broken software in the cases there is

I repeat the question others asked: which "myths" are you referring to?

In specific, a lot of web development is done in JavaScript. In current JavaScript, there is no way to send DNS queries, I believe. In fact, for security reasons, I believe all you can do is send HTTP queries. You might consider this to be "broken software", but I might consider allowing insecure code pushed into my (browser) application to send and receive arbitrary messages on any transport and port to be a security issue.

I note that you Cc'd the IAB on this. Is the IAB considering requiring applications that include active code such as JavaScript to be able to do DNS?

> SRV records (and similar new RR types added now more than 10 years ago) MUST be possible to be used.

Everywhere? Or only in systems that can already do their own DNS?

> It is time IETF says STOP to these arguments for non-evolution of the protocols and standards IETF develop.

Yes, and hyperbole is killing the Internet. :-)

--Paul Hoffman

---

From: Blaine Cook <[email-masked]>
Date: Mon, 12 Nov 2012 17:14:32 +0000

... if the thing we're trying to guard against is environments where
individuals can't deploy Webfinger / SWD because of constraints that are
beyond their control, then subdomains aren't going to help, since beyond
the blatant security issues, there's the fact that many people and groups
aren't going to be able to setup sub-domains, and if they can, it's going
to be harder than just using a document under /.well-known/ at their
top-level domain.

If we're making compromises, let's make compromises that actually achieve
the goals we're trying to achieve, please!

b.

On 12 November 2012 17:07, Paul Hoffman <[email-masked]> wrote:

> >> The problem with SRV records is they aren’t ubiquitously accessible.
>  Some Web development platforms don’t support direct DNS queries.  For
> instance, I don’t believe that there are JavaScript functions available for
> doing DNS queries.  Likewise, I’ve been told that some web hosting
> companies don’t expose a function to write SRV record values.
> >
> > It is about time to:
> >
> In specific, a lot of web development is done in JavaScript. In current
> JavaScript, there is no way to send DNS queries, I believe. In fact, for
> security reasons, I believe all you can do is send HTTP queries. You might
> consider this to be "broken software", but I might consider allowing
> insecure code pushed into my (browser) application to send and receive
> arbitrary messages on any transport and port to be a security issue.
>
> I note that you Cc'd the IAB on this. Is the IAB considering requiring
> applications that include active code such as JavaScript to be able to do
> DNS?
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Nov 2012 09:15:29 -0800

> arbitrary messages on any transport and port to be a security issue.
Indeed. There are very good reasons not to allow this...that said, however,
a simplified "Discovery API" of sorts, based around DNS, could be defined
and provided to javascript developers if we could get the browser
developers on board. HTTP/2 could very well provide a strong motivation to
do so given that srv-based upgrade discovery is one of the options on that
table. It does not have to be code sending "arbitrary messages on any
transport" ... it could be something as simple as....  Discovery.inspect("
example.org", "srv.service.type", callback) where any discovered matching
srv records are passed to the callback. Fairly simple and straightforward
and would not introduce any significant new security risks that do not
already currently exist. All that would be necessary to make it happen is
browser-vendor support and a relatively simple, well-defined interface.
Certainly not impossible.

- James

---

From: George Fletcher <[email-masked]>
Date: Mon, 12 Nov 2012 12:28:04 -0500

Hi Blaine,

I can say that deploying the sub-domain solution is MUCH easier within 
my company than trying to put a dynamic web service on the "root" domain:)

Discovery (especially resource= discovery) is largely an identity 
problem and in many large companies the "identity group" has no control 
over the corporate / main site. So for small companies deploying on the 
"root" domain is pretty straight forward (especially if they start with 
that in mind). I think for larger companies it will be significantly harder.

For me, the sub-domain is the simplest solution to deploy because it 
doesn't require any coordination with other internal groups. The next 
easiest is a static redirect file that tells the requester to go to my 
deployed sub-domain.  Solutions beyond these two start to get 
complicated very quickly (for me).

Thanks,
George

On 11/12/12 12:14 PM, Blaine Cook wrote:
> individuals can't deploy Webfinger / SWD because of constraints that 
> are beyond their control, then subdomains aren't going to help, since 
> beyond the blatant security issues, there's the fact that many people 
> and groups aren't going to be able to setup sub-domains, and if they 
> can, it's going to be harder than just using a document under 
> /.well-known/ at their top-level domain.
>
> If we're making compromises, let's make compromises that actually 
> achieve the goals we're trying to achieve, please!
>
> b.
>
>
> On 12 November 2012 17:07, Paul Hoffman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Nov 11, 2012, at 9:55 PM, Patrik Fältström <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >
>     > On 11 nov 2012, at 21:58, Michael Jones
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     >
>     >> The problem with SRV records is they aren't ubiquitously
>     accessible.  Some Web development platforms don't support direct
>     DNS queries.  For instance, I don't believe that there are
>     JavaScript functions available for doing DNS queries.  Likewise,
>     I've been told that some web hosting companies don't expose a
>     function to write SRV record values.
>     >
>     > It is about time to:
>     >
>     In specific, a lot of web development is done in JavaScript. In
>     current JavaScript, there is no way to send DNS queries, I
>     believe. In fact, for security reasons, I believe all you can do
>     is send HTTP queries. You might consider this to be "broken
>     software", but I might consider allowing insecure code pushed into
>     my (browser) application to send and receive arbitrary messages on
>     any transport and port to be a security issue.
>
>     I note that you Cc'd the IAB on this. Is the IAB considering
>     requiring applications that include active code such as JavaScript
>     to be able to do DNS?
>
>     > It is time IETF says STOP to these arguments for non-evolution
>     of the protocols and standards IETF develop.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Nov 2012 09:35:21 -0800

Do we have any actual quantitative data?  I can believe that there are some
people for whom anything DNS-based is bad, and some other people for whom
the webspace root is bad, but I haven’t even the beginnings of a guess as
to which group is larger.  Or which class of problem is going to be easier
to address at scale in the medium/long term.

 -T

On Mon, Nov 12, 2012 at 9:28 AM, George Fletcher <[email-masked]> wrote:

>  Hi Blaine,
>
> I can say that deploying the sub-domain solution is MUCH easier within my
> company than trying to put a dynamic web service on the "root" domain:)
>
> Discovery (especially resource= discovery) is largely an identity problem
> and in many large companies the "identity group" has no control over the
> corporate / main site. So for small companies deploying on the "root"
> domain is pretty straight forward (especially if they start with that in
> mind). I think for larger companies it will be significantly harder.
>
> deployed sub-domain.  Solutions beyond these two start to get complicated
> very quickly (for me).
>
> Thanks,
> George
>
> apps-discuss mailing [email-masked]://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>

---

From: Blaine Cook <[email-masked]>
Date: Mon, 12 Nov 2012 17:39:35 +0000

> company than trying to put a dynamic web service on the "root" domain:)

I meant the static solution, rather than the dynamic one, since this is
about redirecting from one domain to another delegated domain, which it
sounds like is a solution that would work for you (if slightly more
complicated than setting up a subdomain for yourself).

b.

---

From: Blaine Cook <[email-masked]>
Date: Mon, 12 Nov 2012 17:41:46 +0000

On 12 November 2012 17:35, Tim Bray <[email-masked]> wrote:

> Do we have any actual quantitative data?  I can believe that there are
> some people for whom anything DNS-based is bad, and some other people for
> whom the webspace root is bad, but I haven’t even the beginnings of a guess
> as to which group is larger.  Or which class of problem is going to be
> easier to address at scale in the medium/long term.

It's maybe worth noting that Google's webmaster tools require modification
of an HTTP location, as do many SSL-issuers and others who are
authenticating ownership of a domain, so it's something that happens
"extremely often" (I can't produce numbers since I don't have access to
that sort of data). I'm not aware of any that use subdomains.

b.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 12 Nov 2012 18:42:35 +0100

> I repeat the question others asked: which "myths" are you referring to?

As a myth I see for example that it is hard to use other RR Types. Yes, hardER, as one can not use one of the libraries that exists.

> In specific, a lot of web development is done in JavaScript. In current JavaScript, there is no way to send DNS queries, I believe. In fact, for security reasons, I believe all you can do is send H…

This is why I said in my response that the day browsers use SRV records to resolve HTTP URIs, then also javascript will do so.

> I note that you Cc'd the IAB on this. Is the IAB considering requiring applications that include active code such as JavaScript to be able to do DNS?

I cc:ed IAB as I think it is close to the point in time where IAB must decide whether we should only(!) have the resource records A, AAAA, TXT, or if we also should be able to start using other RR Types.

We (IETF) waste time by repeating this discussion over and over again.

> Everywhere? Or only in systems that can already do their own DNS?

Enough so that IETF know whether new RR Types should be specified or not.

> Yes, and hyperbole is killing the Internet. :-)

On Thursday next week in fact!

   Patrik

---

From: George Fletcher <[email-masked]>
Date: Mon, 12 Nov 2012 12:57:33 -0500

On 11/12/12 12:39 PM, Blaine Cook wrote:
> On 12 November 2012 17:28, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Blaine,
>
>     I can say that deploying the sub-domain solution is MUCH easier
>     within my company than trying to put a dynamic web service on the
>     "root" domain:)
>
>
> I meant the static solution, rather than the dynamic one, since this 
> is about redirecting from one domain to another delegated domain, 
> which it sounds like is a solution that would work for you (if 
> slightly more complicated than setting up a subdomain for yourself).
> b.

Yes, it's doable... however, given that we support multiple domains 
(from a SWD perspective) the complexity grows with each new static file 
we have to deploy.

If my recollection of previous discussions is correct, there are some 
deployments where being able to serve a file from the "root" site is not 
possible. Hence the sub-domain solution was introduced.

Thanks,
George

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Nov 2012 10:00:13 -0800

> As a myth I see for example that it is hard to use other RR Types. Yes, hardER, as one can not use one of the libraries that exists.

I fear that you are misunderstanding this thread then. The debate is not "SRV vs. some other RRtype like TXT", but "SRV versus HTTP lookup and redirect".

> This is why I said in my response that the day browsers use SRV records to resolve HTTP URIs, then also javascript will do so.

Browsers currently use port 53 to look up A records, but they do not allow JavaScript to do so. To many of us, that is a good thing. Even if a browser used SRV to look up HTTP URIs, it sounds like you are saying that the browser should let JavaScript look up arbitrary URIs in the DNS. I'm not sure that the security properties of doing this have been investigated.

> We (IETF) waste time by repeating this discussion over and over again.

But that's not what this thread is about at all. If the IAB wants to decide whether indirection in application protocols should be done in the DNS with SRV versus in the protocols, that's fine, but for HTTP, that's kinda late.

> Enough so that IETF know whether new RR Types should be specified or not.

As you say above, SRV is not a new RRtype here.

> On Thursday next week in fact!

Well played, sir! :-)

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Nov 2012 10:11:29 -0800

> > On Thursday next week in fact!

You guys are so wrong, per the Mayans the Internet and everything else ends
Dec 21, which is not next week. -T

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 12 Nov 2012 19:13:12 +0100

> I fear that you are misunderstanding this thread then. The debate is not "SRV vs. some other RRtype like TXT", but "SRV versus HTTP lookup and redirect".

I absolutely understand the debate (and have in fact had a few phone calls to me about it), but I started to see arguments that "SRV is not a good choice as we can not deploy SRV". If that is an argument to use, then, well, then we have the "SRV or TXT" discussion. At least in the form of arguments.

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Nov 2012 10:53:44 -0800

> I absolutely understand the debate (and have in fact had a few phone calls to me about it), but I started to see arguments that "SRV is not a good choice as we can not deploy SRV". If that is an ar…

Fair enough. I read them as "we cannot deploy DNS-in-JavaScript".

--Paul Hoffman