On Thu, 22 Dec 2016, Vernon Schryver wrote:
SERVFAIL signaling DNSSEC validation failure is the equivalent to an
HTTP 4yz failure status. Neither is a full and open disclosure to end
users that censorship has occurred, because in both cases end users
only understand that the internet is broken.
When using HTTPS, I can tell the 4xx failure is from a legitimate source
(the publisher) or a middle man proxy/filter system.
A SERVFAIL (or BOGUS/INDETERMINATE answer if chained to my own resolver)
does not tell me if this came from a legitimate source or an intermediary.
But on the real Internet, HTTP 4yz results do not signal censorship,
because great firewalls, HTTP(S) proxies, and compliant PKI CAs are
used for invisible censorship, content injection, etc.
Which is why we now have Certificate Transparency ("trans" working group)
in RFC6962 and soon 6962bis, and DANE/TLSA. These are IETF efforts to
ensure that we can see a distinction between (optin) censorship and
MITM attacks.
Protocol signalling can help, but it is a relatively trivial matter
compared to how the blocking technology is explained to the people who are
affected by it.
I don't agree. While my Aunt Mildred might understand the instructions
of a walled garden the next time she infects her computer, she'll never
understand RPZ, HTTPS proxies, or even firewalls. Even if she had the
wit, she lacks the interest.
This is a red herring. No one is suggesting any visible changes for
Aunt Mildred. But what we do want is for experts to be able to determine
the type of censorship and the actor involved. So we have
accountability.
More important is that while DNS and HTTP lies can be used in open,
transparent, and virtuous ways, they won't be in the cases that justify
concern. Perhaps that is why among the thundering about ethics, human
rights, honesty, evil, and that the draft must never ever in a million
years be accepted without warning text, no text has been proposed. I
do not see how a principled stand for DNS honesty could accept any
warning text (or protocol signalling).
Some of us were not advocating for such text, although some text is surely
appropriate for the Security Considerations or Privacy Considerations
sections. Instead, I advocated for simple accountability by ensuring
the censored are able to determine the censor.
The IETF has undertaken some responsibility with respect to internet
protocols and their impact on society. If you want the IETF stamp of,
approval, those are the implications.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
