Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-domain-verification-techniques-02

[Shivan Kaul Sahib <[e-mail]>]

Hi Jim, thanks for the review, but it looks like you reviewed an older
version of the draft, not -02.

-02 addresses a lot of the feedback you have:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-02

On Wed, 12 Jul 2023 at 17:48, Jim Reid via Datatracker <[e-mail]>
wrote:

> Reviewer: Jim Reid
> Review result: Not Ready
>
> Since this I-D was submitted for early dnsdir review, the draft is
> essentially a work in progress and much remains to be done.
>
> I doubt this I-D will be a valuable addition to the DNS oeuvre that
> merits WG attention. As written, it's a mixture of implementation
> guidelines and a survey of current approaches to domain verification
> techniques. These might be better as discrete documents on the ISE
> track. However the I-D has been adopted by the WG. It's not adding or
> changing the core protocol and therefore won't be a burden to the DNS
> Camel.
>
> There are quite a few gaps that need to be filled. Which is to be
> expoected in early versions of a draft.
>
> There isn't a clear enough problem statement or use case: what
> problems does this I-D solve and how does it do that?
>

In -02, there's a Common Pitfalls section pretty early on that outlines the
issues we've seen running DNS operations which motivates this document.


>
> The I-D is unclear about the roles and responsibilities commonly found
> in today's DNS where the domain name holder is not the controller or
> administrator for the domain and neither provides authoritative DNS
> service for it. How could/should domain verification work in these
> settings?
>

In -02, we have sections on delegated domain control validation, and
described it in a fair bit of detail. Beyond that, I don't think the
outsourcing of the record management causes the draft's recommendations to
not apply.


>
> The doc could be clearer on the semantics of these validation domain
> RRs. ie Their presence only proves who had control of the domain when
> these RRs were added or removed, not who holds the domain name or is
> ultimately responsible for it. This is important, especially when so
> many aspects of DNS operations are outsourced these days.
>

In -02, we have a section on optional metadata that could provide context
on the RR. In practice we haven't seen either a demand or example of folks
putting point-in-time domain ownership data in the RR.


>
> Section 1 describes how domain verification is performed today but
> doesn't explain why. Or discuss the strengths and weaknesses of this
> approach. Could non DNS-based approaches - some out of band method -
> work or not? Are there scenarios where these could be better than
> using something stored in the DNS? Or does the DNS-based approach
> obliterate these?
>

In -02, Section 3 talks about why. We define non-DNS methods to be out of
scope.


>
> A definition for the counterpart of Provider is missing. Client
> perhaps?
>

We don't use the word Client in the document; we say user. We can add a
definition for the user to be "entity trying to avail of a Provider's
services" but didn't feel like it added much. If it would be helpful I can
add text for that in Section 2 around that.


>
> Several Sections are missing. The I-D jumps directly from Definitions
> to Recommendations! The authors need to show their working. In
> detail. ;-) This should include details of which approaches were
> considered and their advantages and disadvantages. There needs to be
> an explanation why TXT records are RECOMMENDED and, by implication,
> why other RRTypes are not. CERT records for instance could be a valid
> alternative that offer additional security features. Section 3.2
> explains (somewhat clunkily) why CNAMEs are unsuitable. But that's
> only a small part of the story.
>

We got the advice to not bury the lede, and that's what we did. This is a
BCP document, and we've laid out the advice upfront, and provided hopefully
detailed text on why those choices are made. The Appendix describes the
survey of existing techniques and why they do or don't work.


>
> A Section on procedural/process issues is needed: how the Provider and
> Client synchronise their updates, how this gets agreed and documented,
> when/how validation domain names get added or removed, max/min TTL
> values, problem escalation considerations, etc.
>
> The discussion of the TXT record in Section 3.1 is defective. The
> validation domain name probably needs to have a unique owner-name as
> well as some unique token in the RDATA. There's no explanation or
> justification for using a random token with at least 128 bits of
> entropy. Why not 256 or 64 (say)? A small number of entropy bits could
> be "good enough", for instance when the validation RRtype is
> short-lived or only used once. Similar issues arise from mandating
> SHA-256. One day that algorithm will be deprecated => updating this
> prospective RFC. A "strong" hash algorithm isn't always necessary
> either. That's also holds for RFC4086's randomness requirements.
> Should the validation domain name include a timestamp to
> detect/prevent replay attacks?


> If these parameters are to be requirements and/or mandatory to
> implement, the rationale for their adoption needs to be given.
>
> Is this part of the I-D documenting one provider's approach? Should it
> be defining a generalised, interoperable solution?
>

There's no Section 3.1 in the current draft version, but I think you mean
5.1. In general though, this is a BCP document, not a new protocol. We've
largely taken ACME's approach and recommended that, and given
considerations for enhancements or alternative approaches.


>
> The last paragraph of 3.1 is in the wrong place. It belongs in a
> section on implementation considerations. Some of the text is
> fluffy. What would "offer detailed help pages that are accessible
> without needing a login on the provider website" look like in
> practice? What content should be in the detailed help pages? The
> sentence beginning "Similarly, for clarity," is confusing. Who is
> expected to provide the full DNS record? How? And in what format?


> The Security Considerations Section needs a lot more work. It should
> document the threat model which outlines roles and responsibilities as
> well as potential attack vectors and how to mitigate them. These would
> include MitM attacks, spoofing, (D)DoS, Client-side or Provider-side
> bad actors, poorly chosen TTL values, replay attacks, securing the
> Client-Provider channel(s), etc.
>

There was a security review done, and we've incorporated those suggestions.
Looking for specific text that would help, but not sure how to make further
changes.


>
> Appendix A is an excellent idea and much appreciated. Some of tha
> material needs to go elswhere in the document though. A 1.3 and A1.4
> should be in the main body of the I-D. It should not be in an appendix
> which describes the domain verification techniques used by significant
> Providers. The discussion of fragmentation also needs to move from
> Appendix A. It should explain that using discrete owner-names for each
> validation domain RR would avoid fragmentation concerns. Guidance on
> the size of validation domain RRs - ie TXT records - and any
> accompanying DNSSEC-related RRtypes might also help here.
>
>
> Minor but annoying nits:
>
> It's domain name holder, not domain name owner.
>
> Standards documents shouldn't use personal pronouns: tThe "you"s in
> Appendix A.
>
>