Re: [acvp] ACVP draft comments

Vukasin Karadzic <vukasin.karadzic@gmail.com> Sun, 28 April 2019 08:51 UTC

Return-Path: <vukasin.karadzic@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 B942D12008F for <acvp@ietfa.amsl.com>; Sun, 28 Apr 2019 01:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 UYJYkH5ts93v for <acvp@ietfa.amsl.com>; Sun, 28 Apr 2019 01:51:34 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 D9268120006 for <acvp@ietf.org>; Sun, 28 Apr 2019 01:51:33 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id d24so6145491otl.11 for <acvp@ietf.org>; Sun, 28 Apr 2019 01:51:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vUtfYNBrzBs/oldqlrC9ZUcBKmpmZenTkOw0JCyr4/w=; b=kUZQW+taBbR5vbQp6VzDzmlh1AjXw2jtuaG0tTv7XBLyBnf50tNjM6cgLj0I+rYMuy 2XsSqr95S7zGq+t4ugp5DIBWfZBOegMI1s/YEYphjCsiFfouJF5R3KBq9yjLVPmgzXlz ceD1FZScRZ2IAK73oxycXFOJgVqPnPPEGKPEnyMzMPeVdrDfuNQi1xo7dQezTmpOmDPQ D7Uwtybb4hQvu4LyDM2F23Y8x2hnOognz+gnrlF5T4OKrbJgKfqLboKud1mLNPnm9SG2 Jm40MXrhk5iMAEc+kngRgMs99qJYHZ87ohWjTgTAbL66jiOcYxLkuv/PdqxqeU+zXQR5 asUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vUtfYNBrzBs/oldqlrC9ZUcBKmpmZenTkOw0JCyr4/w=; b=uRxVrKV+W01SyfnqwwB7exUep0IaFK1PD+YgjMZi8Dii0cxWTOVOb8SAiR2IMXYMQ2 hTMTMh14kZPlW6rxso/yyIbHuyO43GvQvG/P9lvCHmF8TMZdvSnY9/Od6h8NFb7i6CkM MOHldD/8ofMYWSA1uczCHOzsYXM3rJ1CUKM/c4bsfh/soMSTrl96zL6x28ZgjsyfhCRp 7+zLaK0JbBcwdfiKndB7hnsyi9iVtRyS2d8aJDrGH4HTgkC0QtkTHWPf1EHSz64l3BbU +/cgrobuCccR5A1ICqcb76sFu2ao0rqiOfi77vOdVA6orxxWLkAhpC9/5GLux/PPX73f 1g4A==
X-Gm-Message-State: APjAAAUuXJVMY+2IyderyHFiYNimWwda14dXZN5SK9SlSH4RKtcIocMe 5PCsjAQAZXv9AnKtJ/RQenjGyo2DqTUzJRIkYlc=
X-Google-Smtp-Source: APXvYqzMuaRa//n4BQvmKfo/ozzVgdYxhU4lfeER/zp+oblM+jnoIPcRnhBnrq5swAQ7X8WN727PcHz/6qTBtnNI6Zk=
X-Received: by 2002:a9d:404:: with SMTP id 4mr32641444otc.352.1556441493201; Sun, 28 Apr 2019 01:51:33 -0700 (PDT)
MIME-Version: 1.0
References: <4e4587bf-6444-d9a1-21bb-400b69e9548b@gmail.com>
In-Reply-To: <4e4587bf-6444-d9a1-21bb-400b69e9548b@gmail.com>
From: Vukasin Karadzic <vukasin.karadzic@gmail.com>
Date: Sun, 28 Apr 2019 10:51:06 +0200
Message-ID: <CAEQ8ZZfd+81QyHmYVfC7gAh16SAKyP6Wfq8RNeAXsCKdsqmq7Q@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: acvp@ietf.org
Content-Type: multipart/alternative; boundary="00000000000050e70e05879346d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acvp/WwjA_cw9ykVVfSBUJzK3IxLuvx0>
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: Sun, 28 Apr 2019 08:51:37 -0000

Dear list,

I agree with Yaron on all of his comments. This point I understand
differently:

* 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.
>

I interpret that as DUT *does* contain the ACVP client. Can the draft
authors explain in more details how should the Figure 1. be interpreted?
Don't know if it's possible, but I would like if the different
architectures could be explained more (sections 4.1, 4.2, 4.3).

Can we expect the updated version of the draft?

Regards,
Vukasin Karadzic

чет, 28. мар 2019. у 11:18 Yaron Sheffer <yaronf.ietf@gmail.com>; је
написао/ла:

> 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/)
> 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?
> --
> acvp mailing list
> acvp@ietf.org
> https://www.ietf.org/mailman/listinfo/acvp
>