Re: [acvp] ACVP draft comments

"Celi, Christopher T. (Fed)" <christopher.celi@nist.gov> Thu, 28 March 2019 14:44 UTC

Return-Path: <christopher.celi@nist.gov>
X-Original-To: acvp@ietfa.amsl.com
Delivered-To: acvp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1113F12042D for <acvp@ietfa.amsl.com>; Thu, 28 Mar 2019 07:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 AWB4d87h1JHo for <acvp@ietfa.amsl.com>; Thu, 28 Mar 2019 07:44:41 -0700 (PDT)
Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830135.outbound.protection.outlook.com [40.107.83.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4731202BA for <acvp@ietf.org>; Thu, 28 Mar 2019 07:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=scXZ75fcGuYWLjD9AoZpfTyJVrgxHoGjinf1OKJyc6o=; b=cJ60pCS2E+sLohqsBAry6X512Elldghi2VoULD/i69HvTzTr/f8d6R4+NywT8gOwczepSIml023FLV9wKCZiCLhJ8BYtTdMXjHkH115c2FlC7qFTobMd1B+ieCe7dO5tpQ4u9l29VRo8rcP21o6BlKNPnDQDq0Tao7c8SoI418g=
Received: from BL0PR0901MB3697.namprd09.prod.outlook.com (52.132.24.147) by BL0SPR01MB0028.namprd09.prod.outlook.com (52.132.31.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Thu, 28 Mar 2019 14:44:39 +0000
Received: from BL0PR0901MB3697.namprd09.prod.outlook.com ([fe80::1dad:f02c:c917:4793]) by BL0PR0901MB3697.namprd09.prod.outlook.com ([fe80::1dad:f02c:c917:4793%5]) with mapi id 15.20.1750.014; Thu, 28 Mar 2019 14:44:39 +0000
From: "Celi, Christopher T. (Fed)" <christopher.celi@nist.gov>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, "acvp@ietf.org" <acvp@ietf.org>
Thread-Topic: [acvp] ACVP draft comments
Thread-Index: AQHU5U+SiFYjylJ9JEq68kvj4u47g6YhHq3K
Date: Thu, 28 Mar 2019 14:44:39 +0000
Message-ID: <BL0PR0901MB36971533A189FB87BE54BD45F0590@BL0PR0901MB3697.namprd09.prod.outlook.com>
References: <4e4587bf-6444-d9a1-21bb-400b69e9548b@gmail.com>
In-Reply-To: <4e4587bf-6444-d9a1-21bb-400b69e9548b@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christopher.celi@nist.gov;
x-originating-ip: [2610:20:6005:218::3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6b0dca10-7d84-4cc1-b0ad-08d6b38be7f0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BL0SPR01MB0028;
x-ms-traffictypediagnostic: BL0SPR01MB0028:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BL0SPR01MB002846B33072C5EE5EB535ABF0590@BL0SPR01MB0028.namprd09.prod.outlook.com>
x-forefront-prvs: 0990C54589
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(396003)(346002)(136003)(376002)(189003)(199004)(55016002)(54896002)(7696005)(186003)(53936002)(6306002)(9686003)(316002)(74316002)(236005)(33656002)(7736002)(19627405001)(106356001)(105586002)(2906002)(6246003)(102836004)(71190400001)(6116002)(68736007)(97736004)(71200400001)(606006)(6436002)(14454004)(46003)(52536014)(229853002)(6506007)(53546011)(86362001)(5660300002)(478600001)(446003)(11346002)(476003)(486006)(25786009)(8936002)(256004)(14444005)(110136005)(2501003)(6606003)(81156014)(81166006)(76176011)(99286004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0SPR01MB0028; H:BL0PR0901MB3697.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: JYjJ7dxGlGU6DIf/1oqZxvzG1Q/am6qv0DogCGn7ET9ZMCn661I65jLX0/HF3iefV9uJUE1UBdYVtXkjDH86asPYk4/0Cfd3jotMFjDDAW6JGnQgnIe5/1CU6JpUYVg/a8S9TJF4wlY2BZo3nYcF8SvveIS85xKddvnk97LrEFo+9n7DnvaAa59RLELa1KWie/70V38yvh3BCu0S8I2SDbHNc4Fjol/Mb+d7lc/R/md38X7289pR0oZFtlefXGeUbHMNLejKeeG+rH1iVRl/P1+doBUfZcfZY6/NOr46p/W0fj8mm+MKtFuzUWUxhYBJBLHLK+/wwIHstdjRgRNciWljkr4r8jUiou6Y+iBgXW/XFMC5JofmvutgvT5F8clTZm9baCuOISTpTpH9TXPTVQWlrECYOX+CQTJ8vP7cnAo=
Content-Type: multipart/alternative; boundary="_000_BL0PR0901MB36971533A189FB87BE54BD45F0590BL0PR0901MB3697_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b0dca10-7d84-4cc1-b0ad-08d6b38be7f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 14:44:39.0989 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0SPR01MB0028
Archived-At: <https://mailarchive.ietf.org/arch/msg/acvp/g6yqoXKeEl3r7MvudQ3PzH9HT80>
Subject: Re: [acvp] ACVP draft comments
X-BeenThere: acvp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Cryptographic Validation Protocol <acvp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acvp>, <mailto:acvp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acvp/>
List-Post: <mailto:acvp@ietf.org>
List-Help: <mailto:acvp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acvp>, <mailto:acvp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 14:44:46 -0000

Hi,


In the symmetric block cipher draft, there is negative testing for GCM (and GCM-SIV) decryption operations.


Thank you for the feedback.


Chris Celi

________________________________
From: acvp <acvp-bounces@ietf.org>; on behalf of Yaron Sheffer <yaronf.ietf@gmail.com>;
Sent: Thursday, March 28, 2019 6:17:39 AM
To: acvp@ietf.org
Subject: [acvp] ACVP draft comments


Hi,


I reviewed the spec in some depth, but only skimmed the other major document. So here are a few comments. Thank you for this important work!


    Yaron


* FCS: expand the acronym: in the Terminology section?

* Why support HTTP (as opposed to HTTPS) at all? IMO TLS should be REQUIRED, not RECOMMENDED.
* What is the difference between validation testing and crypto assessment testing?
* The notion of "verifiable artifacts" is not well defined here or possibly even bogus (any crypto module can be subverted to produce fake results), so I wouldn't use it.
* Authentication should actually be in scope, at least to enable a minimum interoperable implementation.
* "Mutual authentication", you probably mean TLS with mutual certificate-based auth, please clarify.
* DRBG: expand.
* Figure 1: I would think the DUT is only the crypto module, and does not include the ACV client which is not actually being tested.
* 4.1: please clarify the notion of real-time vs. non-real time operation. It's not clear to me where real-time testing can be useful. (This is explained later, so maybe add a forward reference to the Terminology).
* I am sure you're already used to it, but first-timers will be highly confused by the sense of request+response which is opposite the usual: server to client. Can we rename them?
* 5.1, please use an example.com URI (RFC 6761).
* 5.1, version numbers are later included in the URI, but not here. Why?
* 6.1, as noted above, IMO a single baseline authentication method should be mandated, though implementations may choose to add others.
* 7: the word "extensions" should be quoted. Better yet, give an example. It is also very common to have an IANA registry for extensions names, in order to avoid conflicts, and/or to give a naming convention such as using a DNS name of the organization (similar to Java packages).
* 8: this is not well-specified. What if a new port is NOT required? Also, what is the syntax for the secondary port? How is it authenticated? And in fact, why is it ever needed, i.e. why would a server agree to accept on an auxiliary port what it refuses to accept on the main port?
* 9. This section mentions "major/minor" but the examples all have "v1". In general this section needs a lot more clarity.
* 10. Maybe start the section with a quick overview of the message exchanges.
* 10.1. Primary contact? I'm not sure it is useful to configure people's names on the servers.
* 10.2. It is implied that you cannot have multiple outstanding requests in parallel for the same client. I suggest to make it explicit.
* 10.3. Alg:none should never be used in production, and also, never in a standard.
* 10.3. "Key agreement would follow RFC7518." I'm not sure what you mean. I suspect you want to say, Keys are pre-provisioned to the client and server according to RFC 7518.
* 10.3. More work is needed on the JWT: you want integrity protection, not encryption. Unless you're passing the database key, in which case you do need encryption. HS256 is obviously only integrity protection. Also, you'd want a public key (RS256) rather than a shared HMAC key, for better security.
* 10.3.2. Why use the expired token in the exchange? This means the server should have a special case where it accepts expired tokens - not very good.
* 10.5. Please avoid Markdown "bold", it doesn't render correctly in the text version.
* 10.5. We should discuss the use of JSON Schema (https://json-schema.org/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjson-schema.org%2F&data=02%7C01%7Cchristopher.celi%40nist.gov%7Cbe9138758ab342dcaa8808d6b366b487%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636893651028812930&sdata=0mnEIPMOjEgXire%2BsAb0WSHNcgDKYQCvaLFNxjVOu5Q%3D&reserved=0>;) to avoid lengthy an ill-defined examples.
* Are you sure you want the complexity of PUT, with per-property updates? This breaks once you have arrays. For example, you cannot add or remove a single phone numbers, you have to specify them all.
* Having the DELETE methods as "optional" makes it very hard to test this API. I would suggest to have them as mandatory, but *allow* servers to refuse them based on policy (and then return an error code).
* 10.8.3. Dependency properties seem to introduce too much complexity. I would assume they can be hardcoded or maybe specified here, but not available for listing/parsing at run-time.
* Algorithms: in many cases you have a cross-product of name X key-length X mode. Maybe for these cases you want an array of available key-lengths and an array of available modes, provided all combinations are supported.
* What does "encrypt at rest" mean, and why is it a parameter at all?
* When listing sessions, I would expect a status field: not-started, in-progress, complete-passed, complete-failed.
* Why is there a per-session access token, why not reuse the on-going login based access token?
* "Expiry" field, please use standard ISO8601 time, as usual. Besides, the current format lacks a time zone.
* 13. Returned errors: please use RFC 7807 rather than creating a new format.
* IANA section: better incorporate it into the main document.
* draft-celi-block-ciph: is there any support for negative testing, specifically cases where AES-GCM decryption should fail because the auth tag is incorrect?