Re: [dnsdir] [DNSOP] Dnsdir early review of draft-ietf-dnsop-svcb-dane-01

[Ben Schwartz <[e-mail]>]

Thanks for this close review, Patrick.  I've copied your notes into the draft's issue tracker so we don't forget to address them: https://github.com/bemasc/svcb-dane/issues/8.

--Ben Schwartz
________________________________
From: DNSOP <[e-mail]> on behalf of Patrick Mevzek via Datatracker <[e-mail]>
Sent: Wednesday, July 12, 2023 7:18 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [DNSOP] Dnsdir early review of draft-ietf-dnsop-svcb-dane-01

!-------------------------------------------------------------------|
  This Message Is From an External Sender

|-------------------------------------------------------------------!

Reviewer: Patrick Mevzek
Review result: Ready with Nits

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 `http://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?)



_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop