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

[Tom Pusateri <[e-mail]>]

> On Jul 19, 2018, at 9:24 AM, Tomek Mrugalski <[e-mail]> wrote:
> 
> 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

Thanks for the encouraging feedback. We will be glad to make the recommended changes.

Tom