Early Review of draft-ietf-dnsop-svcb-dane-01
review-ietf-dnsop-svcb-dane-01-dnsdir-early-mevzek-2023-07-12-00
Request | Review of | draft-ietf-dnsop-svcb-dane-01 |
---|---|---|
Requested revision | 01 (document currently at 04) | |
Type | Early Review | |
Team | DNS Directorate (dnsdir) | |
Deadline | 2023-07-12 | |
Requested | 2023-06-23 | |
Requested by | Tim Wicinski | |
Authors | Benjamin M. Schwartz , Robert Evans | |
I-D last updated | 2023-07-12 | |
Completed reviews |
Dnsdir Early review of -01
by Patrick Mevzek
(diff)
Secdir Early review of -01 by Donald E. Eastlake 3rd (diff) |
|
Assignment | Reviewer | Patrick Mevzek |
State | Completed | |
Request | Early review on draft-ietf-dnsop-svcb-dane by DNS Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/dnsdir/jrUPB8pw3OvGBNAjFMp4kuVUIMk | |
Reviewed revision | 01 (document currently at 04) | |
Result | Ready w/nits | |
Completed | 2023-07-12 |
review-ietf-dnsop-svcb-dane-01-dnsdir-early-mevzek-2023-07-12-00
I have been selected as the DNS Directorate reviewer for this draft draft-ietf-dnsop-svcb-dane-01 The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir This is an early review, and the document seems mostly ready to ship, with some nits in formatting or presentation, and nothing specifically related to DNS. There are no changes or consequences on DNS operations based on this draft, outside what is already defined in the specifications for TLSA and SVCB/HTTPS records. My points below are just in chronological order of reading it. * It updates 6698, but it also focuses mostly on operational issues/guidance, which is what 7671 is about, so maybe it should also be marked as updating 7671 in addition of 6698? * Section 1. — Nit: `_8080._tcp.example.com.` does not appear in specific “code” font in HTML output of draft, while other names later in document do, so I guess just a formatting change. — Potentially use “TLSA records” (plural) in various places instead of “the TLSA record” as this gives the impression there can be only one. — Introduction says the document does two things: giving details using DANE with SVCB and also how to use DANE with QUIC. However, neither the document title nor the abstract of it mention QUIC, only SVCB is mentioned. If the document does both, perhaps both points should be clearly listed early on (title + abstract), or otherwise (as SVCB and QUIC are fairly distinct things in my view), it should be split in two documents, each one focusing on one point only. * Section 3 — name of section: I would suggest using SVCB specifically instead of Service Bindings Same for title and abstract of document in fact. — s/This draft applies/This document applies/ (or specification, or other terms, but not “draft”) Maybe other occurrences of “draft” later on should be replaced as well. — “if SVCB resolution was entirely secure” : maybe mentioning it once that secure here means with DNSSEC along all the paths (DNS answers) taken? Or pointing to somewhere where secure is defined (maybe: §4.1 of RFC6698?) — “In usage modes other than DANE-EE(3)”: shouldn't that also include DANE-TA case at same level than DANE-EE? — section 3 “Section 6 of [RFC7671] says:” (present) vs section 4 “Section 3 of [RFC6698] defined the protocol prefix used for constructing TLSA QNAMEs, and said:” (past) I suggest using either present or past tense in both cases, as the intent is the same (redefining something coming from elsewhere) * Section 4 — name of section: I would make sure to list QUIC explicitly, otherwise seems too generic — “this draft Updates the above sentence as follows:” Replace “draft” by document or equivalent and lowercase “Updates”. — “udp” (DTLS [I-D.draft-ietf-tls-dtls13]) Shouldn't that instead reference by RFC9147 “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”? * Section 5.1 — Please replace examples of `alias.net`, `provider.com` with things under `.example` TLD. — “TLSA <provider keys>” Why plural? Possibly just ellipse the whole <> part, as it could be a hash too, etc. — “Service consumers are expected to use CNAME or SVCB AliasMode”, yet the example given is using only HTTPS record and not SVCB record. Maybe use multiple examples? — Perhaps add that this works mostly for DANE-EE and DANE-TA use cases? * Section 6 — “might use DANE for some conection” => connection — While not having actual element to provide, I feel the section to be a little too simple and specially the last paragraph, saying basically “insecurely resolved is not safe”, without giving guidance or at least detailing the tradeoffs between various possible scenarios (ignoring unsecure results, continue, etc.) * Section 7 — make sure all examples use IETF reserved names for hostnames (ex: `example-cdn.com` => `cdn-foobar42.example`) — “7.3. QUIC and CNAME”, not sure what the record on `www.example.com` is useful for? Or the URI should be `https://www.example.com/`? — “7.7. DNS ServiceMode”: perhaps use another TargetName to avoid having to say “The TLSA base name is taken from the SVCB TargetName.”? — “7.8. DNS AliasMode”: I don't understand the example given. Where does `ns1` come from? — nitpick/personal: I would prefer the examples to go from specific to general, and as such I would put the two DNS cases currently at the end more in the middle, right before “New scheme ServiceMode” * Section 8 — “IANA is instructed to add the following entry to the “Underscored and Globally Scoped DNS Node Names” registry:” Give some references on where this registry is located/where it is defined? (RFC 8553 maybe?)