Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitori

Hi,

Not long ago, someone was stabbed with a knife, so:

> Encryption has its dangers and the IETF should not be encouraging its
> widespread adoption.
Knives have their dangers, and the metal-processing industry should not
be encouraging their widespread adoption.

Funny - that conclusion, which is analogous to yours, doesn't make much
sense to me. Does it to you?

Encryption is a tool - it's neither good nor bad in itself. What you do
with it is the question.

What we have seen in deployed reality is that lack of usage of this tool
by the internet population at large has played into the hands of
adversaries. The idea to put the tool into everybody's hands and make
them *use* it is absolutely a good idea as a countermeasure IMHO.

Especially since the adversaries *are* using it, regardless whether the
good guys do or not. The rioters you mention above did use it - and they
can continue to do so no matter what we decide in the IETF. The TV
manufacturer could have used it - they were simply stupid enough to
forget about it.

Greetings,

Stefan Winter

> Tom Petch
>
> ----- Original Message -----
> From: "Jari Arkko" <jari(_dot_)arkko(_at_)piuha(_dot_)net>
> To: <ietf(_at_)ietf(_dot_)org>
> Sent: Wednesday, December 04, 2013 4:45 AM
> Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive
> Monitoring is an Attack) to Best Current Practice
>
>
> I wanted to draw your attention on this last call:
>
> > The IESG has received a request from an individual submitter to
> consider
> > the following document:
> > - 'Pervasive Monitoring is an Attack'
> >  <draft-farrell-perpass-attack-02.txt> as Best Current Practice
> >
> > http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/
>
> It is a short read and important, so please comment. The last call ends
> in four weeks and covers holiday time, but we'll deal with this document
> on the January 9th telechat in the IESG, so in practice there should be
> enough time to comment.
>
> I would like to see this document as a high-level policy we have on
> dealing with this particular type of vulnerabilities in the Internet. A
> little bit like RFC 3365 "Danvers Doctrine" was on weak vs. strong
> security. Please remember that the details and tradeoffs for specific
> solutions are for our WGs to consider and not spelled out here. The
> draft does say "where possible" - I do not want to give the impression
> that our technology can either fully prevent all vulnerabilities or do
> it in all situations. There are obviously aspects that do not relate to
> communications security (like access to content by your peer) and there
> are many practical considerations that may not make it possible to
> provide additional privacy protection even when we are talking about the
> communications part. But I do believe we need to consider these
> vulnerabilities and do our best.
>
> Jari

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

0x8A39DC66.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature