Re: [Curdle] Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07

Daniel Migault <daniel.migault@ericsson.com> Thu, 06 June 2019 15:00 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D237F120115; Thu, 6 Jun 2019 08:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 N3irc2otv2kg; Thu, 6 Jun 2019 08:00:05 -0700 (PDT)
Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (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 5EB101200F9; Thu, 6 Jun 2019 08:00:05 -0700 (PDT)
Received: by mail-qt1-f173.google.com with SMTP id u12so3020714qth.3; Thu, 06 Jun 2019 08:00:05 -0700 (PDT)
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=06a5Q6j5d41VhLQ8CjqsgkWYMvugZi9dljdu5qxnvbc=; b=nejmWecYswRLcZSUK0KE8WV5KBZx2dh4RHVPZ9e121pY3jn9sFkpUdau+nwd2K9l5o mTJPawmoLl1dbgbaIULURspf1/NsH3LdQUj7RUgMqRSXJ+6FtZx9qAwojVSoMz8079wq MwokOgYgu6nF0089pcdJLi6r1763SAayF30ERwGv/x07JQ+l2EiOJ1TsqQAfe0oddmQ9 Nr37P0/K9ObYjR04PeZohfXewucPsRpsXFHLuCXwmORnRit1TOvmDvxJof2q9mLOW7hl ThmmC0lnnNaX+wqP3QdexAI5sBic0Hb9lXZ6q0wf7ptWyxSTEnwm/gqrX9iUe4LTM7l9 zzcg==
X-Gm-Message-State: APjAAAUVzA7EYbc/k6U2o8OTZhDVtOYD5UESjT44vbKzmRuzbOLCM7EH djz0JQ2U3lUPQRrqXnR8f2WMK1ES33WURTgmQY4=
X-Google-Smtp-Source: APXvYqyGZuSYe97ik0iSmAgEwkZ/KSdsH7TwNRM70B/A+cvTsuTjuF/GDn+3GFhEPlE4MKl7KOY3OUzgXxUwbv3GYyg=
X-Received: by 2002:aed:2dc7:: with SMTP id i65mr41266537qtd.365.1559833204264; Thu, 06 Jun 2019 08:00:04 -0700 (PDT)
MIME-Version: 1.0
References: <154642329120.32625.18387931087720472774@ietfa.amsl.com> <BL2PR15MB0947E4B0DCC8C36615F09B4DE38C0@BL2PR15MB0947.namprd15.prod.outlook.com> <BN6PR14MB11069BB257E0A8B2627522C8838C0@BN6PR14MB1106.namprd14.prod.outlook.com> <BL2PR15MB0947FEA09887D6D43FCD2B2AE38C0@BL2PR15MB0947.namprd15.prod.outlook.com> <5D36713D8A4E7348A7E10DF7437A4B92902DEBEC@NKGEML515-MBX.china.huawei.com> <BL2PR15MB0947AB8A5ED7E28E5EC4B8E4E38D0@BL2PR15MB0947.namprd15.prod.outlook.com> <CADZyTkmV_YbUW_Evf=rRLhXmTSeVqiRWozONoufRSU0oQsuhBQ@mail.gmail.com> <CAOp4FwQKkjP9NcyyhpcVT=c2M0zVr3CaHtbB+k0cWkh0Y_AH3g@mail.gmail.com>
In-Reply-To: <CAOp4FwQKkjP9NcyyhpcVT=c2M0zVr3CaHtbB+k0cWkh0Y_AH3g@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 06 Jun 2019 10:59:52 -0400
Message-ID: <CADZyTknDiL=CFMn6rt3vwkT+4CdJOkuMPDThHiG2i0af95X9+Q@mail.gmail.com>
To: Loganaden Velvindron <loganaden@gmail.com>
Cc: Sheng Jiang <jiangsheng@huawei.com>, Tim Hollebeek <tim.hollebeek@digicert.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" <draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org>, "curdle@ietf.org" <curdle@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000c9163058aa8f895"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/Ax11LZPCep_xED_xL2juDDRoRBg>
Subject: Re: [Curdle] Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2019 15:00:09 -0000

This is correct, I was looking at the wrong version 07. I believe this
issue is now closed.
Yours,
Daniel

On Thu, Jun 6, 2019 at 2:13 AM Loganaden Velvindron <loganaden@gmail.com>
wrote:

> I believe that this change already took place in rev08. What more do we
> need to add ?
>
>
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-curdle-ssh-ed25519-ed448-08.txt
>
>
>
> On Wed, Jun 5, 2019 at 5:53 PM Daniel Migault <daniel.migault@ericsson.com>
> wrote:
>
>> Dear co-authors of curdle-ssh-ed25519-ed448,
>>
>> Could we update the document and address the concern from Sheng ?
>>
>> Yours,
>> Daniel
>>
>> On Thu, Jan 3, 2019 at 11:23 AM Daniel Migault <
>> daniel.migault@ericsson.com> wrote:
>>
>>> Hi Sheng,
>>>
>>> Thanks for the comment. It should be easily addressed in the next
>>> version.
>>>
>>> Yours,
>>> Daniel
>>>
>>> -----Original Message-----
>>> From: Sheng Jiang <jiangsheng@huawei.com>
>>> Sent: Thursday, January 03, 2019 8:59 AM
>>> To: Daniel Migault <daniel.migault@ericsson.com>; Tim Hollebeek <
>>> tim.hollebeek@digicert.com>; ops-dir@ietf.org
>>> Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
>>> ietf@ietf.org
>>> Subject: RE: Opsdir last call review of
>>> draft-ietf-curdle-ssh-ed25519-ed448-07
>>>
>>> Hi, Daniel,
>>>
>>> The suggestion from Tim is a good improvement. However, it would be even
>>> better for a "standard track" document, if it gave a little bit more
>>> detailed guidance "where" and "how" a SSH implement should quota the key
>>> format that defined in this document.
>>>
>>> Regards,
>>>
>>> Sheng
>>>
>>> -----Original Message-----
>>> From: Daniel Migault [mailto:daniel.migault@ericsson.com]
>>> Sent: Thursday, January 3, 2019 2:57 AM
>>> To: Tim Hollebeek <tim.hollebeek@digicert.com>; Sheng Jiang <
>>> jiangsheng@huawei.com>; ops-dir@ietf.org
>>> Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
>>> ietf@ietf.org
>>> Subject: RE: Opsdir last call review of
>>> draft-ietf-curdle-ssh-ed25519-ed448-07
>>>
>>> Thanks for the suggestion Tim. That works for me.
>>> Yours,
>>> Daniel
>>>
>>> -----Original Message-----
>>> From: Tim Hollebeek <tim.hollebeek@digicert.com>
>>> Sent: Wednesday, January 02, 2019 1:12 PM
>>> To: Daniel Migault <daniel.migault@ericsson.com>; Sheng Jiang <
>>> jiangsheng@huawei.com>; ops-dir@ietf.org
>>> Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
>>> ietf@ietf.org
>>> Subject: RE: Opsdir last call review of
>>> draft-ietf-curdle-ssh-ed25519-ed448-07
>>>
>>> Why not just reference RFC 2119 and say "Standard implementations of SSH
>>> SHOULD implement these signature algorithms." ?
>>>
>>> -Tim
>>>
>>> > -----Original Message-----
>>> > From: Curdle <curdle-bounces@ietf.org> On Behalf Of Daniel Migault
>>> > Sent: Wednesday, January 2, 2019 10:43 AM
>>> > To: Sheng Jiang <jiangsheng@huawei.com>; ops-dir@ietf.org
>>> > Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
>>>
>>> > ietf@ietf.org
>>> > Subject: Re: [Curdle] Opsdir last call review of
>>> draft-ietf-curdle-ssh-ed25519-
>>> > ed448-07
>>> >
>>> > Hi Sheng,
>>> >
>>> > Thanks for the comment and the suggestion. I agree that it may sound
>>> > strange to have a standard Track category without any reference to
>>> > RFC2119. In addition, while the document provides IANA registry
>>> > updates, the IANA registration does not require a Standard Track. So
>>> > *technically*
>>> the
>>> > informational category could be fine.
>>> >
>>> > The motivation for a Standard Track document was to have these
>>> > algorithms as part of the SSH protocol. In other words, we expect that
>>> > SSH will come with these algorithms in the future. For that reason we
>>> > requested the
>>> status
>>> > to be "Standard Track" to remain coherent with RFC425{1-4}.
>>> >
>>> > (RFC4250 and) RFC4253 provided the initial values for the Public Key
>>> registry.
>>> > While the protocol comes with some registry values, my understanding
>>> > is that updating the registry by adding a new value is not considered
>>> > as an update the RFC. For that reason we did not provide RFC4253 or
>>> > RFC4250 in the update status. While the update does not concern the
>>> > RFC, it affects
>>> the
>>> > protocol and should - in my opinion be associated to the same status
>>> > as
>>> the
>>> > protocol.
>>> >
>>> > As a side note, all RFCs that have updated the Public Key Algorithm
>>> > Names are Standard Track documents. On the other hand, they seem to
>>> > reference and use the RFC2119 terms.
>>> >
>>> > I believe that the Standard Track category is the most appropriated,
>>> > however, I am happy to be wrong and have misunderstood something. Feel
>>> > free to let me know your opinion on the category, as well as if there
>>> > are
>>> any
>>> > clarification we should add in the text. I suggest that we add a
>>> > sentence around the lines:
>>> > """ These signature algorithms are expected to be integrated into the
>>> > standard implementations of SSH. """
>>> >
>>> > Any feed back is welcome!
>>> >
>>> > Yours,
>>> > Daniel
>>> > -----Original Message-----
>>> > From: Sheng Jiang <jiangsheng@huawei.com>
>>> > Sent: Wednesday, January 02, 2019 5:02 AM
>>> > To: ops-dir@ietf.org
>>> > Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
>>>
>>> > ietf@ietf.org
>>> > Subject: Opsdir last call review of
>>> > draft-ietf-curdle-ssh-ed25519-ed448-07
>>> >
>>> > Reviewer: Sheng Jiang
>>> > Review result: Has Issues
>>> >
>>> > Reviewer: Sheng Jiang
>>> > Review result: Has Issues
>>> >
>>> > Hi, OPS-DIR, Authors,
>>> >
>>> > I have reviewed this document as part of the Operational directorate's
>>> > ongoing effort to review all IETF documents being processed by the
>>> IESG.
>>> > These comments were written with the intent of improving the
>>> > operational aspects of the IETF drafts. Comments that are not
>>> > addressed in last call
>>> may
>>> > be included in AD reviews during the IESG review. Document editors and
>>> > WG chairs should treat these comments just like any other last call
>>> comments.
>>> >
>>> > This standard track document describes the use of the Ed25519 and
>>> > Ed448 digital signature algorithm in the Secure Shell (SSH) protocol.
>>> > This
>>> document
>>> > is one of the shortest documents I have ever seen. It is clear and
>>> > well written.
>>> > However, I have a fundamental issue regarding to its Intended status
>>> > "Standards Track", describe below. Therefore, it has issues for
>>> publication
>>> > although I think it is easy to fixed - changing the Intended status.
>>> >
>>> > Major issue: this document has Intended status for Standards Track.
>>> > However, neither this document fails to quota RFC 2119 or has any
>>> > normative words.
>>> > Consistently, I don't think the description in this document has any
>>> > mandatory requirements for any implementations of protocols. Actually,
>>> > the most important quota of this document, RFC8032, is Informational,
>>> > which is a Downref in this document. Therefore, I think it is more
>>> > proper this document intends for Informational status.
>>> >
>>> > Minor issue: no.
>>> >
>>> > Regards,
>>> >
>>> > Sheng
>>> >
>>> >
>>> > _______________________________________________
>>> > Curdle mailing list
>>> > Curdle@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/curdle
>>> _______________________________________________
>>> Curdle mailing list
>>> Curdle@ietf.org
>>> https://www.ietf.org/mailman/listinfo/curdle
>>>
>>