[DNSOP] Re: New Version Notification for draft-andrews-private-ds-digest-types-00.txt

Mark Andrews <marka@isc.org> Tue, 23 July 2024 18:22 UTC

Return-Path: <marka@isc.org>
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 C0621C157915 for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2024 11:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.408
X-Spam-Level:
X-Spam-Status: No, score=-4.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="W6LidYX8"; dkim=pass (1024-bit key) header.d=isc.org header.b="ghq1hVFX"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-YnnZJfJl9u for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2024 11:22:20 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E08C14CF15 for <dnsop@ietf.org>; Tue, 23 Jul 2024 11:22:20 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id C1C093AB276; Tue, 23 Jul 2024 18:22:19 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org C1C093AB276
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1721758939; cv=none; b=aIqMtPpuHGAKGSMhBS3IiBhcm+pQ/M0jaiMrkxv1n+V8xwn1W+OIS7ZEsaPPpU1rRIyZTFNl6ee2dx68OFqPzkos7pZbLoue+oJyb6d3S+yZBhVaBCzNpjNQNGUPame6XPNDanWVqbx9IR677kpL6SI4dFDymqHVWxpg4N9cudk=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1721758939; c=relaxed/relaxed; bh=W6hjQ9ntrXsvBDnKgm7/EP2LvBW1I9UQtRcs5WUbFo4=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=KCBqlMXxRedHywLJedam9fo3JDR88ApAGc9k3dpk2mjxH7BbG2YEi5YtUC8RTSodYqVsy5J/vGaFIxIdnkM3Zm+ibEP9DHOVNvXJsfZLNPY40SF0UuNRBtTwtZg6X9DsQU24orD4JlNiKPLRGFox2v6eFa2dyVhghUrGUR+G12M=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org C1C093AB276
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1721758939; bh=9ve8kNFqJ3xq1ua/ZVHhbuOpylbPjv0mJF3nnJIsumA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=W6LidYX8Wwt0RdvBZjVPiSHf/8vwOiHXhHID6QHI828vJrKfvI51+WKGwp+cNDt2M Y6V6rVTvCeLbutUgvkpskLogy7jX/f9gUE5pSpFROvWueh0F7BI/49/pPgKyZiE3/G 9oJc+vOkg6sz5LNVjmowsg/y7SSxEDC+yqj4imQ4=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id BCEF3E64EBD; Tue, 23 Jul 2024 18:22:19 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 991B6E66F04; Tue, 23 Jul 2024 18:22:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 991B6E66F04
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1721758939; bh=W6hjQ9ntrXsvBDnKgm7/EP2LvBW1I9UQtRcs5WUbFo4=; h=Mime-Version:From:Date:Message-Id:To; b=ghq1hVFXNLhfybBuYwk5G4NhjkrCG1F2q1AUxduSGEFdcHtV9YvnJIK93XdPuUUiV OuNWaKdeGHUN8q67Pnfo1f78IjcgyQXFSuNJmLxPjjqCxt8tXjTcfoiKSDU6aKegP7 hB31iN7Vujp9lcZzoMtk4v6RczL/2njMeg4AdPrs=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id H1-REoUajpAM; Tue, 23 Jul 2024 18:22:19 +0000 (UTC)
Received: from smtpclient.apple (dhcp-891b.meeting.ietf.org [31.133.137.27]) by zimbrang.isc.org (Postfix) with ESMTPSA id 6977DE64EBD; Tue, 23 Jul 2024 18:22:19 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <SA1PR15MB43707E3420937C7FF9D2CB8CB3A92@SA1PR15MB4370.namprd15.prod.outlook.com>
Date: Tue, 23 Jul 2024 11:22:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3266859-6160-463E-A46F-17471B48AA69@isc.org>
References: <SA1PR15MB43701E583A134C26A410C9A8B3A92@SA1PR15MB4370.namprd15.prod.outlook.com> <273D207B-0990-4323-9FBC-71BB1DBC4DE9@isc.org> <SA1PR15MB43707E3420937C7FF9D2CB8CB3A92@SA1PR15MB4370.namprd15.prod.outlook.com>
To: Ben Schwartz <bemasc@meta.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Message-ID-Hash: YSFVIUPXWRMIIT5QTB6AYC4PKQSPPBCQ
X-Message-ID-Hash: YSFVIUPXWRMIIT5QTB6AYC4PKQSPPBCQ
X-MailFrom: marka@isc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: New Version Notification for draft-andrews-private-ds-digest-types-00.txt
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DfIMuUkwR-9fBzrJ-tGLvXVST5k>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>


> On 23 Jul 2024, at 10:41, Ben Schwartz <bemasc@meta.com> wrote:
> 
> OK, thanks for the explanation.  That helps me understand the scenario where this would be needed, but it seems like simpler solutions are possible.  For example, the resolver could be configured to restrict the use of PRIVATEDNS keys to specific subtrees where their usage is known.

This does not scale.  One could use a private algorithm with billions of zones.

> This draft effectively turns PRIVATEDNS into a general-purpose extension point for _public_ DNSSEC algorithms.  These algorithms could be used interoperably in public, so they would be quite different from normal Private Use range values in an IANA registry.  That's an interesting idea, but it seems like a significant revolution in DNSSEC algorithm registration without an obvious motivation.

You obviously have different ideas about what can and can’t be done with private code points.  There is nothing that states PRIVATEOID and PRIVATEDNS can’t be used over the global internet.  They are designed so that different implementors can avoid collisions by using OIDs and DNS names assigned to the implementor.

I’ve in the past had requests about using BIND to test new algorithms using private code points (yes it was plural).  This testing was abandoned when I pointed out the current flaws in the specification.

Mark

> --BenFrom: Mark Andrews <marka@isc.org>
> Sent: Tuesday, July 23, 2024 12:28 PM
> To: Ben Schwartz <bemasc@meta.com>
> Cc: dnsop <dnsop@ietf.org>
> Subject: Re: [DNSOP] Fwd: New Version Notification for draft-andrews-private-ds-digest-types-00.txt
>  At the moment you can only have one private algorithm per key type world wide. 
> 
> This is all to do with how you prove a zone is to be treated as insecure.   If example.com is using private.example.com and example.net is using private.example.net how done  validator that knows about private.example.com prove that example.net response are to be treated as insecure when there is a DS with PRIVATEDNS returned?  
> -- 
> Mark Andrews
> 
>> On 23 Jul 2024, at 07:46, Ben Schwartz <bemasc@meta.com> wrote:
>> 
>> Two questions I didn't see addressed:
>> 
>> Why would a zone need to be signed with multiple private algorithms?
>> 
>> Why isn't it sufficient to treat all private algorithms as a single algorithm for DS purposes, and distinguish by the Key Tag and/or trial hashing?
>> 
>> --Ben SchwartzFrom: Mark Andrews <marka@isc.org>
>> Sent: Monday, July 22, 2024 1:08 PM
>> To: dnsop <dnsop@ietf.org>
>> Subject: [DNSOP] Fwd: New Version Notification for draft-andrews-private-ds-digest-types-00.txt
>>  This addresses a gap in the DNSSEC specification.  DS records need to identify specific DNSSEC algorithms rather than a set of DNSSEC algorithms.
>> 
>>> Begin forwarded message:
>>> 
>>> From: internet-drafts@ietf.org
>>> Subject: New Version Notification for draft-andrews-private-ds-digest-types-00.txt
>>> Date: 22 July 2024 at 10:05:24 GMT-7
>>> To: "M. Andrews" <marka@isc.org>, "Mark Andrews" <marka@isc.org>
>>> 
>>> A new version of Internet-Draft draft-andrews-private-ds-digest-types-00.txt
>>> has been successfully submitted by Mark Andrews and posted to the
>>> IETF repository.
>>> 
>>> Name:     draft-andrews-private-ds-digest-types
>>> Revision: 00
>>> Title:    Private DS Digest Types
>>> Date:     2024-07-22
>>> Group:    Individual Submission
>>> Pages:    5
>>> URL:      https://www.ietf.org/archive/id/draft-andrews-private-ds-digest-types-00.txt
>>> Status:   https://datatracker.ietf.org/doc/draft-andrews-private-ds-digest-types/
>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-andrews-private-ds-digest-types
>>> 
>>> 
>>> Abstract:
>>> 
>>>   When DS records where defined the ability to fully identify the
>>>   DNSSEC algorithms using PRIVATEDNS and PRIVATEOID was overlooked.
>>> 
>>>   This documents specifies 2 DS Algorithm Types which allow the DNSSEC
>>>   algorithm sub type to be encoded in the DS record.
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org