Re: [dnsext] DNSSEC, robustness, and several DS records

"Marc Lampo" <marc.lampo@eurid.eu> Thu, 12 May 2011 06:18 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 2BAF0E0675 for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 23:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.15
X-Spam-Level:
X-Spam-Status: No, score=-9.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znx8vIYkUmou for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 23:18:07 -0700 (PDT)
Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id A96CEE06F2 for <dnsext@ietf.org>; Wed, 11 May 2011 23:18:05 -0700 (PDT)
X-ASG-Debug-ID: 1305181083-03694916393be70001-uIE7UK
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id 5xYEnjt6refq9lRz for <dnsext@ietf.org>; Thu, 12 May 2011 08:18:03 +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 31906E407C for <dnsext@ietf.org>; Thu, 12 May 2011 08:10:18 +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 4OxbFAiT-77D for <dnsext@ietf.org>; Thu, 12 May 2011 08:10:18 +0200 (CEST)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 17593E4050 for <dnsext@ietf.org>; Thu, 12 May 2011 08:10:18 +0200 (CEST)
From: "Marc Lampo" <marc.lampo@eurid.eu>
To: <dnsext@ietf.org>
References: <201105112022.p4BKMHmp010275@givry.fdupont.fr> <20110512012832.296D7EAE55F@drugs.dv.isc.org> <DD056A31A84CFC4AB501BD56D1E14BBBA1C13B@exchange.secure64.com>
In-Reply-To: <DD056A31A84CFC4AB501BD56D1E14BBBA1C13B@exchange.secure64.com>
Date: Thu, 12 May 2011 08:10:18 +0200 (CEST)
X-ASG-Orig-Subj: RE: [dnsext] DNSSEC, robustness, and several DS records
Message-ID: <001c01cc106c$5af59ca0$10e0d5e0$@lampo@eurid.eu>
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: AcwQRkitxlewHY/1S9K9mxBRGK2m7gAJLv8g
Content-Language: en-za
X-Originating-IP: [172.20.5.23]
X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121]
X-Barracuda-Start-Time: 1305181083
X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
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, 12 May 2011 06:18:08 -0000

Isn't the SHA-1 DS there to accommodate for validating caching name
servers that do not understand the SHA-256 "type" ?


Sorry to go somewhat off-topic, but still related to strengths of
algorithms :
Similar "problems" with the DNSKEY algorithms : RSASHA1, NSEC3RSASHA1,
RSASHA256 and ..512
A validating caching name server that does not understand a stronger
algorithm
treats the data as "unsigned"
+ great design of DNSSEC, this backward compatibility
- but pushing towards stronger algorithms, makes them being ignored by
"older" software

Last time I looked, Microsoft DNS topped at RSASHA1 (5);
the root uses algorithm 8
--> Microsoft DNS, even configured to validate, cannot even start to
validate.

No, I don't want to start a war of which vendor to use or not to use,
but by pushing towards better security,
the security level can be *reduced* !
(if the push is "too soon")

Kind regards,

Marc Lampo


-----Original Message-----
From: Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com] 
Sent: 12 May 2011 03:46 AM
To: Mark Andrews; Francis Dupont
Cc: Paul Hoffman; dnsext@ietf.org
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records

Regarding the RFC4509 discussion,

I don't see why anybody would like to upload both a SHA-1 and SHA-2 DS
to their parent. With AM, CAT, CH, CL, COM, CZ, DK, EDU, FI, FR, GR, LI,
LU, MUSEUM, NET, NL, PM, RE, SE, TF, UK, WF and YT using only the SHA-2
algorithm for their DS in the root zone. Additionally, ARPA, BE, BIZ,
CO, JP, MY, XN--0ZWM56D, XN--11B5BS3A9AJ6G, XN--80AKHBYKNJ4F,
XN--9T4B11YI5A, XN--DEBA0AD, XN--G6W251D, XN--HGBK6AJ7F53BBA,
XN--HLCJ6AYA9ESC7A, XN--JXALPDLP, XN--KGBECHTV, XN--ZCKZAH all requires
a resolver to understand SHA-2 to be able to understand the DNSKEY in
their zone anyway.

I think it is fair to say that the DNSSEC functionality of a resolver
without support for SHA-2 is highly limited. As such I don't believe
that there are that many of them out there. (Am I wrong?)

Do like .COM and Just don't upload the SHA-1 and you will never have
this problem. We can perhaps have a different requirement wording in any
future RFC that is introducing a new DS algorithm. But for SHA-1 vs.
SHA-2 in reality this is not an issue.

I'm noticing that FR currently only has a SHA-2 in the root zone. I
guess they came to the same conclusion.

/S
----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940

>-----Original Message-----
>From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On
Behalf Of
>Mark Andrews
>Sent: Wednesday, May 11, 2011 8:29 PM
>To: Francis Dupont
>Cc: Paul Hoffman; dnsext@ietf.org
>Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
>
>
>In message <201105112022.p4BKMHmp010275@givry.fdupont.fr>fr>, Francis
Dupont
>writes:
>>  In your previous mail you wrote:
>>
>>    Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact
>>    that the BIND and Unbound people treat it as a MUST seems like a
>>    bug.
>>
>> => I don't understand how the SHOULD can be interpreted in order to
>> avoid the "bug" (:-). Seriously you can disagree with RFC 4509
>> but not about the way it has to be implemented, i.e., your concern
>> is not about what it should be...
>>
>> Regards
>>
>> Francis.Dupont@fdupont.fr
>> _______________________________________________
>> dnsext mailing list
>> dnsext@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsext
>
>Agreed.  You are either configured to follow the SHOULD or not and
>the default is to fail.  Now not having a switch to turn it off
>means you don't have a work around once you discover that DS is
>wrong which requires contacting the administrators for the zone as
>they are the only ones that can tell you whether it is wrong or you
>are under attack.  You can make a educated guess without contacting
>the zone administrators.
>
>Mark
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>_______________________________________________
>dnsext mailing list
>dnsext@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsext