Re: [secdir] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08

"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Thu, 28 May 2020 01:02 UTC

Return-Path: <ncamwing@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 735E23A0819; Wed, 27 May 2020 18:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=heVIqvxI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YY4HTU6A
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 EKSCPrmhHewC; Wed, 27 May 2020 18:02:42 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318303A082B; Wed, 27 May 2020 18:02:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6402; q=dns/txt; s=iport; t=1590627762; x=1591837362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=heVIqvxIHUd+kf36F73/YyW7IMEZSgNDI2tNbgN2we1/QzlyfK8Wa8WS 6R8/lAhf+yNWmr/i4JPlGjVC5TszgdDmVa/JGMiUTJDsYV5/7l4G2p0oW CdTLI/4mQoNwhm4btqHenxkUXqTncd3RxkPUWDP0C3iwT/1Jw2g49rPjq E=;
IronPort-PHdr: =?us-ascii?q?9a23=3A4dSrEhe1g1bN4btr2rcElojFlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaSB9fS9v1ZkPbdvqTkUHYbp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0bBx?= =?us-ascii?q?riLhZ+K+DxE5TJyc+w0rP695jaeQ4dgj27bPt7Jwm3qgOEsM4QjO4AYqY8wx?= =?us-ascii?q?fEuD1GYeNTkGhpPlmU2R3745S9?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBQCvDM9e/4QNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUCMvB4FHLywKhBuDRgONP5hCglIDVQsBAQEMAQEtAgQ?= =?us-ascii?q?BAYREAheBfwIkOBMCAwEBCwEBBQEBAQIBBgRthVcMhXIBAQEBAxIREQwBATc?= =?us-ascii?q?BCwQCAQYCDgMEAQEDAiYCAgIwFQgIAgQBDQUigwSCTAMuAZN+kGcCgTmIYXa?= =?us-ascii?q?BMoMBAQEFhUMYgg4JgQ4qgmSJQx0aggCBESccgk0+hCaDPDOCLZFnj1yRcAq?= =?us-ascii?q?CVI45hU6EWR2CZIkDkiGQUp1pAgQCBAUCDgEBBYFqIoFWcBVlAYI+UBgNkEC?= =?us-ascii?q?DcopWdDcCBgEHAQEDCXyJdIE0AYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.73,443,1583193600"; d="scan'208";a="773261627"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2020 01:02:41 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 04S12fsk006122 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2020 01:02:41 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 May 2020 20:02:40 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 May 2020 20:02:40 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 27 May 2020 20:02:40 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LfFIGlFaDyFDNK92mBwFcIW5NmX8igSp+BIeGjJ8TlzOL7USf/bZNWP/0jbpS/B5MFtI1iQM7gAmTn/O9MsPRTZjJVBH0Vq/fbSpC81SioF8gfX0EkhCSYB0zUVxbBroOr2ZPc32vGfXQkSulNZXEbgjgDZKLXYG2d4PBRWUfEn6pqHoE/f7am8+jhTxho+vPLGzPIMobXYgSZksy7lS8Z6V2EfA4dryM0pokVYUYSItldAzmXRecfffwI2del0jqLjCUG4KMYwdR6h17sUSgk9M8B9F72bVQZj5spoBDjIuPCi0A1E7+5tdBGgB5JQ0t7V1v1WrEQjqQTJz+Slcqg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=WyKze7V50Xf4SqeJaHldw6WPHPNGevDSTUySIBYA8rNrwhGTl1QKqyRiqR6OQJgzbO5qOlq/mTG+R+5hH7rKnYF0c0y8Q0E2C55QfD9Jdp0zcF89IDOMOLgpgPMu96kVslqbCYRhLXPSUsb41qlCzn7dynwlzl7mDdFxidrMfpklTWjQOyyvhxcvARRFGRYfjWdco7cq4tdIdlrPzLlzp7WmKmyw3IsLQLdXqIXMkVzEQMqq3AAXG/wuKMS7gMCKbcGx4OcEp7fSQq7lVAeEZuwQVEjIvhWSaUfYEWJKtruYHbVBdc3GTZCJ+4h4Z1H+7gs4CbVs+PtlQg6Jy3sYrg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=YY4HTU6Ac8RhfXz961klY/TvkivEpKaeHEqJMx0zYd14hwwh0S7OyrbiO4Zz/kwsL17ovrBtlIarnzXUtIywSOpf3Hxa5sYcSdmqcBw5PJcCgeRQHgIHBlxcd4uV2RsO3GKrMuN86xffAneEhuK+mtM8RN3hjZoTaJddGPZYzn8=
Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4291.namprd11.prod.outlook.com (2603:10b6:a03:1c2::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Thu, 28 May 2020 01:02:38 +0000
Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949%6]) with mapi id 15.20.3021.030; Thu, 28 May 2020 01:02:38 +0000
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: Jim Schaad <ietf@augustcellars.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "cose@ietf.org" <cose@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-cose-rfc8152bis-algs.all@ietf.org" <draft-ietf-cose-rfc8152bis-algs.all@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08
Thread-Index: AQHWM9KZeZSj+xDsXECz02YXYKWNB6i8Ol2A
Date: Thu, 28 May 2020 01:02:38 +0000
Message-ID: <4853C09B-52BB-495F-B533-E624C55A626B@cisco.com>
References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> <037801d633d2$92f189a0$b8d49ce0$@augustcellars.com>
In-Reply-To: <037801d633d2$92f189a0$b8d49ce0$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.16.200509
authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [73.162.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e335dee0-8bd8-4f39-b746-08d802a2d0eb
x-ms-traffictypediagnostic: BY5PR11MB4291:
x-microsoft-antispam-prvs: <BY5PR11MB42910A8F86BBC2BE71B64B06D68E0@BY5PR11MB4291.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0417A3FFD2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: f5PDTbFQS5HiMUQ1vziKHMUabHu1f71VFy/NX0+OEufCJLkMcxmF6x8Ag3PYg/a3Kd9EZniirDNYC0RirovLp5rTtG3ocHDuO652yUbEJaZiC1Y/4pQP/A3ZipWYEjubKdUg0qatwpeZAqs5+S4QA/iy1lkZcMNX5lQ0VW7fgaQ9i+0HAgQwZgdVnl20+DjHLy06Rpi5uMqVH1A2XjPgE1dBHbzNpe0fU1DAhChFrxmqxfzHML+Mv8zRoqljbJ+yWZtpBwPFfS2cxU2JDSw8l37924M9r2RwyddqbkPzrP/t5bBWW9tAKPOT7wgEfns5bxQprg03e+Myiag85obTjA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(39860400002)(136003)(376002)(2616005)(54906003)(8676002)(2906002)(4326008)(6512007)(316002)(76116006)(186003)(66476007)(36756003)(64756008)(26005)(53546011)(5660300002)(71200400001)(33656002)(478600001)(110136005)(6506007)(66446008)(86362001)(66556008)(83380400001)(8936002)(6486002)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: FUZdDEStbBdhfC9cB/Og0K6oURhgiesRaw7hPOzrS/UmE3weK8nX6ltCJJ2Knh/rl2Fykji86pOInNlo1DLEeFDpn3vwb2LG5G1LNtkpkxTw1MGoyKfLrg6a15QNJQgnE/h3pMrErJonak1fDWHXLeCUGZ/t8OgKf08ev/SNxuew2y4IF2+utKMZGBQrp9Yjmb8fED6a9svv1nkT1EsJBlpZ/Ro8OHK0QuChko7Hhvurbk3mPZH9pbg44Rr0bos7sGujrWj6c0ywhb5pGZcGtXkjpi2NboKICTv82oDAdA7F5cmdv6VvrMKNnfwx1ikcPE0bzxZK8qhUNWn5YDiARZkzZXq3m2V9oCtNWVIcuxRvzHKeMaKEffLKNRfqYFYJuN82ddClZAvEf7fvkR4ZSr1r4TLFAQ2qX1397ZISWOM5ZXFYaksBrL7dtc8cDK6ARd4f06e4LsITKCYyltuJyeC2GNrgg6xOGpiX0eRiWMNyvF+Dhui1Gi2lyCIMlpjG
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A3D258A27E406D429AF4A6F04A17D703@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e335dee0-8bd8-4f39-b746-08d802a2d0eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 01:02:38.4182 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BFZmROvb6gvBLnlTJU8xWsLzPWYJLNtTj+g/wlUnh9rRnvm7T77XO7HkhjNh+0OwlBxW/TOlfvu6eh5RtfUw+g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4291
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/HFodDfEJ53gHTF_VEylQiZAnRJo>
Subject: Re: [secdir] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 28 May 2020 01:02:52 -0000

Hi Jim,
Apologies for not being more clear, see more context below:

On 5/26/20, 7:57 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:

    Nancy - one clarification please
    
    jim
    
    -----Original Message-----
    From: Nancy Cam-Winget via Datatracker <noreply@ietf.org> 
    Sent: Tuesday, May 26, 2020 2:23 PM
    To: secdir@ietf.org
    Cc: cose@ietf.org; last-call@ietf.org; draft-ietf-cose-rfc8152bis-algs.all@ietf.org
    Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08
    
    Reviewer: Nancy Cam-Winget
    Review result: Has Nits
    
    IOTDIR review of draft-ietf-cose-rfc8152bis-algs-08
    
    Reviewer: Nancy Cam-Winget
    
    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 describes an initial set of cryptographic algorithms used to protect CBOR, I believe this document is almost ready, barring some editorial nits (I only made a few below).  In general, the description of the "initial"
    set of algorithms used in COSE make sense and it is good to see each section carry their own security section for better mapping of the considerations based on the security algorithm applied.  As a reader (like myself) who is not fully versant to the nuances of CBOR it was a little hard to follow as the structures and taxonomy is described in the companion draft (draft-ietf-cose-rfc8152bis-struct). As a whole, I think the document is close to ready, I only noted a few technical and editorial nits for the earlier sections below:
    
    Section 2.1:
    - What field does the ECDSA algorithm value map to? I presume it is the 'alg'
    field (if present)? But should be made explicit. - It seems that the "should"
    in the 4th paragraph is normative (e.g. SHOULD) as it is needed for interoperability, and perhaps even a MUST as I'm not seeing negotiation or selection of curve choice.  So, if it is to be implicit, then a MUST would be more appropriate.
    [JLS] I don't think I know which "should" you are talking about.  The word does not exist in that paragraph so I don't know for sure that I have the same number.
[NCW] The sentence doesn't have a SHOULD though I think the word "suggested" should be stronger; e.g. "In order to promote interoperability, SHA-256 SHOULD be used with curve P-256...."
    
    Section 2.2:
    - The rationaleThere may be some corner case in which there may be a very large
    (2K?) structure to be protected.  It would be better to quantify "extremely large" or perhaps another/additional rationale for the need to ONLY do Pure edDSA is the intent for constrained devices not have enough memory to compute the block updates.
    
    Section 4.1.1:
    - GCM's limitation for one encryption string is 2^39-256 e.g. not "a single key"....so sufficiently large for COSE!  However, it does mean that the nonce MUST be unique for every encrypted message (e.g. the bullet before this one is correct).  I think the limit for one key using GCM is based on the size of the nonce as it must be unique.
    
    Section 4.2:
    - 'k' is the key size in bits (I presume), would be good to describe that before the table.
    
    Editorial nits:
    Section 1.5
    - The second sentence is hard to parse.  Is it that the intermediate values used for debugging are represented in both a hex as well as a CBOR diagnostic notation format"? - Third sentence, is it that some examples were designed to fail (e.g. they are "failure test bases")?
    
    Section 2.2:
    - The rationale for why Pure EdDSA is used only (vs. HashEdDSA) may leave more room for questions; as there may be some corner case in which there may be a very large (2K?) structure to be protected.  For those that are in the healthcare sector (of IoT), I could see potential for large blocks and may wonder what qualifies as "extremely large".  RFC 8032 speaks to HashEdDSA as providing better collision resilience...so am inclined to suggest to either remove this rationale or be more complete in justification.
    
    Section 3.1
    - 3rd paragraph: "Some recipient algorithms carry the key while others derive a key from secret data"....I think you mean "Some algorithms are used to transmit a key, e.g. key wrapping."  "Carry the key", in this sentence leads me to imply it's the same key being used in the HMAC.