Re: [dns-privacy] Operating System API support for DNS security policy

On Tue, 20 Aug 2019 at 03:13, Iain Sharp <isharp@atis.org> wrote:

> Thanks for the informative replies.
>
> The use cases I was thinking of are similar to those outlined by Bob and
> Stephen. Hypothetically, there might also be scenarios where the
> application wishes the DNS to be done without security (e.g. for debugging)
> though I don't know in practice how important these are.
>
> The getdns API is quite similar to what I had in mind. In getdns you can
> specify the transports you want from UDP, TCP and TLS. Possibly other
> levers may be needed for things like ESNI.
>
> Would the following be a fair summary of the discussion?
> 1) There is some support for the idea it would be useful for APIs to allow
> an application to at least know, and perhaps influence, what DNS security
> features will be used if it makes a DNS request via the operating system.
> 2) The getaddrinfo() API in RFC3493 doesn't provide this capability.
> 3) As far as we are aware there is no work in IETF currently on how to
> express security policy in DNS APIs, but the getdns API seems to have
> similar goals to point 1.
>

Re (3), I haven't been following taps work closely, but it seems like the
kind of thing they might have spent some cycles on.

> Regards
>
> Iain
>
>
>
> -----Original Message-----
> From: dns-privacy <dns-privacy-bounces@ietf.org> On Behalf Of
> stephen.farrell@cs.tcd.ie
> Sent: 19 August 2019 19:14
> To: rharolde@umich.edu
> Cc: Iain Sharp <isharp@atis.org>; dns-privacy@ietf.org; Jensen.Thomas=
> 40microsoft.com@dmarc.ietf.org
> Subject: Re: [dns-privacy] Operating System API support for DNS security
> policy
>
>
>
> On Monday, 19 August 2019, Bob Harold wrote:
> > On Mon, Aug 19, 2019 at 1:29 PM Tommy Jensen <Jensen.Thomas=
> > 40microsoft.com@dmarc.ietf.org> wrote:
> >
> > > Hey Iain,
> > >
> > > Iain> Many applications rely on operating system APIs to access DNS
> > > services. As native support of DNS over TLS rolls out in to
> > > operating systems it seems likely that some applications will wish
> > > to control the security policy that the operating system applies
> > > when it performs DNS resolution. For example, the application may
> > > wish to require that the operating system uses an encrypted DNS
> protocol.
> > >
> > > I actually don't see this being necessary. Walking through the
> > > possibilities:
> > >
> > >    - If the OS supports DoT and the configured servers support it:
> > >       - OS should be using DoT whether the app requests it or not
> > >    - If the OS supports DoT but the servers don't:
> > >       - App intent isn't helpful (to the same server)
> > >    - If the OS doesn't support it:
> > >       - App intent isn't helpful
> > >
> > > I read this differently - the api needs to tell the app whether the
> > > OS
> > does encrypted DNS:
> >
> >    - OS supports DoT and can connect to a DoT resolver
> >       - App uses OS for DNS
> >    - OS does not support DoT
> >       - App connects to a DoT server itself, bypassing the OS  (even
> though
> >       I dislike this, unless the user has agreed)
> >    - OS supports DoT but cannot reach a DoT server
> >       - various choices, we don't need to discuss this now.
> >
>
> +1, there's also the case of TLS ESNI where the application wants to only
> do the lookup if DNS privacy will be used. Different applications may
> choose different  fallbacks if DNS privacy is  not available from the OS.
>
> Cheers,
> S.
>
>
> > --
> > Bob Harold
> >
> >
> > >
> > >
> > > My view is that the OS should be taking the most secure DNS route it
> > > has available regardless of app request (after all, think of all the
> > > apps which won't request DoT but should). In the case where the OS
> > > supports DoT but isn't using it, that decision is being made in the
> > > context of other information, such as enterprise configuration, that
> the app may not have.
> > >
> > > Iain> Unless operating systems support secure DNS standards and
> > > Iain> expose
> > > APIs to allow applications to use them effectively then applications
> > > that require secure DNS have little choice other than to roll their
> > > own implementations.
> > >
> > > I totally agree. Platforms should be providing the network tools
> > > apps need so all apps can benefit similarly, rather than leaving
> > > apps to figure out networking nuance on their own. I just think in
> > > this case that there should never have to be a situation where an
> > > app needs to request DNS encryption (because either it's already
> > > happening or it can't happen for some reason unknown to the app).
> > >
> > > Summary: I think such an API should be unnecessary on well-behaved
> > > platforms.
> > >
> > > Thanks,
> > > Tommy
> > > ------------------------------
> > > *From:* dns-privacy <dns-privacy-bounces@ietf.org> on behalf of Iain
> > > Sharp <isharp@atis.org>
> > > *Sent:* Monday, August 19, 2019 2:56 AM
> > > *To:* dns-privacy@ietf.org <dns-privacy@ietf.org>
> > > *Subject:* [dns-privacy] Operating System API support for DNS
> > > security policy
> > >
> > >
> > > All,
> > >
> > >
> > >
> > > DNS over TLS offers the ability to perform DNS queries over a TLS
> > > secured channel. In my understanding, DNS over TLS is not yet
> > > available in all operating systems, but operating system support
> > > could become common in future.
> > >
> > >
> > >
> > > Many applications rely on operating system APIs to access DNS
> > > services. As native support of DNS over TLS rolls out in to
> > > operating systems it seems likely that some applications will wish
> > > to control the security policy that the operating system applies
> > > when it performs DNS resolution. For example, the application may
> > > wish to require that the operating system uses an encrypted DNS
> protocol.
> > >
> > >
> > >
> > > Today, most operating systems use the getaddrinfo() function
> > > described in
> > > RFC3493 as the basis of their API for translating DNS names to IP
> > > addresses, but this does not have security policy attributes.. Is
> > > anyone aware of any activity to enhance the RFC3493 work to add
> > > application control of security policy to the getaddrinfo()
> capabilities?
> > >
> > >
> > >
> > > Unless operating systems support secure DNS standards and expose
> > > APIs to allow applications to use them effectively then applications
> > > that require secure DNS have little choice other than to roll their
> own implementations.
> > >
> > >
> > >
> > >
> > >
> > > Thanks
> > >
> > >
> > >
> > > Iain
> > >
> >
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>