[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-01.txt

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 18 September 2021 03:34 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 0C6133A24DD for <dnsop@ietfa.amsl.com>; Fri, 17 Sep 2021 20:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IMOUnhVRbSeU for <dnsop@ietfa.amsl.com>; Fri, 17 Sep 2021 20:34:06 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 448803A24DB for <dnsop@ietf.org>; Fri, 17 Sep 2021 20:34:06 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id i25so41411140lfg.6 for <dnsop@ietf.org>; Fri, 17 Sep 2021 20:34:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sL0bs2IIaj7k69Sc+1NAz0MzhBx4kO2tD8ZcwldIlSs=; b=hkXiYGcDHdRhbWzH2IpnXlEBaaiPhDkwPBoMbwUOKAwmlxu8HbXFtEDI5aoiRBne1R OVzmNYP3ElYkMC2KIp7228L+RFD4e/2eh5iFEHIfCSNwUK6WfZztkjbSwZw/9t2GaGLR j0lGsNEjyyX8AR2QNAF2LC5UOjJlw3ljfW3DCo4HG/UIwka2Nfeyy4UbzzyLxI3tS++T T1UWkzGbzINn0qGMqLrwygid8KJ+E/0okt6BHivEGUB1Z5BuliP0f9v0dwFsl7nvX96v 4VvUMISKPiTUFI9LffwsSDjQbm/AqSfERug/P0HhBDidRb9SPZlaU/tR6RNA+c02C7HM Ek3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sL0bs2IIaj7k69Sc+1NAz0MzhBx4kO2tD8ZcwldIlSs=; b=l2jtrHMXCoomAEkuVlmYySTLvU7znVYJH7+jjbddD2LdlJmhqNRAQH/9tvo8Awe2zw D0jAj62BGXq98PG+pN4uknghbNaTb6APT+hTA+/cO0669mw2Tic7SMJmimJP2aCBh+0j 3sDeKxA4OArbzijEatx1R1ieIq7EtUkMxEiPrxBo5LuMQeCGoTWCxpp5oa1RONFD/3Sn n/tmzJBAFzNHWEXFcM+STNnCcy3ML4Z/CSMf878zFgV5m42Mcikl8MCXEBVtBiOrYES7 JPTxKwrUHAWyMiHueddduLLWgSmf10TLgCJP3oTYAK88bL8cPBDS3Yqaxu7uQ93D6QGw rKfA==
X-Gm-Message-State: AOAM532lcOtxGYnhponzPNhjYtLfz+WFsKdQIOJr0qZumyfN14quj5rR W8AqwseYG7TAWbxaUcbCAr0OjLx6FAy50VUOBCEdZzGw
X-Google-Smtp-Source: ABdhPJz9CsICV61bR67uQiLdLWMcG8MEvv4yBZExgbk7EkuqlBsL0d7f8SJxwEJi2SHeAfQbMAnJtZapjzBVmjb5Abo=
X-Received: by 2002:a2e:a884:: with SMTP id m4mr3444651ljq.318.1631936043329; Fri, 17 Sep 2021 20:34:03 -0700 (PDT)
MIME-Version: 1.0
References: <163186735118.22899.12008358276068718959@ietfa.amsl.com>
In-Reply-To: <163186735118.22899.12008358276068718959@ietfa.amsl.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 17 Sep 2021 20:33:51 -0700
Message-ID: <CAH1iCiokZf8J4R3XAf7s1J2dopyCfH8L=Pxq_fvqEJFp9-HQWQ@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000028ac4b05cc3cb826"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bm313MHagLiLSA-riQ3unRrDRF0>
Subject: [DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-01.txt
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: Sat, 18 Sep 2021 03:34:11 -0000

Hi, DNSOP folks,
I have been working on the "unsigned NS record" problem (and related
"unsigned glue record" problem).

I think this is relatively widely applicable, even though it was originally
motivated by a problem that needed to be solved within DPRIVE.
(That problem is the subject of a draft I will be posting in DPRIVE, for
those interested.)

I think it's fairly straightforward, but it is difficult to tell without
getting feedback, so please let me know what you think.

Brian Dickson

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Fri, Sep 17, 2021 at 1:29 AM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-01.txt
To: Brian Dickson <brian.peter.dickson@gmail.com>



A new version of I-D, draft-dickson-dnsop-ds-hack-01.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:           draft-dickson-dnsop-ds-hack
Revision:       01
Title:          DS Algorithms for Securing NS and Glue
Document date:  2021-09-17
Group:          Individual Submission
Pages:          6
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-01.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-ds-hack-01

Abstract:
   This Internet Draft proposes a mechanism to encode relevant data for
   NS records on the parental side of a zone cut by encoding them in DS
   records based on a new DNSKEY algorithm.

   Since DS records are signed by the parent, this creates a method for
   validation of the otherwise unsigned delegation records.

   Notably, support for updating DS records in a parent zone is already
   present (by necessity) in the Registry-Registrar-Registrant (RRR)
   provisioning system, EPP.  Thus, no changes to the EPP protocol are
   needed, and no changes to registry database or publication systems
   upstream of the DNS zones published by top level domains (TLDs).

   This NS validation mechanism is beneficial if the name server _names_
   need to be validated prior to use.




The IETF Secretariat