Re: [dnssd] Secdir last call review of draft-ietf-dnssd-update-lease-07

[Ted Lemon <[e-mail]>]

On Tue, Jun 13, 2023 at 3:07 AM Shivan Sahib via Datatracker <
[e-mail]> wrote:

> Reviewer: Shivan Sahib
> Review result: Has Nits
>
> A few minor issues for the Security Considerations section:
>
> 1. RFC 2119 keywords are used for some but not all bounds mentioned in this
> section. Is there a reason we don't use SHOULD and RECOMMEND for the
> maximum
> acceptable value for the LEASE values?
>

These may vary depending on the application. That would belong in a
specific operational document for a specific set of use cases. We thought
about specifying a limit, but just didn't have a basis for specifying one.
As an example, though, the Thread specification, which is for a particular
use case, specifies a limit of 14 days for the key lease and 7 days for the
lease.

2. It would be useful for the document to also RECOMMEND a minimum interval
> between updates.
>

We do, in Security Considerations.

3. More broadly, ISTM that all the recommended values here (minimum interval
> between updates, lease renewal min and max) should be moved up into the
> main
> content of the document. A too-short lease, for e.g., has implications not
> just
> for security but operation in general.
>

We do recommend a minimum of 1800 seconds in the Requestor Behavior section.


> 4. Is the "public key signing" a reference to SIG(0) [RFC 2931]?
>

Yes. I will add an informative reference—this is rather vague, isn't it?


> 5. Again, the language is in the last para of the Security Considerations
> section around auth strategy is not very strong. Perhaps a reference to RFC
> 3007 would help.
>

The only specific application of update lease is SRP
(draft-ietf-dnssd-srp). SRP specifies exactly one authentication scheme,
FCFS naming, which is referenced in the aforementioned paragraph.
Realistically, that is the only standard application for this that is not
somebody doing something weird on their own. If someone decides to add
another, more general application, then the general advice about DNS updates

Aside from the existing example of SRP, I don't think this request is
actionable. I agree that it's a good idea in principle, but I think it
requires new protocol work for which there is currently no demand. SRP
solves a specific real-world use case, which is why it's being advanced and
nothing else is. I'd love to see a more general solution to this problem,
but right now nobody is asking for it.

>
> 6. "conver" in the last sentence of this section seems like a typo, I'm not
> sure what this sentence means.
>

Typo. This is what the sentence should say:

      An example of a key management strategy can be found in <xref
target="I-D.ietf-dnssd-srp"/>,
      which uses "first come, first-served naming" rather than an explicit
trust establishment process,
      to confer update permission to a set of records.

 Thanks so much for the review. I'm sorry we're not agreeing on every
point, but hopefully the IESG will decide how they feel about this and make
recommendations if they think more work is needed.