Subject: draft-jennings-http-srv-00

From: Cyrus Daboo <[email-masked]>
Date: Mon, 07 Jul 2008 09:50:53 -0400

Hi,
Just saw this posted: 
<http://www.ietf.org/internet-drafts/draft-jennings-http-srv-00.txt>. I am 
in the process of defining SRV record lookups for CalDAV and CardDAV as 
well.

The HTTP SRV draft proposes both an 'http' and an 'https' service type. 
However, comments here: <http://www.dns-sd.org/ServiceTypes.html> for the 
https service suggest that 'https' should not be used.

What do people think? Should there be a separate 'https' SRV service type? 
If so, then should I define both 'caldav'/'caldavs' and 
'carddav'/'carddavs', or instead just rely on the http redirect approach 
with a single service type? Or perhaps, 'caldav' and 'carddav' should be 
specified in terms of the http service, e.g. 'caldav.http' and 
'caldav.https'.

Also, why isn't there an IANA registry of SRV service types? The port 
numbers registry is not sufficient.

-- 
Cyrus Daboo

_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Lars Eggert <[email-masked]>
Date: Mon, 7 Jul 2008 17:24:28 +0300

On 2008-7-7, at 16:50, ext Cyrus Daboo wrote:
> Also, why isn't there an IANA registry of SRV service types? The  
> port numbers registry is not sufficient.

FYI, some transport folks have started to bring the documented IANA  
ports guidelines in line with reality. (Watch for draft-ietf-tsvwg- 
iana-ports-00 later today.)

Part of that effort is to finally move the SRV registry over to IANA,  
but that hasn't happened yet. But it's on the to-do list.

Lars

---

From: Peter Koch <[email-masked]>
Date: Mon, 7 Jul 2008 16:41:50 +0200

> >port numbers registry is not sufficient.

we've had this topic in DNSOP more than once when it came to review of
documents trying to make use of SRV.  There is no registry and RFC 2782
has the Applicability Statement for a reason.  Ironically, during the
processing of RFC 2782 the use of http as an example was carefully avoided.

> but that hasn't happened yet. But it's on the to-do list.

There are a couple of DNS caveats, including, but not limited to, "backwards
compatibility" issues especially in those cases where SRV is retroactively
introduced for existing services.  I'm looking forward to the draft you
mentioned.

-Peter

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Jul 2008 08:08:27 -0700

> > Part of that effort is to finally move the SRV registry 
> > over to IANA, but that hasn't happened yet.  But it's on 
> > the to-do list.
> 
> There are a couple of DNS caveats, including, but not limited 
> to, "backwards compatibility" issues especially in those cases 
> where SRV is retroactively introduced for existing services. 

Like when MX was introduced.  HTTP, at least, would be easier,
as an HTTP redirect can point 'legacy' clients towards the 
correct resource.  Such redirection was not possible with SMTP.

Safari has experience with SRV queries; we should ask Stuart
Cheshire (who is now on the IAB) to share their experiences.

-d

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 07 Jul 2008 11:13:32 -0400

Hi Dan,

> Cheshire (who is now on the IAB) to share their experiences.

Take a look at the http and https definitions at 
<http://www.dns-sd.org/ServiceTypes.html> which I think is fairly 
representative of what is going on. But these discussions should definitely 
involve Stuart too.

-- 
Cyrus Daboo

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Jul 2008 18:40:47 -0700

thanks - I did not realize how caldav was doing this.

On Jul 7, 2008, at 6:50 AM, Cyrus Daboo wrote:

> Hi,
> Just saw this posted: <http://www.ietf.org/internet-drafts/draft-jennings-http-srv-00.txt 
> >. I am in the process of defining SRV record lookups for CalDAV and  
> CardDAV as well.
>
> The HTTP SRV draft proposes both an 'http' and an 'https' service  
> type. However, comments here: <http://www.dns-sd.org/ 
> ServiceTypes.html> for the https service suggest that 'https' should  
> not be used.

Hmm - I don't see how the security would work on the redirect  
approach. If one started wanting a HTTPS connection to foo.com, found  
a _http SRV for foo.com, connected to it, then got a redirect to  
bar.com,  then when you do a TLS to bar.com, does the cert need to  
match foo.com or bar.com.

Anyways, the redirect seem unnecessary, I sort of lean to do it the  
same way SIP does but agree we need to sort this out and do it a  
common way.

>
>
> What do people think? Should there be a separate 'https' SRV service  
> type? If so, then should I define both 'caldav'/'caldavs' and  
> 'carddav'/'carddavs', or instead just rely on the http redirect  
> approach with a single service type? Or perhaps, 'caldav' and  
> 'carddav' should be specified in terms of the http service, e.g.  
> 'caldav.http' and 'caldav.https'.
>
> Also, why isn't there an IANA registry of SRV service types?
yep, I agree, I tried to work on this a long time ago and the pain  
threshold was too high but I think some folks might be slowly getting  
to it.

> The port numbers registry is not sufficient.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Jul 2008 09:47:55 -0600

Cullen Jennings wrote:
>> <http://www.ietf.org/internet-drafts/draft-jennings-http-srv-00.txt>. 
>> I am in the process of defining SRV record lookups for CalDAV and 
>> CardDAV as well.
>>
>> type. However, comments here: 
>> <http://www.dns-sd.org/ServiceTypes.html> for the https service 
>> suggest that 'https' should not be used.
> 
> Hmm - I don't see how the security would work on the redirect approach. 
> If one started wanting a HTTPS connection to foo.com, found a _http SRV 
> for foo.com, connected to it, then got a redirect to bar.com,  then when 
> you do a TLS to bar.com, does the cert need to match foo.com or bar.com.

Would RFC 4985 help here?

Peter

---

From: Stefanos Harhalakis <[email-masked]>
Date: Thu, 10 Jul 2008 22:17:45 +0300

(Excuse me for the bad reply that will destroy threading but I've just 
subscribed to this list and I don't have the original message to reply to. If 
you don't see any problem ignore this comment).

> ServiceTypes.html> for the https service suggest that 'https' should

I've though this a bit and couldn't find any security flaw. I believe that 
there is no difference (regarding security) between A or CNAME records and 
SRV records.

AFAICS https security will not be degraded. In fact, using a redirect method 
is a more serious security issue since forcing users to type 
http://www.mybank.org/ makes it easier to redirect them to 
https://www.notyourbank.com/ using a Mitm attack. The key point here is that 
users will be partially *forced* to initially type http instead of https (and 
probably bookmark this). This may also be true for any links that point to 
that site.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss