Re: [dnssd] Dnsdir telechat review of draft-ietf-dnssd-srp-22

[Ted Lemon <[e-mail]>]

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 <
[e-mail]> 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
>
>
>
>