On Tue, Jun 13, 2023 at 3:07 AM Shivan Sahib via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Shivan Sahib
Review result: Has Nits
A few minor issues for the Security Considerations section:
1. RFC 2119 keywords are used for some but not all bounds mentioned in this
section. Is there a reason we don't use SHOULD and RECOMMEND for the maximum
acceptable value for the LEASE values?
These may vary depending on the application. That would belong in a specific operational document for a specific set of use cases. We thought about specifying a limit, but just didn't have a basis for specifying one. As an example, though, the Thread specification, which is for a particular use case, specifies a limit of 14 days for the key lease and 7 days for the lease.
2. It would be useful for the document to also RECOMMEND a minimum interval
between updates.
We do, in Security Considerations.
3. More broadly, ISTM that all the recommended values here (minimum interval
between updates, lease renewal min and max) should be moved up into the main
content of the document. A too-short lease, for e.g., has implications not just
for security but operation in general.
We do recommend a minimum of 1800 seconds in the Requestor Behavior section.
4. Is the "public key signing" a reference to SIG(0) [RFC 2931]?
Yes. I will add an informative reference—this is rather vague, isn't it?
5. Again, the language is in the last para of the Security Considerations
section around auth strategy is not very strong. Perhaps a reference to RFC
3007 would help.
The only specific application of update lease is SRP (draft-ietf-dnssd-srp). SRP specifies exactly one authentication scheme, FCFS naming, which is referenced in the aforementioned paragraph. Realistically, that is the only standard application for this that is not somebody doing something weird on their own. If someone decides to add another, more general application, then the general advice about DNS updates
Aside from the existing example of SRP, I don't think this request is actionable. I agree that it's a good idea in principle, but I think it requires new protocol work for which there is currently no demand. SRP solves a specific real-world use case, which is why it's being advanced and nothing else is. I'd love to see a more general solution to this problem, but right now nobody is asking for it.
6. "conver" in the last sentence of this section seems like a typo, I'm not
sure what this sentence means.
Typo. This is what the sentence should say:
which uses "first come, first-served naming" rather than an explicit trust establishment process,
to confer update permission to a set of records.
Thanks so much for the review. I'm sorry we're not agreeing on every point, but hopefully the IESG will decide how they feel about this and make recommendations if they think more work is needed.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
