Re: [Add] draft-grover-add-policy-detection-00

[Alec Muffett <[e-mail]>]

Rather than snark, I would like to raise the negative example of
"Haystack", a failed security and anonymity tool from several years back,
which collapsed in much contentiousness.

I was involved in revealing its flaws, so am deeply aware of the story:

*
https://www.theguardian.com/media/2010/mar/29/austin-heap-megas-innovator-award
[context]
*
https://www.computerworlduk.com/it-business/-awardwinning-haystack-security-system-could-risk-iranian-lives--3569566/
* https://dropsafe.crypticide.com/article/4409
*
https://liberationtech.stanford.narkive.com/jMCy8EpJ/deconstructing-the-security-risks-narrative-of-haystack#post2

Long story short: the application upon startup "beaconed" its existence in
a way which could lead to those who used it to be revealed to repressive
authorities, contra both its intention and its advertising.

It strikes me that any system - in pursuit of "protecting" the user with
"filters" - which both delegates the ability for the feature to be used to
some environmental authority and also reveals its use, is:

* defeating the intention of security, or at least placing the threat model
of the environment above that of the user, and...
* revolting against the end-to-end principle which drives so much of
ancient, and modern, internet architecture

As I understand it, we went to great lengths to ensure that TLS1.3 was not
open for environmentally-driven "downgrade attacks" to be possible; I
cannot reconcile this stance with the above proposal, where:

* [as I understand it] any cafe owner using PiHole will be able to suppress
TBD.arpa resolution, and disable DoH
* [as I understand it] any state telco (Iran, above?) can suppress TBD.arpa
resolution, and arrest anyone who attempts to resolve it for using
"non-compliant" software
* albeit the desire to protect people with MITM-filters is variously
legislated and appears desirable, I cannot see how delivery of such is now
compatible with the themes of rfc7258

Hence, I do and will strongly disapprove of this, and any other,
proposition that would disable -- or, importantly, reveal! -- explicit DoH
enablement choices that have made by a user.

I believe that DoH is a long-awaited universal good, and that it should
become common, even default, in order to foster consumer choice both in the
application space, and in the space of DNS providers; and that such choice
that must not be overridden by "environmental factors" - for all such
filters are men in the middle.

If not -- if policy detection and disablement is acceptable -- then why did
we work to expunge downgrade attacks in TLS1.3?

- alec