On Fri, Mar 15, 2024 at 11:56 AM Catherine Meadows via Datatracker < nore...@ietf.org> wrote: > Reviewer: Catherine Meadows > Review result: Has Issues > > I have reviewed draft-ietf-cose-type-header-parameters as part of > the security directorate's ongoing effort to review all IETF > documents being processed by the IESG. These comments were written > primarily for the benefit of the security area directors. Document > editors and WG chairs should treat these comments just like any > other last call comments
Thank you for detailed review Catherine, and apologies for our very belated response. > I do not see any serious problems with this draft. However, there are a number > of minor things that need changing that go beyond nits, so I am rating this as > having issues. > > 1. Comments in the security considerations are all relevant and necessary. My > only suggestion is to mention that it also inherits the security considerations > of 8901, 8078, and 7477. > > 2.All acronyms should be defined, e.g. in a glossary. Yes, I think that's a reasonable suggestion. One other thing I'd like to do is to expand all acronyms and initialisms at first encounter. And where a pre-existing definition exists (e.g. in RFC 8499 "DNS Terminology"), we should reference that. > 3. The terms “parent should be defined. Indeed. And we can refer to the definition in RFC 8499, Section 7, which defines parent, child, and related miscellany. > > 4. The term “trust mechanism” should be defined. I assume that goes beyond > just authenticating a principal but determining that it is authorized to do its > job, but this should be stated clearly. I guess this refers to the following in 4.4: "Establish a trust mechanism between the Multi-Signer group and the Signer". I agree that this is unclear and deserves elaboration. We will add some appropriate text for this. And yes, this is mainly about the zone owner authorizing a signer to be part of a multi-signer group. In the "centralized model", all trust is established by the zone owner, who has authenticated access to the DNS providers, can verify the keying material, and exchange it with the other parties in the multi-signer group (as well as updating the NS set to include the signer's name servers). The decentralized model, where DNS providers directly communicate with each other is not yet fully developed, and has some bootstrapping challenges that we should be clear about in the document. My co-author, Johan Stenstam, actually has a more fully fleshed out proposal for this, so let me have a chat with him and see if we can incorporate that. > > 5. In section 4.2.2 it says > > The minimum DNSKEY Waiting Time is the maximum of all DNSKEYS TTL > values from all signers plus the time it takes to publish the zone > on all secondaries. > > How is the latter computed? Or is the way the it is computed left up to the > implementor? Ok, we'll elaborate on this. For TTLs: In the centralized model, this is straightforward. The zone owner (or a central controller acting on behalf of the zone owner) can easily performs this computation, since it knows when it has updated the DNSKEY RRset at each provider and what their TTLs are. In the distributed model, each signer can note the TTL as the remote ZSKs from other providers are queried and/or imported. (Ideally, the DNSKEY RRset TTLs should be the same across all providers in a multi-signer group, but it's possible that some only support a fixed value, and the protocol should allow that to work with the appropriate timing constraints). For the zone propagation time to all servers: I don't think there is a precise way to calculate this. Rather, I think this it typically based on the expected zone update propagation performance of each provider. Commercial providers often provide SLAs or SLOs providing such numbers. I took a look at past DNSSEC specs that deal with timing issues to see if any of them cover this and they don't appear to. Both RFC 6781 (DNSSEC Operational Practices) and RFC 7583 (DNSSEC Key Rollover Timing Considerations) mention propagation delay many times but neither states how to compute it. > > 6. This is the one I had the most trouble with. 4.9. appears to be saying > that a setup in which different signers use different key algorithms either > MUST NOT be allowed, or SHOULD be allowed, depending on which RFC you read. > But then it says “So a Multi-Signer setup where different signers use different > key algorithms should still validate.” I’m not sure why this conclusion is > made, unless it’s because SHOULD always outranks MUST NOT. But I don’t see > anything in RFC 2119 about that. That should be clarified. Note that this > does not mean I see anything wrong with the reasoning with the rest of 4.9; it > seems reasonable. But it seems to be discussing a scenario that is already > ruled out by the RFCs, and there no instructions for handling this case in the > current draft. This needs be clarified. I understand your confusion. SHOULD definitely does not outrank MUST. The issue is that some folks in the DNS protocol community disagree with what is currently specified as a MUST in this case. In the real world we will come across situations where providers are using disjoint algorithms only and we want the DNSSEC automation mechanisms described in this draft to work for them. In addition to the RFCs quoted, there is also RFC 6781 (DNSSEC Operational Practices) which outlines a "liberal" approach to algorithm rollovers that also arguably clashes with the MUST clause. My personal feeling is that this discussion about what violates the spec but can work in the field belongs in other documents that are attempting to formally revise the spec. This document for now could just state that presently, the signers in a multi-signer group need to all use the same algorithms. If there is a successful update to the spec that (conditionally) relaxes the MUST, we can come back and update this doc. (Just as an aside though, I've personally set up multi-signer zones in the field, where each party signed with a different well known algorithm, and they work fine with all validators I've tested). > Finally, some nits: > > 1. 4.1 number 4: signer or controller, number 4. I think “signer controller” > should be “signer or controller” Yes, thanks. > > Each Signer to be added, including the initial Signer, must meet the > following prerequisites before joining the Multi-Signer Group > 1. A working setup of the zone, including DNSSEC signing. > > If the zone is the zone the Signer is entering, then it can’t be considered an > attribute of the signer. This is confusing and the wording should be changed. I think what this sentence is trying to say is: if a new signer is being added to a multi-signer group for a specific zone, it must first be configured to serve that zone, and the zone needs to be signed with its own keys. Does that make sense? We'll rewrite this section to make that clearer. > > 2. Section 4.9 doesn’t have any content. I'm not sure what was supposed to go there, since timing considerations are present throughout other sections of the doc. Let me check with my co-authors. Otherwise, we can delete the section. > > 3. Security considerations, second paragraph: “steps to allows” should be > “steps to allow” Ok. Thanks! Shumon Huque
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
