Hi Ted
No problem at all
I am totally fine with your commentary as well, it makes sense to let IESG determine if these are big enough molehills to squash at this late stage – I don’t believe they are truly
substantive issues, It’s more wordsmith stuff really
Thanks
Anthony
Internal All Employees
From: Ted Lemon <mellon@xxxxxxxxx>
Date: Tuesday, 11 July 2023 at 14:44
To: Anthony Somerset <Anthony.Somerset@xxxxxxxxxxx>
Cc: dnsdir@xxxxxxxx <dnsdir@xxxxxxxx>, dnssd@xxxxxxxx <dnssd@xxxxxxxx>, draft-ietf-dnssd-srp.all@xxxxxxxx <draft-ietf-dnssd-srp.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Re: Dnsdir telechat review of draft-ietf-dnssd-srp-22
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
This email disclaimer applies to the original email, all attachments and any subsequent emails sent by Liquid Telecom. This email contains valuable business information that is privileged, confidential
and/or otherwise protected from disclosure, intended only for the named person or entity to which it is addressed. If you are not the intended recipient of this email and you received this e-mail in error, any review, use, dissemination, distribution, printing
or copying of this e-mail is strictly prohibited and may be unlawful and/or an infringement of copyright. Please notify us immediately of the error and permanently delete the email from your system, retaining no copies in any media. No employee or agent is
authorized to conclude any binding agreement on behalf of Liquid Telecom with another party or give any warranty by email without the express written confirmation by an authorized representative or a director of Liquid Telecom. Nothing in this email shall
be construed as a legally binding agreement or warranty or an offer to contract. Liquid Telecom will not be responsible for any damages suffered by the recipient as a result of the recipient not taking cognizance of this principle. Liquid Telecom accepts no
liability of whatever nature for any loss, liability, damage or expense resulting directly or indirectly from the access of any files which are attached to this message. Any email addressed to Liquid Telecom shall only be deemed to have been received once
receipt is confirmed by Liquid Telecom orally or in writing. An automated acknowledgment of receipt will not suffice as proof of receipt by the Liquid Telecom. This email disclaimer shall be governed by the laws of South Africa.
|
