Subject: Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

From: Cullen Jennings <[email-masked]>
Date: Mon, 21 Jun 2010 12:10:46 -0600

It seems like using NAPTR might be a better choice than the ./well-known with redirect. 

On Jun 18, 2010, at 9:51 AM, The IESG wrote:

> The IESG has received a request from an individual submitter to consider 
> the following document:
> 
> - 'Use of SRV records for locating CalDAV and CardDAV services '
>   <draft-daboo-srv-caldav-05.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-07-16. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-daboo-srv-caldav-05.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18589&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 22 Jun 2010 08:54:22 +0200

All,

I have together with Olaf Kolkman suggested a new RR type that I call URI that work similarly to what is described in this draft (regarding the owner of the RRSET), but a URI in the RDATA. It has been posted to the namedroppers list a few times...but maybe that has been wrong. Maybe Apps Area should have been notified about the work a bit more...

Cyrus has asked a few questions about it, and maybe it is me that have not reached out to the Caldav people enough? I have tried to push it through via the DNS people in the IETF, but there have not been enough traction.

Anyway...

I can do that via an individual submission if there is interest. I think the draft is ready for publication.

See http://tools.ietf.org/html/draft-faltstrom-uri-04 (i.e. the draft has expired a few months ago).

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Priority             |          Weight               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                             Target                            /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this case (to take an example from the draft in question), it would be for example:

Instead of:

_caldav._tcp     SRV 0 1 80 calendar.example.com.

Followed by doing PROPFIND for

http://calendar.example.com/.well-known/caldav

...etc...

With a potential redirect etc...

It could with the URI resource record for example be:

_caldav._caldav    IN URI 10 1 "http://www.example.com/example/whatever/uri/caldav/"

or

_carddav._caldav    IN URI 10 1 "http://www.example.com/foo/some/other/uri/carddav/"

And the URI is used directly for the PROPFIND.

   Patrik

On 21 jun 2010, at 20.10, Cullen Jennings wrote:

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Jun 2010 07:15:38 -0700

>I have together with Olaf Kolkman suggested a new RR type that I call URI that work similarly to what is described in this draft (regarding the owner of the RRSET), but a URI in the RDATA. It has be…

Patrik and Olaf's proposal has some big advantages over two-step SRV searching. To implementers, there will be just one API for many services; now that "web browsers" are the universal application, this could be a big win. It is also only one DNS lookup instead of a DNS request followed by a HTTP PROPFIND. It should be seriously considered (and they should get a new draft out...) instead of a hodgepodge of scheme-specific methods.

--Paul Hoffman, Director
--VPN Consortium

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 22 Jun 2010 16:22:43 +0200

On 22 jun 2010, at 16.15, Paul Hoffman wrote:

> It should be seriously considered (and they should get a new draft out...) instead of a hodgepodge of scheme-specific methods.

Consider a new draft posted tomorrow (it is already close to evening here in Sweden, and my cats are screaming after food).

   Patrik

---

From: SM <[email-masked]>
Date: Tue, 22 Jun 2010 12:55:47 -0700

>final comments on this action.  Please send substantive comments to the

What is the "XXXX-CardDAV" tag for in "Updates"?

In Section 5:

    "The client will need to make authenticated HTTP requests to the
     service.  Typically a "user identifier" is required for some form
     of user/password authentication."

Is that the userinfo from RFC 3986?  Is the user prompted for the password?

In Section 5:

   "An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp
    (for CardDAV) is done with the user provided "domain" as the
    service domain."

The IANA request (Section 8.3) only mentions adding "caldav" and 
"caldavs" service labels as aliases for "http" and "https" respectively.

Regards,
-sm

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jun 2010 21:10:11 +0100

>> final comments on this action.  Please send substantive comments to the
Hi SM,

> What is the "XXXX-CardDAV" tag for in "Updates"?

This is the same as [I-D.ietf-vcarddav-carddav].

> Is that the userinfo from RFC 3986?

Yes.

> Is the user prompted for the password?
>
> In Section 5:
>

carddavs and carddav are already registered in [I-D.ietf-vcarddav-carddav].

---

From: SM <[email-masked]>
Date: Tue, 22 Jun 2010 13:30:55 -0700

Hi Alexey,
>carddavs and carddav are already registered in [I-D.ietf-vcarddav-carddav].

Section 11 of draft-ietf-vcarddav-carddav-10 mentions that the 
specification adds two service types for use with SRV records, i.e. 
carddav and carddavs.  That's not mentioned under IANA Considerations 
(Section 14).

Regards,
-sm

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jun 2010 21:33:18 +0100

> carddav and carddavs.  That's not mentioned under IANA Considerations 

That was done as an RFC Editor note.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 23 Jun 2010 06:59:25 +0800

> has expired a few months ago).

It seems that Section 7 has an old example in it.  Did you previously use NAPTR with a "D" flag?

For security considerations, I have one to add.  RFC 3958 (S-NAPTR) has this nasty little authentication hitch, that you should really consider in this draft.  The reference identifier (see draft-saintandre-tls-server-id-check) that you are required to use for authenticating the host is the one that is input to the resolution process...not the product of the process.

Basically, if you search for _http._web.example.net and get "http://www.example.com/ ", then you are expected to authenticate against _http._web.example.net (or maybe example.net, I'm not sure - NAPTR doesn't use the '_' prefix).

I'm happy to expand on the problems that I faced with this little security tangle.  The problem doesn't end there.

Cheers,
Martin

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jun 2010 16:04:43 +0200

> It seems that Section 7 has an old example in it.  Did you previously use NAPTR with a "D" flag?

Actually, no. If you do know what protocol you look for, you can use the URI RR directly. The idea with the NAPTR and the "D" flag was that it would list what URI records exists in the zone.

Let me expand a bit also including the caldav example:

$ORIGIN example.com.

     IN NAPTR 200 10 "D" "EM:protA"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

     IN NAPTR 200 10 "D" "caldav:caldav"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

     IN NAPTR 200 10 "D" "caldav:carddav"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

_protA._EM IN URI "prota://somehost.example.com/"

_carddav._caldav IN URI "http://somehost.example.com/whateveruri"

_caldav._caldav IN URI "http://somehost.example.com/someotheruri"

I.e. if you know you want the carddav/caldav URI, you just look up the {IN,URI,_carddav._caldav.example.com} RRSET, if you want to know the services example.com has, you look up {IN,NAPTR,example.com} and then with flag "D" you see what you can find using lookup of URI RR.

So, the NAPTR and flag "D" is not really needed for the resolution. It is a "list the services" feature.

But, I will remove that part because it is not really a piece of the URI definition.

> Basically, if you search for _http._web.example.net and get "http://www.example.com/ ", then you are expected to authenticate against _http._web.example.net (or maybe example.net, I'm not sure - NA…

I thought you should authenticate against example.net?

I.e. you want "caldav"/"caldav" for "example.com" and get back "http://www.calendarserverfoobar.com/caldav/example.com/caldav" (for a PROPFIND), what is the best to require for authentication? example.com or www.calendarserverfoobar.com? I presume example.com (the domain name used _before_ the URI lookup happens.

   Patrik

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 23 Jun 2010 10:33:03 -0400

>> For security considerations, I have one to add.  RFC 3958 (S-NAPTR)  
>> has this nasty little authentication hitch, that you should really  
>> consider in this draft.  The reference identifier (see draft- 
>> saintandre-tls-server-id-check) that you are required to use for  
>> authenticating the host is the one that is input to the resolution  
>> process...not the product of the process.
>>
>> Basically, if you search for _http._web.example.net and get "http://www.example.com/ 
>>  ", then you are expected to authenticate against _http._web.example.net 
>>  (or maybe example.net, I'm not sure - NAPTR doesn't use the '_'  
>> prefix).
>
> I.e. you want "caldav"/"caldav" for "example.com" and get back "http://www.calendarserverfoobar.com/caldav/example.com/caldav 
> " (for a PROPFIND), what is the best to require for authentication?  
> example.com or www.calendarserverfoobar.com? I presume example.com  
> (the domain name used _before_ the URI lookup happens.

In principle, example.com is the proper domain to authenticate, but in  
practice, that causes a lot of problems.  Consider the case where the  
target of the redirection is a separate entity from the origin; this  
could arise, for example, in a situation where example.com has  
outsourced its calendaring services to calendardserverfoobar.com.   
Then requiring the target domain to authenticate as the origin (i.e.,  
as example.com) means that you're enabling the outsourced calendaring  
provider to authenticate as their customer, which requires them to  
keep different keys for each customer and present different certs on  
different connections (which may or may not be feasible depending on  
how customer resources are distributed in the provider infrastructure)  
-- and invites the risk of abuse.

On top of that, there's the implementation issue that a lot of  
libraries (for HTTP, but others as well) don't let you authenticate  
any identifier than the domain name in the URI.

One flavor of this problem is being worked in XMPP now.  They're  
creating Domain Name Assertions so that the origin domain can create a  
signed object attesting to the delegation and the target domain can  
authenticate as itself.
<http://tools.ietf.org/html/draft-ietf-xmpp-dna-00>

But it's clearly a more general problem.  Stpeter and I are planning  
to organize a bar BoF about it in Maastricht, but in the spirit of  
having more ad-hoc bar BoFs, we haven't done any concrete planning.

--Richard

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jun 2010 20:52:45 +0200

On 23 jun 2010, at 16.33, Richard L. Barnes wrote:

> In principle, example.com is the proper domain to authenticate, but in practice, that causes a lot of problems.  Consider the case where the target of the redirection is a separate entity from the origin; this could arise, for example, in a situation whereexample.com has outsourced its calendaring services to calendardserverfoobar.com.

So, the "connect the dots" is to:

- Announce the fact example.com is hosted at calendarserverfoobar.com (with some URL) in DNS

- Secure that announcement in DNS with DNSSEC

- Verify the SSL (for example) cert for the connection to calendarserverfoobar.com matches

- Do application layer authentication etc over the then encrypted connection

Sounds ok?

   Patrik

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 23 Jun 2010 15:01:38 -0400

Basically, yeah, as long as you have DNSSEC.  In fact, if you've got  
DNSSEC, you don't really even need the application-specific bit at the  
end.  The goal of the XMPP DNA work (and other analogous things) is to  
work around not having DNSSEC in the mean time.  In that solution, the  
parallel path is:

- Announce the fact that example.com is hosted at  
clendarserverfoobar.com in DNS

- Connect to calendarserverfoobar.com over TLS and check that the name  
in the cert is indeed calendarfoobar.com

- Obtain an attribute cert for calendarfoobar.com signed by example.com

- Valid signature and certificate for example.com implies that  
delegation is OK

The third of these steps of course require some application-specific  
magic.

--Richard

On Jun 23, 2010, at 2:52 PM, Patrik Fältström wrote:

>> In principle, example.com is the proper domain to authenticate, but  
>> in practice, that causes a lot of problems.  Consider the case  
>> where the target of the redirection is a separate entity from the  
>> origin; this could arise, for example, in a situation  
>> whereexample.com has outsourced its calendaring services to  
>> calendardserverfoobar.com.
>
> - Announce the fact example.com is hosted at  
> calendarserverfoobar.com (with some URL) in DNS
>

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 23 Jun 2010 15:09:32 -0400

Hi Patrik,

--On June 23, 2010 8:52:45 PM +0200 Patrik Fältström <[email-masked]> 
wrote:

>> could arise, for example, in a situation whereexample.com has outsourced
>> its calendaring services to calendardserverfoobar.com.
>

So the srv-caldav (and srv-email) drafts reference Section 3 of 
draft-saintandre-tls-server-id-check which describes how clients can go 
about verifying a server identity when using TLS under various 
circumstances, including an initial discovery via SRV records.

> - Do application layer authentication etc over the then encrypted

Well the key here is DNSSEC of course!

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 23 Jun 2010 15:20:40 -0400

Hi Patrik,

--On June 22, 2010 8:54:22 AM +0200 Patrik Fältström <[email-masked]> 
wrote:

> I have together with Olaf Kolkman suggested a new RR type that I call URI
> that work similarly to what is described in this draft (regarding the
> owner of the RRSET), but a URI in the RDATA. It has been posted to the
> namedroppers list a few times...but maybe that has been wrong. Maybe Apps
> Area should have been notified about the work a bit more...
>
> Cyrus has asked a few questions about it, and maybe it is me that have
> not reached out to the Caldav people enough? I have tried to push it
> through via the DNS people in the IETF, but there have not been enough
> traction.

I did chat with a few server implementors about this and the feeling was 
SRV + .well-known is a good solution that can quickly be deployed. Some 
points:

1) SRV's are very deployable today - a new RR will be harder to deploy.

2) There is a push to support SRV's with other protocols (e.g. 
draft-daboo-srv-email for IMAP, POP3, and Submission) so from an 
operational standpoint its likely to be more common.

3) .well-known is useful in the absence of any DNS records. i.e. if no 
SRV/URI were available, a client can still try auto-discovery by attempting 
an HTTP connection to the host (derived from user input) and the 
.well-known path.

-- 
Cyrus Daboo

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jun 2010 22:07:44 +0200

On 23 jun 2010, at 21.20, Cyrus Daboo wrote:

> I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points:
> 
> 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common.
> 
> 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path.

Hmm...regarding the new RR, the only thing I can think of today is the need for some changes in the provisioning system from which one create the DNS zones. I do not know of any DNS code today that can not handle "unknown" DNS RR Types, but maybe I am wrong? I am though confused over (1) as this is 2010 and not 1998.

Regarding (3), I think it is sad people move redirects and lookups and functionality to be on top of HTTP instead of IP. And I do not understand "in the absence of DNS"...that is an interesting situation ;-) Specifically to use that as the foundation for the architecture to use for calendaring, that is -- I hope -- one of the more fundamental applications on the Internet.

A new version of my draft I promised today, but due to this security consideration discussion, it is now delayed yet another day.

And yes, I will do the job of releasing a new version although there will continue to not be any interest of using it. :-)

Or maybe I should just push it through, although for calendaring draft-daboo-srv-caldav will be used. Hmm... I do not want to be problematic here.

   Patrik

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 23 Jun 2010 17:05:49 -0400

Hi Patrik,

--On June 23, 2010 10:07:44 PM +0200 Patrik Fältström <[email-masked]> 
wrote:

>> SRV/URI were available, a client can still try auto-discovery by
>> attempting an HTTP connection to the host (derived from user input) and
>> the .well-known path.
>
> Hmm...regarding the new RR, the only thing I can think of today is the
> need for some changes in the provisioning system from which one create
> the DNS zones. I do not know of any DNS code today that can not handle
> "unknown" DNS RR Types, but maybe I am wrong? I am though confused over
> (1) as this is 2010 and not 1998.

I am thinking more of client APIs.

> Regarding (3), I think it is sad people move redirects and lookups and
> functionality to be on top of HTTP instead of IP. And I do not understand
> "in the absence of DNS"...that is an interesting situation ;-)
> Specifically to use that as the foundation for the architecture to use
> for calendaring, that is -- I hope -- one of the more fundamental
> applications on the Internet.

Sorry - bad wording on my part. What I meant was "in the absence of a 
service-type to hostname mapping in the DNS".

-- 
Cyrus Daboo

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Jun 2010 15:17:05 -0700

>3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user i…

This sounds weird to me. The tradeoff is using two different protocols (DNS and HTTP) versus one (DNS). For schemes that are not being run over HTTP, that means that the client needs to add an HTTP client stack just to find the right server. Is this really a good idea?

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Thu, 24 Jun 2010 03:00:57 +0200 (MEST)

> Well the key here is DNSSEC of course!

Absolutely.  Without DNSSEC verification by the client,
there is zero security when DNS SRV records are used to
determine the hostname of the server.

It took many many years from the DNSSEC spec to
the creation of secure DNS zones in the DNS root.

It'll take at least 5 years before the average client will be
able to receive and verify DNSSEC records through the ubiquituous
middle-boxes that seperate most PCs from the internet.

Is this about a spec with a "to be opened/used not before 2015" label?

-Martin

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 24 Jun 2010 07:47:40 +0200

> I am thinking more of client APIs.

Sure, but, support for unknown RR Types is said to be needed since long time back. And what API do not handle the ability to request an RR with a specific RRTYPE?

int res_query(const char *dname, int class, int type, u_char *answer, int anslen);

Anyway...this discussion has been held in the IETF I do not know how many times. Instead of writing another 10 lines of code (or whatever is needed) people fall back to existing RR Types, and not only that, define future protocols because of lack of #define for new RRTYPES.

I know people have different views here, and I have one specific view ;-)

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Jun 2010 08:59:18 -0700

>I know people have different views here, and I have one specific view ;-)

As someone who normally has that "different view", I support a new RRTYPE in this case because the option of reusing SRV is not sufficient: it requires DNS-SRV-followed-by-HTTP. I think a new RRTYPE that keeps the DNS lookup entirely in the DNS protocol far outweighs reusing SRV but requiring HTTP on both sides.

--Paul Hoffman, Director
--VPN Consortium

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 24 Jun 2010 18:07:25 +0200

The new draft is now posted:

> A new version of I-D, draft-faltstrom-uri-05.txt has been successfully submitted by Patrik Faltstrom and posted to the IETF repository.
> 
> Filename:	 draft-faltstrom-uri
> Revision:	 05
> Title:		 The Uniform Resource Identifier (URI) DNS Resource Record
> Creation_date:	 2010-06-24
> WG ID:		 Independent Submission
> Number_of_pages: 12
> 
> Abstract:
> This document defines a new DNS resource record, called the Uniform
> Resource Identifier (URI) RR, for publishing mappings from hostnames
> to URIs.

   Patrik

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 24 Jun 2010 12:24:02 -0400

Hi Paul,

--On June 24, 2010 8:59:18 AM -0700 Paul Hoffman <[email-masked]> 
wrote:

> As someone who normally has that "different view", I support a new RRTYPE
> in this case because the option of reusing SRV is not sufficient: it
> requires DNS-SRV-followed-by-HTTP. I think a new RRTYPE that keeps the
> DNS lookup entirely in the DNS protocol far outweighs reusing SRV but
> requiring HTTP on both sides.

"in this case" as in the draft under discussion? If so, I don't don't 
understand your position. The protocols/services being referenced by the 
draft are HTTP protocols, so it is always going to be SRV-followed-by-HTTP. 
What is more, simply getting a generic host/path is not sufficient for 
client configuration - additional steps are required to find the principal 
resource of the user for whom the client is setting up an "account" (as 
described in the draft).

-- 
Cyrus Daboo

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 24 Jun 2010 18:32:48 +0200

On 24 jun 2010, at 18.24, Cyrus Daboo wrote:

> --On June 24, 2010 8:59:18 AM -0700 Paul Hoffman <[email-masked]> wrote:
> 
> "in this case" as in the draft under discussion? If so, I don't don't understand your position. The protocols/services being referenced by the draft are HTTP protocols, so it is always going to be SRV-followed-by-HTTP. What is more, simply getting a generic host/path is not sufficient for client configuration - additional steps are required to find the principal resource of the user for whom the client is setting up an "account" (as described in the draft).

The only real differences are, I think (correct me here if I am wrong Cyrus):

draft-daboo-srv-caldav uses SRV + an http transaction towards a "well known path", followed by the normal caldav HTTP transactions.

draft-faltstrom-uri uses the new RR Type URI (that give the path, that does not have to be the same all over the place), followed by the normal caldav HTTP transactions.

Personally, I think first of all the URI RR can be useful for many things (else I would not have written the draft in the first place) and will push this to an RFC status. Secondly, what I "do not like" in the draft-daboo-srv-caldav is that you need an explicit well known path that one tag onto the URI. Virtual hosting (given normal http hosts) might be "interesting"...but of course, someone will hack an .htaccess together that give the right redirect given the HOST header... But I think that is "uglier" (note the quotes) than a new RR Type. YMMV...

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Jun 2010 09:33:10 -0700

>"in this case" as in the draft under discussion? If so, I don't don't understand your position. The protocols/services being referenced by the draft are HTTP protocols, so it is always going to be S…

Sorry, I wasn't clear. My "in this case" was "how does the IETF want to handle the case of getting a resource from the DNS", not the CalDAV/CardDAV case. It may be fine that the CalDAV/CardDAV API include HTTP, but I would hope that the IETF could settle on one DNS-specific method that all apps could use.

--Paul Hoffman, Director
--VPN Consortium

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 24 Jun 2010 14:26:33 -0400

Hi Patrik,

--On June 24, 2010 6:32:48 PM +0200 Patrik Fältström <[email-masked]> 
wrote:

>> draft are HTTP protocols, so it is always going to be
>> SRV-followed-by-HTTP. What is more, simply getting a generic host/path
>> is not sufficient for client configuration - additional steps are
>> required to find the principal resource of the user for whom the client
>> is setting up an "account" (as described in the draft).
>
> draft-daboo-srv-caldav uses SRV + an http transaction towards a "well
> known path", followed by the normal caldav HTTP transactions.

Well, I think .well-know/caldav should be "normal" for CalDAV irrespective 
of whether SRV or URI is setup. That still provides major advantages to 
clients and server admins.

> draft-faltstrom-uri uses the new RR Type URI (that give the path, that
> does not have to be the same all over the place), followed by the normal
> caldav HTTP transactions.
>
> Personally, I think first of all the URI RR can be useful for many things
> (else I would not have written the draft in the first place) and will
> push this to an RFC status.

I can certainly see where it would be useful. However, I question your 
comments in Section 9 of your draft: specifically that URI should be viewed 
as a replacement for SRV. URI (may) make sense for "resource" discovery, 
but I don't believe that is true for "service" discovery - I think SRV 
still makes the best sense for that.

-- 
Cyrus Daboo

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 24 Jun 2010 21:47:31 +0200

On 24 jun 2010, at 20.26, Cyrus Daboo wrote:

> I can certainly see where it would be useful. However, I question your comments in Section 9 of your draft: specifically that URI should be viewed as a replacement for SRV. URI (may) make sense for "resource" discovery, but I don't believe that is true for "service" discovery - I think SRV still makes the best sense for that

[not in context of the caldav draft...]

Hmm...you might be correct here. For example in the case of a URI RR that refer to a mailto URI that in turn (theoretically) should use SRV to know what port and hostname to use for the destination of the SMTP connection?

So a URI might in some cases in turn result in the need for an SRV lookup?

Is that your point?

   Patrik

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 13:49:06 -0600

On 6/24/10 1:47 PM, Patrik Fältström wrote:
>> I can certainly see where it would be useful. However, I question
>> your comments in Section 9 of your draft: specifically that URI
>> should be viewed as a replacement for SRV. URI (may) make sense for
>> "resource" discovery, but I don't believe that is true for
>> "service" discovery - I think SRV still makes the best sense for
>> that
> 
> 
> Hmm...you might be correct here. For example in the case of a URI RR
> that refer to a mailto URI that in turn (theoretically) should use
> SRV to know what port and hostname to use for the destination of the
> SMTP connection?
> 

That's often the case for xmpp URIs.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 24 Jun 2010 21:58:45 +0200

> That's often the case for xmpp URIs.

Point taken.

New draft will be produced.

   Patrik

---

From: Ray Bellis <[email-masked]>
Date: Fri, 25 Jun 2010 07:53:49 +0000

> I can certainly see where it would be useful. However, I question your comments in Section 9 of your draft: specifically that URI should be viewed as a replacement for SRV. URI (may) make sense for "resource" discovery, but I don't believe that is true for "service" discovery - I think SRV still makes the best sense for that.

IMHO, that depends on the service.

In RAI we have "LoST" and "HELD", both of which are HTTP(s) based services contacted through a URI.

A "URI" RR-based solution for discovery of those would, I think, have been cleaner than the current U-NAPTR based methods.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jun 2010 18:24:37 -0400

I strongly disagree with the use of NAPTR. It has a ridiculous amount of
power and mechanism. SRV is well supported in servers, NAPTR is not.

The process of standards making is to eliminate unnecessary flexibility. In
this case the configuration of the caldav Web host is not relevant to the
client. Therefore those details should not be exposed to the client. This is
a security issue but also an encapsulation issue.

Exposing unnecessary details to clients is an invitation to engage in the
equivalent of undocumented API calls. I do not want to expose that
information to clients because I do not want them to start relying on it.

Rather, I suggest that we generalize the process and adopt the convention
that the URL be formed from the SRV prefix. That is we have one registry for
prefixes and apply them to SRV and URI formation.

I would also suggest adding in a version number so that it is possible to
run two versions of the protocol using different back ends.

Since we are using SRV we will have two DNS names involved

1) The DNS name of the protocol
2) The DNS name of the host on which the service is provided

The DNS name of the host need not be the only DNS name that the host
responds to. Ergo, there is no actual need to use the .wellknown hack in
this particular case. We can insist that the DNS name be reserved for
forwarding web services.

As for the need for 'redirect' this should not affect the protocol on the
wire. Rather the Web server should perform any internal mapping.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jun 2010 19:15:37 -0400

[Sorry, got Cullens' out of thread, did not realize there was more debate
since, replying to a number of different posters here]

I really do not like the idea of a new RR unless it can be shown that SRV is
not sufficient.

There are still issues deploying new RRs. Windows DNS does not provide an
administrator interface for new RRs. Plugging them into BIND is not exactly
simple either. At root DNS remains a binary protocol and that means that no
DNS server is going to have decent support for unknown RRs until it gets an
update.

The mere ability to dynamic update a new RR into a server is not the same
thing as being able to use that RR in a production environment. You have to
be able to update the RR using the same tools you use for the rest of the
zone.

What really worries me is that there are people who are busy inventing new
discovery mechanisms for Internet protocols via HTTP who are completely
ignoring the existing DNS infrastructure.

For example, why does OpenID not just use [email-masked] as the identifier
for a user and SRV to discover the authentication server that can give an
answer for that domain? It would be job done five years ago.

At the moment OpenID has a discovery mechanism via HTTP and a proprietary
lookup scheme via XRI that isn't proprietary really because the people who
control the rights tell us they trust themselves.

A proposal for a new RR in that debate is the last thing we need. It
suggests that the IETF does not understand how to do service discovery and
opens up the field for XRI.

For caldav over HTTP, SRV works fine.

For finding the right protocol amongst a number of options (e.g. finding the
right authentication protocol from Kerberos, SAML, OpenID, KitchenSink,
etc.) we need something additional. I can see that a new RR could add value
there if it provided a list of protocols on offer, protocol options, version
numbers etc.

In other words a Service DESCRIPTION record.

I think that that would be a very valuable thing for the IETF to work on.
The functionality I need is not considered in NAPTR.

As for the interaction with DNSSEC, I think it is double ended. At the
moment DNSSEC has no particular function. If we only implement what is
described to date there is nothing that DNSSEC can do that is not already
done better by the existing infrastructure of SSL and CA issued Domain
Validated X.509 certs.

Now consider what would happen if we added the ability to use the DNS to
distribute statements of the form 'this SMTP server always offers STARTTLS",
"This Caldev server always offers SSL"

Suddenly DNSSEC not only has a point, it has a point that cannot be
supported using any other infrastructure.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Jun 2010 09:17:37 -0400

Has anyone talked to anyone in the applications world about this?

The use of a new DNS Resource Record creates far more problems than any of
these proposed discovery mechanisms offer. No matter how much the DNSEXT
people want to believe that adding DNS records is not an issue, the fact is
that it is.

SRV is a well established record. It is already widely used for service
discovery. This new proposal does not offer any real functionality. All it
allows is for the service administrator to choose a random string to insert
into every one of their service URLs. The random string chosen has no
semantic significance whatsoever, has no security benefit and the only
constraint on it is that it should be unique for each service.

Back in the earliest days of the web, the first web server was info.cern.ch.
After a short while www.example.com became the standard naming to the point
where it is now embedded in many browsers that if a search for a domain
fails, add www. to the name and try again.

Whether you like that approach or not, the fact is that the administrative
constraint of a web server being expected to be at www has not proved
onerous. If we pick out one way to do the management of web services via SRV
lookup the software world will quickly adapt to it. The transition from the
SRV way of doing things to the new way of doing things can be easily managed
through server side URI mapping. There is no need for HTTP redirects of any
on-the-wire protocol impact.

What we are missing here is a better way to find the protocol properties.
That is something that should be done through a DNS record rather than an
HTTP lookup. If the protocol properties are discovered through HTTP lookup
then we have already made the decision to use HTTP and we can't use DNSSEC
to advertise that SSL is always available to avoid a downgrade attack.

On Fri, Jun 25, 2010 at 3:53 AM, Ray Bellis <[email-masked]>wrote:

> as a replacement for SRV. URI (may) make sense for "resource" discovery, but
> I don't believe that is true for "service" discovery - I think SRV still
> makes the best sense for that.
>
>
> A "URI" RR-based solution for discovery of those would, I think, have been
> cleaner than the current U-NAPTR based methods.
>
> Ray
>
> --

---

From: Martin Rex <[email-masked]>
Date: Sat, 26 Jun 2010 07:39:57 +0200 (MEST)

> ignoring the existing DNS infrastructure.

Well, I'm worried about the security nightmare that is going to
happen when two different technologies from the IETF that are based
on mutually exclusive assumptions are combined into solutions for
the marketplace.

In the security area, the focus in recent years has been on making
pervasive use of hostname-based server endpoint identification.
However, this scheme is based on the flawed assumption that users
provide these hostnames strictly in a trusted fashion.  In the
Web, however, most https-URLs that user access, originate from
html-pages that were received insecurely through http and
invisble to users, rather than being conciously typed by
users or being bookmarked https urls.

In the apps area I'm seeing proposals to provide and use service
location discovery on a global scale.  While it might be possible
(one day) to perform the lookup itself in a secure fashion,
e.g. through DNSSEC, the hard problem is that a desire to
resolve an abstract service into arbitrary hostnames is mutually
exclusive with the concept of "user provides trusted hostname"
for hostname-based server endpoint identification.

Personally, I think that a scheme of service location discovery
has merit, even one that is untrusted and insecure.  And I've
been considering hostname-based authentication a fatally flawed
idea from the day I got to know them in Kerberos in 1995.

In theory, one could get entirely rid of hostnames in the authenticated
identities of services with a trusted and secure directory service,
that translates a user-provided trusted(!) abstract service name
into a 3-tuple of ip-address, service-port and security identity
(I think DCE could do this) ... but there is the problem that trust
scales at best to a small number of closely related organizations,
and never beyond.

The current practice with TLS in WebBrowsers is definitely not
about trust -- it is about _faith_.  Faith in each and every of
the ~40 Gods around the world that managed to get their
"trust anchor certificates" preconfigured in the TLS-enabled
products of you software supplier.  To top it off, there appear
to be Gods that disclaim liability for completely unverified stuff
in the certificates they sign in something called a
"Certificate Practice Statement" (CPS).  So it is faith, because
most consumers of the technology do not know and neither care
who those Gods are and what they do or disclaim -- there is
only the underlying hope and belief, that whoever it is and
whatever they do, that it is well-intended.

I guess it is inevitable that whenever humans try to expand
trust beyond the boundaries of their monkeysphere, they will
make compromises that effectively substitute an original
model of trust with a concept of faith.

> done better by the existing infrastructure of SSL and CA issued Domain

DNSSEC provides exactly what is described in the last sentence of the
introduction of rfc-4033:

   The DNS security extensions provide origin authentication and
   integrity protection for DNS data, as well as a means of public key
   distribution.  These extensions do not provide confidentiality.

DNSSEC provides this from the start and in full.  But there is never
going to be anything else that DNSSEC will be able to provide.
In particular, DNSSEC is never going to be able to provide "trust",
not now, and not in the future.

-Martin