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

[Daniel Migault <[e-mail]>]

On Thu, Sep 10, 2020 at 4:48 PM Ben Schwartz <bemasc=
[e-mail]> wrote:

>
>
> On Thu, Sep 10, 2020 at 11:31 AM Tommy Jensen <Jensen.Thomas=
> [e-mail]> wrote:
>
>> > As a new device or application, when I join a network that I have no
>> prior relationship with or configuration for, I want to discover the DoT or
>> DoH resolver that corresponds to the Do53 resolver offered by that network
>>
>> My issue with this scenario is I see "discover a DoT/DoH" server
>> differently from "discover a DoT/DoH server that corresponds to the Do53
>> resolver". The former doesn't require authentication to meet security
>> parity with Do53 server use today. The latter is a novel concept I would
>> prefer to be authenticated. This means for existing TLS infra would only be
>> possible for publicly routable IP addresses, a subset of the
>> network-offered servers out there.
>>
>
> I think of this as a distinction about how the correspondence is
> validated.  In one scenario, the client validates the correspondence
> topologically.  That could be the IP network topology (e.g. using the same
> IP for both Do53 and encrypted DNS) or the DNS lookup topology (in-band
> upgrade, with or without forwarder bypass).
>
> In the other scenario, correspondence is validated using a PKI with its
> own validation rules.
>
> <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>

Which of these is appropriate depends on the intended user experience (does
> the user see this IP address?) and also threat modeling questions (what
> does it mean to own an IP address?).  This seems like a good example of how
> even this seemingly narrow use case has a wide variety of potential
> variations and complexities.  Here are some more potential complications:
>
> * Increased query linkability, if multiple users' queries would otherwise
> be mixed together by a NAT or a DNS forwarder.
> * When should the client validate the certificate chain, and to which
> trust anchor?
> * Enabling a DNS-poisoning attacker to capture all DNS traffic
> * Enabling a transient attacker to become persistent
> * Defending against a passive+drop attacker who is trying to prevent
> upgrade
> * Defending against a late-arriving attacker who is trying to trigger a
> downgrade
>
> All of these apply to the narrow use case that Martin highlighted.  When
> we talk about requirements, these are the kinds of questions I'd like to
> see the group considering.  On some points, I think we will find consensus;
> on others, I think we will need to leave options open for implementers.
> Which properties we can provide will depend on the details of our protocol
> design.
>
> For developing requirements, I agree that we should focus on this use
> case, which deserves its own requirements draft.  When it's time to adopt
> solutions, I'd prefer to consider the bigger picture, and try to find a
> solution that extends naturally to other use cases as well.
>

<mglt>
I think that is important we do not exclusively work in a single use case
when it comes to designing a solution and that we do have a global picture
of the use cases and requirements. More specifically, I do not think that
discovery is limited to the discovery of the network provided resolvers.
</mglt>


> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>


-- 
Daniel Migault
Ericsson