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

From: Richard Shockey <[email-masked]>
Date: Thu, 30 Jan 2003 15:24:44 -0500

In the absence of consensus on the list ..and after consulting with various 
members of the DNSOPS community that are close to the matter I think we are 
safe in leaving as is the proposed language that DNSSEC is 'recommended' in 
lower case.

However I would caution that those of you that are involved in various 
national ENUM trials and in documenting procedures for various national 
ENUM administrations that "recommended" does not mean REQUIRED. I sill 
believe that it is premature to mandate DNSSEC deployment in the ENUM 
context at this time.

There is still much work to be done and we should all monitor progress in 
this area closely.

Is this a fair and reasonable statement of consensus?

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: Jim Reid <[email-masked]>
Date: Thu, 30 Jan 2003 15:58:36 -0800

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

    Richard> However I would caution that those of you that are
    Richard> involved in various national ENUM trials and in
    Richard> documenting procedures for various national ENUM
    Richard> administrations that "recommended" does not mean
    Richard> REQUIRED. I sill believe that it is premature to mandate
    Richard> DNSSEC deployment in the ENUM context at this time.

    Richard> There is still much work to be done and we should all
    Richard> monitor progress in this area closely.

    Richard> Is this a fair and reasonable statement of consensus?

Yes. I don't believe any trials are making DNSSEC mandatory. However I
know of at least one that intends to evaluate it. :-) DNSSEC will have
to be tried before ENUM goes into production use, assuming that this
happens after DNSSEC is completed of course. Not that I can see telcos
and regulators ever deploying ENUM unless the answers from the DNS can
be validated.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jeff Williams <[email-masked]>
Date: Thu, 30 Jan 2003 20:03:23 -0800

Richard and all,

  Recommended, yes.  Mandated/REQUIRED no.  Hence I would
agree that only recommended not mandated or REQUIRED.  I cannot say
if there is a consensus here on that however.

>   <http://www.neustar.biz> ; <http://www.enum.org>

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

---

From: Michael Mealling <[email-masked]>
Date: 31 Jan 2003 01:21:17 -0500

> safe in leaving as is the proposed language that DNSSEC is 'recommended' in 

I would personally recommend something slightly stronger. More like
this:

At the time of publication of this document the DNSSEC standard had not
been finished. Until that time ENUM's use of DNSSEC is merely
recommended. When DNSSEC becomes a published specification, ENUM based
systems SHOULD fully implement DNSSEC.

> Is this a fair and reasonable statement of consensus?

I can live with it but I think the case needs to be made a little
stronger than what it is. As it stands an implementor will read that and
assume they can ignore DNSSEC which isn't the intent...

-MM

---

From: Chip Sharp <[email-masked]>
Date: Fri, 31 Jan 2003 07:15:35 -0500

Question for clarification:

I believe the current text says:
"As this system is built on top of DNS, one can not be sure that the 
information one gets back from DNS is more secure than any DNS query. To 
solve that, the use of DNSSEC [7] for securing and verifying zones is to be 
recommended. "

To which zones does this recommendation reach?  Does this recommendation 
(or a subsequent SHOULD if Michael's proposal is accepted) apply to the 
Tier 2 zones, CC.e164.arpa., e164.arpa., arpa., .?

Thanks,
Chip

---

From: Richard Shockey <[email-masked]>
Date: Fri, 31 Jan 2003 11:48:55 -0500

At 07:15 AM 1/31/2003 -0500, Chip Sharp wrote:
>solve that, the use of DNSSEC [7] for securing and verifying zones is to 
>be recommended. "
>

and what is the effect of zone opt-in...

Title           : DNSSEC Opt-in
         Author(s)       : R. Arends, M. Kosters, D. Blacka
         Filename        : draft-ietf-dnsext-dnssec-opt-in-03.txt
         Pages           : 21
         Date            : 2002-10-14

In RFC 2535, delegations to unsigned subzones are cryptographically
secured.  Maintaining this cryptography is not practical or
necessary.  This document describes an 'Opt-In' model that allows
administrators to omit this cryptography and manage the cost of
adopting DNSSEC with large zones.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-03.txt

>>assume they can ignore DNSSEC which isn't the intent...

I would like to hear some other opinions here.... and  any other issues we 
need to work through in 2916bis... as I mentioned before I would like to 
maintain a fast track on the discussions here so that we can consider last 
call on 2916bis on or before IETF SanFrancisco.

---

From: David Conrad <[email-masked]>
Date: Fri, 31 Jan 2003 10:35:38 -0800

Hi,

On Friday, January 31, 2003, at 08:48  AM, Richard Shockey wrote:
>> Does this recommendation (or a subsequent SHOULD if Michael's 
>> proposal is accepted) apply to the Tier 2 zones, CC.e164.arpa., 
>> e164.arpa., arpa., .?

Yes.  DNSSEC validates by traversing up from the leaf nodes to a 
'security root', that is, a zone for which you have a trusted key.  The 
intent is that validating caching servers will ship with "."'
s trusted keys.  If 3.0.0.6.1.8.3.0.5.6.1.e164.arpa is signed (which 
would be necessary to ensure the NAPTR RRs weren't tampered with after 
they are fetched), then each and every parent zone of 
3.0.0.6.1.8.3.0.5.6.1.e164.arpa will need to be signed as well.

> and what is the effect of zone opt-in...

Mass insanity and global thermonuclear war?  Err... OK, so maybe my 
biases are showing :-).

More seriously, DNSSEC opt-in (should it be accepted) does not remove 
the need for the tree to be signed as described above.  What it would 
provide is the ability for individual leaf nodes to choose not to be 
included in the secure part of the zone.  I don't see any value to this 
in the context of ENUM (the only value opt-in brings is if you have a 
_very_ large zone that makes signing the entire zone (arguably) 
problematic -- this wouldn't be the case with ENUM).

Rgds,
-drc

---

From: Chip Sharp <[email-masked]>
Date: Fri, 31 Jan 2003 14:13:01 -0500

Thanks.
So the effect of a statement in a national or regional ENUM deployment 
requirements spec that DNSSEC shall be used would be that no ENUM 
deployment could occur until the root-servers also support DNSSEC (or some 
part of it).
And of course this is mostly outside the control of any regional or 
national ENUM-oriented group.
To follow this to its absurd conclusion... making such a requirement would 
be tantamount to stating that such group should just disband until DNSSEC 
is deployed on root and arpa. ;-)

Chip

At 01:35 PM 1/31/2003, David Conrad wrote:
>>>Does this recommendation (or a subsequent SHOULD if Michael's proposal 
>>>is accepted) apply to the Tier 2 zones, CC.e164.arpa., e164.arpa., arpa., .?
>
>Yes.  DNSSEC validates by traversing up from the leaf nodes to a 'security 
>root', that is, a zone for which you have a trusted key.  The intent is 
>that validating caching servers will ship with "."'
>s trusted keys.  If 3.0.0.6.1.8.3.0.5.6.1.e164.arpa is signed (which would 
>be necessary to ensure the NAPTR RRs weren't tampered with after they are 
>fetched), then each and every parent zone of 
...snip...

---

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

Chip,

On Friday, January 31, 2003, at 11:13  AM, Chip Sharp wrote:
> deployment could occur until the root-servers also support DNSSEC (or 
> some part of it).

Not necessarily.

As I said, validation occurs up from a leaf node to a security root.  
The way you avoid having a dependency on the root or .arpa being signed 
is by publishing the trusted key of (say) the e164.arpa tree (or the 
<cc>.e164.arpa tree).  The complexity here is that people who want to 
validate the data (that is, folks who run caching servers) will need to 
install that trusted key in their caching server.

Rgds,
-drc

---

From: Richard Shockey <[email-masked]>
Date: Fri, 31 Jan 2003 15:21:34 -0500

>systems SHOULD fully implement DNSSEC.

Michael ..by published specification are you saying Draft Standard only vs 
Proposed ? What level of Standard are you suggesting is acceptable before 
systems SHOULD fully implement DNSSEC?

Folks ..this is important that 2916bis accurately reflect the consensus of 
the WG and as such can be implemented by various national ENUM 
administrations in their requirements and recommendations based on our 
expert opinion.

Please add your responsible comments or alternative language ASAP.

---

From: Michael Mealling <[email-masked]>
Date: 31 Jan 2003 15:27:21 -0500

> systems SHOULD fully implement DNSSEC?

Sorry I wasn't clear. Since ENUM is also at proposed and that's where
DNSSEC would end up at, it makes sense to me to make it a SHOULD at the
time that DNSSEC is published as Proposed. Here's the exact text:

At the time of publication of this document the DNSSEC standard had not
been finished. Until that time ENUM's use of DNSSEC is merely
recommended. When DNSSEC becomes a Proposed Standard, ENUM based 
systems SHOULD fully implement DNSSEC.

-MM

---

From: Jim Reid <[email-masked]>
Date: Fri, 31 Jan 2003 13:09:39 -0800

>> At the time of publication of this document the DNSSEC standard
    >> had not been finished. Until that time ENUM's use of DNSSEC is
    >> merely recommended. When DNSSEC becomes a published
    >> specification, ENUM based systems SHOULD fully implement
    >> DNSSEC.

SHOULD isn't strong enough IMO. Once DNSSEC is deployed operationally,
it will be used for ENUM. Zones will (have to) be signed. So even if
signing is not mandatory -- I hope it will be mandatory -- resolvers
will have to be prepared to deal with SIG, KEY, NXT records or
whatever in the answers they get for their lookups. Even if those
resolvers don't care about DNSSEC and won't do the validation. They
won't be able to control what RRs exist for the names they lookup.

I think a SHOULD could be misinterpreted by regulators and
implementors. They may well decide it isn't compelling enough to
deploy or support DNSSEC once it's ready.

    Richard> Please add your responsible comments or alternative
    Richard> language ASAP.

Putting aside my quibble over "SHOULD", how about adding after
Michael's text above:
	Resolvers MUST be capable of handling responses containing
	DNSSEC-related RR types even in cases where the resolver or 
	client application is unwilling or unable to perform
	DNSSEC validation. 

By "handling responses" I mean not barfing on DNSSEC RR types, coping
with bigger DNS payloads (ie EDNS0 packets), perhaps indicating to the
client that no validation was done (or the crypt RRs are there) and so
on. Should that level of detail need to be provided?
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: 31 Jan 2003 17:03:56 -0500

> on. Should that level of detail need to be provided?

While we might quibble over SHOULD vs MUST at this point for deployment
reasons, I have to agree with Jim on this one. I would also support
making DNSSEC mandatory when ENUM moves to Draft Standard.

So I support Jim's proposed changes plus mine....

-MM

---

From: Richard Shockey <[email-masked]>
Date: Fri, 31 Jan 2003 17:19:21 -0500

>So I support Jim's proposed changes plus mine....

text would be useful for folks to review ...

but we certainly need more information and reporting from the various 
DNSSEC workshops if some of us are going to give informed opinions to 
various national ENUM adminstrations.

this is all very a very useful record ..

---

From: Michael Mealling <[email-masked]>
Date: 31 Jan 2003 17:56:45 -0500

> text would be useful for folks to review ...

Well, we both suggested text but I guess it should be more explicit. I
think we are recommending that the first paragraph of the Security
Considerations be changed from this:

   As this system is built on top of DNS, one can not be sure that the
   information one gets back from DNS is more secure than any DNS query.
   To solve that, the use of DNSSEC [7] for securing and verifying zones
   is to be recommended.

to this:

   As this system is built on top of DNS, one can not be sure that the
   information one gets back from DNS is more secure than any other DNS 
   query. Being the only extant mechanism for securing DNS responses, 
   DNSSEC is the obvious solution for ensuring the security of ENUM 
   responses. However, at the time of publication of this document the 
   DNSSEC standard has not been finished. Until that time ENUM's use of 
   DNSSEC is merely recommended. Once DNSSEC is published as a Proposed 
   Standard, ENUM based systems SHOULD fully implement DNSSEC. At the 
   point at which DNSSEC becomes a Draft Standard, it MUST be 
   implemented by ENUM compliant systems.

   Additionally, due to the fact that some parts of the ENUM system may 
   be using DNSSEC before others, resolvers MUST be capable of handling 
   responses containing DNSSEC-related RR types even in cases where the 
   resolver or client application is unwilling or unable to perform 
   DNSSEC validation. 

-MM

---

From: Jim Reid <[email-masked]>
Date: Fri, 31 Jan 2003 15:41:16 -0800

I agree with Michael's revised text.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jeff Williams <[email-masked]>
Date: Fri, 31 Jan 2003 18:19:16 -0800

Chip and all,

  Nice satirical response.  Well deserved as well! >;)

  But seriously, with independent commercial DNSSEC development
underway and expanding, despite David's disagreement to the contrary,
moving forward with DNSSEC implementation for ENUM is quite
viable and perhaps preferred.  Waiting on the IETF to move forward
in an earnest enough pace is really not being perceived adequate.

Regards,

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 1 Feb 2003 00:35:41 +0000

>I agree with Michael's revised text.

Hi Folks,
   So...If I understand the comments so far, the aim is to
require all resolvers (and I assume thus *all* ENUM Clients)
to handle Truncated messages they'll get from their ENUM
queries in a DNSSEC-ured system and be forced to send EDNS
extended length queries to get the RRs from an ENUM zone,
regardless of whether or not they validate.

Is this correct?

If so, this is required for *ALL* ENUM Clients, or am I
missing something?

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