On Sun, Oct 20, 2013 at 1:59 PM, Stephen Farrell <[email protected]>wrote:
> > Hi Ted, > > Thanks for the draft. As you might guess from earlier discussion > on here, I think the more-than-MTI approach espoused is maybe the > right one, if we can figure out how to state the requirement well. > Have you any ideas on that, or on how we could get towards a > situation where that gained consensus? > > I think the issue here is that "mandatory to implement" is theoretically something testable by the IETF's process; mandatory to use is a condition of the overall system and far less liable to the same testing. "Default on" might be testable. I think, though, to get anywhere we'll need a combination of insistence at the protocol stage, user education about the meaning of confidentiality and data integrity, and plain old marketing. When a user can evaluate a statement like "safer messaging alternative" and the company providing it can profit from that evaluation, we'll get traction. > I've a similar question wrt how to "consider more carefully and > more consistently the effects of information leakage by DNS and > other infrastructure" - any ideas how an effort in that direction > could usefully be structured? > > Well, I think some of the other comments have explored this. If you are putting up a web site for blogs, providing a URL like blogname.blogsite.example leaks data that blogsite.example/blogname does not; providing both (for vanity or safety, but not both) is a better design than forcing the leak. A document that described the issues here may be quite useful, though I suspect it needs a lot more marketing than the usual RFC. On a slightly more protocol-oriented note, David Conrad pointed out years ago that once DNS data is secured by DNSSEC, you could deliver it over confidential channels. If the validation is done at the end user's system (or within the application there), downloading the data from anywhere you trust should work. regards, Ted > Ta, > S. > > On 10/20/2013 02:21 AM, Ted Hardie wrote: > > Like most folks involved in this list, I have a personal response to the > > current situation and some thoughts on how it will impact my or our work > in > > the future. Since I expect we will pretty short of mic time in Vancouver > > for thoughts like these, I decided to write them out. > > > > http://tools.ietf.org/html/draft-hardie-perpass-touchstone-00 > > > > is the result. It's quite short but a quick summary is this: > > > > Pervasive monitoring induces self-censoring which harms the Internet and > > its users. At the scale of the modern Internet, that means it harms > > humanity. > > > > We can and should change our approach to Internet engineering and system > > design to deal with this. There will be costs for that, but we should > pay > > them. > > > > It helps me, personally, to focus on a single user when asking whether a > > system or protocol is appropriate in the current environment. The draft > > lays out why. > > > > regards, > > > > Ted Hardie > > > > > > > > _______________________________________________ > > perpass mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/perpass > > >
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
