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

From: "Stastny Richard" <[email-masked]>
Date: Thu, 6 Feb 2003 13:14:51 +0100

Hi Jim,

nice to hear that you are also busy with ENUM work ;-) and I will try
to catch up with the RIPE issues dicussed last week.

The major problem I have with your proposal is to see the MUSTs NOW in
RFC2916bis:

   "At the 
   point at which DNSSEC becomes a Draft Standard, it MUST be 
   implemented by ENUM compliant systems."

Some may get the idea to prevent DNSSEC to get a Draft Standard ;-)

I also have problems with this:

   "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." 

See the comments from Lawrence. I have a problem here because I do not
yet fully understand the implications of this. I have learned 
during the discussions on the enumservices that the clients
out there may be so dumb that they cannot evaluate the regexp of all
NAPTRs first,
so they have to select the NAPTR only with the enumservice, but the same
dumb clients (example was always mobile phones) now MUST be fully
capable
of handling DNSSEC.

I am just wondering.

regards
Richard

> -----Original Message-----
> From: Jim Reid [mailto:[email-masked]] 
> Sent: Thursday, February 06, 2003 12:34 PM
> To: Stastny Richard
> Cc: Peter Koch; [email-masked]
> Subject: Re: [Enum] On the question of DNSSEC and recommended 
> 
> 
> >>>>> "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: Bill Manning <[email-masked]>
Date: Thu, 6 Feb 2003 04:23:28 -0800 (PST)

% I also have problems with this:
% 
%    "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." 
% 
% See the comments from Lawrence. I have a problem here because I do not
% yet fully understand the implications of this. I have learned 
% during the discussions on the enumservices that the clients
% out there may be so dumb that they cannot evaluate the regexp of all
% NAPTRs first,
% so they have to select the NAPTR only with the enumservice, but the same
% dumb clients (example was always mobile phones) now MUST be fully
% capable
% of handling DNSSEC.

	From here, I think this means that there is no flag day.
	Some parts of the DNS infrastrucuture will be signed before
	other parts and if ENUM systems expect anything different,
	e.g. everything is or is not signed, then such a system
	will find -very- limited deployment.  

% 
% I am just wondering.
% 
% regards
% Richard
% 
% > -----Original Message-----
% > From: Jim Reid [mailto:[email-masked]] 
% > Sent: Thursday, February 06, 2003 12:34 PM
% > To: Stastny Richard
% > Cc: Peter Koch; [email-masked]
% > Subject: Re: [Enum] On the question of DNSSEC and recommended 
% > 
% > 
% > >>>>> "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
% 

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Jim Reid <[email-masked]>
Date: Thu, 06 Feb 2003 08:35:16 -0800

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

    Richard> The major problem I have with your proposal is to see the
    Richard> MUSTs NOW in RFC2916bis:

    Richard>    "At the point at which DNSSEC becomes a Draft
    Richard> Standard, it MUST be implemented by ENUM compliant
    Richard> systems."

    Richard> Some may get the idea to prevent DNSSEC to get a Draft
    Richard> Standard ;-)

I think dnsext has enough people with that opinion already. :-)

    Richard> I also have problems with this:

    Richard>    "Additionally, due to the fact that some parts of the
    Richard> ENUM system may

    Richard>    be using DNSSEC before others, resolvers MUST be
    Richard> capable of handling responses containing DNSSEC-related
    Richard> RR types even in cases where the resolver or client
    Richard> application is unwilling or unable to perform DNSSEC
    Richard> validation."

    Richard> See the comments from Lawrence. I have a problem here
    Richard> because I do not yet fully understand the implications of
    Richard> this.

The implication is resolvers have to be capable of handling DNS
responses that contain SIG, NXT, KEY records and whatever. This should
be no surprise to anyone. That does not necessarily mean to say
resolvers must validate those signatures. At least not until DNSSEC is
finished. Until then, at the very least, a resolver should not crash
or misbehave because it sees a bigger than expected DNS response or
"unknown" RR types. If the resolver is slightly smarter than that, it
might want to tell the calling application it saw signed data which
has not been validated. Or it might choose to pass the DNSSEC stuff
via some API in case the calling application has some other means of
doing the validation (eg lwres in BIND9).

    Richard> I have learned during the discussions on the
    Richard> enumservices that the clients out there may be so dumb
    Richard> that they cannot evaluate the regexp of all NAPTRs first,
    Richard> so they have to select the NAPTR only with the
    Richard> enumservice, but the same dumb clients (example was
    Richard> always mobile phones) now MUST be fully capable of
    Richard> handling DNSSEC.

No. Though I suspect that's where we'll eventually be heading. I don't
believe a resolver that has a trust relationship with a DNSSEC-aware
name server will always be a valid assumption.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

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

> Some may get the idea to prevent DNSSEC to get a Draft Standard ;-)

The point of the MUST being at Draft instead of Proposed is that once
that level of standardization is obtained with DNSSEC it probably should
be made a MUST for all new protocols anyway. The MUST isn't there for
Proposed. There is an ___extremely___ important difference. If/When
DNSSEC gets to Proposed I'm pretty sure the IETF will feel very strongly
that you will have to have an extremely good reason to not require
DNSSEC.

> dumb clients (example was always mobile phones) now MUST be fully

The point here is that there have been resolvers that choked on unkown
RR types. This is a violation of the DNS standard itself and simply a
bad implementation. Being able to not fail when presented with an
unknown RR type will not add any size or complexity to a 'dumb' device.
Heck, there are RFID tags that have tiny built in cameras for taking
pictures and transmitting them. I can't imagine what kind of
requirements a device might have that it can't handle the minimum of not
barfing when presented with DNSSEC RRs...

Again, this requirement doesn't say you have to implement DNSSEC, you
just have to not die if you see them in your responses...

-MM

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 19 Feb 2003 08:59:39 +0100

I am a bit nervous of talking too much of how and when DNSSEC is to be 
applied. I agree completely with what Michael said from a technical 
standpoint, but, DNSSEC can unfortunately not be deployed not only 
before the RFC's are ready, but also not before the 
key-management/distribution issues are resolved.

Just because nothing of this is done yet, I rather have a text which 
say something which specify the functionality requirement people are 
after in 2916bis.

What do you all say about something like the following:

    As ENUM is using DNS, which in its current form is an insecure
    protocol, there is no mechanism for ensuring that the data one
    get back is authentic. In the IETF, work is going on with DNSSEC
    which is a mechanism where data integrity can be verified by
    the querying party, so the client can be sure the data is
    originating from an authoritative source.

    ENUM services deployed on the global Internet is expected to be
    a popular target for various kind of attacks, and attacking the
    DNS is one way of attacking the ENUM service itself.

    Because of this, an ENUM service deployed SHOULD include mechanisms
    which implement security services like DNSSEC do, verification
    of authenticity of the data. This include not only the ENUM
    lookup itself, but also the various records needed for the
    services to be useful (for example MX, SRV and A records).

    Finally, as an ENUM service according to the previous paragraph
    is expected to use DNSSEC when defined by the IETF, software
    which implement ENUM MUST be prepared on DNSSEC being used, which
    include large responses, requirement for EDNS0 signaling etc.

Note that SHOULD and MUST is defined in RFC 2119. I am not as afraid of 
misinterpretation of the SHOULD.

The difference I try to make between the above and what Michael wrote 
are mainly 2:

(1) No MUST for DNSSEC, because I don't see we can write MUST together 
with a 2nd requirement which is impossible to measure today.

(2) I try to point out that IF other mechanisms are invented before 
DNSSEC is deployed, which implement the same kind of authenticity, that 
is possibly a solution which can be used. I don't see one today, but, 
who knows?

It is also the case that when we have had our test beds, it might be 
the case that we see that the _services_ need to be so secured in all 
different kinds of way that security on the ENUM lookup doesn't add 
anything. It might be too complicated to have security on the ENUM 
level. Yes, one can inject a ddos attack by faking DNS responses, but 
even if the ENUM DNS queries/responses are signed I am sure we might 
see other ways of breaking the DNS lookup by attacking the protocol 
itself (i.e. making sure _no_ response is reaching the querying party).

Requiring DNSSEC for the ENUM lookup make people believe the rest of 
the system is secure, the SRV and A records used for SIP, MX+A for 
SMTP, the actual protocol (SIP, SMTP etc) used for the exchange of 
information.

Security is not something that can be applied at one location, and the 
Internet will be secure. That said, of course ENUM should (as any 
protocol) have appropriate security.

     paf

On torsdag, feb 6, 2003, at 18:10 Europe/Stockholm, Michael Mealling

---

From: Michael Mealling <[email-masked]>
Date: 19 Feb 2003 09:39:23 -0500

> key-management/distribution issues are resolved.

Which is why I didn't make it required until the Draft Standard point
because I figured it would've had to solve those problems in order to
get to that point. But that is possibly a false assumption on my part.

>     include large responses, requirement for EDNS0 signaling etc.

I'm fine with it. I'd prefer it to be stronger simply because I've seen
large numbers of people assume that everything that isn't a 'MUST' can
be safely ignored.

> with a 2nd requirement which is impossible to measure today.

Yea, I can see that. I just wish we could say it more strongly than you
have. But I guess putting "really, really SHOULD" isn't really proper.

> is possibly a solution which can be used. I don't see one today, but, 

If that becomes the case then large numbers of documents have to change,
not just ENUM....

> SMTP, the actual protocol (SIP, SMTP etc) used for the exchange of 

Sure, but conversely, people will think that if DNSSEC isn't required
then there isn't sufficient need for ENUM to be secured.

> protocol) have appropriate security.

Completely agree. I'm fine with your language but I think in the future
as soon as DNSSEC is 'ready' that the IAB and IESG should make some
statement similar to what they did for Unicode and 7bit ascii.

-MM

---

From: Jim Reid <[email-masked]>
Date: Fri, 28 Feb 2003 08:46:03 -0800

Just about coming up for air....

Patrik, I share your concerns about what we put into 2916bis given
that DNSSEC isn't quite done yet and the key management stuff is even
further away. However I'd prefer if we stuck to the earlier text.
(Trials MAY want to use DNSSEC and it will become mandatory if/when
DNSSEC is finalised.) We seemed to have reached consensus on that.

Your proposed text considerably waters down that recommendation
IMO. This gives me a problem as it implies we're backing off from
DNSSEC. For ENUM this is a Bad Thing since DNSSEC is the only game in
town in the forseeable future for validating DNS packets. And saying
an ENUM service SHOULD (only should???) include validation of DNS
packets is just far too half-hearted. ENUM will die (or never be born)
if there's no way to prevent or detect DNS spoofing under e164.arpa.

In my capacity as an ENUM trial manager, I have a further problem
with the new text. It will make it harder for me to encourage or
persuade folk to introduce DNSSEC into the trial. If there's push back
on that, I'd like to point the nay-sayers at an IETF or IAB document
which says that DNSSEC is important for ENUM and should figure in
trials if possible. Now if that isn't appropriate for 2916bis, it
needs to be said somewhere else. Where?
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum