On Wednesday, 13 March 2019 00:36:32 UTC Stephen Farrell wrote: > Hiya, > > On 12/03/2019 22:51, Paul Vixie wrote: .... > > 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"?
yes. > 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. relevant security mechanisms allow for short term losses, leading to long term policy shifts. that is, i didn't isolate my chromecast-ultra until it misbehaved too egregiously. at work we're on more of a hair trigger. > > it's the inability to inter[e]fere (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. i think that's off-topic. my point is, as an operator, i can decide whether to allow DoT to off-net providers, based on whether it's OK with me that i cannot see what it's doing OR interfere with its results. (and i choose _not to_.) whereas, as an operator, that choice was deliberately taken out of my hands with respect to DoH... by design. i think if the DoH people had wanted operators to have a choice, they might have said, DoT will handle anti-surveillance and anti-interference if it works, and the runtime will handle the selection. and, they wouldn't have said that one of their goals was to prevent on-path interference in DNS operations. their def'n of "interfere" is probably unrelated, having a totally different scope, to the RPZ concept of interference. > 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. i don't take it as an accusation, but this is about security economics, not new vs. old ways of doing the same thing, or preferences. the DoH people intended to dramatically raise the costs of on-path DNS interference. as an on-path interference fan, i don't like the choices they've left me with. one of those is "let any user or app inside my network do its DNS outside of my surveillance and outside of my (RPZ) policy controls." i won't be choosing that. my motives are grounded in security economics, teenagers, and malware. vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
