Subject: Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th

From: Patrik Fältström <[email-masked]>
Date: Mon, 11 Oct 2010 15:00:50 +0200

I am working on an update to this document given the comments on the mailing list.

For this issue, IRI, I have think the best thing is to allow one of:

- A URI
- An IRI but only using UTF-8 charset, and that the IRI is such that it can be converted to a URI and back again.

A new version that reflects this change will be released shortly.

   Patrik

On 26 jul 2010, at 02.43, Phillip Hallam-Baker wrote:

> Use the same RR for both.
> 
> As far as the infrastructure is concerned there is absolutely no
> difference. DNS does not need to know the semantics of the bits being
> shipped.
> 
> IRIs are going to have to fit into slots where URLs are used. In most
> cases the application will not know which is being used.
> 
> The justification for IRIs is that they are friendlier for human use.
> This is another technology meant to make things easier for human use.
> There is really no reason that the target should be another human
> friendly format. But there is no particular harm either. Provided that
> the target is something that the app can just use as a blind chunk of
> bits.
> 
> 
> 2010/7/25 Masataka Ohta <[email-masked]>:
>> Klaus Malorny wrote:
>> 
>>> dumb question: I don't consider myself an expert in that respect, but
>>> wouldn't it make more sense nowadays to use UTF-8 encoded IRIs (RFC
>>> 3987) instead of URIs? Or is there a need to keep everything ASCII-safe?
>> 
>> UTF-8 is causing a lot of problems, some of which was predicted
>> but some are new, with CJK unification and will never be stable.
>> 
>> Patrik;
>> 
>>> But I take on the task to check with the IRI people really fast,
>> 
>> They are the wrong people to ask, because only the positive
>> answers are expected.
>> 
>>                                                Masataka Ohta
>> 
>> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 11 Oct 2010 15:03:15 +0200

On 26 jul 2010, at 07.35, Florian Weimer wrote:

> * Frederico A. C. Neves:
> 
>>     The wire format of the RDATA is as follows:
>> 
>> 
>>                         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                            /
>>    /                                                               /
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Would it make sense to include an "insert original domain here"
> placeholder in the target part?  This would help with aliasing.

For this issue, to have some rewrite rules for the URI, I pushed back slightly on the mailing list, and I interpret your response to that (Florian) as if you agree it is dangerous.

My take is, given noone else ask for this, that such rewrite should not happen.

Because of this, I will not include any change because of this comment in the upcoming release.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 11 Oct 2010 15:41:02 +0200

On 27 jul 2010, at 20.48, Ted Hardie wrote:

> At the moment, the draft

> describes a mechanism that
> relies on two associated things:  a composed service name and an RR with format:
> 
> Ownername TTL Class URI Priority Weight Target
> 
> One composed service name example you give is
> 
> $ORIGIN example.com.
>   _http._web    IN URI 10 1 "http://www.example.com/"
> 
> That is, someone looks up _http._web.example.com and discovers
> this URI there.  The first issue is the one draft notes, that you
> must know in advance to check for this in order to populate
> the fields correctly.

Correct.

> For your "two domains, one homepage"
> example, the querier must know in advance, in other words,
> to check for the _http._web.example.net in order to
> discover that there is another domain.  That's not going
> to happen as an adjunct for standard web queries without
> a lot of other work, so it really relies on some application
> that wants that bit of data (as opposed to just wanting
> the home page).

That is correct. The use of the URI RR Type will only happen in new protocols, or new use. I do not think it will be used for existing protocols, like HTTP, or other protocols where you have inbound "redirect" functionality.

> It's okay that it is only useful to applications that
> already know they want it, but, unfortunately,
> it's also not really enough.  _http._web is a very general
> service name, and there is no way with that level of
> granularity to know whether the URI you're getting
> is meant to be an equivalent, an alternate, or to
> stand in some other relationship (e.g. hold meta data).

Correct, and that is why the actual service type registrations must be more precise. What I have in the draft (draft-faltstrom-uri-05) is the following:

>    Valid service
>    parameters used are those used for SRV resource records, or
>    registered by IANA for Enumservice Registrations.

What you say, which I agree with, is that "just" use of some prefixes without having them defined is dangerous. And this is why I am leaning towards either the Enumservice Registrations (where you have this issue) or the SRV resource records that according to the SRV spec is requiring further specification in its applicability statement:

>    In general, it is expected that SRV records will be used by clients
>    for applications where the relevant protocol specification indicates
>    that clients should use the SRV record. Such specification MUST
>    define the symbolic name to be used in the Service field of the SRV
>    record as described below. It also MUST include security
>    considerations. Service SRV records SHOULD NOT be used in the absence
>    of such specification.

Now, I do not see as much of a problem as you do, as whoever that is using the URI know already what it is after. It can either (as today) use a URI directly for the communication, or start by using a hostname, look up a URI RR and get back the URI to use.

What I think you are after is in the case we have the following scenario:

1. The owner of a domain is publishing a URI RR for a specific service named foo, so the URI RR _foo._tcp.example. is provisioned.
2. The service name is overloaded, for not only what the owner of the name was thinking of, but also bar.
3. Someone that want to use the service bar, for the domain name example is also looking up _foo._tcp.example, get back the URI that was to be used for the foo service, and the application is at best "surprised".

Here "foo" can be for example "web surfing" while "bar" can be for example calendaring that also uses the HTTP protocol.

In this case, the service "bar" should use a specific scheme, for example _bar._tcp.example.

And we once again hit a problem I do not think is "my" fault, but rather that we do not have a proper registry for service types. As you can see already there in the SRV spec.

Yes, I was Area Director for apps area then, and did rise exactly this issue ;-)

> Each pairing of composed service name and URI
> has to have some semantic that tells you what the
> URI has to do with the related service name.

Agree, and my view is that that should be made in the service name (i.e. in the owner of the RR) and not anywhere in the resulting URI.

Note that the service in the owner is not an encoding of the uri scheme. It is really a service definition/name. Many different such names can result in a URI using the HTTP scheme.

> If I create a URI record at  _dns._udp.example.net
> with a target of dns:example.org.?clAsS=IN;tYpE=CNAME
> am I reporting the CNAMES which point to example.net?
> Or am I telling you that example.net is authoritative for
> the domain name that is the result of that query?
> The service name and URI pointer aren't really enough
> to know.

I do not know what the spec of the dns service type says. Does one exist? I know there is a dns URI scheme.

As you can see in RFC 4501 (from which I see you have grabbed this example ;-) ), the URI is for a resource record with the absolute name example.org, class IN and type CNAME. So a spec of the dns service must tell how to handle this case. I think your example is one where there must be subtypes. For example:

_cname._in._dns._udp.example.net. IN URI 10 10 "dns:example.org.?clAsS=IN;tYpE=CNAME"

> You touch on this in the draft by noting that the service
> name usage may be subtly different for each RR that uses,
> but I think the situation is far more complicated than that.
> URIs are inherently sub-typable (by scheme, query, etc.),
> and that means that the semantics here seem to me to
> need a much richer description capability than the draft
> assumes.

Hmm...I think a lot of work is needed for each service type.

> I'm not sure that this explanation is all that much better,
> so feel free to batter away at the results.

I think you talk about more how the registration and spec of each service type is done, and not this spec. But maybe you want more stuff in this document? I have added some text about it.

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Oct 2010 00:09:24 +0900

Patrik Faltstrom wrote:

> - An IRI but only using UTF-8 charset, and that the IRI is such that
> it can be converted to a URI and back again.

As long as you use DNS, only the domain name is visible to end users
and results of query is something like binary that there is no point
to introduce alien characters, editing of which is impossible in
internationalized context.

For example, you can't input my name in my local Kanji characters,
just as most Japanese, including me, can't input your name with
ISO 8859/1 specific characters, which means it is a lot better
to handle % notations.

Note also that domain names in characters other than ASCII is
unrealistic as was exemplified with more than 1M variations of
a case insensitive label with 20 Greek characters.

						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 11 Oct 2010 18:03:28 +0200

> internationalized context.

The URI/IRI is in the RDATA part, and the new draft allows both IRI and URI, and furthermore require that the URI/IRI can be mapped to each other back and forth.

draft-faltstrom-uri-06.txt

Just posted.

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Oct 2010 05:49:23 +0900

Patrik wrote:

> The URI/IRI is in the RDATA part, and the new draft allows both
> IRI and URI, and furthermore require that the URI/IRI can be
> mapped to each other back and forth.

That's a meaningless statement as the conversion is not well
defined at all.

Here are excerpts from RFC3987 how LRIs do not work:

            a. If the IRI is written on paper, read aloud, or otherwise
               represented as a sequence of characters independent of
               any character encoding, represent the IRI as a sequence
               of characters from the UCS normalized according to
               Normalization Form C (NFC, [UTR15]).

As I said, you can do nothing on LRIs on a paper with Kanji.

   The ToASCII operation may fail, but this would mean that the IRI
   cannot be resolved.

and LRIs do not require that it can be resolved.

   Note: Internationalized Domain Names may be contained in parts of an
      IRI other than the ireg-name part.  It is the responsibility of
      scheme-specific implementations (if the Internationalized Domain
      Name is part of the scheme syntax) or of server-side
      implementations (if the Internationalized Domain Name is part of
      'iquery') to apply the necessary conversions at the appropriate
      point.

and the localization conversion is scheme OR server specific.

   However, the IRI resulting
   from this conversion may not be exactly the same as the original IRI
   (if there ever was one).

thus, it is not back and forth.

Please never bother us with broken localization attempts of Unicode.

						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 13 Oct 2010 04:54:39 +0200

On 12 okt 2010, at 21.30, Phillip Hallam-Baker wrote:

> For example it
> could tell the client that it can use SRV or NAPTR or URI for enhanced
> discovery.
> 
> example.com  ESRV "prefix=_http._tcp,_imap._tcp"
> _http._tcp.example.com ESRV "tls=required disc=srv"
> _http._tcp.example.com SRV 1 1 80 site1.example.com
> _http._tcp.example.com SRV 1 1 80 site2.example.com

For me this is what NAPTR does...

example.com. NAPTR 20 0 "s" "http" "" _http._tcp.frobbit.se.
example.com. NAPTR 20 0 "s" "imap" "" _imap._tcp.frobbit.se.
_http._tcp.example.com. SRV 1 1 80 site1.example.com.
_http._tcp.example.com. SRV 1 1 80 site2.example.com.

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Oct 2010 09:13:21 -0400

Unfortunately, NAPTR does not have the ability to specify security policy
information so the deployment incentives don't work the same.

SRV has existed for a decade now, yet we still cant get applications to
bother to check it for no-brainer applications such as imap.

If people care about security (an unproven hypothesis unfortunately) and are
thus willing to check a DNSSEC signature chain, then I have to hope that
they are willing to do an extra lookup to actually give that DNSSEC lookup a
point.

The biggest security hole in the Internet at the moment is the fact that
security is an optional afterthought. So sites have to rely on people
noticing the dorky padlock icon which means only that the communication was
encrypted.

DNSSEC deployment might not require an out of pocket cost, but that does not
mean that the cost of deployment is 'free'. Just the fact that DNSSEC means
that DNS deployment has to be done right means several hours extra work a
year and that translates into higher administration costs.

There has to be a compelling value provided by DNSSEC and merely defeating
the Kaminsky attack on its own isn't enough.

Provide protection against the downgrade attack however and suddenly you
have a very compelling value with an immediate value to the client that
cannot be realized any other way.

An e-commerce site does not need to be very large for the value of a
security policy record to be in the hundreds of dollars. For the major
phishing targets it is in the hundred of thousands or millions.

Making a case for better discovery techniques on their own is much harder
since the cost of bandwidth continues to fall and the application providers
have not seen a benefit to date.

Which is why I think that a flag in the security policy record that says
'hey there is also a better discovery mechanism' is more powerful as a
deployment strategy than a flag in the discovery record saying to use https.

2010/10/12 Patrik Fältström <[email-masked]>

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Wed, 13 Oct 2010 16:51:43 +0200

On 13 okt 2010, at 15:13, "Phillip Hallam-Baker" <[email-masked]> wrote:

> Unfortunately, NAPTR does not have the ability to specify security policy information so the deployment incentives don't work the same.

NAPTR only exists within a DDDS context, so that is up to your definition of the algorithm that uses the NAPTR.

So I do not understand the above. Please expand.

   Patrik

> SRV has existed for a decade now, yet we still cant get applications to bother to check it for no-brainer applications such as imap.
> 
> 
> If people care about security (an unproven hypothesis unfortunately) and are thus willing to check a DNSSEC signature chain, then I have to hope that they are willing to do an extra lookup to actually give that DNSSEC lookup a point.
> 
> The biggest security hole in the Internet at the moment is the fact that security is an optional afterthought. So sites have to rely on people noticing the dorky padlock icon which means only that the communication was encrypted.
> 
> 
> DNSSEC deployment might not require an out of pocket cost, but that does not mean that the cost of deployment is 'free'. Just the fact that DNSSEC means that DNS deployment has to be done right means several hours extra work a year and that translates into higher administration costs.
> 
> There has to be a compelling value provided by DNSSEC and merely defeating the Kaminsky attack on its own isn't enough.
> 
> Provide protection against the downgrade attack however and suddenly you have a very compelling value with an immediate value to the client that cannot be realized any other way.
> 
> 
> An e-commerce site does not need to be very large for the value of a security policy record to be in the hundreds of dollars. For the major phishing targets it is in the hundred of thousands or millions.
> 
> Making a case for better discovery techniques on their own is much harder since the cost of bandwidth continues to fall and the application providers have not seen a benefit to date.
> 
> 
> Which is why I think that a flag in the security policy record that says 'hey there is also a better discovery mechanism' is more powerful as a deployment strategy than a flag in the discovery record saying to use https.
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Oct 2010 15:30:41 -0400

Originally I was somewhat skeptical of URI. After all, if NAPTR, SRV and
such have failed, why would this succeed? And just as NAPTR makes the
discovery problem worse rather than better since it means that there are two
discovery mechanisms to choose from, URI looked like it would make things
worse.

Once I started to look at security policy publication, I realized that the
discovery signaling problem is solved almost for free.

So the starting point is the need to express policy of the form 'always use
TLS' in the DNS. Which is what I propose with ESRV:

_imap._tcp.example.com   ESRV "tls=required"
_http._tcp.example.com   ESRV "tls=required"

[From this starting point we could easily elaborate the scheme to require
specific trust roots for use of TLS or IPSEC or whatever. But that is
actually a somewhat subtle and involved problem I would like to defer for
now.]

Now due to the problem with CNAME, it is highly desirable that the
resolution process for ERSV (or any other policy record) is incremental and
starts at the unprefixed zone. So the first lookup would be for an ESRV
record for unprefixed example.com:

example.com  ESRV "tls=required match=_http._tcp, _imap._tcp"
www.example.com CNAME example.com

Which should deliver the relevant policy records in a single lookup for
either example.com or www. example.com.

What does become rather clear is that the original attempt to avoid the need
for an SRV registry by re-using the protocol names registry in a horrible
kludged fashion was a big mistake. I think we should seriously consider
starting the use of prefixes from scratch and abandon the tcp/udp layer.

Now once you have a lookup that is allowing security policy to be
distributed, it can be used to publish other information. For example it
could tell the client that it can use SRV or NAPTR or URI for enhanced
discovery.

I have an initial draft out, but I am still working on the details. The
practical significance of this is that it is not necessary for the use of
the URI scheme to be hardwired into the application protocol as Patrik
states.

I think that it is in fact practical to use a mechanism such as ESRV to
retrofit a new discovery mechanism to existing protocols.

One real concrete benefit of this is that we establish a space in which we
can develop rather more interesting discovery mechanisms that make use of
geographic location or account data to optimize discovery.

At the moment when I connect to gmail via POP3, I guess my client must be
connecting me to a tier 1 server whose only reason for existence is the need
to route my request to the place where the data is actually stored. Wouldn't
it be nice if we could possibly eliminate that tier at a future date? Think
of the carbon emissions we could save.

Sure there are performance issues to clear. But I think those can be
managed. The important thing here is to get the architecture right so that
applications have the right information to work with and get the most
efficient transport layer possible. We can work out how to save DNS round
trips as a lower priority.

2010/10/11 Patrik Fältström <[email-masked]>

> That is correct. The use of the URI RR Type will only happen in new
> protocols, or new use. I do not think it will be used for existing
> protocols, like HTTP, or other protocols where you have inbound "redirect"
> functionality.
>
> Correct, and that is why the actual service type registrations must be more
> precise. What I have in the draft (draft-faltstrom-uri-05) is the following:
>
> >    Valid service
> What you say, which I agree with, is that "just" use of some prefixes
> without having them defined is dangerous. And this is why I am leaning
> towards either the Enumservice Registrations (where you have this issue) or
> the SRV resource records that according to the SRV spec is requiring further
> specification in its applicability statement:
>
> Now, I do not see as much of a problem as you do, as whoever that is using
> the URI know already what it is after. It can either (as today) use a URI
> directly for the communication, or start by using a hostname, look up a URI
> RR and get back the URI to use.
>
> 1. The owner of a domain is publishing a URI RR for a specific service
> named foo, so the URI RR _foo._tcp.example. is provisioned.
> 3. Someone that want to use the service bar, for the domain name example is
> also looking up _foo._tcp.example, get back the URI that was to be used for
> the foo service, and the application is at best "surprised".
>
> Here "foo" can be for example "web surfing" while "bar" can be for example
> calendaring that also uses the HTTP protocol.
>
> And we once again hit a problem I do not think is "my" fault, but rather
> that we do not have a proper registry for service types. As you can see
> already there in the SRV spec.
>
> Agree, and my view is that that should be made in the service name (i.e. in
> the owner of the RR) and not anywhere in the resulting URI.
>
> Note that the service in the owner is not an encoding of the uri scheme. It
> is really a service definition/name. Many different such names can result in
> a URI using the HTTP scheme.
>
> As you can see in RFC 4501 (from which I see you have grabbed this example
> ;-) ), the URI is for a resource record with the absolute name example.org,
> class IN and type CNAME. So a spec of the dns service must tell how to
> handle this case. I think your example is one where there must be subtypes.
> For example:
>
> I think you talk about more how the registration and spec of each service
> type is done, and not this spec. But maybe you want more stuff in this
> document? I have added some text about it.
>
>   Patrik
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Oct 2010 14:00:03 -0400

DDDS is a feature that can only be realistically added to a specification at
the time that the protocol is first defined. It is the same problem with SRV
and pretty much every other expanded discovery mechanism.

The point I am making about security policy is that security policy is a
feature that we can realistically retro-fit to existing protocols. We have
already applied security policy to SMTP via DKIM. We can usefully apply
security policy in many other contexts.

Since the additional functionality NAPTR provides over SRV is very similar
to the functionality that can be usefully added to a security policy
mechanism, there is probably not a great deal of milage in having a security
policy record that contains a flag saying 'you can get there better using
NAPTR'. But there is certainly a lot of value in a flag that says 'you can
get there better using SRV or URI'.

The way I think this would be presented to an application programmer would
be a replacement for gethostbyname where the caller specifies a DNS name, a
DNS protocol prefix, a default port number (optional) and a minimum set of
security criteria (optional) and the routine then returns the best
connection possible to a host providing the service.

So in this model the application programmer's mental model would not change
very much from gethostbyname.

If we later define new discovery mechanisms they can be used by any client
that has the appropriate library support.

On Wed, Oct 13, 2010 at 10:51 AM, Patrik Faltstrom (pfaltstr) <
[email-masked]> wrote:

> If people care about security (an unproven hypothesis unfortunately) and
> are thus willing to check a DNSSEC signature chain, then I have to hope that
> DNSSEC deployment might not require an out of pocket cost, but that does
> not mean that the cost of deployment is 'free'. Just the fact that DNSSEC
> means that DNS deployment has to be done right means several hours extra
> work a year and that translates into higher administration costs.
>
> 2010/10/12 Patrik Fältström < <[email-masked]>[email-masked]>
>
>> > <http://example.com>example.com  ESRV "prefix=_http._tcp,_imap._tcp"
>> > _http._ <http://tcp.example.com>tcp.example.com ESRV "tls=required
>> disc=srv"
>> > _http._ <http://tcp.example.com>tcp.example.com SRV 1 1 80
>> <http://site1.example.com>site1.example.com
>> > _http._ <http://tcp.example.com>tcp.example.com SRV 1 1 80
>> <http://site2.example.com>site2.example.com
>>
>>  <http://example.com>example.com. NAPTR 20 0 "s" "http" "" _http._<http://tcp.frobbit.se>
>> tcp.frobbit.se.
>>  <http://example.com>example.com. NAPTR 20 0 "s" "imap" "" _imap._<http://tcp.frobbit.se>
>> tcp.frobbit.se.
>> _http._ <http://tcp.example.com>tcp.example.com. SRV 1 1 80
>> <http://site1.example.com>site1.example.com.
>> _http._ <http://tcp.example.com>tcp.example.com. SRV 1 1 80
>> <http://site2.example.com>site2.example.com.
>>
>>   Patrik
>>
>>
>
>
> --
> Website: <http://hallambaker.com/>http://hallambaker.com/
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Oct 2010 09:18:27 -0400

Reading the comments, i was seeing the claim made that this is limited to new protocols.

I think we can make all these enhanced discovery schemes more useful if we have a common means of advertising the availability of one or more upgrades in band. And this is better than tying a web service to just one enhanced discovery mechanism.

In other words, this is not a defect, it is the better way to do things. 

Sent from my iPad

On Oct 22, 2010, at 7:43 AM, Patrik Fältström <[email-masked]> wrote:

> 
> On 12 okt 2010, at 15.30, Phillip Hallam-Baker wrote:
> 
> Philip, I am not hardwiring any URI scheme. This is the key part of the application:
> 
>> The URI RR has service information encoded in its ownername.  In
>> order to encode the service for a specific owner name one uses
>> service parameters.  Valid service parameters used are either
>> Enumservice Registrations registered by IANA, or prefixes used
>> for the SRV resource record.
> 
> I.e. in the example in the draft, the http in the owner is not there due to the fact the string http is one of the URI schemes that one might get back when looking up _http._web, but because the http and web type/subtype says http is one of the uri schemes one might ge bad in the resolution step.
> 
>> $ORIGIN example.com.