Thanks for persisting. I think you make some good points. I don't think we can address them in this document (the working group did a /lot/ of work to make sure that all of the sections on constraints and so forth are mutually consistent and complete, and that's part of why it seems bigger than it should be—the original spec was indeed smaller, but also had a lot of gaps where implementors could get confused). I've added the following text which I think addresses the problem of not having a good introduction (it'll be in the introduction). This somewhat reiterates language elsewhere in the document, but as you say, having it in the introduction would make the reader's life a lot easier.
<t>
It is important to understand that "authenticate" here just means that we can tell that an update came from the same source
as the original registration. We have not established trust. This has important implications for what we can and can't do
with data the client sends us. You will notice as you read this document that we only support adding a very restricted set
of records, and the content of those records is further constrained.</t>
<t>
The reason for this is precisely that we have not established trust. So we can only publish information that we feel safe in
publishing even though we do not have any basis for trusting the requestor. We reason that mDNS <xref target="RFC6762"/>
allows arbitrary hosts on a single IP link to advertise services <xref target="RFC6763"/>, relying on whatever service is
advertised to provide authentication.</t>
<t>
This is considered reasonably safe because it requires physical presence on the network in order to advertise. An off-network
mDNS attack is simply not possible. Our goal with this specification is to impose similar constraints. Because of this you will
see in <xref target="add_validation"/> that a very restricted set of records with a very restricted set of relationships are
allowed. You will also see in <xref target="source_validation"/> that we give advice on how to prevent off-network attacks.</t>
<t>
This leads us to the disappointing observation that this protocol is not a mechanism for adding arbitrary information to
DNS zones. We have not evaluated the security properties of adding, for example, an SOA record, an MX record, or a CNAME
record, and so these are forbidden. A future protocol specification might include analyses for other records, and extend
the set of records that can be registered here. Or it might require establishment of trust, and add an authorization model
to the authentication model we now have. But this is work for a future document.</t>
It is important to understand that "authenticate" here just means that we can tell that an update came from the same source
as the original registration. We have not established trust. This has important implications for what we can and can't do
with data the client sends us. You will notice as you read this document that we only support adding a very restricted set
of records, and the content of those records is further constrained.</t>
<t>
The reason for this is precisely that we have not established trust. So we can only publish information that we feel safe in
publishing even though we do not have any basis for trusting the requestor. We reason that mDNS <xref target="RFC6762"/>
allows arbitrary hosts on a single IP link to advertise services <xref target="RFC6763"/>, relying on whatever service is
advertised to provide authentication.</t>
<t>
This is considered reasonably safe because it requires physical presence on the network in order to advertise. An off-network
mDNS attack is simply not possible. Our goal with this specification is to impose similar constraints. Because of this you will
see in <xref target="add_validation"/> that a very restricted set of records with a very restricted set of relationships are
allowed. You will also see in <xref target="source_validation"/> that we give advice on how to prevent off-network attacks.</t>
<t>
This leads us to the disappointing observation that this protocol is not a mechanism for adding arbitrary information to
DNS zones. We have not evaluated the security properties of adding, for example, an SOA record, an MX record, or a CNAME
record, and so these are forbidden. A future protocol specification might include analyses for other records, and extend
the set of records that can be registered here. Or it might require establishment of trust, and add an authorization model
to the authentication model we now have. But this is work for a future document.</t>
On Sat, Jul 8, 2023 at 6:41 AM Patrik Fältström <paf@xxxxxxxxxx> wrote:
On 7 Jul 2023, at 20:41, Ted Lemon wrote:
>> I presume the choice will be SRP although there are many acronym
>> collisions...?
>
> This isn't even an RFC. I don't think we have a problem here. It's really DNSSD SRP, but we don't need to say that every time. :)
Ok, I just wanted to let you know.
>> In section 3.2.1 there is some text that talks about what RR types that are
>> supported. At least for me the text ends up being a bit unclear on whether
>> it
>> describes what is implemented, or what is required by entities being in
>> accordance with this specification. As specified in many DNS related RFCs,
>> protocols should allow any RR Type be used, and limiting protocols to some
>> is
>> by experience a bad thing. For example all crazy use of TXT records because
>> implementations do not handle RR Types properly.
>
> This is specifically for DNSSD, so we tried to keep it simple. DNSSD uses PTR, TXT, SRV and A/AAAA in very specific ways. The working group explicitly chose not to make this more general. That's what RFC2136 is for.
Let me then suggest you say this in the document. The mechanism can indeed be generic and I am allergic to DNS related things not being able to handle "any RR Type". See the toxic discussions on TXT compared with new RR Types, and ultimately the bad use of TXT that we see in so many cases where specific RR Types should have been used instead.
>> This spec should be about how things according to this spec should work.
>> Maybe
>> it is also explaining differences from other protocols, but it should not
>> explain on what and how this is *not* doing things. Makes it harder to
>> implement.
>
> You're misunderstanding the purpose of this section. The goal of SRP is to provide a very constrained update mechanism for DNS specifically to support DNSSD, and the reason for all this "it is NOT an SRP update" is so the implementor knows what updates it can treat as SRP updates (and do FCFS with) and what updates it can't. So this text is exactly as intended, and your proposed changes would essentially break the specification.
Ok, I get that part, but I still feel this document is explaining too much what one should NOT do instead of explaining what one CAN do, and how it SHOULD be done.
>> In section 3.2.4 there is a claim "This model does not work for automatic
>> service registration.". I do not understand why it is not. I can guess it
>> is
>> "impractical" as there must be a shared secret deployed and various other
>> things, which implies the zero-conf piece of service registration is
>> messy, but
>> "...does not work..."?
>
> This is what we intended to say. It does not work for this use case. I don't think there's any controversy about that.
I disagree with the claim that it "does not work". It definitely does. It might be "impractical", but claiming it "does not work" I think is wrong.
>> I also think wording in section 1 (related to 3.2.4) is unfortunate. It
>> says in
>> sixth paragraph "to authenticate both the initial claim and subsequent
>> updates". I do not think it is authenticating the initial claim. It is
>> using
>> the FCFS security model together with (section 6.1), if TCP is used,
>> inability
>> to inject registrations from outside network locations.
>
> So the objection is the use of the term "authentication?"
Yes
> The sense in which it authenticates the update is precisely that we know that the update came from the same host that sent the initial registration. It's true that the initial update is not authenticated, and I don't think the document claims otherwise, so I don't see what change I could make here other than to add more text to clarify something I think is already pretty clear.
I think you can say what you wrote here (which I also discovered), that "After use of the initial FCFS security model, authentication is done by ensuring the same host is doing updates that did the original FCFS registration". Or something like that.
>> In section 3.2.4 there is a statement "The goal is not to provide the
>> level of
>> security of a network managed by a skilled operator." which honestly I do
>> not
>> understand what it means and why it is in this text.
>
> You're the third person to mention this sentence, which I agree is pretty confusing and also useless, so it's been removed. :)
:-)
>> In section 3.2.5.3 there is a time constraint of lease time of 14 days
>> that is
>> "typical" but it can be chosen to something else. As this is a choice that
>> might impact the security (and reuse of the same name) my question is
>> whether
>> it is not for security reasons necessary to say it MUST be higher than a
>> certain lowest value.
>
> No, I don't think so. Although we do suggest in the update-lease document that values lower than 30s are a bad idea for performance/DoS reasons.
Ok, fair.
>> In section 6.3 a reference is made to RFC8624. Should be to RFC9157.
>
> Thanks for noticing that. I added this reference before 9157 was published and didn't notice the update.
Ok, such things happens all the time... ;-)
>> In 3.2.5.4 there is a claim that compression saves "substantial space".
>> Although it might do, I think this specification should stay at saying
>> "compression MUST be supported".
>
> Yeah, that wording is pretty optimistic, isn't it? I changed it as follows:
>
> Compression of the
> target can save space in the SRP Update, so we want clients to be able
> to assume that the SRP server will handle
> this. Therefore SRP registrars MUST support compression of SRV RR
> targets.
Excellent, thanks!
>> In 3.3.1.3 it is stated that some A or AAAA records can be ignored by the
>> server. I think it would be more proper to say that the server can ignore
>> ANY
>> request due to contents of the update request be "weird".
>
> I don't know what specific advice we'd give here, and I'd rather not say something this vague.
>
> In section 4 about TTLs it is said the request TTL should only be advisory.
Hmm....I at least read it as an advice to be able to ignore A or AAAA records:
> A and/or AAAA records that are not of of sufficient scope to be validly published in a DNS zone can be ignored by the SRP server, which could result in a host description effectively containing zero reachable addresses even when it contains one or more addresses.
What I am saying is that I feel a better text could be:
> Resource records, for example A and/or AAAA records, that are not of of sufficient scope to be validly published in a DNS zone can be ignored by the SRP server, which could result in a host description effectively containing zero reachable addresses even when it contains one or more addresses.
>> I
>> understand why the SRP registrar might believe the TTL is too short, but
>> that
>> should be flagged in the response. A client must according to my view be
>> able
>> to request something short so that the client can honor the use of the
>> service
>> for the protected time period.
>>
>
> This is the wrong model for what we're doing here. If this were a general DNS protocol, that might make sense, but the goal here isn't to provide a general mechanism for updating DNS zones. It's to provide a replacement for mDNS using DNS.
Fair, I do though see this as unfortunate ;-) I like what you have written here.
> In that context, the client's preference can only ever be advisory. If the client wants a service to only be valid for a short time, it can use a short lease, and in fact that is the current practice. A short TTL would not actually accomplish this, if the zone weren't updated to withdraw the service.
>
> Anyway, I've updated the document as best I can to address your suggestions. Sorry about my lack of cooperation on the ones that I don't think should be changed!
Thanks!
Patrik
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
