Re: [perpass] Fwd: Re: perens-perpass-appropriate-response-01

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 08 December 2013 20:50 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5F31AE0E2 for <perpass@ietfa.amsl.com>; Sun, 8 Dec 2013 12:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdA1Z2R6dnz3 for <perpass@ietfa.amsl.com>; Sun, 8 Dec 2013 12:50:09 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 986271AE0E1 for <perpass@ietf.org>; Sun, 8 Dec 2013 12:50:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 83E17BE5B; Sun, 8 Dec 2013 20:50:04 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFVAkLH2Q9X7; Sun, 8 Dec 2013 20:50:03 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.44.71.228]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A537BE59; Sun, 8 Dec 2013 20:50:03 +0000 (GMT)
Message-ID: <52A4DB71.8040806@cs.tcd.ie>
Date: Sun, 08 Dec 2013 20:49:53 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Nicholas Weaver <nweaver@icsi.berkeley.edu>
References: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu>
In-Reply-To: <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: perpass <perpass@ietf.org>
Subject: Re: [perpass] Fwd: Re: perens-perpass-appropriate-response-01
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 20:50:11 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 12/08/2013 03:55 PM, Nicholas Weaver wrote:
> 
> On Dec 7, 2013, at 4:09 PM, Bruce Perens <bruce@perens.com> wrote:
>> Well, we do have some HTTP uses where encryption that hides the 
>> content won't be allowed, and thus authentication is important.
>> 
>> We can't have encryption when we use HTTP over Amateur Radio in
>> the US and many other countries. There is self-policing on ham 
>> frequencies that requires that people be able to copy other 
>> people's transmissions, and encryption defeats that. Obviously
>> we don't put confidential data on those frequencies, that belongs
>> on your cell phone. So, an authentication-only WiFi protocol is
>> needed for Amateur Radio, and possibly an authentication-only
>> version of TLS.
> 
> NO!!!!
> 
> The reason is downgrade attacks.  A huge problem with the IPSec 
> standard is that NULL encryption was allowed in there, and also
> known weak modes (single DES, 720b D/H etc).  Its one of the
> primary reasons why John Gilmore and therefore others feel the
> IPSec process was sabotaged by the NSA.

Really? That makes no sense to me. I've never heard any report of a
use of IPsec that "accidentally" used a NULL or weak cipher. Have
you? And Jeff Schiller I think convincingly repudiated claims that
either the development process for IPsec or the output were
saobtaged in any such way.

I wasn't much involved myself but my impression was that we (the
IETF security community) shot ourselves in the foot a bit via
complexity and various refusals to prioritise progress and
deployment over purity.

We need to carefully balance security and pragmatism here IMO if
our goal is to make for a more secure and privacy friendly Internet.

I also think that throwing "sabotage" into the mix damages that
discussion so should be avoided.

S.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJSpNtuAAoJEC88hzaAX42iZbIH/iT8GFrHPhn/+4fUq4Z1+fIb
zZyMhypk0bV4LJaSRXvke2ExU0q8NuMp1OTqhw1baxGPpTR5WK6Xj0H6Dm5iRNKK
61ONTbeTnPwp8AW1CaRzT+3kX82D+vy1guz7pEP0iE4EQIKRtsFsIo/JaUtDIv1k
+xvHdyjnUFcSPQQqh4T969IpB0WpGT1Iw9RNGjqrEws9CqakMyVw8k2BiT7GtQOt
X71Z9DWdjZkohEEDvzZGj9m0NyeZz//r1qNDgKTWCPM6YLtHxhjyzyI7Qv38Lcyo
SV/5+OOSbjpenQp8rStTFvfZVeFzXYe5vr5l+vZJARfJLUv+d3HdVK/jYT0U2gU=
=m8H+
-----END PGP SIGNATURE-----