Re: [6lo] [Lake] SEC-DIR review of AP-ND:
Jim Schaad <ietf@augustcellars.com> Mon, 03 February 2020 22:50 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1002B1200B1; Mon, 3 Feb 2020 14:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8_GjJoUDUTMH; Mon, 3 Feb 2020 14:50:03 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46DDB12001B; Mon, 3 Feb 2020 14:49:09 -0800 (PST)
Received: from Jude (50.38.98.51) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 3 Feb 2020 14:49:03 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Rene Struik' <rstruik.ext@gmail.com>, "'Pascal Thubert (pthubert)'" <pthubert@cisco.com>, draft-ietf-6lo-ap-nd@ietf.org
CC: 6lo-chairs@ietf.org, "'Shwetha Bhandari (shwethab)'" <shwethab@cisco.com>, 'The IESG' <iesg@ietf.org>, 6lo@ietf.org, 'Benjamin Kaduk' <kaduk@mit.edu>
References: <MN2PR11MB3565A885E27E86C53205825BD8000@MN2PR11MB3565.namprd11.prod.outlook.com> <020301d5dabe$01c24d10$0546e730$@augustcellars.com> <d020a2b2-0fd6-b95d-dc1f-f16c143ab126@gmail.com>
In-Reply-To: <d020a2b2-0fd6-b95d-dc1f-f16c143ab126@gmail.com>
Date: Mon, 03 Feb 2020 14:49:01 -0800
Message-ID: <024a01d5dae4$22e79a60$68b6cf20$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_024B_01D5DAA1.14C98A80"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI51a2x6Xn9gJl7cgl9kt+4OYRyJQHfM/BXAXP0gJ2nJ3dWoA==
Content-Language: en-us
X-Originating-IP: [50.38.98.51]
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/ETJ6s73cTISibcHWB8k3QmJJVPk>
Subject: Re: [6lo] [Lake] SEC-DIR review of AP-ND:
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2020 22:50:06 -0000
From: Rene Struik <rstruik.ext@gmail.com> Sent: Monday, February 3, 2020 12:47 PM To: Jim Schaad <ietf@augustcellars.com>; 'Pascal Thubert (pthubert)' <pthubert@cisco.com>; draft-ietf-6lo-ap-nd@ietf.org Cc: 6lo-chairs@ietf.org; 'Shwetha Bhandari (shwethab)' <shwethab@cisco.com>; 'The IESG' <iesg@ietf.org>; 6lo@ietf.org; 'Benjamin Kaduk' <kaduk@mit.edu> Subject: Re: [Lake] SEC-DIR review of AP-ND: Hi Jim: Just weighing-in on this: see below. Best regards, Rene On 2/3/2020 1:16 PM, Jim Schaad wrote: What is following is personal opinion (although I will admit to being one of the DEs on these registries): 1. I don't think that you are going to be able to start doing compressed points easily in JOSE. It is a design philosophy that people really wanted at the time. There was extensive discussions about getting compressed points as well as how to expressed the point format. RS>> I would be curious what this design philosophy was: if there is a record of this, that would be great. It would be particularly interesting to understand the reasoning as to why for Montgomery curves and twisted Edwards curves compression is a must, while for short Weierstrass curves this is forbidden... This is not just so with JOSE, it is also in RFC 8152 (OKP vs. EC2 distinction). It seems to be pretty random. <<RS [JLS] I would suggest going and reading through JOSE mailing list for how things were setup for there. I think that you and I have a different view of how the curves are setup for the difference between OKP and EC2. For the EC2 curves, there are both an X and a Y point publicly provided to the user. For the Edwards curve, only the X portion of the point is provided publicly to the user. This means that there would be a large discussion of what should be done with the Y coordinate. Being able to validate that the correct set of fields are present without having to understand all of the fields is considered to be desirable, at least by me, so reflecting that difference between the two key formats is logical. I don't see it as being random at all. I can see some future three coordinate version of a hyperspace that might come in the future that would get some type of 3 point public key and that would again require a new key format to be defined. (Note that I have no reason to expect it, just that I can imagine it.) 2. In my opinion, table 2 should not be referencing the Curve25519 in the last column. From my point of view when curves are expressed as using different coordinate systems then you need to be expressing these as different curves. An algorithm negotiation currently only needs to include the curve and not additionally include the point format. This needs to be maintained. I therefore believe that a new curve code point should be registered here. That is the only registration that I believe needs to be done in the JOSE registries. RS>> Please note that the different crypto types in Table 2 refer to complete specifications of signature schemes, including point representation, bit/byte ordering, etc. Please note that curves expressed in different coordinate systems are not really different: only their representations are (unfortunately, this confusion is caused by heavy marketing by some people in the past). The different representations, not just of curve points, but also LSB/MSB and lsb/msb ordering conventions, are already captured in Table 2. Since different bit/byte ordering, even with the same curve, makes a difference, representation conventions are the guiding metric, not just different curve models. <<RS [JLS] If you do not plan to use either JOSE or COSE key formats, then you are free to do what you will. If you want to use those key formats then I am afraid that you are going to need to deal with the perceptions of the people who currently hold the review world there. 3. Note, I find section 7.5 to be missing a small piece of guidance that might be needed. If you use the "same" private key for both the Edwards and Weierstrass curve representations, is that a problem according to this guidance? RS>> Reuse of the same public-private key pair with different signature schemes is not allowed. <<RS [JLS] And are they different signature schemes? Some people might not think so based on what is currently documented. Can you switch the signature format between the two schemes? If so does that mean that they are really different? Jim From: Lake <mailto:lake-bounces@ietf.org> <lake-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert) Sent: Monday, February 3, 2020 5:29 AM To: draft-ietf-6lo-ap-nd@ietf.org <mailto:draft-ietf-6lo-ap-nd@ietf.org> Cc: 6lo-chairs@ietf.org <mailto:6lo-chairs@ietf.org> ; Shwetha Bhandari (shwethab) <mailto:shwethab@cisco.com> <shwethab@cisco.com>; The IESG <mailto:iesg@ietf.org> <iesg@ietf.org>; 6lo@ietf.org <mailto:6lo@ietf.org> ; lake@ietf.org <mailto:lake@ietf.org> ; Benjamin Kaduk <mailto:kaduk@mit.edu> <kaduk@mit.edu> Subject: [Lake] SEC-DIR review of AP-ND: Dear all During SEC-DIR review, Benjamin pointed out: > Why do we need to allow ambiguity/flexibility as to the point representation > within a given Crypto-Type value (as opposed to fixing the representation as a > parameter of the Crypto-Type)? Alternately, what does "(un)compressed" > mean, as it's not really clarified directly? Furthermore, Table 2 lists an > "(un)compressed" representation for type 0 (over P-256), but RFC 7518 notes > that the compressed representation is not supported for P-256 (Section > 6.2.1.1). I also am not finding the needed codepoints registered in the JOSE > registries to use ECDSA25519 (crypto-type 2) -- do we need to register > anything there? Any idea how we can address this? In particular does anyone know why RFC 7518 does not support the compressed representation for P-256? Cc'ing LAKE on the impact of this Pascal -- email: rstruik.ext@gmail.com <mailto:rstruik.ext@gmail.com> | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
- [6lo] SEC-DIR review of AP-ND: Pascal Thubert (pthubert)
- Re: [6lo] [Lake] SEC-DIR review of AP-ND: Jim Schaad
- Re: [6lo] [Lake] SEC-DIR review of AP-ND: Jim Schaad
- Re: [6lo] [Lake] SEC-DIR review of AP-ND: Rene Struik
- Re: [6lo] [Lake] SEC-DIR review of AP-ND: Rene Struik
- Re: [6lo] [Lake] SEC-DIR review of AP-ND: Jim Schaad
- Re: [6lo] [Lake] SEC-DIR review of AP-ND: Rene Struik