[DNSOP] ECDSA woes

Mikael Abrahamsson <swmike@swm.pp.se> Sat, 15 October 2016 06:22 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD281295AC for <dnsop@ietfa.amsl.com>; Fri, 14 Oct 2016 23:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.997
X-Spam-Level:
X-Spam-Status: No, score=-4.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 078A7zN8f2Mh for <dnsop@ietfa.amsl.com>; Fri, 14 Oct 2016 23:22:46 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D427F129422 for <dnsop@ietf.org>; Fri, 14 Oct 2016 23:22:45 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4CD81A2; Sat, 15 Oct 2016 08:22:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1476512563; bh=MamHIGS/Z0EufMP8WUty4X2dbLw/9cyIAv6izedoFWg=; h=Date:From:To:Subject:From; b=1+mOHbc1xUuwzBoD82LTNhWAYKMZN+arhi8RgqGVtIsiFnBV4ERfSsjzo2poH7FFs EuT/VUnD97nlqQkVpT70yi/4nPlXDswServiuAJgjNwRTacycp2Zz96F4A7YohgXFu gBN5kaxfhnLHeXxwK+cbIPOAfE1cDpZ/J120mmTQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3F0F8A1 for <dnsop@ietf.org>; Sat, 15 Oct 2016 08:22:43 +0200 (CEST)
Date: Sat, 15 Oct 2016 08:22:43 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: dnsop@ietf.org
Message-ID: <alpine.DEB.2.02.1610150806380.26951@uplift.swm.pp.se>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LdI9-BAmmsKWS9CGDXroxtvlF0c>
Subject: [DNSOP] ECDSA woes
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Oct 2016 06:22:48 -0000

Hi,

we have a deployment of home gateways, based on OpenWrt BB that uses 
dnsmasq v2.71 as resolver, with DNSSEC validation turned on. It seems some

Dnsmasq v2.71 does not support ECDSA. A rather large CDN uses ECDSA only. 
I also found bug reports for Debian with same problem, because they also 
used dnsmasq.

Breakage occured, for instance www.ietf.org was not resolvable.

Our plan is now to disable DNSSEC validation on all of these HGWs.

So I read some documents:

https://tools.ietf.org/html/draft-wouters-sury-dnsop-algorithm-update-02
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-01

I via these found RFC4035:

"If the resolver does not support any of the algorithms listed in an
    authenticated DS RRset, then the resolver will not be able to verify
    the authentication path to the child zone.  In this case, the
    resolver SHOULD treat the child zone as if it were unsigned."

So obviously dnsmasq doesn't implement this SHOULD, because it treats 
these zones as bogus and doesn't respond back to the client.

(btw, what happens if the entire child zone and all its RRs are signed 
with an unknown algoritm, is that even covered in the above paragraph?)

It took us a while to figure out why things didn't work. We even fault 
reported this to the CDN who never at any time (during their prompt and 
friendly communication) indicated that they had any knowledge of resolvers 
that didn't support their chosen algorithm, or pointed me in that 
direction.

So... my question to you fine people is:

Is there any (existing and freely available) testing suite I can run 
against my chosen resolver that tests all the SHOULDs and MUSTs regarding 
DNSSEC validation, including future proofing for new algorithms?

If not, I would like to call upon for instance ccTLD registrys, ISOC and 
others, to develop a test suite for this, maintain it over time, and make 
it freely available.

I like DNSSEC and want to see it widely deployed. It's an important part 
of Internet plumbing. These kinds of problems that I've had last weeks 
mean people who oppose it with FUD actually have concrete breakage to 
point at that means it's not "Uncertain" anymore.

Thanks.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se