Re: [DNSOP] ECDSA woes

Mikael Abrahamsson <swmike@swm.pp.se> Sun, 16 October 2016 08:14 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 10C221295D1 for <dnsop@ietfa.amsl.com>; Sun, 16 Oct 2016 01:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 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=-0.431, 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 rEjyq6_uTcTX for <dnsop@ietfa.amsl.com>; Sun, 16 Oct 2016 01:14:10 -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 3D43D1295CB for <dnsop@ietf.org>; Sun, 16 Oct 2016 01:14:09 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0C2CEA2; Sun, 16 Oct 2016 10:14:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1476605647; bh=6cxD+tegZy0fl/cUtNP1JdDirX+iI5ijYma/bYYrtUM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=0Mg2+IiV5ZOyQ5fWoW6qxtJljYvwItpPntzEjCm5kmQm1V0GujglBzCzBNHpUPvNK AGZE5mtFqTzcQmoFDLr/SabGcBy9DHu7b6OK1ZoSaDk73JB17/rJE8M8zs6JsBHXrb UjUmxkiqQY08afW0EEutRAYNCQum2Rnt9LuNPXhI=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 017B4A1; Sun, 16 Oct 2016 10:14:06 +0200 (CEST)
Date: Sun, 16 Oct 2016 10:14:06 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Geoff Huston <gih@apnic.net>
In-Reply-To: <11BD031F-EDBF-4DF6-A167-0240581EBD0F@apnic.net>
Message-ID: <alpine.DEB.2.02.1610161010310.12036@uplift.swm.pp.se>
References: <alpine.DEB.2.02.1610150806380.26951@uplift.swm.pp.se> <c1e14584-a444-37ef-1e4c-d1077ba4f384@bellis.me.uk> <alpine.DEB.2.02.1610151717420.12036@uplift.swm.pp.se> <0A83A7D9-E7E8-4494-86F9-F19AE96967D7@fl1ger.de> <alpine.DEB.2.02.1610151751210.12036@uplift.swm.pp.se> <11BD031F-EDBF-4DF6-A167-0240581EBD0F@apnic.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-2111312547-1476605647=:12036"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/L_lP4bAnjrE-nRf0XKjs1gUjN7o>
Cc: dnsop@ietf.org
Subject: Re: [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: Sun, 16 Oct 2016 08:14:12 -0000

On Sun, 16 Oct 2016, Geoff Huston wrote:

> so I have three tests:
>
> A: a validly-signed ECDSA P-256 domain
>
> B: an invalidly-signed ECDSA P-256 domain
>
> C: an unsigned control
>
> now if the resolver does NOT recognise ECDSA we should see a fetch for A, B and C  (as they treat both A and B as if they were unsigned)
>
> if the resolver recognises ECDSA we will see a fetch of A and C but not B
>
> and if the resolver incorrectly returns SERVFAIL when it sees ECDSA (which I presume is what DNSMASQ 2.71 is doing) then we should see only C and not A or B
>
> The report generated uses these definitions to determine if a user is passing their queries to ECDSA-aware resolvers
>
> So thats the long answer to yes, this error is caught by these tests, and the error is put into the “does not do ECDSA” bucket.

Ok, thanks! It seems to me that anyone not loading A or B, but loads C, is 
of high interest. They're obviously behind a broken resolver.

Could you please try to create two buckets out of the "does not do ECDSA", 
one being "doesn't understand ECDSA, loads invalid resources" and "doesn't 
load ECDSA resources regardless of valid or not".

I'm very interested in the last of these two, because they're hindering 
rollout of new algorithms. I'd like to understand how big this breakage 
is.

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