On Sat, Aug 18, 2018 at 9:21 PM, Paul Vixie <p...@redbarn.org> wrote:
>
> Ted Lemon wrote:
>
>> The thing is that most devices don't connect to just one network.   So
>> while your devices on your network can certainly trust port 853 on your
>> network, when they roam to other networks, they have no reason to trust
>> it.
>>
>
> that's far afield of my stated use-case.
>
> if i receive advice and pre-shared key, concerning tcp/853, from my dhcp
> server, the tcp/853 service i'm advised to use may not be on my own
> network, it could be part of my corporate VPN, or an anycasted commercial
> service, or almost anywhere else.
>
> in that case, my DHCP transaction was local, and my resulting TCP/853
> transactions won't be local. and in that case i will have a greater reason
> to trust the pre-shared key and the TCP/853 advice because of where i
> received it, than i would have reason to trust privacy or integrity of the
> path to a UDP/53 + TCP/53 ("traditional DNS") server.
>
> roaming is another matter, because in those cases, i'll speak DHCP to some
> new network provider, and will receive some advice concerning an RDNS
> service from that new DHCP transaction, which will obviate any previous
> advice, or whether i took that advice, or how trustworthy that advice
> turned out to be.
>

If you are trusting a "pre-shared key," why not just pre-share the DoT
server information?   If you are using the pre-shared key as a way to
validate a server whose IP address may change over time, why not configure
the pre-shared key with a domain name?

.... If you have devices that never roam to other networks, that's
>> fine, but we have to design for the more general case.   There's no way
>> with DHCP for the device to tell that it's connected to a particular
>> network, other than matching IP addresses, which isn't a great idea.
>>
>
> if i'm not roaming, i won't receive RDNS advice from the other DHCP
> servers that i never come into contact with. this seems a non-sequitur.
>
> if i am roaming, then anyone who hands me an address via DHCP should feel
> free to advise me as to what DNS service i use, including a TCP/853 service
> for which a pre-shared key may be needed. because the network operator may
> forbid and prevent the use of other DNS services which i may prefer, it
> would be wise for me to listen to that advice, and consider following it,
> especially if my usual service can't be reached while operating on said
> network.
>
> roaming is off-topic. DHCP authentication and integrity is off-topic. this
> is a simple proposal to allow a network operator to include TCP/853 ("DoT")
> advice including pre-shared keys in their DHCP responses. it ought to be
> drama-free.


The reason it's not drama-free is because you can't just hand-wave the
threat model.   What you just said is a fine way for you, Paul Vixie, a
knowledgeable user, to configure your device, but I can't explain this
threat model to a typical end user, and they have no basis for deciding
what they should do.   You mention the GFWoC, and that's certainly a use
case we need to consider, but we also need to consider the use case of the
malicious coffee shop network that wants to harvest your passwords.   I
don't know if you have friends who've been taken by this scam, but I have,
and it cost them a *lot.*   So how does my host tell the GFWoC from the
malicious coffee shop server?   Assume that it can't ask me to figure it
out—it has to follow some decision heuristic that is programmed in at the
factory.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to