Subject: Re: [Dots] Call for adoption on draft-boucadair-dots-server-discovery

From: <[email-masked]>
Date: Mon, 3 Dec 2018 06:51:11 +0000

Hi all, 

I support this draft, obviously. 

FWIW, I don't have any IPR related to this I-D.

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Roman Danyliw
> Envoyé : vendredi 30 novembre 2018 23:22
> À : [email-masked]
> Objet : [Dots] Call for adoption on draft-boucadair-dots-server-discovery
> 
> Hello!
> 
> This is the start of a two week call for input on the WG adoption of the
> document:
> 
> draft-boucadair-dots-server-discovery
> https://tools.ietf.org/html/draft-boucadair-dots-server-discovery-05
> 
> The document has been presented and discussed at IETF 103, IETF 100 and IETF
> 99;  and revisions have been made based on WG feedback.  Discussion of
> adoption of this draft was previously deferred pending submission of the
> signal draft for publication (which occurred in September 2018).
> 
> At the IETF 103 meeting, there were not many participants who had read the
> draft.
> 
> Please provide feedback to the list/chairs if you believe that this document
> should be adopted as a WG document.  The adoption call will end on December
> 14 2018.
> 
> Regards,
> Roman and Frank
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 6 Dec 2018 10:12:03 +0000

I support the draft. Some comments

[1] Using DHCP to learn the DOTS sever information does not look suitable, the DHCP client will not have a secure trusted relationship with the DHCP server to learn the DOTS server information (see the challenges we faced in DNS over TLS https://tools.ietf.org/html/rfc8310#section-7.3.1 for using DHCP).
[2] A separate Section is probably required to discuss BRSKI, and the draft needs to align with the latest changes in https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-16. The DOTS WG is yet to discuss this mechanism, and BRSKI can help avoid human intervention to provision the DOTS agents with the required credentials to trust each other, this will be really useful in deployments like Home/SOHO networks. 
[3]Table 1 in the draft needs to align with the updated use cases draft.

Cheers,
-Tiru

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Monday, December 3, 2018 12:21 PM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: RE: Call for adoption on draft-boucadair-dots-server-discovery
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> Hi all,
> 
> > Envoyé : vendredi 30 novembre 2018 23:22 À : [email-masked] Objet :
> > [Dots] Call for adoption on draft-boucadair-dots-server-discovery
> >
> > Hello!
> >
> > The document has been presented and discussed at IETF 103, IETF 100
> > and IETF 99;  and revisions have been made based on WG feedback.
> > Discussion of adoption of this draft was previously deferred pending
> > submission of the signal draft for publication (which occurred in September
> 2018).
> >
> > At the IETF 103 meeting, there were not many participants who had read
> > the draft.
> >
> > Please provide feedback to the list/chairs if you believe that this
> > document should be adopted as a WG document.  The adoption call will
> > end on December
> > 14 2018.
> >
> > Regards,
> > Roman and Frank
> >

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Dec 2018 19:22:46 -0800

I support adoption of this draft.  

However, I would really encourage the working group to analyze if all 4 discovery methods are really necessary.  4 mechanisms causes a bifurcation of products.  It complicates the features of a DOTS gateway, and raises questions such as "is quality implementation of a DOTS gateway expected to interoperate amongst the 4 DOTS discovery mechanisms."  Such interoperation becomes necessary when, say, some devices won't support DHCPv6 (Android) but an ISP only supports DHCPv4 & DHCPv6 DOTS discovery, for example.  There are other examples of incompatible discovery and how a vendor or an open-source DOTS gateway might try to overcome such issues with a Discovery Interoperability Feature ...

-d

> On Nov 30, 2018, at 2:21 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hello!
> 
> This is the start of a two week call for input on the WG adoption of the document:
> 
> The document has been presented and discussed at IETF 103, IETF 100 and IETF 99;  and revisions have been made based on WG feedback.  Discussion of adoption of this draft was previously deferred pending submission of the signal draft for publication (which occurred in September 2018).
> 
> At the IETF 103 meeting, there were not many participants who had read the draft.
> 
> Please provide feedback to the list/chairs if you believe that this document should be adopted as a WG document.  The adoption call will end on December 14 2018.
> 
> Regards,
> Roman and Frank
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 13 Dec 2018 09:41:27 +0000

Hi Dan,

Good point. DHCP to learn the DOTS sever information does not look suitable, the DHCP client will not have a secure trusted relationship with the DHCP server to learn the DOTS server information (see the challenges we faced in DNS over TLS https://tools.ietf.org/html/rfc8310#section-7.3.1 for using DHCP).

For auto discovery the DOTS client can try mDNS or anycast or both to reach the DOTS gateway, and the DOTS gateway can try both DNS-SD or anycast or both to reach the DOTS server in the ISP network.

Cheers,
-Tiru

> From: Dots <[email-masked]> On Behalf Of Dan Wing
> Sent: Thursday, December 13, 2018 8:53 AM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Dots] Call for adoption on draft-boucadair-dots-server-discovery
> 
> However, I would really encourage the working group to analyze if all 4
> discovery methods are really necessary.  4 mechanisms causes a bifurcation
> of products.  It complicates the features of a DOTS gateway, and raises
> questions such as "is quality implementation of a DOTS gateway expected to
> interoperate amongst the 4 DOTS discovery mechanisms."  Such
> interoperation becomes necessary when, say, some devices won't support
> DHCPv6 (Android) but an ISP only supports DHCPv4 & DHCPv6 DOTS
> discovery, for example.  There are other examples of incompatible discovery
> and how a vendor or an open-source DOTS gateway might try to overcome
> such issues with a Discovery Interoperability Feature ...
> 
> -d
> 
> 
> > The document has been presented and discussed at IETF 103, IETF 100 and
> IETF 99;  and revisions have been made based on WG feedback.  Discussion
> of adoption of this draft was previously deferred pending submission of the
> should be adopted as a WG document.  The adoption call will end on
> December 14 2018.
> >
> > Regards,
> > Roman and Frank
> >

---

From: Dan Wing <[email-masked]>
Date: Thu, 13 Dec 2018 11:24:28 -0800

> Good point. DHCP to learn the DOTS sever information does not look suitable, the DHCP client will not have a secure trusted relationship with the DHCP server to learn the DOTS server information (s…

DHCP is not solely inadequate because of the insecurity of DHCP, because other DOTS server discovery techniques suffer the same problem that a bogus DOTS server might be used by the DOTS client; the specification mentions that risk for the gratuitous multicasted DNS for mDNS, but the same issue exists with anycast.  Of all of them, N-SAPTR is most robust, but still suffers from the problem of how one might select or configure the domain name; if via DHCP (rather than user-configured or user-confirmed), we're back to trusting DHCP.  I would step back and see how we want to solve authentication overall for reliable and trustable time servers (NTP or TLS date/time or Google's Roughtime (https://roughtime.googlesource.com/roughtime).  Specific example, if I can authenticate the anycast DOTS server, but I can't authenticate or can't authorize with one of the higher-priority Discovery servers (e.g., NAPTR) the client should continue using the anycast server.

The document could be improved by separating how to find servers (currently 4 techniques) from how those are authenticated and what happens when authentication expires (e.g., server certificate has expired), and if existing server should be abandoned if a higher-priority Server Discovery happens to learn of a new server.  Are implementations expected to re-run their server discovery all the time, or only when a connection dies or only when server certificate expires, or .. never?  This stuff is partially discussed in Security Considerations, and maybe expanding that would be sufficient, but it seems the overall model needs to be discussed earlier -- that model being that the client is (somehow) given a trust anchor prior to joining a network and prior to trying to authenticate its discovered DOTS server.

> For auto discovery the DOTS client can try mDNS or anycast or both to reach the DOTS gateway, and the DOTS gateway can try both DNS-SD or anycast or both to reach the DOTS server in the ISP network.

Yeah, a discussion on when or why to re-run discovery seems important for the document, at some point -- probably too early now but worth some discussion and analysis.

-d

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 14 Dec 2018 11:04:00 +0000

Hi Dan,

The problem after auto-discovery is for the DOTS client to authenticate the DOTS server and vice-versa. If the DOTS agents cannot mutually authenticate each other, the discovery mechanism is of no use.  It means client has to be configured with DOTS server name and DOTS server domain's trust anchor certificate. 

>From my understanding listing the discovery mechanisms required 

[1] S-NAPTR lookup happens after the client is statically (or manually) configured with the DOTS server domain name, and uses PKIX based authentication of the server. 
[2] Static configuration of DOTS server domain name and its anycast IP address. PKIX is used to authenticate the DOTS server.
[3] Static configuration of SPKI + IP address. SPKI is used to authenticate the DOTS server. 
[4] The only way to automate the discovery of DOTS server and automatically configure the explicit trust anchor store for the attached domain is to use BRSKI, using BRSKI the device (co-located with DOTS client) would have already learned and validated the network domain name, and can use DNS-SD/mDNS to discover the DOTS server. DNSSEC validation also becomes possible, and even if the client does not support DNSSEC it will validate the DOTS server certificate using the installed explicit trust store.

Cheers,
-Tiru

> From: Dan Wing <[email-masked]>
> Sent: Friday, December 14, 2018 12:54 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; [email-masked]
> On Dec 13, 2018, at 1:41 AM, Konda, Tirumaleswar Reddy
> <[email-masked]> wrote:
> > Hi Dan,
> >
> > Good point. DHCP to learn the DOTS sever information does not look
> suitable, the DHCP client will not have a secure trusted relationship with the
> DHCP server to learn the DOTS server information (see the challenges we
> faced in DNS over TLS https://tools.ietf.org/html/rfc8310#section-7.3.1 for
> using DHCP).
> 
> DHCP is not solely inadequate because of the insecurity of DHCP, because
> other DOTS server discovery techniques suffer the same problem that a
> bogus DOTS server might be used by the DOTS client; the specification
> mentions that risk for the gratuitous multicasted DNS for mDNS, but the
> same issue exists with anycast.  
> Of all of them, N-SAPTR is most robust, but
> still suffers from the problem of how one might select or configure the
> domain name; if via DHCP (rather than user-configured or user-confirmed),
> we're back to trusting DHCP.  I would step back and see how we want to
> solve authentication overall for reliable and trustable time servers (NTP or
> TLS date/time or Google's Roughtime
> (https://roughtime.googlesource.com/roughtime).  Specific example, if I can
> authenticate the anycast DOTS server, but I can't authenticate or can't
> authorize with one of the higher-priority Discovery servers (e.g., NAPTR) the
> client should continue using the anycast server.
> 
> The document could be improved by separating how to find servers
> (currently 4 techniques) from how those are authenticated and what
> happens when authentication expires (e.g., server certificate has expired),
> and if existing server should be abandoned if a higher-priority Server
> Discovery happens to learn of a new server.  Are implementations expected
> to re-run their server discovery all the time, or only when a connection dies
> or only when server certificate expires, or .. never?  This stuff is partially
> discussed in Security Considerations, and maybe expanding that would be
> sufficient, but it seems the overall model needs to be discussed earlier --
> that model being that the client is (somehow) given a trust anchor prior to
> joining a network and prior to trying to authenticate its discovered DOTS
> server.
> 
> 
> > For auto discovery the DOTS client can try mDNS or anycast or both to
> reach the DOTS gateway, and the DOTS gateway can try both DNS-SD or
> anycast or both to reach the DOTS server in the ISP network.
> 
> Yeah, a discussion on when or why to re-run discovery seems important for
> the document, at some point -- probably too early now but worth some
> discussion and analysis.
> 
> -d
> 
> 
> 
> >
> > Cheers,
> > -Tiru
> >
> >> This email originated from outside of the organization. Do not click
> >> links or open attachments unless you recognize the sender and know
> >> the content is safe.
> >>
> >> However, I would really encourage the working group to analyze if all
> >> 4 discovery methods are really necessary.  4 mechanisms causes a
> >> bifurcation of products.  It complicates the features of a DOTS
> >> gateway, and raises questions such as "is quality implementation of a
> >> DOTS gateway expected to interoperate amongst the 4 DOTS discovery
> >> mechanisms."  Such interoperation becomes necessary when, say, some
> >> devices won't support
> >> discovery, for example.  There are other examples of incompatible
> >> discovery and how a vendor or an open-source DOTS gateway might try
> >> to overcome such issues with a Discovery Interoperability Feature ...
> >>
> >> -d
> >>
> >>
> >>> and
> >> IETF 99;  and revisions have been made based on WG feedback.
> >> submission of the signal draft for publication (which occurred in
> September 2018).
> >>>
> >>> document