Re: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)

[Edward Lewis <[e-mail]>]

At 7:31 PM -0500 3/7/97, Karen R. Sollins wrote:
>Third, I am still unhappy the treatment of security, both for myself and
...
>DNSSEC will address them has been studied.  I do not think that NAPTR needs
>to be extremely ruggedized with respect to security, but I do think that as

I've been involved in DNSSEC, so when I see it mentioned in a thread, I
wake up and read the document for DNS-type things.

First minor things - on line 598 "DNS_CHAR" is defined.  It is never used,
so I don't know for certain what it is supposed to mean (so maybe it should
be deleted).  If it is the legal, non-escaped chars in DNS, then underscore
("_") should not be there, instead a hypen ("-") should be included as well
as upper case characters.

In the paragrapgh following, "...URI shall be a legal domain name" should
be either:

"...URI MUST be a legal domain name"

or better yet:

"...URI MUST be a legal domain name and SHOULD BE a legal host name"

or perhaps:

"...URI MUST be a legal domain name and MUST BE a legal host name"
                                        ^^^^

There is some confusion over legal domain names and host names, and the
reference to 1123 does not make things clearer.  draft-ietf-dnsind-
clarify-0?.txt is the latest best way to define the binary form of domain
names.  All of the drafts I have seen on defining the ascii/zone-file form
of a domain name have expired.  I haven't followed legal host names as
closely, but I think RFC 1123 is probably the best reference for that.

The distinction is this: a domain name can have non-printable bytes in it
which is legal.  In the zone file, the non-printable bytes must conform to
a specific escape syntax ("\<char>" or "\<three-digits>").  A legal domain
name might not be a legal host name.  (There are length limits for domain
names.)

About the security (the reason I clipped the above mail message),
specifically related to DNSSEC:

DNSSEC will (in a nutshell) let you trust that the NAPTR record received is
what the owner submitted, i.e., no one has substituted a fake record.  (Of
course, DNSSEC will not prevent either bad or malicious data from being
entered, it will just make the insertion of
malicious-data-that-successfully-causes-bad-things harder.)  DNSSEC will
also provide a mechanism for retrieving public keys - if you need that sort
of thing.

DNSSEC does not address denial of service attacks against name servers.

I'm not saying "trust me, DNSSEC will take care of all DNS security issues"
but you probably shouldn't dwell on them too much in the NAPTR document.
(As it is now, IMHO document is fine on security.)  I don't see a security
concern in the document, perhaps you do want to consider security within
the resolver.  I admit to have not read other URN documents...but I'd
venture to say you may want to include a digital signature to authenticate
a URN processed response.  (DNSSEC only helps get you to the URN resolver,
we don't help the URN resolver's security.)  But such a topic is outside
the scope of the NAPTR document.

PS -

One question - has IANA approved the number 35 for NAPTR?  It's not on
their web page (ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters)
yet.  (The page is rather old - dated January 14.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                      Trusted Information Systems
Phone: [phone]               Email: [e-mail]