Re: [Add] My principles for discovery

[Daniel Migault <[e-mail]>]

On Wed, Mar 25, 2020 at 12:37 AM Martin Thomson <[e-mail]> wrote:

> As I raised this in the meeting, I think that it's only fair that I
> include what I think the principles should be.
>
> In short, I believe that any entity that you interact with should be able
> to present their views on what resolver you should use.  Client policy will
> then dictate which - if any - of those is used.  Authentication of the
> source of these opinions is likely a necessary input for the client policy
> decision.
>
> It is discussing client policy that has caused us to get into unproductive
> discussions.  To be clear, I regard the question of whether it is users or
> the software they choose to run that make policy decisions to be firmly
> part of this discussion.  We might variously lament the ability of software
> to properly reflect the wishes of users, but this is not the place to
> debate that.
>
>  <mglt>
I think I also agree. The policy should in theory be independent
from the application enforcing that policy. The problem is that a
formal definition of what such policy is likely to never be defined,
and as such a large part of it will be defined by the
application. For that reason, the policy is likely be represented
by the application itself. In other words, not everything is being
configured by the end user and we assume the application
reflects the end user policy. - this also suppose the end user
will have the choice between different applications.

That said, the policy enforced by the application may involve
some interaction of the end user during the selection process. I
also believe that some means may be provided so the application
may notify the end user of the resulting selection.
</mglt>

 That doesn't mean that you should expect the person serving you sausages
> at a local deli to offer an opinion on what resolver you should use.  But
> we should look to provide ways in which entities that have some relevant
> stake to make their opinion known.  As a provider of application software
> that might be interested in having its own policies, I might expect to
> receive opinions from the following places:
>
> * The networks that endpoints connect to.
> * DNS servers that might be involved in answering queries.
> * Other communication endpoints, such as sites or enterprise services, and
> their representatives, such as CDNs or corporate IT.
>
>  <mglt>
The end user may have a say in the selection process.  I agree
that interaction with the end user should be limited and that
such interaction is up to the application performing the
selection. It thus sounds to me that some election parameter
should be designed to be presented to the end user. I also do not
think we should go much further than a UTF8 string.
The scenarios I would envision is that a list of resolvers is
proposed to the end user. Another thing is that when one resolver
is chosen or changed, the end user may be notified of that
change or selection.

I am unsure I clearly get the third bullet. I understand it
includes things such as:
* some configuration parameters to perform some resolutions over
* a specific resolver a web site to advertise a preferred
* resolver.
</mglt>
>
> These next three might not depend on a protocol that we define here, but
> we can still recognize that there might be other entities involved in
> expressing opinions and - for these - even setting policy:
>
> * The operating system configuration.
> * Various "owners" or stakeholders for the endpoint, such as an employer
> or a government (this might not extend all the way to full control of the
> device MDM-style, but it might still be relevant to the client policy).
> * Application configuration.
>
 <mglt>
I would see those entities as being able to configure/provide
information to the application that proceed to the selection.
</mglt>


> I don't personally see a lot of value in having entities other than those
> from the first set of three stand on soapboxes to broadcast their opinions
> about resolver choice, but there is nothing fundamentally wrong with having
> other sources of opinions.  So while the IETF could provide more protocols,
> it's not a good use of our time and resources unless we expect that the
> information would be acceptable to genuine client policies.
>
> When it comes to setting policy, authentication is important.  When making
> a decision about whether to use a particular resolver, depending on the
> policy you have, it might be important that you know whose opinion is
> guiding the decision.  If you want a server that doesn't store logs of
> queries for longer than a certain time, then I'm not aware of a technical
> mechanism for verifying that claim.  You likely have to rely on the
> assertions of an entity you trust.  Opinions received over the delicatessen
> counter are unlikely to carry any particular weight.
>
>  <mglt>
I believe the end user may decide to trust the delicateness
counter more than other ways. Think of an IETF meeting happening
nearby the deli. I am not convinced it is an easy problem to
select what the end user trust.
</mglt>

 It was good to see both Tommy and Dan address this question directly;
> though I'm not sure I totally agree that the right trust anchors were used,
> building in ways to authenticate an opinion makes it more likely that
> client policy will allow use of the indicated resolver.
>
> I think that the need to be flexible about authenticity derives largely
> from the desire to allow networks to have an opinion.  I know of no way to
> authenticate the output of DHCP or a RA, except to say that this is most
> likely the provider of the network who is speaking.  That's very weak
> authentication, so while it carries some weight, it's not a lot.
>
>  <mglt>
I think RFC3971 and RFC3118 are at least an attempt to provide
authentication. I am unaware of large deployment of these
mechanisms. DHCP / RA may provide  an IP address without
authentication, but this could be used as an hint to retrieved
authenticated information. If DHCP/RA is being spoofed, this may
end up in the resolver you connect NOT being the one proposed by
the ISP, but at least upon the selection you can trust who you
are connected to.
</mglt>

>  So, I would suggest that the best we can hope for from this WG is a set
> of mechanisms that report on resolver options/opinions and some associated
> information that includes who provided the option/opinion and how.
>
>  <mglt>
I agree.
</mglt>

 Cheers,
> Martin
>
> p.s., Regarding work on the table, I think that it is clear what the
> models are driving draft-btw-add-home, draft-peterson-do[th]-dhcp, and
> draft-pauly-dprive-adaptive-dns-privacy.  I struggle a little with
> draft-mglt-add-rdp in this regard and I would appreciate a little more
> clarity about intent.

<mglt>
I am happy to clarify anything that does not appear to be clear.

The intent is (limited) to enable the discovery resolving services
available.
All resolving services provided by example.com are listed under
_dns.example.com and selection parameters are provided through SVCB RRsets.

Since you need example.com to start the discovery, we define a repo that
contains resolving domain the dns client may consider for global resolver.
We
also define a possible way to derive the resolving domain from the local
resolver advertised by the DHCP RA.

Other ways may be defined to communicate resolving domains (DHCP
for example)

Currently the resolving domain take part of the selection by only providing
a
preference on the resolving service.

Since DNS is used to carry this information it may be requested by a dns
client
or eventually provided as additional data by a resolver the dns client
interacts with.

</mglt>


> It is possible that draft-reddy-add-server-policy-selection is firmly in
> the authentication space, but it seems to be more firmly aimed at
> communicating policy than I am currently comfortable with right now.
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>


-- 
Daniel Migault
Ericsson