Joey, thanks for the review!
On Mon, Jun 12, 2023 at 2:21 PM Joey Salazar via Datatracker <noreply@xxxxxxxx> wrote:
Minor Concerns: 1
6. Security Considerations
Although the method described in the '3.3.3. FCFS Name And Signature
Validation' section seems a good improvement over mDNS security, I
second what Anthony Somerset highlighted in the dnsdir review; that
some text would be welcome about a domain/service potentially denying
naming to other domains/services by "squatting".
I'm addressing this by adding the following text:
discovery. This does not prevent registering names as mentioned above, but does ensure that genuinely important names
are not accidentally reserved for SRP clients. So for example, the zone "dnssd.example.com" could be used instead of
"example.com" for SRP updates. Because of the way that DNS browsing domains are discovered, there is no need for the
DNSSD discovery zone that is updated by SRP to have a user-friendly or important-sounding name.</li>
<li>Configure a dictionary of names that are prohibited. Dictionaries of common obscene and offensive names are no doubt
available, and can be augmented with a list of typical "special" names like "www", "mail", "smtp" and so on. Lists of
names are generally available, or can be constructed manually.</li>
Nits:
Section 3.1.1 Full-featured Hosts
Since a default registration domain is a requirement for the Service
Registration protocol to be discoverable on the local network using the
mechanism in the draft, perhaps normative language is needed, i.e
Full-featured hosts MUST be either configured manually with a registration
domain, or capable of discovering the default registration domain as
described in Section 11 of [RFC6763].
It was not our intention to set normative requirements that hosts implement this protocol, which I think is what you are suggesting. To say that "hosts that want to do this protocol must ..." is interesting, but out of scope for this document. This document is just intended to describe how a requestor communicates with a registrar. There can be a variety of ways that a registrar is discovered, and we elected not to specify that in this document. At this point I think a change like this would be inappropriate.
3.1.2. Constrained Hosts
"It is the responsibility of a Constrained-Node Network supporting SRP to
provide one or more SRP registrar addresses. It is the
responsibility of the SRP registrar supporting a Constrained-Node
Network to handle the updates appropriately."
Similar to the observation for the previous section, stronger language is
recommended here for setting clearer expectations of Constrained Hosts and
the SRP registrar supporting them. s/updates may be accepted/updates MAY be
accepted/ s/may be rewritten/MAY be rewritten/
Same comment.
3.2.1. What to publish
Text seems to be missing in
"For any Service Instance Name ([RFC6763], Section 4.1), an SRV RR,
one or more TXT RRs, and a KEY RR."
s/In principle Service/In principle, Service/
Similar to the wording in 3.3.2. Valid SRP Update Requirements, I would
suggest s/There is never more than one hostname in a single SRP update./Each
SRP update MUST contain one single hostname./
This is talking about a service instance entry, not a host entry. There are no hostnames in a service instance entry, although a service instance name is a domain name. It's perfectly permissible for there to be more than one service instance per SRP update, so this requirement doesn't apply here.
3.2.4. How to secure it
s/what we describe here/the FCFS Naming method we propose/
Text seems to be missing in "The goal
is not to provide the level of security of a network managed by a
skilled operator."
Good point. I changed the second "what we describe here" to "FCFC naming", which I think reads better than the original text. I don't think we need to say "we propose" because that's fairly clear from the context. :)
I just deleted the sentence after that. I don't think it makes things clearer, and it's sufficiently inaccurate that I agree with you that it would need to be changed to be more clear. When this was originally written, our mental model of when key management could be done was quite different than it is now.
3.3.2. Valid SRP Update Requirements
The sentence "An SRP registrar MAY either
process such messages are either processed as regular RFC2136
updates" seems unclear.
There was some extra text there that I deleted. The sentence now reads:
process such messages as regular RFC2136 updates, including access control checks and constraint
checks, if supported, or MAY reject them with Refused RCODE.
6. Security Considerations
s/credentials to to update/credentials to update/
Done.
Other than these, I found the document easy to read and to follow, with good
use of highlights of related protocols and RFCs. Thank you for your work on
this draft.
Thanks again. I'll try to update this document later this afternoon with your changes. Please let me know if any of the above fixes doesn't adequately address your concerns!
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
