For some reason your review didn't show up (and still doesn't) when I search for it. I should just use the datatracker for these searches I guess. I do see some things I'd address in your review if the IESG wants a document update. Since I didn't reply to it earlier, I will do so now. And thank you for doing that review—I know these are significant effort, and I am sorry that I didn't see it earlier!
I would suggest being consistent with the naming, Apple should probably be
referred to as MacOS, iOS (and likely the derivatives like iPadOS etc) or
perhaps:
e.g. Android, Windows, Linux, and Apple based Operating Systems
That's a good point—I hadn't noticed that. I'm not sure this desperately needs to be fixed, but we can discuss it during the RFC editor phase if the IESG doesn't ask for a fix.
Should there be some commentary about preventing a domain/service squatting
type denial of service in the security considerations? or am I just being
overly cynical here?
Sounds like this is covered.
Section 4
TTLs sent in SRP Updates are advisory: they indicate the SRP
requestor's guess as to what a good TTL would be. SRP registrars may
override these TTLs. SRP registrars SHOULD ensure that TTLs are
reasonable: neither too long nor too short. The TTL should never be
longer than the lease time (Section 5.1).
I would suggest a RECOMMENDED TTL or upper and lower bound - otherwise this is
vague. I like how you handled a similar suggestion around leases in section 5.1
which could be applied here, the rest of the section makes a good explanation
to the various tradeoffs which helps bring context.
I would not be averse to updating this text if the IESG thinks it's worth doing. However, I think the last sentence (should never be longer than the lease time) addresses the main concern. Our experience has been that users of SRP choose short leases when they expect the registration to be withdrawn quickly. So if the record expires out of the cache after a maximum of one lease interval after the SRP registration expires, this is probably okay. I actually thought about recommending a TTL of 10% of the lease interval, but that only makes sense if the lease is going to be allowed to expire immediately. Most of the time that's not the situation.
Section 6.1 mentions UDP - but earlier says only TCP in 3.1.3, also 10.4
and 10.5 only reference TCP service entries
We expect that anycast will be used for UDP, but it could be worth explaining this (I thought we had, but it wouldn't surprise me if we never actually did).
There is no matching reference to UDP in 3.1.2 as the reference in 6.1 is to
constrained networks. Maybe a reference to state that UDP is possible in
constrained networks?
It isn't our intention that constrained devices be _required_ to use UDP. It's just available as an option there. In some cases TCP may actually be a better choice. So that's why we don't mention it explicitly.
Also does the smallest possible SRP update fit inside a UDP datagram in the
first place, especially given the use of public keys in updates?
Yes, absolutely. The signature isn't that big, nor is the key, since we're using ECDSA.
Anyway, I'm going to note this reply in the github tracker; if the IESG wants me to do an update to address these points, I will, but since we're past the submission cutoff, and the document is with the IESG for review, I will defer this decision to them.
On Tue, Jul 11, 2023 at 5:42 AM Anthony Somerset via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Anthony Somerset
Review result: Ready
Hello
I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir
Please note that I previously reviewed version 20 of this draft and at that
time stated that the document was "Ready"
I am therefore only reviewing the differences between version 20 and current
version (22)
There are are clear and direct references to various DNS RFC's and this
draft is not in any conflict with the wider DNS space.
All in all I think this is a very well written document, although quite
lengthy and makes lots of references to the appropriate RFC's it is well
understandable and didn't take me too long to get to grips with the context.
All but one of my previous editorial comments still remain except for my notes
on security around domain/service squatting, this particular aspect I believe
has been dealt with excellently with the additional text in 6.1 and I agree
with the authors statements here. As previously noted the other items were more
editorial comments rather than substantive.
The additional sections 8.3 through 8.7 add much better clarity to the specific
considerations around authoritative and recursive servers
Therefore I continue to consider this document as "Ready"
Many Thanks to the authors for this work.
Best Regards
Anthony Somerset
DNS Directorate
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
