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.