Subject: AW: [Enum] Re: Public Keys in ENUM

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jun 2002 11:02:16 +0200

Hi folks,
nice to see, that some work is done overnight (at least from a European point of view) and not everybody is watching soccer only ;-)
What bothers me a bit is that everytime I ask a question, I do not get an answer, but either 10 more questions are raised or I get the hint, that the issues are treated already somewhere else and I should look there ;-)

I think we have again the two or three camps here:

Camp A is the minimalistic camp, saying that you finally need only one pointer in ENUM DNS to a service resolution services (srs) and this service is doing the rest. Can it be that this is also the sip camp?

Camp B in the middle (Patrik) is saying, you do not want to put all eggs in a basket and you should use ENUM DNS to POINT to other services, thats what ENUM and DNS is intented for.

Camp C is saying that I already have a service subscribed (ENUM) and have to pay for it, so I do not want to subscribe another service (e.g. a public key storage services) for things I can do in DNS as well. Jim and David, can it be that this is the DNS service providers camp also?

Some additional comments:

1. If it can be done technically, it will be done. And having finally a common global repository for a PKI will drive the usage of public keys AND ENUM, to the benefit of both.

2. What about UDP package lenght with storing keys in DNS? This could be a problem. But on the other side, if I look at the current requirements for ENUM done by the national groups, everybody seems to insist on using DNSSEC for ENUM. If  I understood Jims presentation  in Geneva correctly, if you use DNSSEC you increase the data in DNS four times at least, so you blow UDP out of the water anyway. Is this correct?

best regards

Richard Stastny

PS to Patrik: Danmark vs Sweden in the final, Danmark world champion?

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Robert H. Walter" <[email-masked]>
Date: Thu, 13 Jun 2002 10:54:19 -0400

Richard,

> 2. What about UDP package lenght with storing keys in DNS? This could be a 
> problem. But on the other side, if I look at the current requirements for 
> ENUM done by the national groups, everybody seems to insist on using DNSSEC 
> for ENUM. If  I understood Jims presentation  in Geneva correctly, if you 
> use DNSSEC you increase the data in DNS four times at least, so you blow 
> UDP out of the water anyway. Is this correct?

RFC 1035 defines the UDP packet size to be 512 bytes.  RFC 2671 defines a
standard mechanism for extending the UDP packet size using the OPT record.
The basic idea is for a client to issue a DNS request containing an OPT
record that specifies the size of the UDP datagram that the server should
reply with...  Of course this only works with DNS clients and servers that
are OPT aware.  So, returning CERT records that are ~2048 bytes in size is
not really an issue.

Regards,

Bob Walter

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Jun 2002 09:26:00 -0700

Richard,

This isn't really related to ENUM.  I was commenting on the generic
statement 'putting keys in the DNS is a no no' which I disagree with for
various reasons that aren't really relevant here.  However...

On 6/13/02 2:02 AM, "Stastny Richard" <[email-masked]> wrote:
> Camp C is saying that I already have a service subscribed (ENUM) and have to
> pay for it, so I do not want to subscribe another service (e.g. a public key
> storage services) for things I can do in DNS as well. Jim and David, can it be
> that this is the DNS service providers camp also?

I have no idea what DNS service providers think on this (not even Nominum).
My view is that the DNS was originally designed (according to the guy who
sits 2 doors down from me) to support arbitrary key/value lookups of
relatively small amounts of relatively static data.  Looking up security
related keys in the DNS easily fits within the original design goals of the
DNS, thus attempting to outlaw the use of the DNS for this purpose has
always struck me as strange.

> 1. If it can be done technically, it will be done. And having finally a common
> global repository for a PKI will drive the usage of public keys AND ENUM, to
> the benefit of both.

I personally believe that one of the primary reasons PKI hasn't gained more
public acceptance is the insistence of the various security-related protocol
developers to attempt to handwave the key distribution problem away.  To
date, no globally scalable system for key distribution has been deployed.
However, if you look at the problem of scalable key distribution, you'll see
that many of the attributes of such a system replicate exactly what the DNS
does (caching, scalability, redundancy, reliability, resiliency, integrity
assurance, etc).  Since I'm lazy by nature, I prefer not to reinvent the
wheel.  Further, the DNS infrastructure is already deployed -- there are
millions of libraries out there that require no modification to enable
fetching of data out of the DNS.  Seems a waste not to make use of it.

> 2. What about UDP package lenght with storing keys in DNS?

EDNS0 was created to address this concern (among others).

Rgds,
-drc

---

From: Jim Reid <[email-masked]>
Date: Thu, 13 Jun 2002 13:05:51 -0700

>>>>> "Richard" == Stastny Richard <[email-masked]> writes:

    Richard> If I understood Jims presentation in
    Richard> Geneva correctly, if you use DNSSEC you increase the data
    Richard> in DNS four times at least, so you blow UDP out of the
    Richard> water anyway. Is this correct?

Zone files will increase by at least a factor of 4 (roughly) if they
are using RFC2535-style DNSSEC. Every resource record (RR) will get a
SIG record. Each RR -- actually each RRset -- will also get a NXT
record and that NXT record also gets a SIG record. The actual
multiplier will probably be more than 4 even though there are 4 times
as many resource records in the signed zone. SIG records are not
small.

Signed answers typically exceed the 512 byte payload limit for a
standard UDP DNS response because of the crypto gunk they have to
include. This should not be an issue. EDNS0 allows for bigger DNS
datagrams and most (all?) DNSSEC-aware servers and resolvers support
this.