Re: [DNSOP] [Ext] More private algorithms for DNSSEC

Peter Thomassen <peter@desec.io> Tue, 29 March 2022 13:28 UTC

Return-Path: <peter@desec.io>
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 684DF3A18BD for <dnsop@ietfa.amsl.com>; Tue, 29 Mar 2022 06:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 1L2XvzW0ysiP for <dnsop@ietfa.amsl.com>; Tue, 29 Mar 2022 06:28:27 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 5F8C53A07A0 for <dnsop@ietf.org>; Tue, 29 Mar 2022 06:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:Cc:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uuVX8rffq6vwAvF1hFB3+Itz6TXBkShyMribkW3CR2U=; b=r78O/eUhDmk/3uk8jEnTWZFY6R Uc4tqb621QvfIpEAb6n3ZOu9Om4TkE67aMr1hMviTZrlsYXCZ/kWXZZeJwRi/ZkuaU2wLEp08eBTf wwTheqg0rq4vRI4LLDAzcdzVq/tTBWzClPcAclJjHfHQWtUeDxhcRB0ES7wAzD7aQ6eT+NFMV0HwS rDxuVgAxI6xTuhuEKDjXQ9jp/IFR9a4nSOHuOnlKRYwA3xEEmWlLpUy/0nuNhqkTZScsHNPrIwfF5 br3Szd4Tn2kjhd8imRGVpaL6aFQktbriV/btETWg7D9il2v7V3qgPNrMzA8KamUB30zItnvBg6C6i kz1sTDkw==;
Received: from [91.65.103.206] (helo=[192.168.178.70]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1nZBtQ-0005bz-HS; Tue, 29 Mar 2022 15:28:16 +0200
Message-ID: <c3a7bfb5-9e43-ca40-8b15-7f84a2826022@desec.io>
Date: Tue, 29 Mar 2022 15:28:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: Mark Andrews <marka@isc.org>, Paul Hoffman <paul.hoffman@icann.org>
Cc: dnsop WG <dnsop@ietf.org>
References: <5C105C71-B18C-4366-94F5-E8D60970109C@icann.org> <20B389EF-4909-43A0-9BC8-F57F5E332E8A@verisign.com> <1D59C3FB-4FCC-4A03-8E13-EA6902B14D2A@icann.org> <54622bd0dd3253187a9c9b69d0a1188a4d898bd9.camel@powerdns.com> <CC878AFE-3B67-49D9-9A9E-F3D21BC900FB@isc.org> <6859EF89-8E3A-4C18-8B4A-2AF4C37CDF65@icann.org> <585479E8-293C-42D4-BA2F-7FD99B27EBDE@isc.org>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <585479E8-293C-42D4-BA2F-7FD99B27EBDE@isc.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cgdZCELsOXwfslomJSBWtx-Ms_M>
Subject: Re: [DNSOP] [Ext] More private algorithms for DNSSEC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 29 Mar 2022 13:28:33 -0000


On 3/28/22 20:34, Mark Andrews wrote:
> About the only part not already specified is matching DS to DNSKEY using PRIVATEDNS but as you can see it is obvious to anyone with a little bit of cryptographic understanding.

That creates problems plus complexity, which I find very undesirable. Orthogonality trumps complexity.

For example, zones need to have a DNSKEY for each signing algorithm given in the DS record set. I would expect most implementations to currently only look at the algorithm number in this context, and not at the 253/254 algorithm identifier.

Of course, a dedicated document may clarify this, but I don't see how this is less complex than assigning experimental algorithm numbers. All DNSSEC software out there would have to implement it, test/maintain it etc. This does not only apply to resolver software; think of application-level libraries like dnspython etc.

There will also be implementations which don't care to implement such "private algorithm peeking". For those, algorithm handling would not be ensured in the same way as it is for non-253/254 algorithms.

Further, if someone actually *is* using private 253/254 algorithms in production, any experiments would not be structurally independent from potential such private use cases. Giving the little confidence that all DNS software would implement "253/254 algorithm disentanglement" correctly, private-algo zone owners may be hesitant to run any experiments at all.

Last, I'm not convinced that running a PQ algorithm (or other) experiment to test (non-supporting) resolvers' behavior should require controlling a domain name or OID (as is required for 253/254).

These concerns bring us back to Nils' comment that 253/254 is not a good basis for performing research and doing real-life experiments.


The above headaches would be in addition to the effort of writing the clarification document, whereas Paul's proposal requires just the document.

I therefore support the assignment of experimental algorithm numbers, and I think the text should mandate that they MUST be treated as unknown and have no special processing, unlike private ones.

Best,
Peter

-- 
https://desec.io/