This discussion (and the other DoH ones) would probably be better handled
on the DoH mailing list -- https://www.ietf.org/mailman/listinfo/doh - so
that the DoH people are involved.
The DoH WG charter specifically says: "The working group will coordinate
with the DNSOP and INTAREA working groups
for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
respectvely. In particular, DNSOP will be consulted for guidance on the
operational impacts that result from traditional host behaviors (i.e.,
stub-resolver to recursive-resolver interaction) being replaced with the
specified mechanism."
W
On Wed, Feb 13, 2019 at 4:56 PM Brian Dickson <brian.peter.dick...@gmail.com>
wrote:
> I've been thinking a bit about some of the issues raised in the recent DoH
> discussion.
>
> What I am wondering about, is what the goals of different parties might be.
>
> I am also wondering whether some available standards (or additions to some
> of those standards) might be helpful.
>
> Finding particular middle ground technical solutions to balance the
> different goals (hard requirements vs philosophical issues vs real-world
> things), is what I think is a productive direction to have discussions.
>
> Some of the issues may need to be examined a bit closer. E.g. distrust is
> pretty vague. There are multiple underlying issues, e.g. privacy ("I don't
> trust you to know stuff"), or data integrity ("I don't trust you to not
> mangle data"), or surveillance ("I trust him more than I trust you, because
> he doesn't keep logs longer than X hours").
>
> I think the ability to separate out DNS from non-DNS traffic when the
> transport is TLS on some commonly-used TCP port, is another issue.
>
> Similarly, being able to identify end-points by name or by cert, and
> possibly having the ability to act on that identification (permit/deny) is
> another thing.
>
> Are there other requirements/drivers on these issues, that are implied or
> that might need to be considered?
>
> Is there any need/desire to separate the transport from the actual DNS
> resolution? Or would that add too much complexity with no obvious benefit?
> Would anyone offer transport while allowing use of a third/fourth party DNS
> resolver??
>
> The technical things that might be worth looking at, that I can think of,
> are:
>
> - New certificate use types (specific to only DNS, DoH, DoT,
> server/client etc?)
> - SNI
> - DNS server names (standardized or validated, or white-listed)
> - SRV stuff or similar
> - AH without any content encryption (Null cipher), allows channel
> integrity while letting network operator monitor view query/response
> traffic, e.g. for pseudo-RPZ functionality
> - Is there a DANE use case anywhere in here?
>
> Sorry for the noise, if anyone isn't interested in this stuff.
>
> Brian
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
---maf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
