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

Stephen Kent <kent@bbn.com> Mon, 09 December 2013 14:53 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 5AB7B1AE30A for <perpass@ietfa.amsl.com>; Mon, 9 Dec 2013 06:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 AKzpXf7xn0TR for <perpass@ietfa.amsl.com>; Mon, 9 Dec 2013 06:53:20 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8B1AE2F6 for <perpass@ietf.org>; Mon, 9 Dec 2013 06:53:19 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:53615 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Vq2Cw-000831-Oo for perpass@ietf.org; Mon, 09 Dec 2013 09:53:14 -0500
Message-ID: <52A5D95A.1020405@bbn.com>
Date: Mon, 09 Dec 2013 09:53:14 -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> <52A4DB71.8040806@cs.tcd.ie> <52A4EBF3.4000001@gmx.net>
In-Reply-To: <52A4EBF3.4000001@gmx.net>
Content-Type: multipart/alternative; boundary="------------000808020302020004050009"
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 14:53:21 -0000

Hannes,
> Hi Stephen, Hi Nicholas,
>
> it would be interesting (as a history lesson) if someone could tell us 
> why the group at that time decided to develop a NULL encryption 
> mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have 
> no heard
NULL encryption is offered as an option for ESP to enable ESP to be used 
in contexts
where data integrity, authentication and anti-replay may be required, 
but confidentiality is not desired. AH was designed to offer this set of 
security requirements, but we found that ESP was much more efficient, 
and thus we included NULL encryption as an option for ESP. BTW, the most 
common motivation for not imposing confidentially is a need to perform 
packet inspection in an enterprise environment.

Steve