[acvp] ACVP draft comments

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 28 March 2019 10:17 UTC

Return-Path: <yaronf.ietf@gmail.com>
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 14DEF12030A for <acvp@ietfa.amsl.com>; Thu, 28 Mar 2019 03:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.275
X-Spam-Level:
X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 TOFMK4HCTlsZ for <acvp@ietfa.amsl.com>; Thu, 28 Mar 2019 03:17:42 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EFB1202E8 for <acvp@ietf.org>; Thu, 28 Mar 2019 03:17:42 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id q1so22152887wrp.0 for <acvp@ietf.org>; Thu, 28 Mar 2019 03:17:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=krmHFzFcgIx4iNB86BVSg2jfMhWulpF5LVVB4gKWf3M=; b=sspvvzeyDDu4xcmulPAy70ge68MUdJV5ZFgHXGKuw9D77MXo8Dmy4XOaRxKDwR1AFm UVNve8oviBAJ+/n4fEGzHhPKMjnywpUTdIH4+dR+80HQ15NkS8T4NoDrW85PVtMjkAOn HRlGEGUbpQ+a0naS27kvwA803WYRNvQab/SNw0+D0/ZNAVl7an54JJXb+Tv3UMvpAW6D jk4vLUNIsJqO8mvAqIGxvvJTGj5Ngx87kENBG9TN1IOTqQ6pBET4LUfrENxPAjSfDgRg Vrsn3JykREbuk/XaiFTmg4NssXL+bIrir5GRveR3hR4URxZwgZpRWCPuFoJHB913AU7A 8HjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=krmHFzFcgIx4iNB86BVSg2jfMhWulpF5LVVB4gKWf3M=; b=o0uZ/qc4t1bEzGrHaxZsXHKn/6KM7MjiZQmKs8CQlaKUH/4dWsjvkvXxU+NiSLTJ5J CNyRNdMDDCeGWGxL8nhVM4MDrLYbAzQCdDgvuuJr3LCDyM6Xof+MYT+pIERBdv5iBkFU 6WB3Ucb4APg/8eQLdyHiZWfSSA4VpEm+MSndA4IW9kRoAdQSfiBPdLncDzl5gZaYmWqm JOmtfZqIIxW9zZM+X8eY3BS44sGu3/S9V4Jnb+1CSkXuCROfaM/gtSPtYMqslqpQLIhe fDK1xc1kK+A5dDGYoiAAv2fHPySc+aLBZJACDWWLIT+OoXkQs2M2a5APRSPgTUHY3Jus X4IA==
X-Gm-Message-State: APjAAAW9qu+6KGPuwqG588H23kHpdW1NPX2Ac+mWMwMR567AM/oQAB6t DXQZepTIdhHS8Y0nfWCkz2zUQoSHTLs=
X-Google-Smtp-Source: APXvYqyJpPa0OTJBijBBMj9vtlcR3NFjRwE424wKsGQcGdF9nXUDN7C96mZx8KHDmTEyZVfX6LMdUw==
X-Received: by 2002:adf:f344:: with SMTP id e4mr25531418wrp.77.1553768260526; Thu, 28 Mar 2019 03:17:40 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:7458:1a7d:5053:53c6? ([2001:67c:370:128:7458:1a7d:5053:53c6]) by smtp.gmail.com with ESMTPSA id i18sm20616935wrm.7.2019.03.28.03.17.39 for <acvp@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 03:17:39 -0700 (PDT)
To: acvp@ietf.org
From: Yaron Sheffer <yaronf.ietf@gmail.com>
Message-ID: <4e4587bf-6444-d9a1-21bb-400b69e9548b@gmail.com>
Date: Thu, 28 Mar 2019 11:17:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acvp/jFxmJpJmrz0_-pcvMUnV0MmA5T0>
Subject: [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 10:17:57 -0000

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/" rel="nofollow">https://json-schema.org/) 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?