[secdir] Secdir review of draft-housley-ct-keypackage-receipt-n-error-05
Radia Perlman <radiaperlman@gmail.com> Sun, 10 November 2013 06:09 UTC
Return-Path: <radiaperlman@gmail.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 715FF21F9F80; Sat, 9 Nov 2013 22:09:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.484
X-Spam-Level:
X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 LHNdBdb-H8ev; Sat, 9 Nov 2013 22:09:53 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 151FA21F9F21; Sat, 9 Nov 2013 22:09:52 -0800 (PST)
Received: by mail-lb0-f182.google.com with SMTP id w6so2473621lbh.41 for <multiple recipients>; Sat, 09 Nov 2013 22:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=x3n6pK+MaG4YMU3Jpup0F7kMaOKZb6/c4CnV0ujXOy0=; b=jcs6wFQi8NuplZzIM5SeosCxAm4x5G4Z+jnRu9sHlscd5qpRDuc13WKgAp2F/BXJ4i NCeKfVS44wp5ljcSsDLghh+su2Id2lOckgu66re9N8+CMHA0vMJP1SkfvU4uK108rv4N XzqvCE934ZSWftMW+jyeFKpbFNQ3xxomSzoAFDgYCUy94xNAJDUBiA2mf20TgKsKwhzq xlz2Pw5aso8bfBE+o47YV+hb3OSoHa62MMPyRJfovrdMlB4G+eaomLW+iSQ7zB0EeAXU jV585hjSK5HS1jUtGy/hsIvc6sMjGs6kC7S/4/Y4iBg6EeFC8ijq2cMx4AKlTchyi9SI NLyw==
MIME-Version: 1.0
X-Received: by 10.112.204.74 with SMTP id kw10mr16969459lbc.13.1384063792035; Sat, 09 Nov 2013 22:09:52 -0800 (PST)
Received: by 10.112.188.197 with HTTP; Sat, 9 Nov 2013 22:09:51 -0800 (PST)
Date: Sat, 09 Nov 2013 22:09:51 -0800
Message-ID: <CAFOuuo6V-ck6H5xspuYH88fq8nZhwrUmdh9g+WhzgjFKtEqCpg@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-housley-ct-keypackage-receipt-n-error.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a11c3bb34abbc9b04eacc76ae"
Subject: [secdir] Secdir review of draft-housley-ct-keypackage-receipt-n-error-05
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: Sun, 10 Nov 2013 06:09:54 -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 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