Re: [6lo] [Lake] SEC-DIR review of AP-ND:
Rene Struik <rstruik.ext@gmail.com> Tue, 04 February 2020 05:06 UTC
Return-Path: <rstruik.ext@gmail.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 D4B4612004D; Mon, 3 Feb 2020 21:06:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BtRpo4dL8xVs; Mon, 3 Feb 2020 21:06:13 -0800 (PST)
Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) (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 8BC8312002F; Mon, 3 Feb 2020 21:05:54 -0800 (PST)
Received: by mail-qv1-xf43.google.com with SMTP id dc14so7975893qvb.9; Mon, 03 Feb 2020 21:05:54 -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-language; bh=PK68X6aFbEvMwVjP3wZXiXoUSiDe05/OZrhssAp14Y0=; b=cDVkJfBmBQLoe1CKAG0aP8x1NHxykHlwp1L8uGzi+5k6pPSfWFkCz/qfLNDCDnx5OU M9mJ5vGq5YV5mMD/Jjo64aq5CUX9adOEdFaYRrt7NzWU5sg1ENK3Op77IQteQz5PQ12s r+Pm6pqwYHLbjLyy55nk9rrp/KaR9yLZG2ua1cOGM+wSE+X/tkNE5s73qHCP5alP5L9C 1FoEC8O9mKZkGrDzyutY36HPQPy4oErwVbwc23olwYB5M3w4VCUww46vcAYcO2rJ3lPW MNymT6i9J4ENzt0P86aVWo2a+cCqpnuB1MjrwpXM6u9afLm0OeJjDn8x/uUVnc7k18B3 bC2A==
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-language; bh=PK68X6aFbEvMwVjP3wZXiXoUSiDe05/OZrhssAp14Y0=; b=MtA7wOQrZ94sipBRQUH1SjhOa6aoSnVK/YOQOzIp9NsS8wXFgHPneg4D1qmUS8g+iZ PfF2QSoUsSql17WlqAzKdlBi9ZWaHa/9IwDkjnTr8MRmCxU+JeJeI3Ya4R/j7nwIxJpJ niT4mSc0yIa1Sc38q3JHb2WWihXI4sFckMaWRWkpiDiXj6PbBEJUH0lryJWgEa8brxg0 vriqMGkSwPDYktllD3vthsQuIqicQlGcezjBH2kXZO/y5gOgK88+gfaReDgedqR0BFvF kL2pPKCATA+v0JX0Ev7tNGxc9fbrs8wwy26e13AqPdT0VbvXepwTLRDjag3SyAVizkNx zYBA==
X-Gm-Message-State: APjAAAV2PotwOMgrcCxyrDbbZ/zaqD3cnseAmGvah+7XZbPA7Wi46mrK RqE+gWZrEvJPU2aG3rnHLIE=
X-Google-Smtp-Source: APXvYqxJen050GUYHAoc/KkM4/abw5HnDIijp8P4LFWohWTzEzjJwqek9epFl7QoZS7jCv3C/EsHZQ==
X-Received: by 2002:ad4:5349:: with SMTP id v9mr26607313qvs.177.1580792753521; Mon, 03 Feb 2020 21:05:53 -0800 (PST)
Received: from ?IPv6:2607:fea8:6a0:1a5a:b4ae:e9f7:285b:1316? ([2607:fea8:6a0:1a5a:b4ae:e9f7:285b:1316]) by smtp.gmail.com with ESMTPSA id w2sm11243075qtd.97.2020.02.03.21.05.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Feb 2020 21:05:52 -0800 (PST)
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>
References: <MN2PR11MB3565A885E27E86C53205825BD8000@MN2PR11MB3565.namprd11.prod.outlook.com> <020301d5dabe$01c24d10$0546e730$@augustcellars.com> <d020a2b2-0fd6-b95d-dc1f-f16c143ab126@gmail.com> <024a01d5dae4$22e79a60$68b6cf20$@augustcellars.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <172c5516-51e0-0fb2-1332-cf4704345ac3@gmail.com>
Date: Tue, 04 Feb 2020 00:05:49 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <024a01d5dae4$22e79a60$68b6cf20$@augustcellars.com>
Content-Type: multipart/alternative; boundary="------------DD89BA80E7D859BAA74F2915"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/fKYVjzJL_ZYjT0VTHvw2yZF27X8>
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: Tue, 04 Feb 2020 05:06:16 -0000
On 2/3/2020 5:49 PM, Jim Schaad wrote: > > *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.) > RS2>> In the future, one may indeed have to deal with definition of new key formats (which is beyond scope of ap-nd deliberations). Just for clarity: For EdDSA, one currently, uses lossless point compression, whereas for X25519, one exchanges only the x-coordinates (lossy compression), and for Weierstrass curves one uses lossless, but uncompressed coordinates. <<RS2 > > > 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. > RS2>> If not both entries in the tuple (curve, representation conventions) are the same, then reuse of the long-term public-private key pair may not be safe. As an example, if one were to use Edwards25519 with deterministic Schnorr and defines two instantiations, viz. (1) with LSB/lsb representation and (2) with MSB/msb representation, then one can certainly not reuse long-term public/private key pairs, since this would immediately expose the private key (since the hash function H(R,Q,m) would have differently formatted representations of R:=kG and Q:=dG. I hope this illustrates that representation conventions are an essential part of a signature scheme. In the end, we both mean the same thing, except that my statement was a little bit broader, in the sense that representations are another input parameter of an instantiation of a signature scheme. <<RS2 > > 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? > RS2>> Those schemes are different per the remark above, since the pairs (curve, representation conventions) are different. Perhaps, reformulating this as different instantiations of signature schemes would satisfy your remark? <<RS2 > > Jim > > *From:* Lake <lake-bounces@ietf.org> > <mailto: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) <shwethab@cisco.com> > <mailto:shwethab@cisco.com>; The IESG <iesg@ietf.org> > <mailto:iesg@ietf.org>; 6lo@ietf.org <mailto:6lo@ietf.org>; > lake@ietf.org <mailto:lake@ietf.org>; Benjamin Kaduk > <kaduk@mit.edu> <mailto: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 -- email: 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