Subject: RE: same protocol, different ports

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 19 Oct 2001 09:32:00 -0700

I think folk are porbably unerestimating the extent to which corporate
firewalls have closed down the scope for establishing new ports. In most
organizations the security officer running the firewall has no incentive to
allow new protocols to be supported and a pretty big disincentive.

What people are trying to do by attaching their barnacles to DNS is to
bypass the problem of building critical mass by leveraging an exisiting
network. Such people will have no interest in any procedure that denies them
ready made critical mass.

Port numbers have the additional disadvantage that the IESG have to exercise
some prudence to avoid falling victim to port number exhaustion. There may
well have to be a cull of little used protocols on well known ports in any
case. But the IESG have been very negative to using duplicate ports for the
same protocol.

There are several types of barnacle being attached to DNS

1) Internationalization.
	Support for international character sets in the DNS system is an
obvious and useful improvement.

2) Attempts to provide security to DNS
	This should not be regarded as scope creep, it should be considered
to be correcting a serious flaw in the original DNS protocol. 

3) Attempts to add in additional information
	These should all be directed towards appropriate use of the existing
SRV record, including those that involve certificates. It is not a good idea
to attempt to merege application certificates with DNS. The administrative
responsibilities of DNS are different to those of any appication PKI.

	I can't see why 1 or 2 should justify a new port. Type 3 barnicles
are almost certain to involve changes to DNS that would be much better
managed using another protocol, either an existing one (LDAP, CNRP) or
something new that will probably end up running over port 80.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 1:57 PM
> To: Michael Mealling
> Cc: [email-masked]
> Subject: Re: same protocol, different ports
> 
> 
> At 10:30 AM 10/18/2001, Michael Mealling wrote:
> > > given that it would be new applications (given that we 
> are talking about
> > > new uses of the DNS) then having to make that small a 
> change to an API
> > > seems... a small matter.
> >
> >It depends on how you deploy it. Do you setup a whole new set of root
> >nameservers on another port or do you use the existing port 53
> >delegation process and then only switch ports when you get to the
> >'last' nameserver?
> 
> This is a really excellent point for discussion, as would be 
> others about 
> making the idea practical.
> 
> First reaction, to the specific point you raise:  Using the 
> same namespace 
> lookup sequence -- ie, only making the leaf query be on a 
> different port -- 
> ensures that the namespace administration -- and operation -- 
> is consistent 
> and shared.
> 
> 
> >I've looked at just about every single DNS client side implementation
> >and for about 80% of the machines on today's internet it would be
> >a hard thing to deploy. I'm not saying its a show stopper, just that
> >if you do decide you want to do it you should make it clear to
> >client developers how they should deal with it.
> 
> My simplistic view is that having the DNS client module 
> switch ports based 
> on the RR being sought would be sufficient.  And there is 
> nothing wrong 
> with having the responding "value-add DNS" server continue 
> the friendly 
> pattern of including additional, related-but-unrequested RRs, 
> including 
> relevant ones from the core DNS.
> 
> d/
> 
> ----------
> Dave Crocker  <mailto:[email-masked]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Oct 2001 16:09:16 -0400

>3) Attempts to add in additional information

I'm trying hard to understand the rationale behind the desire to limit the
scope of data held in DNS.  These are the following reasons I can come up
with:

1) New data types engender more lookups and hence heavier load on the root
servers.  Regardless of the lookup, in a situation without cached data, the
root will be asked first.  The use of the srv record to fend off some kinds
of data won't reduce the load on the root servers (or others on the way
down the tree) becuase whether I am looking for the data (eg FOO) or a
reference to the data (SRV), I still hit the root first.

2) New data types might require additional processing of the name server.
E.g., when I ask for data with the DNSSEC OK bit on, the new SIG records
are added to the answer (if available).  This is an example of special
processing.  (This issue is also germain to the handling of
unknown-to-the-server types.)  If a new type does not require any
additional processing, how is one of it more or less harmful than one of
the traditional types?

3) New data may expand the scope of DNS beyond what its core protocol was
defined to support.  After spending many hours blindly poking at the
elephant that is DNS, my take on DNS is that it is a simple lookup service.
Meaning that directory searching, fuzzy matches, etc. are beyond the scope.
So what is the damage of putting a FOO record at a domain name instead of
an A record?  The core of the protocol doesn't seem to care what the value
of the type is, nor the internal wire format of the RDATA.

4) New data types deplete the type number's 16-bit space.  This I can
understand, but how quickly are we chewing through this space?  Perhaps I
am underestimating the concern here.  (Wouldn't IPv6 solve this?  Just
kidding folks.)

What technical reason am I missing?  What of the above am I misinterpreting?
What would be the big problem if I wanted to suggest a BRAND RR, which
stored a base64 encoding of the UTF-8 version of the computer's retailer?
(Kinda like a screwed up version of HINFO.)

Signed, confounded in Glenwood...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Oct 2001 14:11:41 -0700

> scope of data held in DNS.

It's perfectly appropriate to be upset. I thought of it in a slightly
different way--like a space that we were exploring and, in the early days,
we figured out this consistent path through the space: IP, TCP, and so
on. What's been happening over the last few years is that the IETF is
filling the rest of the space with every alternative approach, not
necessarily any better. Every possible alternative is now being written
down. And it's not useful.  -- Jon Postel

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 19 Oct 2001 14:24:10 -0700

> responsibilities of DNS are different to those of any appication PKI.

i'm not in full agreement here.  dns as a carrier for certain forms of PKI
could work very well IF DNS WAS SECURE.  for example i'd be very happy if
i could put my uuencode/base64/whatever PGP public key into a TXT RR at
paul.vix.com (assuming a '@' -> '.' mapping similar to that in SOA ANAME or
in an RP RR).  imagine if PGP didn't have to make an http or ftp connection
to retrieve my key!  i guess what i mean is, there's more than one kind of
PKI and it would be unwise to characterize DNS as unsuitable for all PKI
when in fact at least one known kind of key would fit into DNS just fine.

on the more general topic of adding random gibberish to DNS, i seem to recall
a recommendation by mike schwartz maybe 10 years ago when he was doing harvest
which would "tag" TXT RR's.  assuming that RFC6565 were the document that
specified an encoding, i'd expect to see

	$ORIGIN vix.com.
	paul		IN TXT	RFC6565 PGP KEY 2.6.2 (
	  "mQCNAzAK1x4AAAEEANkrzStNGbzzqskxspacnGdfxmxbhxrXl+pnGte5wGM8l70m"
	  "jqSExbbgsqSEPDuXvv/ClYmQBleCgvI3XTLo1yAIgSzL9MVtGKuOICV90/JYlt2Z"
	  "vtSturqKzEqcCaMWZPqyOkfpXRv6hYUTh0YTTeZ2G+e5651dQ3cdkq6JcsfBAAUR"
	  "tBlQYXVsIFZpeGllIDxwYXVsQHZpeC5jb20+"
	  "=2A+R" )

note the disturbing but intentional absense of outer quote (") marks.  TXT
has a segmented RDATA, so if you don't surround the whole RDATA in quotes
in the master file, BIND (at least; one assumes that other implementations
also do it this way) will preserve the field boundaries in the wire format.

also note that the word PGP in this example would be reserved with IANA when
this particular TXT encoding was RFC'd, and such RFC would specify (in this
example) that the next word was the version number the key required, and the
rest of the words ("TXT RDATA segments") were the key itself, in ascii armor
format.

this wouldn't work well with large values.  even assuming that TCP was used,
there's a limit of ~64K per RDATA.  but it should have been used in lieu of
"rwhois" and maybe LDAP as well.  new transports need better justification
than "adding new RR types to the DNS is too difficult."

of course, i am not volunteering to write RFC6565 (the container protocol in
the above example.)  "let's you and him fight."

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 20 Oct 2001 00:34:33 +0200

Paul A Vixie <[email-masked]> writes:

> i'm not in full agreement here.  dns as a carrier for certain forms
> of PKI could work very well IF DNS WAS SECURE. for example i'd be
> very happy if i could put my uuencode/base64/whatever PGP public key
> into a TXT RR at paul.vix.com (assuming a '@' -> '.' mapping similar
> to that in SOA ANAME or in an RP RR).  imagine if PGP didn't have to
> make an http or ftp connection to retrieve my key!

You can do that now.  It doesn't require secure DNS.  My mail client
locates S/MIME certificates this way.

(As for _trusting_ the PGP or S/MIME key located this way, you need a
separate trust chain.  Secure DNS and trust of a certain DNSSEC key
isn't a replacement for that and will never be, unless you're trying
to make DNSSEC a full-blown PKI which it wasn't designed for and is
far from able to support, at least as the standards are written
today.)

> i guess what i mean is, there's more than one kind of PKI and it
> would be unwise to characterize DNS as unsuitable for all PKI when
> in fact at least one known kind of key would fit into DNS just fine.

I couldn't agree more!

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 19 Oct 2001 18:28:51 -0500

> From: "Edward Lewis" <[email-masked]>

> I'm trying hard to understand the rationale behind the desire to limit
> the scope of data held in DNS.

I didn't see the comment as an effort at limiting DNS so much as I saw it as a
question about the suitability of DNS as an extensible platform in the first
place. There are many many well-known reasons supporting that position
(assuming that was the statement made).

Personally I'd like to hear more about the base effort. The subject says "same
protocol" but so far it seems to be a new protocol that reuses the DNS message
and namespace, which doesn't really make a lot of sense, so that is probably
wrong. If there really is a new protocol, there's no reason whatsoever to use
DNS for anything other than SRV pointers to the new protocol space. The
existing delegation tree is the most important (and the only
future-functional) architectural aspect of DNS.

---

From: Derek Atkins <[email-masked]>
Date: 22 Oct 2001 10:28:46 -0400

> when in fact at least one known kind of key would fit into DNS just fine.

Actually, Paul, you don't need a secure DNS to be able to store PGP
(or X.509) Keys (Certs).  The reason: PGP certs are self-verifying.
The PGP client obtains the key from an "untrusted" source and then
verifies the key against other known keys.  You don't necessarily need
DNS Security for this operation.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Derek Atkins <[email-masked]>
Date: 22 Oct 2001 10:25:00 -0400

> reference to the data (SRV), I still hit the root first.

The key point here is "without cached data".  You are right that most
likely the FIRST lookup will not be cached, but subsequent lookups
will.  So for example the SRV request may require going through the
root servers, but then you'll already have the NS/A records cached for
that zone.  Then the A record lookups for the servers in question, and
subsequent CERT/APPKEY lookups, will NOT need to hose the root server
at all.

> additional processing, how is one of it more or less harmful than one of

This is perhaps "special processing", but from a security point of
view this is negligible.  Adding TSIG is certainly going to be more
cpu intensive than just returning a SIG record.  And performing
on-the-fly SIG-generation would be even more cpu intensive.

In my mind, a branch to decide whether to include an extra RRset is
truly negligible.

-derek

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 22 Oct 2001 18:22:23 +0200 (MEST)

> DNS Security for this operation.

you might however do want to put more trust in a PKIX certificate
retrieved from dns if it was verified using dnssec. Leif Johansson and I
have described this in an upcoming draft that will be submitted later this
week, preliminary abstract below:

    A major problem facing PKIX deployment and implementation is the
    problem of constructing certificate paths for input to the path
    validation algorithm. This draft describes the use of the DNS and
    DNSSEC as a certificate store and it's implication for path
    validation in PKIX.

	jakob

---

From: Derek Atkins <[email-masked]>
Date: 22 Oct 2001 12:40:56 -0400

> week, preliminary abstract below:

This is true of PGP and other certificates as well.  The more lines of
validation, the better.  If you have the PGP Web of Trust (or X.509
Cert Chain) as well as a DNSSec SIG over the object, there is a higher
level of trust possible.

OTOH, do _you_ trust your DNS administrator to put your key up for
you?  How about if you're a CableModem/DSL subscriber?  What about if
you have a dynamic address?  There are LOTS of issues with putting
user/application keys into the DNS.  Not that I'm saying it should
be done -- I think there are a lot of GOOD reasons for putting app
keys into DNS.  I just think that we as a group should be aware of
the ramifications.

-derek

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Oct 2001 10:09:34 -0700

At 04:28 PM 10/19/2001, Eric A. Hall wrote:
>and namespace

same protocol = the packet formats are the same and the rules for 
exchanging them are the same.

The suggested differences were:

1.  Permit long-term divergence of the protocol, IFF necessary.  At the 
moment, I do not see the need for making any changes to the base protocol, 
but it is important to permit the divergence if a requirement later emerges.

2.  Permit support of additional RRs, for uses outside of core Internet 
name/address mapping.  Adding RRs does not change the protocol.

3.  A different port, for the additional RRs, so that administration and 
lookup traffic are independent of the core Internet name/address mapping.

Hence, the primary focus is on administrative independence, rather than 
technical independence.  As stated in the original note, messing with 
infrastructure services is dangerous.  All of these value-added uses of the 
DNS protocol are serious, interesting, and probably useful.

However there is nothing about them that requires them to share the 
Internet's core mapping service.  Quite the opposite.  Separating the 
administration and operation of these additional services is likely to make 
their adoption much easier.

d/

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 23 Oct 2001 23:52:16 -0500

From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 22, 2001 12:09 PM

> >Personally I'd like to hear more about the base effort. The subject
> >says "same protocol" but so far it seems to be a new protocol that
> >reuses the DNS message and namespace

I still don't understand what you're trying to achieve with this but I will
give some generic responses. I've been working on a personal draft that
discusses some of these issues which you may or may not find useful (see
http://www.ehsco.com/misc/draft-hall-dns-data-00.txt, completion pending the
acquisition of performance related data).

> 1.  Permit long-term divergence of the protocol, IFF necessary.  At the >
moment, I do not see the need for making any changes to the base
> protocol,  but it is important to permit the divergence if a
> requirement later emerges.

DNS is a message, a protocol, and a namespace. The unarguably crippled
component is the message (no version field, fixed length predefined fields,
maximum message-sizing constraints with UDP and TCP, etc.). Reusing the
message for anything is suicidal. By the time you fixed the problems with the
message (at the least adding a version field so that you CAN make changes
later), you would not have anything like what you started with. You would be
better off starting from scratch.

The protocol has lots of minor problems (fixed timers for example), but no
major limitations apart from those inherited by message restrictions (EG lack
of per-user authentication due to issues with the message structure), unless
you also consider some of DNS' features as problems (transparent caching =
lack of cache management). Mimicing the protocol makes sense if you're
interested in replicating the lookup-centric, cache-laden, unauthenticated
functionality. These are compelling features for a lot of uses, but they are
also preventative for a lot of uses (storing and reading logged-in users, for
example). Introducing features like authenticated cache management controls
are not simple modifications to the DNS protocol as it exists today.

The namespace only has one fundamental problem apart from the message, which
is that delegation and authority are represented by a common NS RR (if they
had used separate RRs, cache pollution would not have been as much of a
problem). But if you're designing a spanking-new protocol, then defining a
separate namespace would also make sense, at least so that you could define a
robust delegation mechanism from the beginning (to the extent that your
protocol may or may not provide service-specific delegation). Also, having to
manage data from an external service is not a new dimension to zone operation
that's particularly desirable. EG, how would this (potentially weird-looking)
data affect zone transfers?

>From your note, you are talking about a new message and namespace, and
probably a new protocol. If you're doing all this work, why not start from
scratch and do it cleanly?

--
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/