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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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

> -----Original Message-----
> From: Dan Wing <[e-mail]>
> Sent: Friday, December 14, 2018 12:54 AM
> To: Konda, Tirumaleswar Reddy <[e-mail]>
> Cc: Roman Danyliw <[e-mail]>; [e-mail]
> 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.
> 
> On Dec 13, 2018, at 1:41 AM, Konda, Tirumaleswar Reddy
> <[e-mail]> 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 <[e-mail]> On Behalf Of Dan Wing
> >> Sent: Thursday, December 13, 2018 8:53 AM
> >> To: Roman Danyliw <[e-mail]>
> >> Cc: [e-mail]
> >> 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 <[e-mail]> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dots
> >>
> >> _______________________________________________
> >> Dots mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dots