Re: [dnssd] Artart last call review of draft-ietf-dnssd-srp-20

[Patrik Fältström <[e-mail]>]

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