[Driu] Comments on draft-pusateri-dhc-dns-driu-00

[Tomek Mrugalski <[e-mail]>]

Hi,

I have read the draft-pusateri-dhc-dns-driu-00 draft and I like it.
A lot.

Here are some improvement suggestions. There are quite a few of them,
but they are mostly editorial in nature and easy to fix. The basic
proposal sounds good, at least from the DHCP perspective. Options are
well designed and mostly follow guidelines of RFC7227.

What should the client do if the options are no longer sent by the
server when renewing or the server sends different values?

Section 3: Each encapsulating option should be specified in a separate
section for easier referencing.

Section 4: The text suggests the options defined in 4.1-4.3 can appear
only in DNS_TLS option, which is not true as they can also appear in
DNS_DTLS. The text also incorrectly mentions four options (three are
defined).

Section 4.1: OPTION_IPV6 is not a good name. The name should be
reasonably descriptive, so when looked upon on an all DHCP options list
users would have some fighting chance to guess what this option is
about. How about OPTION_DNSS_ADDR?  The same applies to other names
(OPTION_PORT and OPTION_URI). Adding the same prefix (DNSS? SDNS?) to
all of them would be useful. When browsing a list of options it would be
then immediately obvious that all of them serve similar goal and are
supposed to be used together.

Section 4.2: This text "The use of OPTION_ADN by the server is OPTIONAL
but strongly encouraged." should use a stronger normative language,
i.e. be rephrased to use SHOULD. Makes a lot of a difference for server
implementors (we can print warnings when not configured) and test
implementors (it's tricky to write reasonable testes for OPTIONAL and
MAY).

Section 4.3: "It defaults to port 853 as defined in Section 3.1 of
[RFC7858]." We don't do option defaults in DHCPv6. This needs to be
clarified. Do you want the server, when not explicitly configured, to
send this option with a value of 853 or the client to assume value of
853 when the option is not sent by the server?  These are two different
things. The former would require extra per-option logic to be
implemented on the server side and that's something the DHCP community
likes to avoid. Having default client behavior is fine, though. I think
this text should be moved to a separate client/server section. See the
explanation below.

Section 7: These are well written security considerations. Thanks for
putting them out clearly. One aspect not mentioned here is time-based
attack, such as using expired (or not yet valid) DNSSEC keys. I wish I
could offer a solution to this problem. Mandating NTP_SERVER option
wouldn't help much, it would just increase the attack complexity (a
perpetrator would need to also spoof NTP server).

Section 10.1: Why these all normative references? As a DHCP implementor,
do I really need to read and understand the whole DoT and DoH to
implement those options? I think most of them are informational, except
2119, 3315.

There should be new client behavior and server behavior sections added.
These sections are very useful for implementors and also help a
lot avoiding confusion which side is supposed to do what. Also, that's
what RFC7227 recommends (and provides some boiler plate text).

The client behavior section should offer some guidance with relation to
plain DNS options (RFC3646). Perhaps something like the following would
make sense: "A client requesting DNS_TLS, DNS_DTLS and/or DNS_HTTPS
SHOULD also request OPTION_DNS as a fallback mechanism.  In legacy
networks that do not support any of the new mechanisms, the client will
receive only OPTION_DNS values. In such case the client should do X".
I'm not sure what X would be. Perhaps adding a non-normative text
explaining that a client can either chose to use plain servers and
losing benefits of TLS/HTTPS or discard them and be left with unusable
connection.

The client behavior section should clarify the client is supposed to
request only the container options, not the options within them.  The
RFC3315bis is around the corner (in RFC-Ed queue right now) and it will
add two extra columns to the DHCPv6 options list. First specifies
whether an option is a singleton (your draft already clearly says that
multiple options are allowed). The second column is whether an option
code can appear in ORO. My recommendation is to request only the
container options.

The A.1 appendix uses non-RFC3849 addresses. Thank you for using ISC
software.

Overall, with a bit of easy tweaking this draft will be in a great
shape. It's been a long time since a new draft appeared in the DHC WG
with such a well defined purpose, reasonable proposed solution and this
level of maturity at -00.

Finally, one comment with my DHC co-chair hat on. If the DRIU BoF turns
out to be a WG forming one, this draft should be adopted there, not in
DHC. However, if there is no better suited WG, we'll need to talk with
our AD and will likely be able to do adoption call in DHC.

Thank you for this work. Let me know if you need any help.

Tomek Mrugalski