Hiya, On 12/03/2019 22:51, Paul Vixie wrote: > On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote: >> On 12/03/2019 21:11, Paul Vixie wrote: >>> ... >> >> There are reasons to want confidentiality for DNS queries >> and answers, and access patterns, for which the IETF has >> achieved consensus. (See RFC7626) (*) > > i have no qualms about confidentiality, for traffic allowed by a network > operator.
To me, the above reads as self-contradictory. If the traffic is confidential the operator doesn't know if its "allowed" except possibly in some extremely coarse-grained sense. Perhaps when you said "traffic allowed" maybe you meant "protocol allowed"? But even that is confusing, given the likes of websockets, alpn, and other webby ways in which stuff gets layered on 443 all the time. > it's the inability to interefere (as called for in RFC 8484) and not > the inability to observe (as called for in RFC 7626) that's at issue here. Hmm. Not sure what to make of that. DNSSEC presumably makes it possible to detect interference, and yet RPZ (IIRC) calls for not changing DNSSEC-signed answers. I don't get why an inability to change is ok for the RPZ/DNSSEC context but not for DoH. Another possibility is that we're discovering that when this confidentiality stuff gets used for real, we find that we'd really prefer to not have to change what we've been doing before. I don't mean that as an accusation but it has been easy to ignore e.g. the lack of deployment of DNSSEC or more recently, DoT. > >> DoT is one way to tackle those problems. DoH is another. > > DoT does not intend to place itself beyond interference by on-path entities, > and as such, my choice as a network operator is either to allow it through > even though i can't see the contents, or disallow it. and that's all fine. > > DoH intends "to prevent on-path interference with DNS operations", and that's > well beyond the remit of RFC 7626, and is therefore not spoken to one way or > another by IETF consensus. i do not believe that a non-interference objective > would reach broader IETF consensus. perhaps we can test that one day. Over the years, we've had quite a few people propose schemes to provide integrity (and presumably hence prevent "interference") but no confidentiality. (There's an ongoing discussion of the very latest iteration of that on the TLS list in the last month or so.) That leads me to guess that a position that "interference is ok but confidentiality is not a problem" is not one that'd tend to garner consensus. But as you say, maybe some day we'll test that proposition. Cheers, S. > > vixie > > > _______________________________________________ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
