Re: [Lwip] Secdir early review of draft-ietf-lwig-curve-representations-08
Rene Struik <rstruik.ext@gmail.com> Tue, 26 November 2019 19:54 UTC
Return-Path: <rstruik.ext@gmail.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4641208E5; Tue, 26 Nov 2019 11:54:41 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Q6_SOE6gowyP; Tue, 26 Nov 2019 11:54:38 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 AD449120018; Tue, 26 Nov 2019 11:54:35 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id e187so17287608qkf.4; Tue, 26 Nov 2019 11:54:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=BMJHI5pTaajvetCSuv4xiig+mOMWowG7+MzTTFsMLmU=; b=qeobCG2kvpXdZOxHC5UMF1FlySxfXRa83HPcFpM/myiPakg/9Uc+c2nBfK0QqzCotK bti8olbHokcQCwv1jRCGSRJMYU+ImLpzgXytw+FQSqti2efZBOv/bGADxoeKKeIPqXls Qh1+ggvS3STMwN+0rdAEe6bO5QWRVk7i+6n6rfn27KGUS6TzwMvzqRvCqqT+xqxInilB 6Xpjk3wRVBjZsVhaj/5qNXpUzkVdrqFmCA4P1D+7JEa+MOn97yh2ZscHu9jnqWjguSZt lvwc/ATiXWDVxtaU3HxKlV0KUSBlPYtW0hAmSGazG3Z71AZzBXRlci9OG+bbaf6SXC9M grHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=BMJHI5pTaajvetCSuv4xiig+mOMWowG7+MzTTFsMLmU=; b=IHMHHbvKO/FwQYvOB7bTsbMJMHGoEg8sGi6OYcWXmH942yndyYPb8UQzqXKhFkj0k7 OJCdw0ev3z0cpSREV84mKrussQd02cjhI8Fp5xPWRb+W5+jKYVdS5kjYZg2gKeq31b0M hjEPZH9YErErPBQJw1/m9K47H/LXylCb47HWj8nOHZosgb/xiiy3teOvRR5CRQ4xxyLu 7tamquOXLGAU/dYizaJ4Nkna+1JgVdPgySTreq3NyK/zSAzboyuiTfl/8+YQCZ4Xg5sT FQPdFyNX9A5bH6j7zt129wAT06h+gah74eu5VBUKOpA/GnsZY+nBBDkwbIRqY4PjVe/f SbWg==
X-Gm-Message-State: APjAAAWlEnp9g7ROw5oPk4ybL4uqfO2KC8EW8/J6b+YADMZdV69e/G4p A9WrTAxpPxwgdXBX8YxDKHDCkKCn
X-Google-Smtp-Source: APXvYqwapFtabMQ/8oA3TrbblmbtMdXq/e5/zloL1InLDIvjLUIfDHpSYH1T3ANe3lc1A8AMaAmAeg==
X-Received: by 2002:a37:9cd:: with SMTP id 196mr96837qkj.325.1574798074320; Tue, 26 Nov 2019 11:54:34 -0800 (PST)
Received: from ?IPv6:2607:fea8:69f:fa3a:fc5f:12b:d173:619a? ([2607:fea8:69f:fa3a:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id d15sm5518286qke.55.2019.11.26.11.54.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Nov 2019 11:54:33 -0800 (PST)
To: Russ Housley <housley@vigilsec.com>, secdir@ietf.org
Cc: lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org
References: <157479110201.13605.6894641490219218764@ietfa.amsl.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <e7a4a264-b38d-5a0e-0418-90eb9684fc30@gmail.com>
Date: Tue, 26 Nov 2019 14:54:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <157479110201.13605.6894641490219218764@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/aks5MPDjKa1ygms4v03iuhwT9dE>
Subject: Re: [Lwip] Secdir early review of draft-ietf-lwig-curve-representations-08
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Nov 2019 19:54:41 -0000
Dear Russ: Thanks for your review (and speedy turn-around). Please find below feedback on how I intend to address all but your last remarks (I will reflect on your suggestion as to introductory text with the appendices when looking over Daniel Migault's earlier "guidance of the reader" remarks). Best regards, Rene On 11/26/2019 12:58 PM, Russ Housley via Datatracker wrote: > Reviewer: Russ Housley > Review result: Has Issues > > I 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 authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. > > Document: draft-ietf-lwig-curve-representations-08 > Reviewer: Russ Housley > Review Date: 2019-11-26 > IETF LC End Date: unknown > IESG Telechat date: unknown > > Summary: Has Issues > > > Major Concerns: > > I am confused by the first paragraph in Section 10. It says that "An > object identifier is requested ...", but then code points for COSE > and JOSE (not object identifiers) are requested in the subsection. > > I am confused by the second paragraph in Section 10. It says that > "There is *currently* no further IANA action required ...". Please > delete this paragraph. RS>> If I remember this correctly, I borrowed this from another draft (but perhaps was somewhat ignorant here about proper formulation). I intend to change the first para to "code points are requested for ....". As to the second para, I believe it has some merit to keep this in, in slightly altered form, e.g., as "New object identifiers would be required in case one wishes to specify one or more of the "offspring" protocols exemplified in Section 4.4. Specification hereof is, however, outside scope of the current document." <<RS > Minor Concerns: > > Requirements Language section is out of date. It should reference > RFC 8174 in addition to RFC 2119, as follows: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. RS>> will do. As minor point (from a non-native speaker's perspective): shouldn't the last part of the above sentence read "if, and only if, these appear...."? <<RS > Section 2 says: "... reuse of existing generic code ..."; I do not know > what is meant by "generic". It either needs to be defined, reworded, or > dropped. I note that elsewhere in the document "existing code" is used. RS>> I will add a sentence to that effect, e.g., "(Here, generic code refers to an implementation that does not depend on hardcoded domain parameters (see also Section 6).)" <<RS > > I expected Section 9 to say something about public keys being unique > identifiers of the private key holder. RS>> I will add an extra paragraph to this effect, e.g., "Use of a public key in any protocol for which successful execution evidences knowledge of the corresponding private key implicitly indicates the entity holding this private key. Reuse of this public key with more than one protocol or more than one protocol instantiation may, therefore, allow traceability of this entity." <<RS > > Some introduction text at the beginning of each Appendix would be very > helpful. Please tell the reader what they will learn by delving into > the subsections of the appendix. RS>> I will reflect on this somewhat more (while also considering "guidance to the reader" remarks in Daniel Migault's Early IoTDir review). Broadly speaking, though, inclusion of all these appendices makes the entire docment self-contained, including arithmetic, representations, how-to-convert details, etc. <<RS > Nits: > > Section 4.2 says: "... at the end of hereof ...". This does not tell > me anything useful. I suggest deleting this phrase. RS>> I will change this to "at the end hereof" (i.e., will remove "of" - a glitch). Here, one can only recover the y-coordinate at the end of the Montgomery ladder, since one needs the x-coordinates of k*G and (k+1)*G to make this work. <<RS > I suggest turning the numbered paragraphs in Section 5 into subsections. RS>> Will do. <<RS > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
- [Lwip] Secdir early review of draft-ietf-lwig-cur… Russ Housley via Datatracker
- Re: [Lwip] Secdir early review of draft-ietf-lwig… Rene Struik
- Re: [Lwip] Secdir early review of draft-ietf-lwig… Russ Housley
- Re: [Lwip] Secdir early review of draft-ietf-lwig… Rene Struik
- Re: [Lwip] Secdir early review of draft-ietf-lwig… Rene Struik
- Re: [Lwip] Secdir early review of draft-ietf-lwig… Rene Struik
- Re: [Lwip] Secdir early review of draft-ietf-lwig… Russ Housley
- Re: [Lwip] Secdir early review of draft-ietf-lwig… Russ Housley