Re: [Doh] [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Stephen Farrell <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>