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

From: "Stastny Richard" <[email-masked]>
Date: Thu, 6 Feb 2003 11:33:10 +0100

Hi folks,

sorry for getting on this thread so late, but I was a bit busy the
last week on real ENUM issues ;-)

I now had time to read through it and finally came to the same
conclusion as raised in
the last message: where to draw the line?

But first one comment to DNSSEC for ENUM and the requested change in
rfc2916bis:

I consider it to be too premature to put such a strong statement in
rfc2916bis
as requested by MM and Jim at this time, IMHO there is too many open
issues
yet with DNSSEC as this thread shows. I have no problem with trials
using
DNSSEC but I do not ENUM trials be sidetracked by solving principle DNS
problems. It is hard enough to get plain DNS and ENUM over the table an
sell it
and there is a lot of other issues to solve first. 

Before DNSSEC is implemented in ENUM I would like to see it feasabely
implemented
somewhere else.

And this leads to the second point. As I understand ENUM, it will be
mainly used to retrieve a NAPTR with an URI pointing to something else,
e.g. sip:[email-masked]. I also understand that the next thing I
have to
do is to resolve foo.microsoft.net to find the sip-server of
foo.microsoft.net
(if MS is changing his mind again and put sip back in the messenger;-)

So what is the reason to get in all this hassle with DNSSEC in
e164.arpa, as
long as .net is not secure?

I am just wondering why the discussion stopped dead on this list after
the very valid question from Peter?

If you want to implement DNSSEC for ENUM, you have to start at the root
servers
and in all domains, not in e164.arpa only. There is no line to draw.

regards
Richard

> -----Original Message-----
> From: Peter Koch [mailto:[email-masked]] 
> Sent: Saturday, February 01, 2003 6:57 PM
> To: Jim Reid
> Cc: [email-masked]
> Subject: Re: [Enum] On the question of DNSSEC and recommended 
> 
> 
> 
> > 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
> 
> 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
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Thu, 06 Feb 2003 03:33:31 -0800

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

    Richard> I consider it to be too premature to put such a strong
    Richard> statement in rfc2916bis as requested by MM and Jim at
    Richard> this time, IMHO there is too many open issues yet with
    Richard> DNSSEC as this thread shows. I have no problem with
    Richard> trials using DNSSEC but I do not ENUM trials be
    Richard> sidetracked by solving principle DNS problems. It is hard
    Richard> enough to get plain DNS and ENUM over the table an sell
    Richard> it and there is a lot of other issues to solve first.

Nobody is suggesting that ENUM activities should solve DNS problems.
Or that DNSSEC would "sidetrack" trials. [And even if it did, surely
that's a matter for the people running those trials?] The text says
DNSSEC is "recommended" so trials can choose to experiment with it or
not. I think it would be foolish for a trial not do investigate DNSSEC
since (a) we know the DNS is not secure; (b) we must be able to
validate data in the 164.arpa tree or else E.164 falls apart; (c)
DNSSEC is the only game in town for validating the DNS. There is no
alternative. There's no choice between DNSSEC and something else. It's
DNSSEC or nothing. What do you suggest?

I appreciate that selling ENUM is hard in these difficult times. Even
more so if DNSSEC is in there too. But the alternative of not doing
that is worse if the DNS gets spoofed. Ignoring the potential damage
that will undoubtedly cause is irresponsible.

    Richard> Before DNSSEC is implemented in ENUM I would like to see
    Richard> it feasabely implemented somewhere else.

If everyone takes that attitude, we get nowhere because it's always
somebody else's problem. ENUM will be an ideal place to experiment
with DNSSEC, mainly because there is no significant installed base, no
backwards compatibility issues and ENUM applications are still under
development so there should be engineering momentum for making those
things DNSSEC-aware. After all, we *know* that one day ENUM stuff will
have to be DNSSEC aware.

There are other DNSSEC activities. RIPE NCC's DISI project for their
in-addr.arpa tree is the most visible. These are hampered by having an
installed base and backwards compatibility considerations. Neither of
these things are significant concerns in the virgin territory of
e164.arpa. 

    Richard> So what is the reason to get in all this hassle with
    Richard> DNSSEC in e164.arpa, as long as .net is not secure?

Because if e164.arpa is secure -- and this can be done much more
easily than other parts of the name space -- it means we can at least
be sure that those lookups can be validated. We can start by being
certain that the NAPTR records you looked up for my phone number are
exactly what I put in the DNS. That alone has to be worthwhile, no?
Maybe these NAPTRs point only at tel: URIs, so if my DNS data is
signed, that has to be a Very Good Thing. You'll know for sure if that
tel: URI really does point at a premium rate number or not. If the
NAPTR records do point at SIP URIs, then I as the owner of some ENUM
delegation have the choice of putting the SIP server under a secure
part of the tree or not. For instance, I could duplicate the address
of Microsoft's SIP server with an entry in my signed zone under
4.4.e164.arpa. So even if microsoft.com isn't signed, there could be a
signed NAPTR record for sip.microsoft.com, albeit one depending on a
duplicate A/AAAA record for that SIP server that lives at say
sip.microsoft.1.2.3.4.4.e164.arpa. It's ugly but could help until such
times as microsoft.com was signed and there was a chain of trust all
the way to the root.

    Richard> I am just wondering why the discussion stopped dead on
    Richard> this list after the very valid question from Peter?

Well in my case it's because I've been too busy with "real ENUM work"
:-) and not had time to respond yet. I think I've partially just done
that above.

    Richard> If you want to implement DNSSEC for ENUM, you have to
    Richard> start at the root servers and in all domains, not in
    Richard> e164.arpa only. There is no line to draw.

In principle, yes. In practice no. Signing the root is fraught with
all sorts of political problems. Some of them were raised in Johan
Ihren's presentation in the DNS WG at RIPE last week. Signing
infrastructure stuff under .arpa is a good place to start. It doesn't
involve ICANN or the DoC. e164.arpa is an attractve choice for the
reasons I gave earlier.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: 06 Feb 2003 12:04:01 -0500

On Thu, 2003-02-06 at 05:33, Stastny Richard wrote:
> rfc2916bis as requested by MM and Jim at this time, IMHO there is too many open
> issues yet with DNSSEC as this thread shows. I have no problem with trials
> using DNSSEC but I do not ENUM trials be sidetracked by solving principle DNS
> sell it and there is a lot of other issues to solve first. 
> 
> implemented somewhere else.

That is why the MUST is only there once DNSSEC goes to Draft Standard.
To get to that point DNSSEC has to fairly bullet-proofed and
implemented. Before Draft Standard you are free to ignore DNSSEC to your
hearts content. The document says SHOULD instead of MUST. What it is
saying is that you can ignore this requirement but you really should be
aware of the security implications of what you are doing.

> have to do is to resolve foo.microsoft.net to find the sip-server of
> foo.microsoft.net
> e164.arpa, as long as .net is not secure?

Because if .net _is_ secured it won't matter one bit since the step
prior to it isn't secured. While securing '.net' is harder, it is
containable and deployable. But without ENUM being secured it simply
won't matter.

> servers and in all domains, not in e164.arpa only. There is no line to draw.

Yes there is. That capability is built into DNSSEC itself since everyone
involved new that the ability to sign at that level was problematic.
Your assertion is that the entire DNS tree has to be signed before its
worthwhile to sign any portion of the tree and that's simply not true
and absurd. DNSSEC wasn't built that way...

-MM

---

From: Jeff Williams <[email-masked]>
Date: Thu, 06 Feb 2003 18:15:16 -0800

Jim and all,

  I by in large agree with Jim's remarks and comments below.  Right now
there is no viable choice or alternative to DNSSEC for ENUM and to ignore
that is irresponsible at a minimum.

  Indeed it may be that the IETF is not up to the task of finishing the
DNSSEC open issues at this time of in a timely manner.  We realized
this some time ago and initiated our own commercial privately funded
effort to address them along with improving what has been thus far
undertaken by the IETF...

  ALthough the IETF may take our efforts are a slight to the IETF's
capabilities, that is certainly not the intent.  Unfortunately some here
have seemingly expressed in so many words that attitude.  This is
unfortunate
and should hopefully be beneath the IETF's ethical standards.

> involve ICANN or the DoC. e164.arpa is an attractve choice for the

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
================================================================
CEO/DIR. Internet Network Eng. SR. Eng. Network data security
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number: 214-244-4827 or 214-244-3801