Hi Paul,
Comments in-line.
On Tue, Mar 12, 2019 at 11:27 AM Paul Vixie <p...@redbarn.org> wrote:
> On Monday, 11 March 2019 18:30:51 UTC Ted Hardie wrote:
> > On Mon, Mar 11, 2019 at 11:06 AM Paul Vixie <p...@redbarn.org> wrote:
> > > DoH will moot that approach.
> >
> > Any system that actually checks the credentials presented by the
> responding
> > server will also moot that approach.
>
> yes! but it will fail "closed". thus, no unauthorized exfiltration risk
> will
> exist.
>
> > Given how easy it is to pin
> > credential characteristics in applications distributed as binaries, this
> > seems to mean that your method will either continue to permit
> applications
> > other than browsers to use their own resolution systems or it will hard
> > fail all such applications it can identify. No pass through will work,
> as
> > far as I can tell, in that scenario.
>
> that's precisely the goal, because very few network operators can
> preordain
> the users and apps that will connect through their networks.
I do not believe this goal is met by what you describe, since an
application can use a proprietary resolution service in its flows. Imagine
for a moment an application on a smart TV that wants to provide content
from the closest server which contains that content. It can use a redirect
from the original server when a new, closer server comes online (or when a
different server has that content), and it can provide the mapping between
that server and one or more addresses for that server with the redirect, in
whatever format its individual cache can store. All of this can take place
within its confidential channel, using whatever proprietary format they
find convenient. In that case, the local network will see new flows to the
new servers without having observed the resolution event. Blocking
destinations for which you have seen no resolution events will work for a
subset of these cases, but it won't work when the resolution points to a
common CDN destination. That approach will, of course, also have a wide
variety of failure modes when the resolution event data is incomplete for
timing or other reasons; it will also block all of the flows which MUD
would handle.
to the extent
> that monitoring ('dnstap') and controlling (DNS RPZ) dns lookups by
> connected
> users and apps is considered a vital local security policy, attempts at
> such
> "pass through" must be made to fail.
>
Those are security mechanisms, rather than policy, and it may be worth
teasing apart what the actual desired security policy is. You may find
that it is more easily implemented at the routing layer than the resolution
system in the light of proprietary resolution systems and DoH.
regards,
Ted Hardie
>
> >
> > Perhaps, though, I am missing something about your intent.
> >
>
> i think you've restated some key points of my position with perfect
> accuracy.
>
> DoH wants to empower users and apps to make decisions about their RDNS
> which
> cannot be interfered with by on-path actors such as their own network
> operators. by doing this, DoH makes a false equivalence between a
> dissident
> (who may be considered a criminal in some places) and a criminal (who is
> always considered a criminal in most places) and private users in a hotel
> room
> or coffee shop or on their home broadband connection, and malware which
> gets
> inside a network and wants to avoid detection/mitigation while performing
> lookups or exfiltration.
>
> those are four very different things. demanding identical treatment for
> all of
> them is, in the best possible interpretation, naive.
>
> vixie
>
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
