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
- [DNSOP] ECDSA woes Mikael Abrahamsson
- Re: [DNSOP] ECDSA woes Ray Bellis
- Re: [DNSOP] ECDSA woes Roy Arends
- Re: [DNSOP] ECDSA woes Mikael Abrahamsson
- Re: [DNSOP] ECDSA woes Ralf Weber
- Re: [DNSOP] ECDSA woes Mikael Abrahamsson
- Re: [DNSOP] ECDSA woes Marek Vavruša
- Re: [DNSOP] ECDSA woes Geoff Huston
- Re: [DNSOP] ECDSA woes Ólafur Guðmundsson
- Re: [DNSOP] ECDSA woes Mikael Abrahamsson
- Re: [DNSOP] ECDSA woes Mikael Abrahamsson
- Re: [DNSOP] ECDSA woes Ólafur Guðmundsson
- Re: [DNSOP] ECDSA woes Mark Andrews
- Re: [DNSOP] ECDSA woes Mark Andrews
- Re: [DNSOP] ECDSA woes Jan Včelák
- Re: [DNSOP] ECDSA woes Dan York
- Re: [DNSOP] ECDSA woes Mark Andrews