Re: [DNSOP] ECDSA woes

Jan Včelák <jv@fcelda.cz> Mon, 17 October 2016 11:50 UTC

Return-Path: <jv@fcelda.cz>
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 B3867129475 for <dnsop@ietfa.amsl.com>; Mon, 17 Oct 2016 04:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz
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 1CHDk1Qe6zxu for <dnsop@ietfa.amsl.com>; Mon, 17 Oct 2016 04:50:31 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0661293E1 for <dnsop@ietf.org>; Mon, 17 Oct 2016 04:50:30 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id b75so284515236lfg.3 for <dnsop@ietf.org>; Mon, 17 Oct 2016 04:50:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2kFma55fPytux7NcyQ+hdI0obN00cwTkqbTbQpGfLXk=; b=bYHC2Y7jODYw7XGKSsIRxTMb6WGyknkleIfFr7uR1Cvr2wIcRf1PMidpo0N/QW0wUm /j/uKtvTE3iNXwOdHlt4YCdr5XWnMQ0J2FBzIro+hscMGZbLhwdBpB+MRdnSQ7R4vci2 WYROeEqoSCX5S9yphA+VsNR5xkpF1H6f7ocXI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=2kFma55fPytux7NcyQ+hdI0obN00cwTkqbTbQpGfLXk=; b=bvEXVQhNu8GGlL5Vs/RFTaV2pL4b6vc2h75Oyn43LkeP/pvaHc/qtSTerFbGwfeVkz RqIWsIiKAaXzRkhmOv0hxrxj0TNNNeOtv5YQ380OO4r8wn2ikBCW2B6IfTagBAsc7epK 7TmA2lIBuAJ6AFJ97AbpxG5EhozxMkPBtEAUXuKCpNp7f5rkO2WU791y6hqREtKq5++4 gqjFkmwJtc9c7XEQeadTD3WfH6xMuVL2WwmxZP/h+pHItVC2Cc1jRfdebmJFsZnMeE1s Vt0EwJKz/LBYQf/Z2P+aR9+KRXMLdeWwhIiy3pa0G9oBAJViSVRDiDC1ICHinjblm/k+ PcXg==
X-Gm-Message-State: AA6/9Rkl4STqOJXxncA09FjvVxdak0GEf0sH0pwyZVIy66UrF17DI6acmwSzECjnQloOPlZ3kWYJaJRtDXDIxA==
X-Received: by 10.28.62.73 with SMTP id l70mr7651833wma.133.1476705028298; Mon, 17 Oct 2016 04:50:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.53.225 with HTTP; Mon, 17 Oct 2016 04:50:07 -0700 (PDT)
X-Originating-IP: [172.56.38.246]
In-Reply-To: <alpine.DEB.2.02.1610150806380.26951@uplift.swm.pp.se>
References: <alpine.DEB.2.02.1610150806380.26951@uplift.swm.pp.se>
From: Jan Včelák <jv@fcelda.cz>
Date: Mon, 17 Oct 2016 06:50:07 -0500
Message-ID: <CAM1xaJ82f9S5Db7RD6X1qVJ8xdmGUKvfNk5gZ0rfg_NPL2KSLg@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jJL89-nEH5GKQEnjEyu8vv7rlN0>
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: Mon, 17 Oct 2016 11:50:33 -0000

Hi Mikael,

> 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?)

On delegation, the resolver checks the DS records in the parent zone. If
the DS record set contains a supported algorithm, the child zone should
be treated as secure. If no algorithm in the set is supported, the zone should
be treated as insecure.

So what happens in this case is that the domain name space below
the delegation with unsupported DS algorithm will be treated as insecure.

Cheers,

Jan