On Mon, 29 Jul 2024, Jim Reid via Datatracker wrote:
Proposed changes below are part of:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/146
draft-ietf-dnsop-domain-verification-techniques-05
Reviewer: Jim Reid
Review result: Not Ready
I am disappointed that many of my earlier review comments have not
been addressed and the authors have not explained why.
I would have to check if my co-authors provided any answers. I don't
remember seeing your email. We worked mostly on github, and I personally
tend to check the directorate reviews at IESG eval time. Sorry we missed
your previous review.
doc says "Other techniques such as email or HTTP(S) based validation are
out-of-scope." Why?
Because this document is specifically for "domain verification
techniques that use DNS". This is not an ACME document.
acme seems to be a better solution. ID needs to explain why it's unsuitable.
ACME is a specific instance of "need to verify domain", namely "need to
verify a domain to issue a certificate". ACME has different methods for
such verification, only one of them being DNS. Another being HTTP.
Our draft is more generic, and in fact the update draft to ACME cites
our draft for justification.
don't like "domain owner" throughout the doc, even if it is imported from
RFC9499
It was specifically requested by DNSOP WG consensus.
CNAMEs can exist with DNSSEC rrtypes
The text was talking about "other data", which didn't really consider
RRSIG/NSEC*. I've changed it to:
"CNAME records cannot co-exist with other (non-DNSSEC) records"
"issuance" is icky to a native English speaker
I believe that is the common terminology for certificates as well. Do
you have an alternative?
4. Perhaps wait for completion of ACME-SCOPED-CHALLENGE work?
Do you mean for content or for MISREF? The latter would happen
automatically by the RFC Editor. For the former, we have talked to
ACME and will continue to do so to ensure the documents are in sync.
5.1 Discourage CNAME chaining: it's ugly and unreliable
I agree it is ugly and unreliable, but when various parties point to
each other for things using CNAMEs, it can happen that a party CNAMEs
their data as well. The document is descriptive that this can happen
and does not promote or condone this practise.
5.1 why 128 bits? Why not 129?
Because standards tend to talk about only a few levels of security.
For example https://csrc.nist.gov/glossary/term/security_strength
And 128 is often used as a lower boundary for security reasons. You
do not want to build for example the authoritaztion of a domain that
authenticates its users using 128bit security, using a lower group
of security such as (112).
5.1 base32, base16 or hex16. Pick one. Pretty please.
Why? The main point I think there is not to use bas64 due to its
case-sensitive nature unsuitable for DNS. Otherwise, I see no reason
to limit the recommendations of encoding. Whatever the application
builder feels is more appropriate for them is fine ?
5.1 _<PROVIDER_RELEVANT_NAME>-challenge could be too long for a label
is -challenge necessary? ditto -wildcard, -host -domain
Maybe use subdomains of PROVIDER_RELEVANT_NAME? ie:
_host-challenge.<PROVIDER_RELEVANT_NAME>.whatever
The provider has the freedom to pick something shorter. Distinguishing
the type of request is intended, hence the -wildcard, -host, -domain,
etc.
5.2.2 Why bother with CNAMEs at all?
There are various services using CNAMEs now. One advantage is that
instead of providing a blob of TXT data, you can point to a random
blob assigned to you by a provider. See section 5.4. Delegated Domain
Control Validation for an example of this.
5.3.1 Why key-value pairs instead of JSON, CBOR, etc?
Because these things are going to be copied and pasted in webforms,
emails and other things that will helpfully do stuff do it, not
display it, block it for anti-virus reasons, etc.
Additionally, parsers are pretty dangerous and vulnerable to injection
attcaks. There is no real advantage here to take on that additional
risk.
5.3.2 Make it clearer this isn't TTL or SOA expiry values
Since this section talks about the data inside the RRdata, I think
that is very clear. Most of the format recommended here aren't
even valid values for TTL or SOA.
5.4 SHOULD or MUST remove?
It is a lowercase should as this is a directive to the operator and
not part of the specification of the protocol.
5.5 "identifier token should be stable over time" - vague!
what's meant by "stable" and "over time"?
Yes it is vague on purpose. Some of it obviously depends on the
length of the arrangement between parties. I am happy to remove
the entire statement if you prefer that.
5.5 not clear how/why 5.4 and 5.5 differ in substance
One is using a single CNAME to allow the target to put in the token at
its location. The other is using different CNAMEs for different accounts.
5.6 exact and full (FQDN?) for what? - just say complete?
Changed to "the entire DNS resource record (RR) using the Fully Qualified Domain
Name"
5.7 APIs MAY be used - current text seems too vendor-specific
I assume you mean 5.6 ?
The reason we say APIs SHOULD be used is exactly why ACME works so well.
It can be automated and scale far better than manual process.
5.8 "caching or resolver load will not be an issue"
[citation needed!] This claim is a subjective opinion.
Seeing that real DNS records often have a TTL of 0, I don't think this
draft talking about records that only a few parties request using "short"
TTLs not being a problem is problematic. Even if an attacker would use
these records with short TTLs (of a few minutes), it would be nothing
compared to regular use DNS entries.
5.9 why not use a dedicated RRtype?
It takes 10+ years to get new RRtypes working over webguis. Look at how
many registrars still do not support DS, CDS, etc.
5.9 CNAME love seems vendor-specific
5.9 starts with saying "for those not able to use TXT". It's hardly
"CNAME love".
5.10 does anyone use DNAME?
Yes. For example, libreswan.ca, libreswan.net and libreswan.com are
DNAMEs to libreswan.org.
6 Why just use (insecure?) email for OOB communication?
Incomplete threat model: spoofing, replay attacks, bad expiry info, etc
We did say "SHOULD use APIs" which you wanted to downgrade to "MAY use
APIs" :)
I think the threat model of how tokens are passed between parties and
who is a part is and how you confirm the identity and authorization of
such part is something that depends on the application.
They could use an HTTPS site with mTLS or Basic Auth if they do not want
to trust "insecure email".
disallowing "_foo-challenge.co.uk" is unreasonable and wrong
can't have special sauce which lets some domain names work but not others
It is not special sauce. The Public Suffix is a very commonly deployed
resource. For example, LetsEncrypt uses it. Browsers use it.
public suffix list isn't standardised or in an IANA registry
unsuitable for an RFC?
It's a normative reference to https://publicsuffix.org/
Documenting current behaviour/practice in Appendix A seems unwise for
an RFC. It'll inevitably become overtaken by events.
Once this RFC gains traction, we can always do a bis document and leave
out the current Survey of Techniques that this document improves upon.
An appendix with illustrative examples would be nice.
The appendix A is literally a list of current real world examples
and their documentation. If more people agree we should add examples
beyond the illustrations within the main document, we can do so.
Paul
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
