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

Nicholas Weaver <nweaver@icsi.berkeley.edu> Sun, 08 December 2013 15:55 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
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 3A6C21ADFBF for <perpass@ietfa.amsl.com>; Sun, 8 Dec 2013 07:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Oq_S18nKEZNy for <perpass@ietfa.amsl.com>; Sun, 8 Dec 2013 07:55:51 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id C0DFD1ADFBB for <perpass@ietf.org>; Sun, 8 Dec 2013 07:55:51 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 971E12C4042; Sun, 8 Dec 2013 07:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IcXLnS1qafvX; Sun, 8 Dec 2013 07:55:47 -0800 (PST)
Received: from [10.0.1.14] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 177D72C401A; Sun, 8 Dec 2013 07:55:47 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_F644DCAE-B6BB-4E91-A485-07765E1478AD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <52A3B8A4.6000309@perens.com>
Date: Sun, 8 Dec 2013 07:55:50 -0800
Message-Id: <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu>
References: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com>
To: Bruce Perens <bruce@perens.com>
X-Mailer: Apple Mail (2.1510)
Cc: perpass <perpass@ietf.org>, Nicholas Weaver <nweaver@icsi.berkeley.edu>
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 15:55:53 -0000

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.

To explicitly support downgraded, athuentication w/o encryption is STUPID!  it is DANGEROUS!  



About the only thing that is not a horrid idea is to have the key exchange generate a separate MAC and encryption key, using an encrypt then MAC structure.   Yet that loses out on the benefit of authenticated encryption modes that build the MAC into the communication.

So face it Bruce, your only option should be to have the client leak the session keys keys, and thereby explicitly say "NO SECURITY ON THIS CONNECTION, HAVE A NICE DAY".  

And yes, this means the French can pwn you.  Sorry, use a network that allows encryption.  Or have your session key leaker in UDP, and only 2-3 hops on the TTL, so only locals can pwn you.  [1] 

Anything more built into the protocol to support unencrypted communication represents a sabotage attempt on the rest of the Internet.


[1] I'm just waiting for the Botnet that uses open-WiFi to pwn the fellow computers in the local starbucks.  Its an old idea, but a good one...

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc