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

Stephen Kent <kent@bbn.com> Mon, 09 December 2013 15:20 UTC

Return-Path: <kent@bbn.com>
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 844761AE33B for <perpass@ietfa.amsl.com>; Mon, 9 Dec 2013 07:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Iw-87o_6G27S for <perpass@ietfa.amsl.com>; Mon, 9 Dec 2013 07:20:25 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A37B91AE338 for <perpass@ietf.org>; Mon, 9 Dec 2013 07:20:25 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:33975 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Vq2dA-0008M9-2W for perpass@ietf.org; Mon, 09 Dec 2013 10:20:20 -0500
Message-ID: <52A5DFB3.90309@bbn.com>
Date: Mon, 09 Dec 2013 10:20:19 -0500
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: perpass@ietf.org
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>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 09 Dec 2013 15:20:27 -0000

Nicholas,
> 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.
John's assertions in this context are not informed by participation in
the IPsec WG process at that time, to the best of my recollection.
> To explicitly support downgraded, athuentication w/o encryption is STUPID!  it is DANGEROUS!
Not at all. We already had AH;  we offered ESP with NULL encryption as a 
more
efficient way to achieve the same security goals.
>   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.
The use of distinct algs for the distinct security services was 
consistent with the standard alg options of the original time frame. 
Note that combined mode algs, that offer confidentiality and integrity, 
are explciitly accommodated in later versions of the specs, e.g., 4303.

Steve