Subject: Re: [Enum] ENUM+DNSSEC Trial in JAPAN

From: "Peter Williams" <[email-masked]>
Date: Mon, 26 Jul 2004 15:23:45 -0400

Jim,
Ive watched the DNSSEC since Jim Galvin et al. got frustrated with the 
infighting between DARPA/NSA over a particular (private) contract for PKI 
(and then a PKI-security management model for SNMPv3 [aborted by ISESG due 
to over politiking]), and went with the competive research area instead 
(with the relevant companies sulking in corner, basically, over money, 
prestige, etc). The camp played to the anti-PKI forces within IETF, who were 
foot stomping about the RSA patent at the time. This all got mixed up with 
the anti-ISO (X.500) camp within IETF, and the forces within NASA (my old 
haunt) and DARPA who were doing everything then could (including internal 
war) to dissuade NSA/DoD to adopt X.500 and GOSIP-based X.400 protocols for 
the DMS. We lost about 5-10 years progress applying intelligent lookup 
algorithms over this little affair. That the same folks are now running 
ICANN is worrying: the same issues are now facing the DNS itself, and more 
intelligent naming practices and usage models (see the VeriSign affair.)

Whats never been clear in ENUM is how ENUM would *apply* DNS SEC. What the 
documents actually say is very little, and send some very poor signals to a 
reader about the relevance of DNS security to the processes of ENUM lookup, 
account provisioning, and protection of the DNS critical infrastructure 
itself (specific to ENUM management). That DNS SEC enables an RR to bear a 
signature is trivial part of the model: the architectural role of the 
secuity management system is what is important to understand: we cannot 
understand security infrastructure required for applying DNSSEC to ENUM 
without relating it to the ENUM's own distributed management infrastructure 
- a topic currently undergoing evolving design and discussion!

Put it this way: it folks use XML to provision the records, and folks secure 
the XML transfer using SOAP, and secure the use of the XML records using 
SAML, then we know that DNSSEC did not address those critical needs. Some 
parallel infrastrucure did.

In the IPSEC VPN world, we see a complete split between the security used 
for provisioning, and the security apparatus used for end-end internet 
protocols. The former are proprietary, and the standards are setup to 
continue the use of proprietary management protocols (e.g. with some system 
using the sidebands between the SONET repeaters in the backbones to 
faciliate realtime wiretapping and packet tracking at OC48 rates). The 
latter use internet standards of course, the former do not, and should not. 
The standard of course have some interplay, to ensure the providers can work 
both worlds together.

I think there is a lot from the military X.500 security management 
architecture that we can reapply to the application of DNSSEC to the ENUM 
problem domain (assuming the chairs dont withold this area from IETF to 
maintain proprietary practices). Mitsuibishi in Japan have a lot of 
experience here from the JDF experience's of matching local lookup 
infrastructure to the US infrastructure for secure messaging and secure 
channel setup in tactical systems. Many of the issues found in tactical 
miltiary wireless systems will be applicable to VoiP to internet phones 
communicating setup using SIP sessions whose proxies are themselves 
provisioned via VPN management stations, using private DNS trees.

From: Jim Reid <jim at rfc1035.com>
To: "Peter Williams" <home_pw at msn.com>
CC: fujiwara at jprs.co.jp, enum at ietf.org
Subject: Re: [Enum] ENUM+DNSSEC Trial in JAPAN Date: Mon, 26 Jul 2004 
19:28:31 +0100

>>>>> "Peter" == Peter Williams <home_pw at msn.com> writes:
    Peter> Can you state the main security objectives for the use of
    Peter> DNSSEC, please?
The Security Considerations section of RFC3761 already makes this
clear.
    Peter> (1) enable users to validate "national authority"
    Peter> delegation of ENUM regions withing e164.arpa
    Peter> (2) enable users to establish a secure channel to a DNS
    Peter> server, when issuing queries
    Peter> (3) distribute public keys to VoIP users
    Peter> (4) use ENUM algorithm to locate public keys of DNS servers
    Peter> of private ENUM tress, and/or SIP proxies
DNSSEC provides for authenticity and non-repudiation of data in DNS
responses using public key crypto and digital signatures. ie I can
lookup your domain name in the DNS and prove that the answer I got
back came from you and wasn't tampered with after it left your name
server. The DNS as we know it today does not have these safeguards. In
the context of ENUM the implication for that should be obvious: spoofed
DNS responses could be used to hijack telephone service or worse. Likewise,
retrieving keys from the DNS only makes sense if the responses from
the DNS can be validated.
FYI, DNSSEC does not provide a "secure channel" between client and
server. It does not encrypt the data being sent in either direction.
For more info, consult the latest internet drafts on DNSSEC.
draft-ietf-dnsext-dnssec-intro-11.txt is an excellent primer on this
important new protocol.

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Mon, 26 Jul 2004 17:07:46 -0400

>>>>> "Peter" == Peter Williams <home_pw at msn.com> writes:

    Peter> Whats never been clear in ENUM is how ENUM would *apply*
    Peter> DNS SEC. What the documents actually say is very little,
    Peter> and send some very poor signals to a reader about the
    Peter> relevance of DNS security to the processes of ENUM lookup,
    Peter> account provisioning, and protection of the DNS critical
    Peter> infrastructure itself (specific to ENUM management). That
    Peter> DNS SEC enables an RR to bear a signature is trivial part
    Peter> of the model: the architectural role of the secuity
    Peter> management system is what is important to understand: we
    Peter> cannot understand security infrastructure required for
    Peter> applying DNSSEC to ENUM without relating it to the ENUM's
    Peter> own distributed management infrastructure - a topic
    Peter> currently undergoing evolving design and discussion!

If you think there's work to be done in this area, feel free to write
up a draft or two. Or ask for some time in the WG agenda at IETF60.

IMO, the security model here is a no-brainer. It just follows the
general ENUM architecture and the hierarchical nature of DNSSEC.  ie
The key for e164.arpa signs the keys for "country code" delegations.
What happens after that becomes a National Matter. The Tier-1 registry
can then sign individual delegations or number blocks/ranges/area
codes as it sees fit: whatever works best for the national numbering
plan, telco regulatory considerations, DNS administration,
competition, etc, etc. There may be trade-offs to be made here and
these could be a good topic for the WG to consider. Another area the
WG could look at is signing policies and key management: how often
keys should be changed, signature durations and so on. That may be out
of scope for the WG or require crypto expertise that isn't available
here.

What would be on-topic for this WG IMO could/should be a deployment &
migration strategy for DNSSEC under e164.arpa. For example, how does a
dumb device validate signed responses? What should/must a client do
when validation fails? What are the trust relationships and how are
these documented? To some extent, this work will get under way once
the dnsext WG throws DNSSECbis over the wall. Which should be Real
Soon Now. Hopefully.