[secdir] secdir review of draft-snell-atompub-tombstones-14

Joe Salowey <jsalowey@cisco.com> Wed, 22 February 2012 03:25 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A52B21E804C; Tue, 21 Feb 2012 19:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9KOwPd8I0Sw; Tue, 21 Feb 2012 19:25:45 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 24E4421E800F; Tue, 21 Feb 2012 19:25:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1296; q=dns/txt; s=iport; t=1329881145; x=1331090745; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=oNa5MulqCTdrlLLsQxckwL+du5DbQV4WGDOE/8M4sT8=; b=PEmzIzHxMCyt3VLQ6xGHdE5rThGcJpwSMKNoCqI1D1rnnS716JdmVlK1 siaJowzk9SFpAql89szlKGywOcKSUn2rpOdsDluhrr/AML5ZbEMSMQapV MX4M+rExKAQJwfkdPnzptPXMue1bNsHT/x1otUW9ZJq3I1ne3TbbTuIKw M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AswHAJ9fRE+Q/khM/2dsb2JhbABEgxKvTYEHggwBJz+BPzSnXgGXK4lUgnIKBAoLCA8ICwMPDQITBAEKAgUDAoUcgz1jBIhPjGmFXY0xgTI
X-IronPort-AV: E=Sophos;i="4.73,461,1325462400"; d="scan'208";a="66705148"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Feb 2012 03:25:44 +0000
Received: from [10.123.1.204] (rtp-vpn5-1498.cisco.com [10.82.237.223]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1M3PgEM026229; Wed, 22 Feb 2012 03:25:43 GMT
From: Joe Salowey <jsalowey@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Feb 2012 19:22:56 -0800
Message-Id: <62D370A2-7E18-4A83-BA4C-C9FEAF5F3C6F@cisco.com>
To: secdir@ietf.org, draft-snell-atompub-tombstones.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: The IESG <iesg@ietf.org>
Subject: [secdir] secdir review of draft-snell-atompub-tombstones-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2012 03:25:46 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document defines a XML data format used to remove entries from an atom feed. The document does make use of the XML digital signature and encryption specifications from the W3C to provide integrity, authenticity and confidentiality.  Key management for the encryption is not discussed, however this seems to be consistent with other AtomPub documents.    How a message is authorized is not described in much detail.  In the security considerations there is mention that it is expected that the delete message will be signed using the same key as the particular feed but how to handle this seems to be largely out of scope of the document.   Both of these are not necessarily problems in themselves, but could lead to interop and manageability problems.   Since the deleted entry document may contain an IRI perhaps it would be good to reference the security considerations in RFC 3987. 

Cheers,

Joe