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

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Thu, 19 July 2018 13:24 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
X-Original-To: driu@ietfa.amsl.com
Delivered-To: driu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EDF129619; Thu, 19 Jul 2018 06:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsEqPQxPCiwJ; Thu, 19 Jul 2018 06:24:08 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733C9130DCE; Thu, 19 Jul 2018 06:24:08 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id y5-v6so7112420qti.12; Thu, 19 Jul 2018 06:24:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:openpgp:autocrypt:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=3o/RwpN0E+Fy18PGNFM3uj4cOmjFivFruX8aWs/zrbA=; b=aoAEyMGvZTlvT0WUfOZbThjIfpXspvCpQno08kz7341GZPfIvZA8BqSK57zahefJHh kFs8L9B0/NtAdDK9P2xNVqV426+H8v/3vcnZillE+Yre4mvKfXzgrqtZhAOeJs4kIKlh o4BHxwOHakdR2xk4nP48UEyJU4006CNw79LGZRcm+Vrxv6/+lTzitNQc1sQhduV0sEE7 sRqQOMBLhGOAqhwSu1zywlyBl4pyn8cTyZ7CuH3W2iasmL0frWhYNUeso3TnaduUotgj xB7THY+fICf5tJA2zWk6yXpT0RMA3xSsgrWfegZmMVkS4f/gwkph/E3rm0FYorLNL7zA OJvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:openpgp:autocrypt:to:subject:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=3o/RwpN0E+Fy18PGNFM3uj4cOmjFivFruX8aWs/zrbA=; b=f4NHbbQbMpw7AxrVl9ISm7KPXeMID5XGAXUzuS4NvapIPYfJjQyaLO1fS1WVsS2sAY OEsyBTedS3L+lFRk3QG6b+tWZJRc2y9WKf2447A8h1XLECOKXpReu3dhDBmtWdXZTQ3b i7lBFu2K1YAGJpbb1jYdVX7m7xlAST0ZEtFuJanC2UJ+0GPjUHifFmYHCOEqC01lKuD+ FjbfYQaq7R37J0DBu1hMz6+X4C4oKHDGXPEeDE4wECPpPX1XK05xX/kgmZguUlscKA1S Fc5HfiuzHWAfSKnJ6Jl42ohPvshiTELS/ktYckaxN5Ock20wipN7C9/bnZVVtdHl/tIp retQ==
X-Gm-Message-State: AOUpUlG3Ey8onGtVWtm+6EqfK7xuRRlA54Oi5FmXpOYwLNUhknedb/mu 4TgDdpPDyK5hMnHD3krFx0kJCDFnm5g=
X-Google-Smtp-Source: AAOMgpcO/J5zPP8cXuKJLyubLQyw2bo3Fj0yqSBtvDvtRz9Af+N2b6gaZ/cXPwwYzJcQcAdjb1atZQ==
X-Received: by 2002:ac8:31cd:: with SMTP id i13-v6mr9634814qte.144.1532006647058; Thu, 19 Jul 2018 06:24:07 -0700 (PDT)
Received: from [192.168.0.149] (modemcable106.203-177-173.mc.videotron.ca. [173.177.203.106]) by smtp.gmail.com with ESMTPSA id t1-v6sm4277224qkf.16.2018.07.19.06.24.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 06:24:06 -0700 (PDT)
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Openpgp: preference=signencrypt
Autocrypt: addr=tomasz.mrugalski@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFnoiMwBEADTmiPRnreg9BKxRAq5IixkTT6sMqpueC9kf3UGP3KAeO032wLkEdLd/ELW bhXv2Z0k2Jeq8N9qSsn0uiwlizPz1trH/lad/xQolv6529jhMdWvpt9iNpmjY/M0bdwG8E3e pSpYLg2p9TSa/N3XOIJYqcMHlWaqTlU+//5w2KXQd585+X68bfWmLJQvA371kUAp75PzwHJt zmL6SI5jZOhONPrisUnvEic1cW/VVLQ0RUc6O9+fmpyzoDKKXO/mKxjXScyE7hGmZI2Yr3X5 bf+wixXRnM6mYSocRbMYtPSotWo9UNRQCM3ns4Q8wf99Hbpy0kdLL3aD1NdgdJbIDcbONBj4 YX0bDiaWMKBuUsbBXe1wEUsmkwYxFSdKKJGiOQpDaOFSbiyn0HXAjj9iOcEOSjls03RHS0RV F59Ra0HTaIQIoqgPimjzZK3D7Yee8UKgzNQ/kvowJvom2H+GI6c4YXhluyDE1k869V/EIRO/ kxyznUaXT1kgD+v8YZESm/s5JG6gPYf2Whxp4zW0mRwJE1nJWUdrR/T5aYJatBhwdiYqhOzt qJm6HRihoAz7DxebsVtv/pH/EdX9K0yMdjw4y9cElrXQkUa5jFiPk5fhYcJFp1lxcMy+IZps FR4JUYUkB2gEKbLRp3o7g3PlA1DmeGOv3ojMAWOw9l1l9UDxHwARAQABzSBUb21layBNcnVn YWxza2kgPHRvbWFzekBpc2Mub3JnPsLBlAQTAQgAPhYhBBGZCpIDRNb+ndZDaYPU7qyYlWHJ BQJZ6IjMAhsjBQkJZgGABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEIPU7qyYlWHJ4d0Q AL46OqfV4zKmAqnHykElhm8hXmWkHHeIhkNIsmX5LdnkigxqAhg/K4nws74Zq9U53T1CBaTa SlxOGnWf+4LW/ZGN6mfp7IS5RcUL7O4O523dY+QRAy/goLBvnzzYL3wXFzmFRNyCoSUHJzwY h2R7PEeGZ8IpEuQA4lNodIKSXK3+iGQAi1kpWfuxD/Nd7bMtpvdmDJ74ZdtuOfgCqQPwvNMN xECTzDEM7K8+1AZtJ9Vk2YR5qNmlHSq/eQoyG3gAQ57Ym/duPTc2qacoJHFO6KGwHpbcnUo8 k5RZYPW5Cr84d4TXg0JmkgIMkDxrc+CgWMJDFIlbC2eS9TmOG3OALjqQ/0iy9athCkCPlq46 PJMKuMHbM5zhwkxJ4nPieLjpGtkewmkTMrQJUWcyuxJNLMdlIvZuioXrXcN9a5/N+UISaWaf tpZAhEK7J8LGTJzVfKP4j0CBRyFklKsuxw4mbZloJYe7JGEybwIArXF1LgXnFUS6S4xV4wyV mfZtd08nugTo407c2snWgNUHjt7g4VvKEXfss4cSg0B2MnBD8BSKcjCp16CDKZCOOKuNJELj outedf2FEGRMsSs26Xiz9uiS4UPjzuv9ZFGSL6fZ0cGaN3isKF4oDXG/YvXIoGwmRdzt+w7N OnU6rB7icW0fyccScFRxqFfImGdXZO20x8lIzsFNBFnoiMwBEADBPSEGUwIayl//i6LJWoy+ xJaMSdsiCvcIKcUUSFFRPvbpJ5vYeqoVVRr+EvobpwEYeoy9MGGXamPO6jC8E2Ufq/pxZAof 5x7Kt5GYs/qEgbJyLvQ+Fc9PADhfoJAZQU5Jm/oQ8lIl0CLPmIv62jtYlAPesK/YjPYoFzdQ fS9jOVso/WJrYVkKIG3+0RN8LOonR82Z1NIm1TXDuXVDLjLAr+M0k3UZwviup3eT/lh6xJkT Sg8/+DXIWv0SNtEkvNjxZPQwPB9WuvtqD/5SVR7QJifyqqq9T0EovFg0KHZognMPqIKiYfuZ 7SGFHBQZut58Fdg7C9kKwv3QoSwJc9jkMfMw2vcPJUoj41JwATAPSwF28Xqa4hBFHZZ/nY3p /3oJOXFW9ubYyf+YrsCbN30FxFN2bCerSZRahb2vkSgibxNjjvemM7YyuabUFfd5MXqBwS6M zFjeUEI/CWMAxfWWFykMisGT+w+rTAC9/YusuoeEAFldvOrSgN4anmQ85CHWGEx3lqNNCLEn hSi9W62MOptfHSGoLLJTz5V2AvGgXX1r4AKhr0upea3ALwXHB41/+wQYPD4uBGQvMb9wFavq 3bSglBZ9gvnk+P0EZ2Sfw8BU+AywDJF0PkFwK4on7zLMntgr73B6RNbsIDzWxXEUq1g94PEL B9nE7O+zEi7N1wARAQABwsF8BBgBCAAmFiEEEZkKkgNE1v6d1kNpg9TurJiVYckFAlnoiMwC GwwFCQlmAYAACgkQg9TurJiVYcmkeg/9Ha9VvXZFUEAEdiKlYJd+nSwdq3QVp5C44EHopblM /AO43OxJREaelc+OPeRo7OaAGtNosLNb1+ocYG6azZjaGyB8UcGXUpKakqzGapJZxbe5ugiI g2HgWsQx2cshfMLAz00z+gYjVkvvrffJeATnVSRJ3/VDxNfXt1SRNp20aw2r6FPTkMq+wQYj HKi4rW3NXMnnTVJd3zNepXEdaLl4o5wggOeWePKFN1bTpLZiBTJG7aWTltrRLzYC1z+4WIut GO1ytQbQV5PDtWncbsbcjtiegpJqNu6q8ThvzvHn1UyP/lx25Sjhgp9/5wOwiyDbZbrrNTks NtHkC36ObM9rRw+CfOkf+aTcM+zZB7TUlj924XzuhzqlLQcjuJZ1Tq4foNz2EeRVDvovZfyh JqO81nNEND4MQi8yumTm4G60IdMPSmJCl4TyIPQJ886h+omcE8hSpbEaMAuV0sLyNKcW3Zgs cQqyaeqX3EB3uHhT7cw6NEOkgzyN9tURCMtfnpVGKFA2fSZh1rXhB1yftxOxaBYTw1Wxp2KN DGllsvKOXjz57O9EI4dhqpd+Wl8z+q1jFc5+8g5Fkv8PWvFNF9h2C/knfNm+qj9w5PCcjkXJ EH3imij2e89rWloVAkSQK14sZNuAykzIUSjQv5gpcUPUpNqIJN4G7PqTiVUOrUt+SYc=
To: dhcwg@ietf.org, driu@ietf.org
Message-ID: <375c9e1d-1911-630d-efc0-7e045052299e@gmail.com>
Date: Thu, 19 Jul 2018 09:24:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/_4uyVyvWL57dhJmveLAvxXecvOM>
Subject: [Driu] Comments on draft-pusateri-dhc-dns-driu-00
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:driu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/driu/>
List-Post: <mailto:driu@ietf.org>
List-Help: <mailto:driu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:driu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2018 13:24:11 -0000

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