Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-dns-catalog-zones-08
Willem Toorop <willem@nlnetlabs.nl> Tue, 07 February 2023 14:58 UTC
Return-Path: <willem@nlnetlabs.nl>
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 3FE4DC14EAA3 for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2023 06:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 2pMrc-w39_ju for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2023 06:57:57 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 CFD46C15152F for <dnsop@ietf.org>; Tue, 7 Feb 2023 06:57:34 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id i38so4824860eda.1 for <dnsop@ietf.org>; Tue, 07 Feb 2023 06:57:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nlnetlabs.nl; s=google; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=sLb9Z59mrReEybyIZk5vQtXN3owilPoqPno6dJTpQ6o=; b=IaEhyS6nTntT6PjCWllWBQ+XvjmJMQZEkrTbl++bnRGy2fSDnqLuLMuoFpwhLUOnIx +W7nDYFcMg02w8Bk2885JP+J6lG6v/mtCOvlIPyLVoDDy/Y48wWika128CasF+9ZqCnm D1Ff1mHTbW7lUuH9uxISk9JfF+EveLTVEEODtiln543V5lJ+AeJbbHprq2/hYYfL8fwA 3n0mnoWEiUutInGrLTRPzFxgOvdcd4XqvCTpZ38wZmHbKvI5WGdptEEmS+vpeCsjqW/p 7ya/nm4/sBai4B7qJbj2qVu/Vhsxb+kEiqdOpec4hDi/UoyVo2MxWq0VZnH9i1g3DRjG 1tTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sLb9Z59mrReEybyIZk5vQtXN3owilPoqPno6dJTpQ6o=; b=FOwOGmK0ZkhJER0FZHwnPvgG/4wMcQO9zCunH+NCNCggmAFatvpekYWLj5gGV3B9EN L5GnwBlxIm5wz8YK+adfUphILN+h/pklIoeHCr4NOoJJtsIDTVDIEoXBVFtqOK/SUbOv UgltdfsHFGWjUKhGknHiYdb5siHbxtHGdnsdfO65F8ivVm8m95VcVXr+xo4F6TqNWdcD fwZelFGPjw4ismkdZkt/Kf/7zUelcT+SEG4ne35NLvhSocUVrmebadnD84+Ueum4c6TV CDam8RhBgEwGnSswlipb5smMhFNHeDPOR7wiWwr9zMidghD0rzTn5cZnSn2D2wzqg8uT Dbvg==
X-Gm-Message-State: AO0yUKW1rCiHFIOPVPKqRhiT6LZrDDRUOCkJs9Cx1vDLiaPZbbYw49sl +lfO+WDIhakrfHbdkGZCWynVlA==
X-Google-Smtp-Source: AK7set+LaA9trgOQ7UNtq0WsP8VganoI3K35g8WFdmb7o5ut9qDsIbrO5z1VdrCqRQaMTsWoD0aKgg==
X-Received: by 2002:a50:a44d:0:b0:4aa:b7ac:e0d2 with SMTP id v13-20020a50a44d000000b004aab7ace0d2mr3689458edb.19.1675781852685; Tue, 07 Feb 2023 06:57:32 -0800 (PST)
Received: from ?IPV6:2a10:3781:2851:0:7c9b:23a5:63ef:7817? ([2a10:3781:2851:0:7c9b:23a5:63ef:7817]) by smtp.gmail.com with ESMTPSA id fg10-20020a056402548a00b004a23558f01fsm6513174edb.43.2023.02.07.06.57.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Feb 2023 06:57:32 -0800 (PST)
Message-ID: <66451e48-b086-c066-9c3e-c533f1ebb053@nlnetlabs.nl>
Date: Tue, 07 Feb 2023 15:57:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1
Content-Language: en-US
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>, secdir@ietf.org
Cc: dnsop@ietf.org, draft-ietf-dnsop-dns-catalog-zones.all@ietf.org, last-call@ietf.org
References: <167062427925.29819.15071045544946491563@ietfa.amsl.com>
From: Willem Toorop <willem@nlnetlabs.nl>
In-Reply-To: <167062427925.29819.15071045544946491563@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/E-LIuUEWdCstoB6IDNiSo0SgIEY>
Subject: Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-dns-catalog-zones-08
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 07 Feb 2023 14:58:01 -0000
Hi Catherine, Op 09-12-2022 om 23:17 schreef Catherine Meadows via Datatracker: > The security considerations section gives a number of reasonable authentication > and privacy requirements, but does stops short of the use of the word MUST. Is > MUST avoided because it is not yet practical? We think that the precise privacy and security requirements are very diverse for the variety of different deployments currently and in the future. Some zones and list of zones may have the requirement to be published publicly without authentication (such as the zones managed by IANA). We don't want to rule anything out. Therefore we deemed it unpractical to have hard MUST requirements. Instead, we've tried to enumerate all the considerations (and measures) as completely as we could. Also, regular zone transfers (RFC5936) don't currently have MUST requirements w.r.t. authentication or encryption. Encrypted zone transfers (RFC9103) MUST be authenticated though. We did fortify the requirements a little bit by changing that "consumer(s) SHOULD scope the set of admissible member zones" instead of "MAY". > Nits: There are a lot of unexplained acronyms, especially at the beginning: > RR, SOA, NS RR, RDATA, PTR, and so on. These should be spelled out the first > time they are used at the document. It would also help to have the more > important ones described in more detail in the terminology section. This has been addressed in version -09 by adding the text that was suggested by Joe Abley: "This document makes use of terminology that is specific to the DNS, such as for transfer mechanisms (AXFR, IXFR), for record types (SOA, NS, PTR), and other technical terms (such as RDATA). Since these terms have specific meanings in the DNS they are not expanded at first use in this document. For definitions of those and other terms, see [RFC8499]." Thank you for your review and kind regards, Willem Toorop on behalf of the draft-ietf-dnsop-dns-catalog-zones co-authors.
- [DNSOP] Secdir last call review of draft-ietf-dns… Catherine Meadows via Datatracker
- Re: [DNSOP] Secdir last call review of draft-ietf… Joe Abley
- Re: [DNSOP] Secdir last call review of draft-ietf… Paul Vixie
- Re: [DNSOP] Secdir last call review of draft-ietf… Joe Abley
- Re: [DNSOP] Secdir last call review of draft-ietf… Meadows, Catherine CIV USN NRL (5543) Washington DC (USA)
- Re: [DNSOP] Secdir last call review of draft-ietf… Willem Toorop