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

On Dec 13, 2018, at 1:41 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> 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
> 
>> -----Original Message-----
>> From: Dots <dots-bounces@ietf.org> On Behalf Of Dan Wing
>> Sent: Thursday, December 13, 2018 8:53 AM
>> To: Roman Danyliw <rdd@cert.org>
>> Cc: dots@ietf.org
>> Subject: Re: [Dots] 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.
>> 
>> 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 <rdd@cert.org> wrote:
>>> 
>>> 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
>>> Dots@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dots
>> 
>> _______________________________________________
>> Dots mailing list
>> Dots@ietf.org
>> https://www.ietf.org/mailman/listinfo/dots