Re: [secdir] Secdir review of draft-housley-ct-keypackage-receipt-n-error-05
Russ Housley <housley@vigilsec.com> Tue, 10 December 2013 16:54 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53BD1AE171; Tue, 10 Dec 2013 08:54:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 pRmGJD8pVAIq; Tue, 10 Dec 2013 08:54:39 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2D1AE1D6; Tue, 10 Dec 2013 08:54:39 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 2C3AC9A41D3; Tue, 10 Dec 2013 11:54:24 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id bMbJijDg4edu; Tue, 10 Dec 2013 11:54:02 -0500 (EST)
Received: from [192.168.2.110] (pool-96-255-140-248.washdc.fios.verizon.net [96.255.140.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8CC859A41DA; Tue, 10 Dec 2013 11:54:02 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary="Apple-Mail-121-365338452"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CAFOuuo6V-ck6H5xspuYH88fq8nZhwrUmdh9g+WhzgjFKtEqCpg@mail.gmail.com>
Date: Tue, 10 Dec 2013 11:53:51 -0500
Message-Id: <2544ADA6-AF4A-45F3-8D83-86BB4531053A@vigilsec.com>
References: <CAFOuuo6V-ck6H5xspuYH88fq8nZhwrUmdh9g+WhzgjFKtEqCpg@mail.gmail.com>
To: Radia Perlman <radiaperlman@gmail.com>
X-Mailer: Apple Mail (2.1085)
Cc: The IESG <iesg@ietf.org>, draft-housley-ct-keypackage-receipt-n-error.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-housley-ct-keypackage-receipt-n-error-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 10 Dec 2013 16:54:43 -0000
Radia: Here is my rewrite of the security considerations to include the concerns that you raised. Let me know what you think. Russ - - - - - - - - - 8. Security Considerations The key package receipt and key package error contents are not necessarily protected. These content types can be combined with a security protocol to protect the contents of the package. The KeyPkgReceiptReq structure includes a receiptsFrom list and a receiptsTo list. Both lists contain SIREntityNames. The syntax does not specify a limit on the number of SIREntityNames that may be included in either of these lists. In addition, there is purposefully no requirement that the receiptTo entries have any relation to the sender of the key package. To avoid these features being used as part of a denial of service amplification, receipts should only be returned for key packages with a valid signature from a trusted signer. If an implementation is willing to accept key packages from more than one source, then there is a possibility that the same key package identifier could be used by more than one source. As a result, there is the potential for a receipt for one key package to be confused with the receipt for another, potentially leading to confusion about the keying material that is available to the recipient. In environments with multiple key sources, a convention for assignment of key package identifiers can avoid this potential confusion altogether. In some situations, returning very detailed error information can provide an attacker with insight into the security processing. Where this is a concern, the implementation should return the most generic error code that is appropriate. However, detailed error codes are very helpful during development, debugging, and interoperability testing. For this reason, implementations may want to have a way to configure the use of a generic error code or a detailed one. On Nov 10, 2013, at 1:09 AM, Radia Perlman wrote: > 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 syntax for two Cryptographic Message Syntax (CMS) content types that can be used in responses to messages containing key packages. One is for acknowledging receipt and the other is for reporting errors. The exact syntax is unimportant to security and the message purpose seems sensible and non-controversial. > > A few thoughts (mostly on procedural rather than technical issues): > > In addition to defining the key-package-receipt and key-package-error content types, this document defines a KeyPkgIdentifierAndReceiptReq attribute. It wasn’t clear (at least to me) whether this document was also defining this attribute or whether this information was included in this document for the purpose of providing context. > > The document defines a long list of error codes with the comment “Expect additional error codes” without specifying a mechanism for additional error codes to be defined. It also says that there are no IANA considerations, but I would assume that IANA would operate the registry for things like the error codes listed here. If not IANA, where would the definitive registry be? > > The KeyPkgReceiptReq includes a specification as to where to send the receipts, and that specification is a sequence of distinguished names. There is no specified limit on the number of distinguished names and no stated requirement that the names have any relation to the sender of the Key Package. This potentially represents a denial of service amplification engine. > > There is no indication that the key package identifier be unguessable or tied cryptographically to the key package contents. As a result, there is the potential that an attacker could stop delivery of a key package and send his own substitute key package with the same identifier. This would result in the recipient acknowledging a key package that he did not in fact receive. This could potentially confuse the sender about the state of the exchange. > > minor typo? The last line of page 5 says “which receivers of the key package are expected to return receipts”. I believe that should read “which receivers of the key package are requested to return receipts”. > > Radia
- [secdir] Secdir review of draft-housley-ct-keypac… Radia Perlman
- Re: [secdir] Secdir review of draft-housley-ct-ke… Russ Housley
- Re: [secdir] Secdir review of draft-housley-ct-ke… Jeffrey Hutzelman
- Re: [secdir] Secdir review of draft-housley-ct-ke… Russ Housley