Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00

"Marc Lampo" <marc.lampo@eurid.eu> Thu, 01 September 2011 07:23 UTC

Return-Path: <marc.lampo@eurid.eu>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC07C21F8581 for <dnsext@ietfa.amsl.com>; Thu, 1 Sep 2011 00:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.443
X-Spam-Level:
X-Spam-Status: No, score=-8.443 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwNEGQjSGdn2 for <dnsext@ietfa.amsl.com>; Thu, 1 Sep 2011 00:23:09 -0700 (PDT)
Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id 786F121F8513 for <dnsext@ietf.org>; Thu, 1 Sep 2011 00:23:08 -0700 (PDT)
X-ASG-Debug-ID: 1314861875-0369494a379b3d0001-uIE7UK
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id 7ZWV8Pyhx8cXaRBG; Thu, 01 Sep 2011 09:24:35 +0200 (CEST)
X-Barracuda-Envelope-From: marc.lampo@eurid.eu
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 3B552E408C; Thu, 1 Sep 2011 09:24:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at techmail.eurid.eu
Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XLJ0OQGPE4w; Thu, 1 Sep 2011 09:24:35 +0200 (CEST)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 129F8E4079; Thu, 1 Sep 2011 09:24:35 +0200 (CEST)
From: Marc Lampo <marc.lampo@eurid.eu>
To: 'Andrew Sullivan' <ajs@anvilwalrusden.com>, draft-vandergaast-edns-client-subnet@tools.ietf.org
References: <20110830162134.GB84494@shinkuro.com>
In-Reply-To: <20110830162134.GB84494@shinkuro.com>
Date: Thu, 01 Sep 2011 09:24:35 +0200
X-ASG-Orig-Subj: RE: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00
Message-ID: <004201cc6878$39116fb0$ab344f10$@lampo>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: AcxnMOJRMUe+YHENS3K3ekEF7uJDYgBQo2ZA
Content-Language: en-za
X-Originating-IP: [172.20.1.97]
X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121]
X-Barracuda-Start-Time: 1314861875
X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
Cc: dnsext@ietf.org
Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2011 07:23:10 -0000

Hello,

As one of the authors observed in a reaction to this posting,
the publication of this draft went mostly unnoticed -
I must admit I missed it as well ...

But now that I have read it, I have one observation regarding the content
 (something I feel is missing)
and one global, "architectural", remark.

About the content :
In my opinion the impact of DNSSEC is underestimated
when the RFC refers to an "optimized reply".

Assuming a service has multiple address records,
optimization could mean
 - order the address records in such a way that the "most optimal address"
is first,
    in the reply from authoritative name server to caching name server.
    (which assumes that that caching name server will not change the order
again)
    --> (for DNSSEC) the RRset remains complete, corresponding RRSIG's can
be used
 - only the "most optimal address for this client" is returned.
    --> (for DNSSEC) the RRset is *modified*, the RRSIG must be
recalculated !

For an authoritative name server, implementing DNSSEC and this RFC,
it probably implies that it must be able to calculate RRSIG's "on the
fly";
Which implies that it must have access to the private part of DNSKEY's;
Which implies that signing on a hidden master
and distributing signed data to public slaves is not enough.
Though I know some name server implementations implement "on the fly
signing",
 I'm hesitant about the consequence of having to transport the private
parts of DNSKEY's
 to all Internet facing name servers.

For this RFC, I suggest some additional text is added to describe
consequences
of implementing both DNSSEC and this RFC.

About the architecture :
Although there is much merit in offering a public, resolving, service (for
individual PC's),
it is quite dangerous for companies to have their (internal) caching name
service
forward (only) to such a service !
A (slight) variation of Dan Kaminski's cache poisoning attack could really
cause big
Problems in such a setup.
Without going in too much detail,
1) a forwarding name server must accept more additional data than a
non-forwarding one !
   Basically because it asks one question, expects one useable reply.
2) the window-of-opportunity for a cache poisoning attack is *seconds* !!!
   (with Dan Kaminsky : *fractions* of seconds : it closes when the reply
from the auth NS arrives)

The only (full proof) way for the forwarding name server to defend against
this,
is by validating (DNSSEC) received answers.
To that purpose, the forwarding name server will need more info (like DS
records).

Which brings me to a demand to those organisations offering such a public,
resolving, service :
Please *do start* to implement DNSSEC *first*,
so that at least this public name service knows where to look for DS
records !
(you could leave the actual verification of signatures to your users - who
wish to do so.
In Bind syntax :
options {
        ...
        dnssec-enable yes;     // <-- name server knows where to look for
for DS records
        dnssec-validation no;  // <-- at your discretion to validate
yourself, or not
};


Kind regards,

Marc Lampo
Security Officer
 
    EURid
    Woluwelaan 150     
    1831 Diegem - Belgium
    marc.lampo@eurid.eu 
    http://www.eurid.eu
    


Want a .eu web address in your own language? Find out how so you don't
miss out!