Resorting to in-line responses to reduce the amount of talking past each
other.
On 08/19/2018 07:17 PM, Ted Lemon wrote:
No, I think maybe I haven't been communicating as well as I should.
What I have been saying is that we need to decide what our threat
model is,
You've been very clear on your numerous repetitions that this is your
perspective. I and others have quite clearly disagreed with that. Please
don't mistake lack of agreement with lack of clarity. I understand your
argument, I just don't agree with it.
so that we can figure out what to recommend. What you are
saying is "we should recommend this."
No, I'm definitely NOT saying that. I and others have expressed surprise
that you feel that the existence of a DHCP option constitutes an
endorsement. I've been in the business over 20 years, and have never
heard this line of reasoning, for example.
What you are proposing to
recommend has a perfectly valid threat model associated with it. I'm
just saying write that up, don't just leave it unstated. Let's get
clarity on it and decide that we're okay with it, or not, before we
write a standard based on it. I don't think this needs to be a
heavy-weight process—I'm just objecting to the handwaving. And to be
clear, the model that Paul has been advocating actually is not what you
just said—it's a different, also valid, threat model. The problem with
Paul's model is that it assumes a user who is able to reason clearly
about threat models; I don't think we can do that, and I would object to
a spec that was based on that threat model. I think we need to do that
work, and not leave it to the user. We've all seen what happens when
you demand that users be security experts.
I think Paul's threat model and mine have more in common than you
imagine, but I'll leave that aside. What confuses me is the idea that a
given option can only be deployed to address one threat model. Clearly,
for any draft the security section needs to weigh the pros and cons of
the approach.
What it seems like we do agree on is that there is no additional risk to
the user who would have been relying on the unencrypted resolver anyway
to rely on an encrypted one.
While your three security models have distinctions to a person who is
knowledgeable about such things, the only time they matter to your
normal, non-security-aware user is when they intentionally configure a
resolver (DOH/DOT or not). If they do this, they are taken out of the
realm of DHCP resolver options entirely.
Doug
On Sun, Aug 19, 2018 at 8:28 PM, Doug Barton <do...@dougbarton.us
<mailto:do...@dougbarton.us>> wrote:
On 08/19/2018 04:57 PM, manu tman wrote:
On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon <mel...@fugue.com
<mailto:mel...@fugue.com> <mailto:mel...@fugue.com
<mailto:mel...@fugue.com>>> wrote:
A user who relies on the dhcp server for dns server info is
no worse
off. The problem is that if your host lets the dhcp server
override
the DoT or DoH configuration you entered manually, you are
a lot
worse off.
This seems to be a static vs dynamic setup. Either you use
dynamic and you will happily accept what you get from DHCP and
possibly upgrade to (HTTP|TL)S or you have set your resolvers
statically and you are already ignoring the nameservers provided
by the DHCP server.
If you do not accept the servers provided by DHCP, there is no
reason you would accept extra attributes for those same
snameservers.
Manu
Yes, those are my thoughts precisely.
I don't see a risk model where a user configures DOH or DOT servers
explicitly, but does not disable DHCP configuration for DNS. Am I
missing something?
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
