Subject: Re: [Enum] On the question of DNSSEC and recommended

From: David Conrad <[email-masked]>
Date: Fri, 31 Jan 2003 21:33:27 -0800

Lawrence,

On Friday, January 31, 2003, at 04:35  PM, Conroy, Lawrence (SMTP) 
wrote:
>   So...If I understand the comments so far, the aim is to
> require all resolvers (and I assume thus *all* ENUM Clients)

No.  DNSSEC (in this context) only applies to recursive resolvers (that 
is, caching servers).  ENUM clients are typically stub resolvers which 
send queries to recursive servers and wait for responses.  The ENUM 
clients should use TSIG and verify the AD bit is on in the response 
from the recursive server.

Rgds,
-drc

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

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 1 Feb 2003 14:31:36 +0000

At 9:33 pm -0800 31/1/03, David Conrad wrote:
>Lawrence,
>
>On Friday, January 31, 2003, at 04:35  PM, Conroy, Lawrence (SMTP) wrote:
>No.  DNSSEC (in this context) only applies to recursive resolvers 
>(that is, caching servers).  ENUM clients are typically stub 
>resolvers which send queries to recursive servers and wait for 
>responses.  The ENUM clients should use TSIG and verify the AD bit 
>is on in the response from the recursive server.
>
>Rgds,
>-drc
>
Hi David, folks,
   OK, so to re-phrase...
ENUM Clients will use an external recursive resolver & use TSIG
in their queries and in processing responses, or support DNSSEC
with EDNS if they "go direct" (i.e. they do not go via an external
Recursive Resolver). Simple resolvers are just not possible in this
world.

It seem to this outsider that there's pain for all, so that
some who want to check security can. Unless I misunderstand
completely, I feel that this will need a deal more justification
for "non-DNS" folk than has been done so far - this needs to be sold!

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Sat, 01 Feb 2003 09:19:31 -0800

>>>>> "David" == David Conrad <[email-masked]> writes:

    David> No.  DNSSEC (in this context) only applies to recursive
    David> resolvers (that is, caching servers).  ENUM clients are
    David> typically stub resolvers which send queries to recursive
    David> servers and wait for responses.  
    David> The ENUM clients should use TSIG and verify the AD bit is
    David> on in the response from the recursive server.

Perhaps the draft should say something about securing the path between
the ENUM client and its resolving name server? I think there will be
circumstances when TSIG with AD won't work because the client and
resolver won't have established a trust relationship. For instance a
roving user on a wireless LAN (at say IETF). The client could end up
using the LAN's DNS server for resolution without knowing its TSIG key
(if it has one).
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Sat, 01 Feb 2003 09:36:57 -0800

>>>>> "Lawrence" == Conroy, Lawrence (SMTP) <[email-masked]> writes:

    Lawrence> Hi David, folks, OK, so to re-phrase...  ENUM Clients
    Lawrence> will use an external recursive resolver & use TSIG in
    Lawrence> their queries and in processing responses, or support
    Lawrence> DNSSEC with EDNS if they "go direct" (i.e. they do not
    Lawrence> go via an external Recursive Resolver). Simple resolvers
    Lawrence> are just not possible in this world.

Simple resolvers -- for some definition of simple -- should be OK.
They will probably have to do EDNS0 anyway. It's likely that there
will be a bunch of NAPTR records for a given phone number and these
will be too big to fit into the old-style 512 byte DNS payloads. What
has to be ensured is that simple ENUM resolvers don't die or get
indigestion if an answer contains DNSSEC signatures. BTW, IDN and IPv6
stuff is likely to mean even more bloated DNS answers too.

    Lawrence> It seem to this outsider that there's pain for all, so
    Lawrence> that some who want to check security can. Unless I
    Lawrence> misunderstand completely, I feel that this will need a
    Lawrence> deal more justification for "non-DNS" folk than has been
    Lawrence> done so far - this needs to be sold!

It shouldn't need to be sold. Without DNSSEC and/or TSIG, answers from
name servers can't be trusted. What more incentive is there than that
for enduring the pain of DNSSEC? The alternative of not validating DNS
answers and having to deal with spoofing attacks, cache poisoning,
number hi-jacking, impersonation, and so on will be far more painful.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: David Conrad <[email-masked]>
Date: Sat, 1 Feb 2003 10:01:55 -0800

Lawrence,

On Saturday, February 1, 2003, at 06:31  AM, Conroy, Lawrence (SMTP) 
wrote:
> in their queries and in processing responses,

As Jim notes, there are situations in where TSIG may not be 
appropriate.  If you trust the network you are on (e.g., you are 
running a full caching server on your machine and are communicating to 
it via localhost) or you have established trust in some other way 
(e.g., IPSEC) you don't need TSIG.

> or support DNSSEC

As described above, a simple resolver is possible assuming the trust 
model is understood.

> for "non-DNS" folk than has been done so far - this needs to be sold!

Just to be clear, the point of all this DNSSEC goop is because the DNS 
as defined is an insecure protocol.  The assumption is that people 
generally want to connect to the party whose number they've dialed 
instead of a party who has spoofed the DNS response to point a 
telephone number to (say) a $10/minute 1-900 number (or whatever).

With regards to pain, there will be administrative overhead at the tier 
1 level due to the need to sign the zones and deal with key rollover.  
 From the perspective of the end user, there won't be that much pain as 
all that would be required is to establish a trust relationship with a 
caching server.  From the perspective of ISPs, nothing changes (as long 
as they are running caching servers that validate DNSSEC responses).  
 From the perspective of ENUM application writers, there is as much pain 
as you want to inflict upon yourselves (i.e., if you want to push 
establishment of trust onto somebody else, all you need to is verify 
the AD bit in the response.  Alternatively, you can implement a full 
validating caching resolver if you _really_ like pain.  The decision as 
to which way to go will probably end up being driven by customer 
demand).

Rgds,
-drc

---

From: Peter Koch <[email-masked]>
Date: Sat, 01 Feb 2003 18:57:03 +0100

> name servers can't be trusted. What more incentive is there than that

Agreed, but wouldn't this suggest to extend the DNSSEC recommendation beyond
the e164.arpa tree to also ensure authenticity and integrity of the targets
of those NAPTR RRs? If not, where to draw the line?

-Peter