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