Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-multi-provider-dnssec-04: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document; it's pretty clear and it's good to have these procedures written down in a well-thought-out manner. Section 3 o It may also be the case that a resolver is unable to provide an authenticated response because it gave up after a certain number of retries or a certain amount of delay. Or that downstream clients of the resolver that originated the query timed out waiting for a response. nit: sentence fragment. Section 5 Since authenticated denial responses are self-contained, NSEC and NSEC3 can be used by different providers to serve the same zone. Doing so however defeats the protection against zone enumeration provided by NSEC3. A better configuration involves multiple It might be worth a few more words about why this defeats the protection against zone enumeration. Section 6.1, 6.2 Should we say anything about when it's safe for a new ZSK to be used to sign responses? Section 8 nit: s/CDNS/CDS/ Also, this section feels a bit sparse compared to 6.1 and 6.2. Section 9 In model 2, once initially bootstrapped with each others zone signing keys via these API mechanisms, providers could, if desired, periodically query each others DNSKEY RRsets and automatically import or withdraw ZSKs in the keyset as key rollover events happen. What kind of authentication would be needed for this provider-to-provider API access? Section 10 Shouldn't we have references for DoT and DoH? Section 12 I think both import and export need to be strongly authenticated, though the DNSSEC itself can provide for authentication of export in most (all?) cases. If (e.g.) the zone owner fetches bad data and then strongly authenticates to shove that bad data into the other services, you still end up with bad data in use. (Also, integrity protection, though I expect this is implicit.) This is the sort of operation that I'd want to have multi-factor authentication for, too. Section 14.1 RFCs 2136, 5731 don't currently seem to be cited in a manner that requires a normative reference. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
