Re: [Add] [EXTERNAL] My single use case

[Daniel Migault <[e-mail]>]

Hi,

I believe that DNSSEC is a good way to get authenticated information.
Especially as DNS is the common protocol between DoX. With DNSSEC, TLSA
would bind a key to a FQDN and the FQDN needs to be bound to *your* or
*the* or *an* ISP.
If UI are involved this seems sufficient as long as the EU is able to see
it is connected to connectivity_provider.net <http://my.isp.net>. What I
had in mind was to improve the level of confidence without UI but by
binding the resolver to the IP address used by the user. Of course the
connectivity provider is not necessarily the legitimate one, but still that
would be the associated resolver. One mechanism I would consider is binding
the IP address with DNSSEC to you resolver.sip.net. One way of doing so is
to start with a reverse resolution of the public IP address which provides
the FQDNs of the resolvers.

Note that in some cases the CPE also advertises the Public IP address of
the ISP resolver. I do not know how frequent this is.

Yours,
Daniel

On Mon, Sep 14, 2020 at 12:55 PM Vittorio Bertola <
[e-mail]> wrote:

>
> Il 14/09/2020 17:54 Daniel Migault <[e-mail]> ha scritto:
>
> <mglt>
> You could also validate (cryptographically) the correspondence between the
> encrypted DNS and the Do53, but in essence the confidence of the
> authentication will remain with a similar level of the Do53. The discovery
> could also provide some proofs that the resolver is associated to your ISP
> or the entity providing you the connectivity with a reasonable level of
> confidence.
> </mglt>
>
> For the use case of "same-provider auto-upgrade" as currently implemented,
> being sure that a given DoH resolver really corresponds to the currently
> active Do53 system resolver would suffice, even if you were not able to
> authenticate who is actually operating those two resolvers. (This is
> different from "same-provider auto-upgrade only for selected trusted
> providers", which requires a hardcoded list of trusted providers in the
> client, but as far as I understand the objective is to get rid of hardcoded
> lists altogether.)
>
> For this purpose, we could simply use a TLSA record. The Do53 resolver
> would provide a TLSA record together with the RESINFO/TXT/whatever response
> to the discovery query, and when establishing the DoH connection, the
> client would validate the certificate against the TLSA record. If you add
> DNSSEC to the Do53 communication, this should be a secure process. Could
> this work?
>
>
(Glenn - perhaps this is a specific topic for discussion tomorrow:
> authenticating the relationship between a Do53 and a DoH resolver without
> necessarily identifying their operator, i.e. breaking your #3 topic into
> two separate parts)
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> [e-mail]
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>

-- 
Daniel Migault
Ericsson