Subject: [Add] TR: New Version Notification for draft-btw-add-home-09.txt

From: <[email-masked]>
Date: Mon, 21 Sep 2020 15:23:58 +0000

Hi all, 

We made a major update of the draft to address some pending comments. A diff is provided below to track the changes.

We think that this version is a good candidate to consider a WG call for adoption. 

Comments are welcome. 

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : lundi 21 septembre 2020 17:16
À : Tirumaleswar Reddy <[email-masked]>; Tirumaleswar Reddy.K <[email-masked]>; Neil Cook <[email-masked]>; Dan Wing <[email-masked]>; BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Objet : New Version Notification for draft-btw-add-home-09.txt

A new version of I-D, draft-btw-add-home-09.txt has been successfully submitted by Mohamed Boucadair and posted to the IETF repository.

Name:		draft-btw-add-home
Revision:	09
Title:		DHCP and Router Advertisement Options for Encrypted DNS Discovery within Home Networks
Document date:	2020-09-21
Group:		Individual Submission
Pages:		30
URL:            https://www.ietf.org/id/draft-btw-add-home-09.txt
Status:         https://datatracker.ietf.org/doc/draft-btw-add-home/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-btw-add-home
Htmlized:       https://tools.ietf.org/html/draft-btw-add-home-09
Diff:           https://www.ietf.org/rfcdiff?url2=draft-btw-add-home-09

Abstract:
   The document specifies new DHCP and Router Advertisement Options to
   discover encrypted DNS servers (e.g., DoH, DoT, DoQ).  Particularly,
   it allows to learn an Authentication Domain Name together with a list
   of IP addresses and optionally a port number to reach such encrypted
   DNS servers.

   This document focuses on encrypted DNS deployment within home
   networks.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 22 Sep 2020 09:17:29 +0000

Hi all, 

I forgot to highlight the major changes made in this version:

*  Updated DHCP/RA extension to retrieve the encrypted DNS server domain name, port number and IP addresses. We don't rely anymore on existing DNS DHCP/RA options. The design allows to avoid probing.
*  If DHCP/RA is not supported, fallback to SUDN. This is basically to handle legacy routers.
*  Updated Security Considerations to discuss the threat models in RFC3552. 
*  List both the well-known or DHCP to retrieve the URI templates.

Cheers,
Med

> De : [email-masked]
> [mailto:[email-masked]]
> Envoyé : lundi 21 septembre 2020 17:24
> À : ADD Mailing list ([email-masked]) <[email-masked]>
> Cc : [email-masked]
> Objet : TR: New Version Notification for draft-btw-add-home-09.txt
> 
> Hi all,
> 
> We made a major update of the draft to address some pending
> comments. A diff is provided below to track the changes.
> 
> Envoyé : lundi 21 septembre 2020 17:16 À : Tirumaleswar Reddy
> <[email-masked]>; Tirumaleswar Reddy.K
> <[email-masked]>; Neil Cook
> <[email-masked]>; Dan Wing <[email-masked]>;
> BOUCADAIR Mohamed TGI/OLN <[email-masked]> Objet : New
> Version Notification for draft-btw-add-home-09.txt
> 
> 
> A new version of I-D, draft-btw-add-home-09.txt has been
> successfully submitted by Mohamed Boucadair and posted to the IETF
> repository.
> 
> Name:		draft-btw-add-home
> Revision:	09

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Sep 2020 17:20:26 -0400

Tiru and authors, I read through draft-btw-add-home-09.

First, I found the CLOUD-ish icon for the "LAN" confusing.
It looks like it is the "H" is inside the CPE.

                      ,--,--,--.
                   ,-'   +--+  `-.
                  ( LAN  |H |    CPE-
                   `-.   +--+   ,-'
                      `--'|-'--'

My eyes see a BOX, with an ISP facing interface labelled "CPE"
and a LAN facing interface labelled "LAN", and then I am
confused by the H inside, and thought it was the CPE acting
as a Host.  Only after a few figures did I understand that
this was a LAN "cloud"

I suggest:

    +-+
    |H|
    +-+         .-------.
     |  LAN     | CPE   +--- .. ISP-cloud
     +----------+       |
                '-------'

There is a tool written in perl called "asciio" which is fabulous for making
these kinds of ascii-art diagrams.  Highly recommended, but alas, it has no
cmd-line options, so integrating it into Makefile is a PITA.

section 3.1:

As I-D.ietf-v6ops-rfc7084-bis has not been worked on in awhile,
can you say what section deals with IPv4 service continuity, maybe
it is worth quoting the relevant text.

I would rather have four section (3.1.1/3.1.2/3.1.3/3.1.4) rather than just
four figures.

3.2: Unmanaged CPEs.

Well, I they are unmanaged by the ISP.
In may small offices, they are managed by a third service.
While some home owners neglect the devices, I wouldn't call them unmanaged.
They are home-owner managed.

As for:
   (assuming the CPE is
   compliant with the network access technical specification that is
   usually published by ISPs)

There is an EU guidelines that suggests that be required.  Some countries
have this as a regulation. Perhaps one of our european correspondants could
provide a useful reference.
They key point is, I think, that the device has no (private) trust anchors
pointing at the ISP, so the device can not validate ISP provided DoH/DoT/DoQ if the
ISP isn't using a public anchor.
There is no TR69 by which to configure the ADN.

the point starting at: Customers may also decide to deploy internal home
                       routers

is really a third kind of "CPE", which could appear in both managed and
unmanaged situations, and it's really this third situation that really
motivates getting this DHCP/RA option right.

section 4.1. DHCPv6 DNS Option.
I suggest you call it "Enc DNS Flags" rather than "Type", since it is split
up in bits.  I suggest you leave the comment about Unassigned Bits to the
IANA Considerations section.
I don't think that there is any reason to leave three bytes unassigned.
I don't think the ADN needs to be 32-bit aligned, since it is interpreted
as a sequence of bytes.

It seems to me that if we have the ADN, then the encrypted DNS service can
be reached at any IP address, including RFC1918, IPv6-LL, ULA, as long as
the service's certificate can be validated using the ADN.

For instance, a CPE device could advertise an IPv6-LL address for DNS, and
then form Circuit Proxy (aka Forward Proxy) to the ISP's service, without
necessarily requiring routing/forwarding to be active.  Any device on the LAN
could provide such service, actually.
It is worth remembering that openwrt's swiss-army-knife DNS/DHCP server
"dnsmasq" started life doing exactly that.

I suggest section 4.2, "DHCPv4 Encrypted DNS Option"

Can the OPTION_V4_ENC_DNS, Encrypted DNS Address Option, OPTION_V6_ENC_ADD
be ommitted (sending just the ADN), in which case the existing DNS address
options are assumed to work for Encrypted DNS at the "normal" port numbers?

Section 5:

"DoH clients re-iterates"   -> _re-iterates_ reads wrong.  "repeats" is
probably what you want.

section 7.1.1
please split the second paragraph into a new section.
Clearly, if the CPE is relaying the encrypted DNS server info, then it
doesn't need a ACME certificate.  That's exactly the case where the CPE is
not hosting encrypted DNS.  Maybe that's section 7.0

section 7.1.2:
        mention of sub-domains... and
        *left-most* label of the pre-configured ADN

I think the entire label has to match the certificate.
I think that it's that the ADN is a sub-domain of the pre-configured domain.
("blessed" might be the better term, channelling Perl more than D&D/Rogue),

Hate the diagram.  Here the DoH/DoT client is not inside the LAN cloud :-)

I think that section 7.2 should be split up into three sections:
1) the CPE will pass the ISP information on.
2) the CPE will provide reference to third-party service.
3) the CPE will be provide encrypted DNS itself thanks to the "security
   service provider" (possible, a person)

section 9.1 is great, and reflects the consensus about DHCP trust from the
virtual interim meeting.  I would reword:

   Because DHCP/RA messages are not encrypted or protected against
   modification within the LAN, their content can be spoofed or modified
   by active attackers (e.g., compromised devices within the home
   network).

to:

   DHCP/RA messages are not encrypted or protected against
   modification within the LAN.  Unless mitigated (described below),
   the content of DHCP and RA messages can be spoofed or modified by active
   attackers, such as compromised devices within the home network.

rework:
   Encrypted DNS sessions with rogue servers spoofing the IP address of
   a DNS server will fail because the DNS client will fail to
   authenticate that rogue server based upon PKIX authentication
   [RFC6125], particularly the authentication domain name in the
   Encrypted DNS Option.

too many embedded noun-phrases for non-native speakers :-)

9.4:
   This results in the
   key being shared to attackers resulting in security breach.
   Man-in-the-middle attacks are possible within home networks because WLAN
   authentication lacks peer entity authentication.

-> The shared key is available to all nodes, including attackers, so
   it is possible to mount an active on-path attack.

section 10, IANA lacks a repeat of the consideration for the Unassigned bits.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: <[email-masked]>
Date: Mon, 28 Sep 2020 07:45:30 +0000

Hi Michael,

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> De : Add [mailto:[email-masked]] De la part de Michael
> Richardson
> Envoyé : samedi 26 septembre 2020 23:20
> À : tirumal reddy <[email-masked]>; [email-masked]
> Cc : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Objet : Re: [Add] Fwd: New Version Notification for draft-btw-add-
> home-09.txt
> 
> 
> and a LAN facing interface labelled "LAN", and then I am confused by
> the H inside, and thought it was the CPE acting as a Host.  Only
> after a few figures did I understand that this was a LAN "cloud"

[Med] You got it :-)

The intent was to distinguish the case where a host connected ** from within** a LAN and the case where the host is directly connected (mobile networks, for example). 

>     |H|

[Med] Will see how to make things clearer. Thanks.

> There is a tool written in perl called "asciio" which is fabulous
> for making these kinds of ascii-art diagrams.  Highly recommended,
> but alas, it has no cmd-line options, so integrating it into
> Makefile is a PITA.
> 
> section 3.1:
> 
> As I-D.ietf-v6ops-rfc7084-bis has not been worked on in awhile, can
> you say what section deals with IPv4 service continuity, maybe it is
> worth quoting the relevant text.

[Med] Can add a pointer to 

" 5.4.1.  IPv4 Service Continuity in Customer LANs  . . . . . .  16 "

> 
> I would rather have four section (3.1.1/3.1.2/3.1.3/3.1.4) rather
> than just four figures.
> 
> 3.2: Unmanaged CPEs.
> 

[Med]  Will add a sentence to state this.  

> There is an EU guidelines that suggests that be required.  Some
> countries have this as a regulation. Perhaps one of our european
> correspondants could provide a useful reference.
> They key point is, I think, that the device has no (private) trust
> anchors pointing at the ISP, so the device can not validate ISP
> provided DoH/DoT/DoQ if the ISP isn't using a public anchor.

[Med] If the CPE is compliant with the spec published by an ISP, it can get the ADN using any discovery means in place by the ISP. 

> is really a third kind of "CPE"

[Med] ... but still an unmanaged one.

, which could appear in both managed
> and unmanaged situations, and it's really this third situation that
> really motivates getting this DHCP/RA option right.
> 
> I suggest you call it "Enc DNS Flags" rather than "Type", since it
> is split up in bits.

[Med] "Flags" is too generic an does not reflect that this field is about indicating the encrypted DNS type(s).

  I suggest you leave the comment about
> Unassigned Bits to the IANA Considerations section.

[Med] This depends whether we want to create a registry to track the bits.

> I don't think that there is any reason to leave three bytes

[Med] Why?  

> I don't think the ADN needs to be 32-bit aligned, since it is
> interpreted as a sequence of bytes.

[Med] Agree. 

> 
> It seems to me that if we have the ADN, then the encrypted DNS
> service can be reached at any IP address, including RFC1918, IPv6-
> LL, ULA, as long as the service's certificate can be validated using
> the ADN.

[Med] Yes. As you can see we don't have any restriction for the IP addresses to be supplied. We do have this text: 

"For example, a home
   router embedding a forwarder has to include one single IP address
   pointing to one of its LAN-facing interfaces."

We can add a statement similar to the one we have for RAs, though. 

> 
> For instance, a CPE device could advertise an IPv6-LL address for
> DNS, and then form Circuit Proxy (aka Forward Proxy) to the ISP's
> service, without necessarily requiring routing/forwarding to be
> active.  Any device on the LAN could provide such service, actually.
> It is worth remembering that openwrt's swiss-army-knife DNS/DHCP
> server "dnsmasq" started life doing exactly that.
> 

[Med] If we use "DHCPv4" then we need to introduce a new term in the terminology section to basically say that: "DHCPv4 refers to DHCPv4 [RFC2131]" 

> 
> Can the OPTION_V4_ENC_DNS, Encrypted DNS Address Option,
> OPTION_V6_ENC_ADD be ommitted (sending just the ADN), in which case
> the existing DNS address options are assumed to work for Encrypted
> DNS at the "normal" port numbers?

[Med] The current text does not assume this. If only an ADD is supplied, that name will be passed to a resolution library to retrieve the IP address(es). This is done to avoid probing.

> "DoH clients re-iterates"   -> _re-iterates_ reads wrong.  "repeats"

[Med] Fixed. Thanks. 

> Clearly, if the CPE is relaying the encrypted DNS server info, then
> it doesn't need a ACME certificate.  That's exactly the case where
> the CPE is not hosting encrypted DNS.  Maybe that's section 7.0

[Med] Good point. 

> I think the entire label has to match the certificate.

[Med] The certificate will include the CPE's sub-domain while the auto-upgrade is basd on the domain itself.

> Hate the diagram.  Here the DoH/DoT client is not inside the LAN

[Med] :-) 

>    service provider" (possible, a person)

[Med] Thanks for the suggestion. Will consider re-organizing the section. 

> 
> section 9.1 is great, and reflects the consensus about DHCP trust
> from the virtual interim meeting.  I would reword:
> 

[Med] I like this. Deal!

> too many embedded noun-phrases for non-native speakers :-)

[Med] ACK.

>    it is possible to mount an active on-path attack.

[Med] That's better. 

> section 10, IANA lacks a repeat of the consideration for the

[Med] Will be added if the WG want to maintain an IANA registry to track the bits.