From nobody Tue Jun 4 10:40:40 2019 Return-Path: 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 76AAC12015F; Tue, 4 Jun 2019 10:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5lwmZjD13hgV; Tue, 4 Jun 2019 10:40:37 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABAC0120157; Tue, 4 Jun 2019 10:40:34 -0700 (PDT) Received: from prolepsis.kaduk.org (c-24-16-119-19.hsd1.wa.comcast.net [24.16.119.19]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x54HeU9Z011878 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Jun 2019 13:40:32 -0400 Date: Tue, 4 Jun 2019 10:40:30 -0700 From: Benjamin Kaduk To: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org Cc: curdle@ietf.org Message-ID: <20190604174029.GC8678@prolepsis.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Curdle] new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 17:40:40 -0000 Hi all, I'm just about ready to send this to the IESG, but there seems to be a few things to fix, first: (1) In Section 8 we say "The generation of SSHFP resource records for "ssh-ed448" keys is described as follows." but then give only an example and not a description of what to do. We need to say more about this procedure (2) I'm not sure if the chain on the opsdir review got fully resolved; see https://mailarchive.ietf.org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uPhaCk (3) The shepherd writeup says that Ben did not confirm IPR (non)disclosure per BCPs 78 and 79 -- Ben, can you please do so now? (4) Daniel, can you please update the shepherd writeup to reflect the discussions with the directorate reviewers about document status? I'm sure that some IESG members will ask "why not Informational?" if we don't forestall them. Thanks, Ben From nobody Wed Jun 5 06:52:39 2019 Return-Path: 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 91A32120046; Wed, 5 Jun 2019 06:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 irDHL9i-95Jb; Wed, 5 Jun 2019 06:52:33 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680086.outbound.protection.outlook.com [40.107.68.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0C9120048; Wed, 5 Jun 2019 06:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eLjT2lWuvTVMsJuKHEbyYIlmMvuc2vrbXxahqudCatY=; b=GkpkNaAj0VEyxvLhb4VXHNm/tGSInGFtrptqcu5C1ErnTk1udfJXmxJEqj9aTIRYj9h0DVZ/9L33eaaV9KOeCfUzLliFBk4nRY9S9Oz5Av0fsCbuiYjSo62P5oLtShOX5e5CtOSQwAThHYUBPcJzbAh4bQ0i4Z3oii0Xlhblx4g= Received: from DM6PR15MB3531.namprd15.prod.outlook.com (10.141.164.29) by DM6PR15MB3195.namprd15.prod.outlook.com (20.179.52.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Wed, 5 Jun 2019 13:52:30 +0000 Received: from DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::15f0:ad13:112d:529d]) by DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::15f0:ad13:112d:529d%7]) with mapi id 15.20.1965.011; Wed, 5 Jun 2019 13:52:30 +0000 From: Daniel Migault To: Benjamin Kaduk , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" CC: "curdle@ietf.org" Thread-Topic: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 Thread-Index: AQHVGvyouXNq2Av80UGqN7hXUNGiHaaNFNsA Date: Wed, 5 Jun 2019 13:52:30 +0000 Message-ID: References: <20190604174029.GC8678@prolepsis.kaduk.org> In-Reply-To: <20190604174029.GC8678@prolepsis.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [192.75.88.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a2f6a731-ac86-4f04-f002-08d6e9bd0d80 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB3195; x-ms-traffictypediagnostic: DM6PR15MB3195: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(396003)(346002)(376002)(13464003)(199004)(189003)(53754006)(68736007)(316002)(99286004)(66574012)(81156014)(478600001)(52536014)(53936002)(14444005)(256004)(5660300002)(305945005)(25786009)(7696005)(8936002)(74316002)(7736002)(76176011)(6246003)(86362001)(8676002)(44832011)(71190400001)(55016002)(3846002)(229853002)(110136005)(76116006)(476003)(6506007)(9686003)(2501003)(71200400001)(186003)(486006)(53546011)(73956011)(6436002)(6306002)(966005)(66476007)(102836004)(4326008)(66946007)(14454004)(81166006)(6116002)(2171002)(66446008)(66066001)(64756008)(33656002)(446003)(11346002)(66556008)(26005)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB3195; H:DM6PR15MB3531.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0jrlDf+wSOaIY+nV5Vyq6auiVLxASwsJI9sItKerxZ8C5Tn+2jo+v+lws7m1N7Jp65mKSzSbr5+svqO1OcF6VEpLh4irj9w84UCtyZ28NKonotInvW3t7+dTjSRsayG4xYANyenBmQOn9vdERqwAzF3QYfflVUm0BTsJWX6NxbXrxAv+1DtFfHtu5z8Fyq5O5keywAqDWwReC3uPg7FbAJf6nHUh72TCFKRqjbo5SLU1Vhr6qntOTZ41bK3AnugDYAncPeSggHX9TM+66mGqmrnDRPMUwXgK1wOs2vaDEJNuvCceLDRPgP2292krUeLVqBI9AzqFRyN9eLizupsecwQSM0jQrbPEK9icALvCfNm62NROsl/R6sbFVCpVcvfBCRurjge0evlguhFp/ZooUGCFoxiJ2D9rV2J2qoy9MIg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2f6a731-ac86-4f04-f002-08d6e9bd0d80 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 13:52:30.3129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: daniel.migault@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3195 Archived-At: Subject: Re: [Curdle] new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 13:52:37 -0000 Thanks Ben for the follow-up, please see my responses inline for (2) and (4= ). I believe a version 08 is needed to address (1) and (2).=20 Yours,=20 Daniel -----Original Message----- From: Benjamin Kaduk =20 Sent: Tuesday, June 04, 2019 1:41 PM To: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org Cc: curdle@ietf.org Subject: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 Hi all, I'm just about ready to send this to the IESG, but there seems to be a few = things to fix, first: (1) In Section 8 we say "The generation of SSHFP resource records for "ssh-= ed448" keys is described as follows." but then give only an example and not= a description of what to do. We need to say more about this procedure (2) I'm not sure if the chain on the opsdir review got fully resolved; see = https://mailarchive.ietf.org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uPhaCk The current version has not accordingly been updated.=20 (3) The shepherd writeup says that Ben did not confirm IPR (non)disclosure = per BCPs 78 and 79 -- Ben, can you please do so now? (4) Daniel, can you please update the shepherd writeup to reflect the discu= ssions with the directorate reviewers about document status? I'm sure that= some IESG members will ask "why not Informational?" if we don't forestall = them. I have update the shepherd as follows: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The requested status is Standard Track. This is necessary for=20 inter-operability and as such the Standard Track seems the=20 most appropriated status. =20 The OPS Directorate wondered why version 07 was a Standard Track=20 document and not an informational document as no normative 2119 words.=20 The reason for being a standard track is that we expect the implementation= =20 that implement SSH to follow these recommendations. The consensus was=20 to explicitly mention it in the document around the lines: "Standard implementations of SSH SHOULD implement these signature algorithm= s." Thanks, Ben From nobody Wed Jun 5 06:53:16 2019 Return-Path: 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 BD899120046; Wed, 5 Jun 2019 06:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, URIBL_BLOCKED=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 DGjAZatNS28w; Wed, 5 Jun 2019 06:53:12 -0700 (PDT) Received: from mail-yw1-f48.google.com (mail-yw1-f48.google.com [209.85.161.48]) (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 52C2C120092; Wed, 5 Jun 2019 06:53:12 -0700 (PDT) Received: by mail-yw1-f48.google.com with SMTP id m16so4290000ywh.12; Wed, 05 Jun 2019 06:53:12 -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=thg1MjOjYqfg5GtnlRDpm2Feb2AjR7F8y0xtdft0L3M=; b=iZiTOUO/Bz60MhH2MPWpHCj1M13b5Mvc/4F0euhahSMIh1JnEKhDy0FHllIKKbRBBq fB/ufAanGqedM6J9B9UWWi1wwrvpiR+pfqzhJrR0coRorjyQGeyM0WelcW7g3+g+sKNH 2A9zYsdp7EEdCoSxXrwq0HhZ14dt4JZtZZA1j9l4PkWt8emoskgx4pyc1md7EFjTFeMf byLmeQ7ZF1egBsP29oTCZkLOvdGkG9rS/09FcK1r2hUr16yV8AmOMdw3w4uhissX4NUs muzCFtf62rbv+28KLajUVMxRoN6G6y0pyeH3mtUw+Xw0avJmob+eucY7LyEDUcSDgvZR bMnA== X-Gm-Message-State: APjAAAWJzmJtbkt6pYJq111H4wbfLkbHMTXzmjdEsVKoUl6n6GNG9hym 5p27iZzVD3Iu6Rt1+n3MnPwtgLDLowB/cy4MRIAoC3FV X-Google-Smtp-Source: APXvYqxHMkQXqq5oyUfKm+iXN0fgJngcc1oFlGlgq4vYNsq/vdXmNhFyaE82JjB4Ou/Ooy22W43yLNrhCbd9zEfksWU= X-Received: by 2002:a0d:fbc6:: with SMTP id l189mr4127322ywf.135.1559742791402; Wed, 05 Jun 2019 06:53:11 -0700 (PDT) MIME-Version: 1.0 References: <154642329120.32625.18387931087720472774@ietfa.amsl.com> <5D36713D8A4E7348A7E10DF7437A4B92902DEBEC@NKGEML515-MBX.china.huawei.com> In-Reply-To: From: Daniel Migault Date: Wed, 5 Jun 2019 09:53:00 -0400 Message-ID: To: Sheng Jiang , Tim Hollebeek , "ops-dir@ietf.org" Cc: "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="00000000000005cb01058a93eb9e" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 13:53:15 -0000 --00000000000005cb01058a93eb9e Content-Type: text/plain; charset="UTF-8" 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 wrote: > Hi Sheng, > > Thanks for the comment. It should be easily addressed in the next version. > > Yours, > Daniel > > -----Original Message----- > From: Sheng Jiang > Sent: Thursday, January 03, 2019 8:59 AM > To: Daniel Migault ; 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 ; 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 > Sent: Wednesday, January 02, 2019 1:12 PM > To: Daniel Migault ; 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 On Behalf Of Daniel Migault > > Sent: Wednesday, January 2, 2019 10:43 AM > > To: Sheng Jiang ; 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 > > 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 > --00000000000005cb01058a93eb9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear co-authors of curdle-ssh-ed25519-ed448,=C2=A0
Could we update the document and address the concern from Sheng= ?

Yours,=C2=A0
Daniel=C2=A0

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.<= br>
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@digi= cert.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 be= tter for a "standard track" document, if it gave a little bit mor= e detailed guidance "where" and "how" a SSH implement s= hould 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&g= t;; ops-dir@ietf.org<= /a>
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 S= SH 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; <= a href=3D"mailto:curdle@ietf.org" target=3D"_blank">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 <= br> > 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 <= br> > *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}.<= br> >
> (RFC4250 and) RFC4253 provided the initial values for the Public Key registry.
> While the protocol comes with some registry values, my understanding <= br> > 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 <= br> > 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, <= br> > 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 integ= rated 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; <= a href=3D"mailto:curdle@ietf.org" target=3D"_blank">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&#= 39;s
> ongoing effort to review all IETF documents being processed by the IES= G.
> 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 co= mments.
>
> This standard track document describes the use of the Ed25519 and
> Ed448 digital signature algorithm in the Secure Shell (SSH) protocol.= =C2=A0
> 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 <= br> > "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 a= ny
> 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
--00000000000005cb01058a93eb9e-- From nobody Wed Jun 5 23:13:45 2019 Return-Path: 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 D0703120182; Wed, 5 Jun 2019 23:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 PGze0boCmaNE; Wed, 5 Jun 2019 23:13:41 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 E6095120162; Wed, 5 Jun 2019 23:13:40 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id m3so1428143itl.1; Wed, 05 Jun 2019 23:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CYsI8vrdSe2mxCQu+0cF2nWkAV+NYECYRKiAau4Nl9Q=; b=f6VsCYEXGrshWSmtCp0v83En0dV2HGW23kSjW2mfrV/dsgvPq4S72Z1Z2SNtofqe8R GxkZGT1oR0+b2P0+xMFiE4dc0ve6OB+u3K+FE9rh2MdfVebV8+bhRcS1VyVLKiBGJV02 sc3Gs1ci6imTsjUV0kE2fi+8WIvOiLCJUY4iPSFFOWSVkFfihEzY/mCA1oHc5lHf3Tba 1DYY238eofpDsR/wPqXsdx8nZWZqg8vq4P/20xMvgs1guZaEdfgzCaJKmxbRdmoBDN3h eDnnaVXz6gvWCVoDXXcNdumhrTjXeiHeaOB0rTc3tqr5SSkSLxMooxqtutQwA2Qs760V gHuw== 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=CYsI8vrdSe2mxCQu+0cF2nWkAV+NYECYRKiAau4Nl9Q=; b=QXR1XrrrZd+7KJMm6Iv808vAF5r3Po7Fo2S9QgnHMFwQD/pBGGizXuL6vkXJ7x+ggA l3Wt1KNLQ4PdqfZZnVXlJcnlVp6inYAQ6KpidiqHz/Aeenavjf2N1qIl5hQtLswX0ddp 1QQBNJoxVEoUAj3eTxTt+jEtZLpPv33uqysf5HSThgLZy2Vkph+FwhBW1XkdmwZXvIG+ 8BotQxHM8u8Gm+0nIqJqD5S17d1gXYGjWfUJRyjtSUnDoOmkAHr+llxT/Ctm1QXuBz5b BRk38v1NXWh0cknLB+6Sy6Nb07tKASNnWuXgoM0aK6ZIbgqDoWYkZqPhXbsnZ8OimgYb ZW0Q== X-Gm-Message-State: APjAAAU/u69h0zaQK37tanc1cAoIwn/vVQI5v1ZHxGhArP4RI7cvLsic bBfMDWrv4sLpjGYcZoJQBTb/JMXjUu0q0NnlN2M= X-Google-Smtp-Source: APXvYqzJQolzEUCA9iCo+m6X20DlB30RNvqjOQ2rdtoaUpMkI4xDtnrVUfTc8uwnyTwQPyNrHQ+aY5zYnRKJFcSZEuo= X-Received: by 2002:a24:eec1:: with SMTP id b184mr31580082iti.61.1559801620270; Wed, 05 Jun 2019 23:13:40 -0700 (PDT) MIME-Version: 1.0 References: <154642329120.32625.18387931087720472774@ietfa.amsl.com> <5D36713D8A4E7348A7E10DF7437A4B92902DEBEC@NKGEML515-MBX.china.huawei.com> In-Reply-To: From: Loganaden Velvindron Date: Thu, 6 Jun 2019 10:13:28 +0400 Message-ID: To: Daniel Migault Cc: Sheng Jiang , Tim Hollebeek , "ops-dir@ietf.org" , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007f1207058aa19d16" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 06:13:44 -0000 --0000000000007f1207058aa19d16 Content-Type: text/plain; charset="UTF-8" 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 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 >> Sent: Thursday, January 03, 2019 8:59 AM >> To: Daniel Migault ; 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 ; 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 >> Sent: Wednesday, January 02, 2019 1:12 PM >> To: Daniel Migault ; 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 On Behalf Of Daniel Migault >> > Sent: Wednesday, January 2, 2019 10:43 AM >> > To: Sheng Jiang ; 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 >> > 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 >> > --0000000000007f1207058aa19d16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe that this change already took place in rev08. Wh= at more do we need to add ?


<= div>

On Wed, Jun 5, 2019 at 5:53 PM Daniel Migault <daniel.migault@ericsson.com>= wrote:
Dear co-authors of curdle-ssh-ed25519-ed448,=C2=A0

<= div>Could we update the document and address the concern from Sheng ?
=

Yours,=C2=A0
Daniel=C2=A0

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.<= br>
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@digi= cert.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 be= tter for a "standard track" document, if it gave a little bit mor= e detailed guidance "where" and "how" a SSH implement s= hould 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&g= t;; ops-dir@ietf.org<= /a>
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 S= SH 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; <= a href=3D"mailto:curdle@ietf.org" target=3D"_blank">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 <= br> > 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 <= br> > *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}.<= br> >
> (RFC4250 and) RFC4253 provided the initial values for the Public Key registry.
> While the protocol comes with some registry values, my understanding <= br> > 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 <= br> > 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, <= br> > 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 integ= rated 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; <= a href=3D"mailto:curdle@ietf.org" target=3D"_blank">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&#= 39;s
> ongoing effort to review all IETF documents being processed by the IES= G.
> 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 co= mments.
>
> This standard track document describes the use of the Ed25519 and
> Ed448 digital signature algorithm in the Secure Shell (SSH) protocol.= =C2=A0
> 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 <= br> > "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 a= ny
> 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
--0000000000007f1207058aa19d16-- From nobody Thu Jun 6 00:02:37 2019 Return-Path: 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 D9D2B120115; Thu, 6 Jun 2019 00:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 fLaaVHPdF0bY; Thu, 6 Jun 2019 00:02:33 -0700 (PDT) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 48A431200F7; Thu, 6 Jun 2019 00:02:33 -0700 (PDT) Received: by mail-it1-x12a.google.com with SMTP id a186so1582268itg.0; Thu, 06 Jun 2019 00:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tGrN2sveiS9g9KxtX5vhysYMX+USeJA+Q/PZQKtB+DM=; b=Gl9vOhNT1y/+sCah+aK/uqqIUSPsXvXM9LJlWjemgu/EswXa11XYnE4koPIDqA2ONv ubvRfFWXVmZhp16DWwmFEmi6kaT8kKxJtGpZpS92xnUF4a2kM22D1vVdpMvm6rbNb1ym blPxD9vys0IDC/uBKna6T+SZswQQ5CbC0u5sFtgUFa7MntPz4TnlQ0HUvulqrkeS8J+s qf+NyxXY0IfN9eW48BXVJBLfPBH7NpxTmRp0WETFNFIFXKsK+s26WuHCJnGE6gQ7pW3x HreKqd98q9Yl8wBKo0OujJSfYozRxrDlo/54Gvyxrahsi5UvqjzZqC3dS1I6h45HA2tv /3kw== 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=tGrN2sveiS9g9KxtX5vhysYMX+USeJA+Q/PZQKtB+DM=; b=W/xmPFiVUN7fFubmf3Tuh+QAVHnSG7BolJ4lBENqR0Xnxny4jlf+Obr09quCKYsgBe sIikJwlIx0V9ZG1BMVsXPdYvi7XNKn/6Sy3OWo2zdxmBdeg0F2V8V1DeE09XI6ZxUt4R X5jdnHK/j7jlFhkSSPmnKvrJ84l/617mAk/lU3uR7XbpBKzXduAcBJtSfXatsNMLntd5 qeBoBNuWPeAmA7NKbTuDROnVZDzDV9oJdxulyoD07Ni86E918VfGnpOBSCklRUFzfwwy ZQi8GgTKFmBLHpseHGsHzeaRdfhoJo2uMOCWNHHIHhQn6Ei9XHPfGt92WEAMaoAi7/13 v6+A== X-Gm-Message-State: APjAAAW7vxGK5D0QifwpklLX76HlyAF3E5PZf9PoY4kmFEGaZR/iGeLX NmI97z/N0N1aSWEP50pb816Nlf5UCgK3+qkitwo= X-Google-Smtp-Source: APXvYqzegc/h0bHWosqZI9CYaZKX22Lm2qK3o0uOKgAgKFJMb3ON+XERqvY6hYO0fds1NqQTNWJONpMPFxe6AfdEw3s= X-Received: by 2002:a24:eec1:: with SMTP id b184mr31721941iti.61.1559804552605; Thu, 06 Jun 2019 00:02:32 -0700 (PDT) MIME-Version: 1.0 References: <20190604174029.GC8678@prolepsis.kaduk.org> In-Reply-To: From: Loganaden Velvindron Date: Thu, 6 Jun 2019 11:02:21 +0400 Message-ID: To: Daniel Migault Cc: Benjamin Kaduk , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046f474058aa24c9b" Archived-At: Subject: Re: [Curdle] new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 07:02:36 -0000 --00000000000046f474058aa24c9b Content-Type: text/plain; charset="UTF-8" I already published rev08 to address those issues: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-curdle-ssh-ed25519-ed448-08.txt On Wed, Jun 5, 2019 at 5:52 PM Daniel Migault wrote: > Thanks Ben for the follow-up, please see my responses inline for (2) and > (4). I believe a version 08 is needed to address (1) and (2). > Yours, > Daniel > > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, June 04, 2019 1:41 PM > To: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org > Cc: curdle@ietf.org > Subject: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 > > Hi all, > > I'm just about ready to send this to the IESG, but there seems to be a few > things to fix, first: > > (1) In Section 8 we say "The generation of SSHFP resource records for > "ssh-ed448" keys is described as follows." but then give only an example > and not a description of what to do. We need to say more about this > procedure > > (2) I'm not sure if the chain on the opsdir review got fully resolved; see > https://mailarchive.ietf.org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uPhaCk > > The current version has not accordingly been updated. > > > (3) The shepherd writeup says that Ben did not confirm IPR (non)disclosure > per BCPs 78 and 79 -- Ben, can you please do so now? > > (4) Daniel, can you please update the shepherd writeup to reflect the > discussions with the directorate reviewers about document status? I'm sure > that some IESG members will ask "why not Informational?" if we don't > forestall them. > > > I have update the shepherd as follows: > > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in the > title page header? > > The requested status is Standard Track. This is necessary for > inter-operability and as such the Standard Track seems the > most appropriated status. > > The OPS Directorate wondered why version 07 was a Standard Track > document and not an informational document as no normative 2119 words. > > The reason for being a standard track is that we expect the implementation > that implement SSH to follow these recommendations. The consensus was > to explicitly mention it in the document around the lines: > > "Standard implementations of SSH SHOULD implement these signature > algorithms." > > Thanks, > > Ben > --00000000000046f474058aa24c9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2019 at 5:52 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
=
Thanks Ben for the = follow-up, please see my responses inline for (2) and (4). I believe a vers= ion 08 is needed to address (1) and (2).
Yours,
Daniel

-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu>
Sent: Tuesday, June 04, 2019 1:41 PM
To: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org
Cc: curdle@ietf.org
Subject: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08
Hi all,

I'm just about ready to send this to the IESG, but there seems to be a = few things to fix, first:

(1) In Section 8 we say "The generation of SSHFP resource records for = "ssh-ed448" keys is described as follows." but then give onl= y an example and not a description of what to do.=C2=A0 We need to say more= about this procedure

(2) I'm not sure if the chain on the opsdir review got fully resolved; = see https://mailarchive.ietf= .org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uPhaCk
<mglt>
The current version has not accordingly been updated.
</mglt>

(3) The shepherd writeup says that Ben did not confirm IPR (non)disclosure = per BCPs 78 and 79 -- Ben, can you please do so now?

(4) Daniel, can you please update the shepherd writeup to reflect the discu= ssions with the directorate reviewers about document status?=C2=A0 I'm = sure that some IESG members will ask "why not Informational?" if = we don't forestall them.

<mglt>
I have update the shepherd as follows:

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?=C2=A0 Why
is this the proper type of RFC?=C2=A0 Is this type of RFC indicated in the<= br> title page header?

The requested status is Standard Track. This is necessary for
inter-operability=C2=A0 and as such the Standard Track seems the
most appropriated status.=C2=A0

The OPS Directorate wondered why version 07 was a Standard Track
document and not an informational document as no normative 2119 words.

The reason for being a standard track is that we expect the implementation =
that implement SSH to follow these recommendations. The consensus was
to explicitly mention it in the document around the lines:

"Standard implementations of SSH SHOULD implement these signature algo= rithms."
</mglt>
Thanks,

Ben
--00000000000046f474058aa24c9b-- From nobody Thu Jun 6 07:56:55 2019 Return-Path: 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 133C012012C; Thu, 6 Jun 2019 07:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.415, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 EG2PwHbmQRk0; Thu, 6 Jun 2019 07:56:50 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820078.outbound.protection.outlook.com [40.107.82.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383071200F9; Thu, 6 Jun 2019 07:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w7f6SJIgRt+z0VcdC9rg/ajh7D6ep+usjS0M2/DjdgQ=; b=NMsphKJSE6f3+P9w+jLH71aDDb45WpoSJD4r023k/WYDFgztXdAjPoD8nYh46mvC/6OUxEfLh80+2J+xoR3N2KTHsW1sd+x/NlNdplMM7UbSUi/OibTWWkLwCnsdeiIr0gbT/wkv9c++KrjFSIC/AFAcVqgWP6Vb5xWRPPMgljU= Received: from DM6PR15MB3531.namprd15.prod.outlook.com (10.141.164.29) by DM6PR15MB2729.namprd15.prod.outlook.com (20.179.162.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Thu, 6 Jun 2019 14:56:46 +0000 Received: from DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::15f0:ad13:112d:529d]) by DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::15f0:ad13:112d:529d%7]) with mapi id 15.20.1965.011; Thu, 6 Jun 2019 14:56:46 +0000 From: Daniel Migault To: Loganaden Velvindron CC: Benjamin Kaduk , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" Thread-Topic: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 Thread-Index: AQHVGvyouXNq2Av80UGqN7hXUNGiHaaNFNsAgAEgvYCAAIACcA== Date: Thu, 6 Jun 2019 14:56:46 +0000 Message-ID: References: <20190604174029.GC8678@prolepsis.kaduk.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [192.75.88.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc75e95e-d0b0-4653-621e-08d6ea8f328c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2729; x-ms-traffictypediagnostic: DM6PR15MB2729: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(376002)(136003)(199004)(189003)(53754006)(13464003)(44832011)(316002)(71200400001)(71190400001)(8936002)(2906002)(99286004)(53936002)(6116002)(790700001)(3846002)(6246003)(486006)(4326008)(66574012)(66476007)(73956011)(64756008)(606006)(14454004)(25786009)(66556008)(66446008)(478600001)(74316002)(66946007)(476003)(66066001)(5660300002)(7736002)(11346002)(54906003)(446003)(229853002)(966005)(81156014)(81166006)(76116006)(33656002)(68736007)(52536014)(14444005)(86362001)(7696005)(6916009)(256004)(9686003)(6306002)(186003)(54896002)(55016002)(26005)(53546011)(102836004)(236005)(6436002)(8676002)(76176011)(1411001)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2729; H:DM6PR15MB3531.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HaCChUgjzrRMGTgUxmOwcZZfANGbKakz1kZ3lWcXteZwcGkVbkRoykvgdUjRT77G47fhryLwkvJiDsWYHQuy6g5NYXyQ0gE0sHMq3gu0c0rnLyG2UCa+0jJ56hTxdnrNkGZCGyY+v0boSLNdxVs2w89+speODYOUMC4irb+b2NUAivBMhpz93WitiyrFy1GG3aCank2ChMNPCkz2G7hTfPSKTVSLH9p1wJNCrvU5mQWSpayfRAUzzK6JyMBPfW8WzB8qxggZOVQOn3Y9dpxDaCB3hkUp/+3rN0zpnPFCYCQSAtotnR+s4j+0jdiWEJgZ4dShXfe8J9qnzzbhlkd7qHTY4GEBR3vXqv8EBTdFv4cg7nXhT/OH8IxKmJb8lEUPM2ulrMvbyJz/gHZ0NH18AKCJJ7XYA8+8s5Hdl2aIH2g= Content-Type: multipart/alternative; boundary="_000_DM6PR15MB3531792B7CB48B7E08D67E2CE3170DM6PR15MB3531namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc75e95e-d0b0-4653-621e-08d6ea8f328c X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2019 14:56:46.7748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: daniel.migault@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2729 Archived-At: Subject: Re: [Curdle] new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 14:56:54 -0000 --_000_DM6PR15MB3531792B7CB48B7E08D67E2CE3170DM6PR15MB3531namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBjb3JyZWN0LCBmb3Igc29tZSByZWFzb25zIEkgcmV2aWV3ZWQgdmVyc2lvbiAwNy4g U28gdmVyc2lvbiAwOCBpcyBzb2x2aW5nIHRoZSBvcHNkaXIgaXNzdWUuIEkgd2lsbCBjbG9zZSB0 aGUgdGhyZWFkIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQoNClRoZSBTU0hGIFJlY29yZCBpbmNsdWRl cyB0aGUgYWxnb3JpdGhtIHVzZWQgZm9yIHRoZSBwdWJsaWMga2V5LCB0aGUgdHlwZSBvZiB0aGUg ZmluZ2VycHJpbnQuIFRoZSBjdXJyZW50IGRyYWZ0IG9ubHkgYWRkcyBhIHJlZ2lzdHJ5IGZvciB0 aGUgYWxnb3JpdGhtLiBJIGJlbGlldmUgdGhlIGNvbmZ1c2lvbiBtaWdodCBiZSB0aGF0IHRoZSBj dXJyZW50IHRleHQgIHNlZW1zIHRvIGluZGljYXRlIHNvbWUgYWRkaXRpb25hbCBjaGFuZ2VzIGZv ciBleGFtcGxlIGluIHRoZSBnZW5lcmF0aW9uIG9mIHRoZSBmaW5nZXIgcHJpbnQuICBNYXliZSB0 aGUgdGV4dCBiZWxvdyBhcm91bmQgdGhlIGZvbGxvd2luZyBsaW5lcyBjbGFyaWZpZXMgdGhlIHB1 cnBvc2Ugb2YgdGhlIGNoYW5nZXMuDQoNCklmIHNvLCB0aGUgb25seSByZW1haW5pbmcgcG9pbnQg aXMgdGhlIElQUiBkZWNsYXJhdGlvbi4NCg0KT0xEOg0KVGhlIGdlbmVyYXRpb24gb2YgU1NIRlAg cmVzb3VyY2UgcmVjb3JkcyBmb3IgInNzaC1lZDI1NTE5IiBrZXlzIGlzDQogICBkZXNjcmliZWQg aW4gW1JGQzc0NzldLg0KDQogICBUaGUgZ2VuZXJhdGlvbiBvZiBTU0hGUCByZXNvdXJjZSByZWNv cmRzIGZvciAic3NoLWVkNDQ4IiBrZXlzIGlzDQogICBkZXNjcmliZWQgYXMgZm9sbG93cy4NCg0K ICAgdGhlIFNTSEZQIFJlc291cmNlIFJlY29yZCBmb3IgdGhlIEVkNDQ4IHB1YmxpYyBrZXkgd2l0 aCBTSEEtMjU2DQogICBmaW5nZXJwcmludCB3b3VsZCBiZSBleGFtcGxlIGJlOg0KDQogICBleGFt cGxlLmNvbS4gIElOIFNTSEZQIFRCRCAyICggYTg3ZjFiNjg3YWMwZTU3ZDJhMDgxYTJmMjgyNjcy Mw0KICAgMzRkOTBlZDMxNmQyYjgxOGNhOTU4MGVhMzg0ZDkyNCAwMSApDQoNCiAgIFRoZSAyIGhl cmUgaW5kaWNhdGVzIFNIQS0yNTYgW1JGQzY1OTRdLg0KDQpORVc6DQoNClRoZSBnZW5lcmF0aW9u IG9mIFNTSEZQIHJlc291cmNlIHJlY29yZHMgZm9yICJzc2gtZWQyNTUxOSIga2V5cyBpcw0KICAg ZGVzY3JpYmVkIGluIFtSRkM3NDc5XS4NCg0KVGhlIFNTSEZQIHJlc291cmNlIHJlY29yZHMgZm9y ICJzc2gtZWQ0NDgiIGtleXMgaXMgZ2VuZXJhdGVkIHNpbWlsYXJseSwNCndpdGggdGhlIGFsZ29y aXRobSBmaWVsZCBpbmRpY2F0aW5nIGEgRWQ0NDggcHVibGljIGtleS4NCg0KVGhlIFNTSEZQIFJl c291cmNlIFJlY29yZCBmb3IgdGhlIEVkNDQ4IHB1YmxpYyBrZXkgd2l0aCBTSEEtMjU2DQpmaW5n ZXJwcmludCB3b3VsZCBiZSBleGFtcGxlIGJlOg0KDQpleGFtcGxlLmNvbS4gIElOIFNTSEZQIFRC RCAyICggYTg3ZjFiNjg3YWMwZTU3ZDJhMDgxYTJmMjgyNjcyMw0KMzRkOTBlZDMxNmQyYjgxOGNh OTU4MGVhMzg0ZDkyNCAwMSApDQoNClRoZSAyIGhlcmUgaW5kaWNhdGVzIFNIQS0yNTYgW1JGQzY1 OTRdLg0KDQpGcm9tOiBMb2dhbmFkZW4gVmVsdmluZHJvbiA8bG9nYW5hZGVuQGdtYWlsLmNvbT4N ClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA2LCAyMDE5IDM6MDIgQU0NClRvOiBEYW5pZWwgTWlnYXVs dCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPg0KQ2M6IEJlbmphbWluIEthZHVrIDxrYWR1 a0BtaXQuZWR1PjsgZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLWVkMjU1MTktZWQ0NDguYWxsQGlldGYu b3JnOyBjdXJkbGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBuZXcgQUQgcmV2aWV3IGNvbW1lbnRz IG9uIGRyYWZ0LWlldGYtY3VyZGxlLXNzaC1lZDI1NTE5LWVkNDQ4LTA4DQoNCkkgYWxyZWFkeSBw dWJsaXNoZWQgcmV2MDggdG8gYWRkcmVzcyB0aG9zZSBpc3N1ZXM6DQpodHRwczovL3Rvb2xzLmll dGYub3JnL3JmY2RpZmY/ZGlmZnR5cGU9LS1od2RpZmYmdXJsMj1kcmFmdC1pZXRmLWN1cmRsZS1z c2gtZWQyNTUxOS1lZDQ0OC0wOC50eHQNCg0KT24gV2VkLCBKdW4gNSwgMjAxOSBhdCA1OjUyIFBN IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208bWFpbHRvOmRhbmll bC5taWdhdWx0QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KVGhhbmtzIEJlbiBmb3IgdGhlIGZvbGxv dy11cCwgcGxlYXNlIHNlZSBteSByZXNwb25zZXMgaW5saW5lIGZvciAoMikgYW5kICg0KS4gSSBi ZWxpZXZlIGEgdmVyc2lvbiAwOCBpcyBuZWVkZWQgdG8gYWRkcmVzcyAoMSkgYW5kICgyKS4NCllv dXJzLA0KRGFuaWVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZW5qYW1p biBLYWR1ayA8a2FkdWtAbWl0LmVkdTxtYWlsdG86a2FkdWtAbWl0LmVkdT4+DQpTZW50OiBUdWVz ZGF5LCBKdW5lIDA0LCAyMDE5IDE6NDEgUE0NClRvOiBkcmFmdC1pZXRmLWN1cmRsZS1zc2gtZWQy NTUxOS1lZDQ0OC5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY3VyZGxlLXNzaC1lZDI1 NTE5LWVkNDQ4LmFsbEBpZXRmLm9yZz4NCkNjOiBjdXJkbGVAaWV0Zi5vcmc8bWFpbHRvOmN1cmRs ZUBpZXRmLm9yZz4NClN1YmplY3Q6IG5ldyBBRCByZXZpZXcgY29tbWVudHMgb24gZHJhZnQtaWV0 Zi1jdXJkbGUtc3NoLWVkMjU1MTktZWQ0NDgtMDgNCg0KSGkgYWxsLA0KDQpJJ20ganVzdCBhYm91 dCByZWFkeSB0byBzZW5kIHRoaXMgdG8gdGhlIElFU0csIGJ1dCB0aGVyZSBzZWVtcyB0byBiZSBh IGZldyB0aGluZ3MgdG8gZml4LCBmaXJzdDoNCg0KKDEpIEluIFNlY3Rpb24gOCB3ZSBzYXkgIlRo ZSBnZW5lcmF0aW9uIG9mIFNTSEZQIHJlc291cmNlIHJlY29yZHMgZm9yICJzc2gtZWQ0NDgiIGtl eXMgaXMgZGVzY3JpYmVkIGFzIGZvbGxvd3MuIiBidXQgdGhlbiBnaXZlIG9ubHkgYW4gZXhhbXBs ZSBhbmQgbm90IGEgZGVzY3JpcHRpb24gb2Ygd2hhdCB0byBkby4gIFdlIG5lZWQgdG8gc2F5IG1v cmUgYWJvdXQgdGhpcyBwcm9jZWR1cmUNCg0KKDIpIEknbSBub3Qgc3VyZSBpZiB0aGUgY2hhaW4g b24gdGhlIG9wc2RpciByZXZpZXcgZ290IGZ1bGx5IHJlc29sdmVkOyBzZWUgaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jdXJkbGUvRFpjMlNyMTl6Sjcxbm5DM3BTSUYwdVBo YUNrDQo8bWdsdD4NClRoZSBjdXJyZW50IHZlcnNpb24gaGFzIG5vdCBhY2NvcmRpbmdseSBiZWVu IHVwZGF0ZWQuDQo8L21nbHQ+DQoNCigzKSBUaGUgc2hlcGhlcmQgd3JpdGV1cCBzYXlzIHRoYXQg QmVuIGRpZCBub3QgY29uZmlybSBJUFIgKG5vbilkaXNjbG9zdXJlIHBlciBCQ1BzIDc4IGFuZCA3 OSAtLSBCZW4sIGNhbiB5b3UgcGxlYXNlIGRvIHNvIG5vdz8NCg0KKDQpIERhbmllbCwgY2FuIHlv dSBwbGVhc2UgdXBkYXRlIHRoZSBzaGVwaGVyZCB3cml0ZXVwIHRvIHJlZmxlY3QgdGhlIGRpc2N1 c3Npb25zIHdpdGggdGhlIGRpcmVjdG9yYXRlIHJldmlld2VycyBhYm91dCBkb2N1bWVudCBzdGF0 dXM/ICBJJ20gc3VyZSB0aGF0IHNvbWUgSUVTRyBtZW1iZXJzIHdpbGwgYXNrICJ3aHkgbm90IElu Zm9ybWF0aW9uYWw/IiBpZiB3ZSBkb24ndCBmb3Jlc3RhbGwgdGhlbS4NCg0KPG1nbHQ+DQpJIGhh dmUgdXBkYXRlIHRoZSBzaGVwaGVyZCBhcyBmb2xsb3dzOg0KDQooMSkgV2hhdCB0eXBlIG9mIFJG QyBpcyBiZWluZyByZXF1ZXN0ZWQgKEJDUCwgUHJvcG9zZWQgU3RhbmRhcmQsDQpJbnRlcm5ldCBT dGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBvciBIaXN0b3JpYyk/ICBXaHkN CmlzIHRoaXMgdGhlIHByb3BlciB0eXBlIG9mIFJGQz8gIElzIHRoaXMgdHlwZSBvZiBSRkMgaW5k aWNhdGVkIGluIHRoZQ0KdGl0bGUgcGFnZSBoZWFkZXI/DQoNClRoZSByZXF1ZXN0ZWQgc3RhdHVz IGlzIFN0YW5kYXJkIFRyYWNrLiBUaGlzIGlzIG5lY2Vzc2FyeSBmb3INCmludGVyLW9wZXJhYmls aXR5ICBhbmQgYXMgc3VjaCB0aGUgU3RhbmRhcmQgVHJhY2sgc2VlbXMgdGhlDQptb3N0IGFwcHJv cHJpYXRlZCBzdGF0dXMuDQoNClRoZSBPUFMgRGlyZWN0b3JhdGUgd29uZGVyZWQgd2h5IHZlcnNp b24gMDcgd2FzIGEgU3RhbmRhcmQgVHJhY2sNCmRvY3VtZW50IGFuZCBub3QgYW4gaW5mb3JtYXRp b25hbCBkb2N1bWVudCBhcyBubyBub3JtYXRpdmUgMjExOSB3b3Jkcy4NCg0KVGhlIHJlYXNvbiBm b3IgYmVpbmcgYSBzdGFuZGFyZCB0cmFjayBpcyB0aGF0IHdlIGV4cGVjdCB0aGUgaW1wbGVtZW50 YXRpb24NCnRoYXQgaW1wbGVtZW50IFNTSCB0byBmb2xsb3cgdGhlc2UgcmVjb21tZW5kYXRpb25z LiBUaGUgY29uc2Vuc3VzIHdhcw0KdG8gZXhwbGljaXRseSBtZW50aW9uIGl0IGluIHRoZSBkb2N1 bWVudCBhcm91bmQgdGhlIGxpbmVzOg0KDQoiU3RhbmRhcmQgaW1wbGVtZW50YXRpb25zIG9mIFNT SCBTSE9VTEQgaW1wbGVtZW50IHRoZXNlIHNpZ25hdHVyZSBhbGdvcml0aG1zLiINCjwvbWdsdD4N ClRoYW5rcywNCg0KQmVuDQo= --_000_DM6PR15MB3531792B7CB48B7E08D67E2CE3170DM6PR15MB3531namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIGlzIGNvcnJlY3QsIGZvciBzb21lIHJlYXNvbnMgSSByZXZpZXdlZCB2ZXJzaW9uIDA3LiBT byB2ZXJzaW9uIDA4IGlzIHNvbHZpbmcgdGhlIG9wc2RpciBpc3N1ZS4gSSB3aWxsIGNsb3NlIHRo ZSB0aHJlYWQgb24gdGhlIG1haWxpbmcgbGlzdC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgU1NIRiBSZWNvcmQgaW5jbHVkZXMgdGhlIGFsZ29yaXRobSB1c2VkIGZvciB0aGUgcHVibGlj IGtleSwgdGhlIHR5cGUgb2YgdGhlIGZpbmdlcnByaW50LiBUaGUgY3VycmVudCBkcmFmdCBvbmx5 IGFkZHMgYSByZWdpc3RyeSBmb3IgdGhlIGFsZ29yaXRobS4gSSBiZWxpZXZlIHRoZSBjb25mdXNp b24gbWlnaHQgYmUgdGhhdCB0aGUgY3VycmVudCB0ZXh0ICZuYnNwO3NlZW1zIHRvIGluZGljYXRl IHNvbWUgYWRkaXRpb25hbA0KIGNoYW5nZXMgZm9yIGV4YW1wbGUgaW4gdGhlIGdlbmVyYXRpb24g b2YgdGhlIGZpbmdlciBwcmludC4mbmJzcDsgTWF5YmUgdGhlIHRleHQgYmVsb3cgYXJvdW5kIHRo ZSBmb2xsb3dpbmcgbGluZXMgY2xhcmlmaWVzIHRoZSBwdXJwb3NlIG9mIHRoZSBjaGFuZ2VzLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHNvLCB0aGUgb25seSByZW1haW5pbmcgcG9pbnQg aXMgdGhlIElQUiBkZWNsYXJhdGlvbi4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9M RDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBnZW5lcmF0aW9uIG9m IFNTSEZQIHJlc291cmNlIHJlY29yZHMgZm9yICZxdW90O3NzaC1lZDI1NTE5JnF1b3Q7IGtleXMg aXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBkZXNj cmliZWQgaW4gW1JGQzc0NzldLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg VGhlIGdlbmVyYXRpb24gb2YgU1NIRlAgcmVzb3VyY2UgcmVjb3JkcyBmb3IgJnF1b3Q7c3NoLWVk NDQ4JnF1b3Q7IGtleXMgaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyBkZXNjcmliZWQgYXMgZm9sbG93cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7IHRoZSBTU0hGUCBSZXNvdXJjZSBSZWNvcmQgZm9yIHRoZSBFZDQ0OCBwdWJs aWMga2V5IHdpdGggU0hBLTI1NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7IGZpbmdlcnByaW50IHdvdWxkIGJlIGV4YW1wbGUgYmU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBleGFtcGxlLmNvbS4mbmJzcDsgSU4gU1NIRlAgVEJE IDIgKCBhODdmMWI2ODdhYzBlNTdkMmEwODFhMmYyODI2NzIzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgMzRkOTBlZDMxNmQyYjgxOGNhOTU4MGVhMzg0 ZDkyNCAwMSApPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBUaGUgMiBoZXJl IGluZGljYXRlcyBTSEEtMjU2IFtSRkM2NTk0XS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TkVX OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ2VuZXJhdGlvbiBvZiBTU0hGUCByZXNvdXJj ZSByZWNvcmRzIGZvciAmcXVvdDtzc2gtZWQyNTUxOSZxdW90OyBrZXlzIGlzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgZGVzY3JpYmVkIGluIFtSRkM3 NDc5XS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFNTSEZQIHJlc291cmNlIHJlY29yZHMg Zm9yICZxdW90O3NzaC1lZDQ0OCZxdW90OyBrZXlzIGlzIGdlbmVyYXRlZCBzaW1pbGFybHksDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGggdGhlIGFsZ29yaXRobSBm aWVsZCBpbmRpY2F0aW5nIGEgRWQ0NDggcHVibGljIGtleS4gJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBTU0hGUCBSZXNvdXJjZSBSZWNvcmQgZm9yIHRoZSBFZDQ0OCBwdWJsaWMg a2V5IHdpdGggU0hBLTI1NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zmlu Z2VycHJpbnQgd291bGQgYmUgZXhhbXBsZSBiZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZXhh bXBsZS5jb20uJm5ic3A7IElOIFNTSEZQIFRCRCAyICggYTg3ZjFiNjg3YWMwZTU3ZDJhMDgxYTJm MjgyNjcyMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MzRkOTBlZDMxNmQy YjgxOGNhOTU4MGVhMzg0ZDkyNCAwMSApPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSAyIGhl cmUgaW5kaWNhdGVzIFNIQS0yNTYgW1JGQzY1OTRdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gTG9nYW5hZGVuIFZlbHZpbmRyb24gJmx0O2xvZ2FuYWRlbkBnbWFpbC5jb20m Z3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAwNiwgMjAxOSAzOjAyIEFNPGJy Pg0KPGI+VG86PC9iPiBEYW5pZWwgTWlnYXVsdCAmbHQ7ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24u Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQmVuamFtaW4gS2FkdWsgJmx0O2thZHVrQG1pdC5lZHUm Z3Q7OyBkcmFmdC1pZXRmLWN1cmRsZS1zc2gtZWQyNTUxOS1lZDQ0OC5hbGxAaWV0Zi5vcmc7IGN1 cmRsZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogbmV3IEFEIHJldmlldyBjb21t ZW50cyBvbiBkcmFmdC1pZXRmLWN1cmRsZS1zc2gtZWQyNTUxOS1lZDQ0OC0wODxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbHJlYWR5IHB1Ymxpc2hlZCByZXYwOCB0byBhZGRyZXNz IHRob3NlIGlzc3Vlczo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/ZGlmZnR5cGU9LS1od2Rp ZmYmYW1wO3VybDI9ZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLWVkMjU1MTktZWQ0NDgtMDgudHh0Ij5o dHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/ZGlmZnR5cGU9LS1od2RpZmYmYW1wO3VybDI9 ZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLWVkMjU1MTktZWQ0NDgtMDgudHh0PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1biA1 LCAyMDE5IGF0IDU6NTIgUE0gRGFuaWVsIE1pZ2F1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5p ZWwubWlnYXVsdEBlcmljc3Nvbi5jb20iPmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzIEJlbiBmb3IgdGhlIGZvbGxvdy11cCwgcGxlYXNlIHNlZSBteSBy ZXNwb25zZXMgaW5saW5lIGZvciAoMikgYW5kICg0KS4gSSBiZWxpZXZlIGEgdmVyc2lvbiAwOCBp cyBuZWVkZWQgdG8gYWRkcmVzcyAoMSkgYW5kICgyKS4NCjxicj4NCllvdXJzLCA8YnI+DQpEYW5p ZWw8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEJlbmph bWluIEthZHVrICZsdDs8YSBocmVmPSJtYWlsdG86a2FkdWtAbWl0LmVkdSIgdGFyZ2V0PSJfYmxh bmsiPmthZHVrQG1pdC5lZHU8L2E+Jmd0Ow0KPGJyPg0KU2VudDogVHVlc2RheSwgSnVuZSAwNCwg MjAxOSAxOjQxIFBNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWN1cmRsZS1z c2gtZWQyNTUxOS1lZDQ0OC5hbGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWll dGYtY3VyZGxlLXNzaC1lZDI1NTE5LWVkNDQ4LmFsbEBpZXRmLm9yZzwvYT48YnI+DQpDYzogPGEg aHJlZj0ibWFpbHRvOmN1cmRsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmN1cmRsZUBpZXRm Lm9yZzwvYT48YnI+DQpTdWJqZWN0OiBuZXcgQUQgcmV2aWV3IGNvbW1lbnRzIG9uIGRyYWZ0LWll dGYtY3VyZGxlLXNzaC1lZDI1NTE5LWVkNDQ4LTA4PGJyPg0KPGJyPg0KSGkgYWxsLDxicj4NCjxi cj4NCkknbSBqdXN0IGFib3V0IHJlYWR5IHRvIHNlbmQgdGhpcyB0byB0aGUgSUVTRywgYnV0IHRo ZXJlIHNlZW1zIHRvIGJlIGEgZmV3IHRoaW5ncyB0byBmaXgsIGZpcnN0Ojxicj4NCjxicj4NCigx KSBJbiBTZWN0aW9uIDggd2Ugc2F5ICZxdW90O1RoZSBnZW5lcmF0aW9uIG9mIFNTSEZQIHJlc291 cmNlIHJlY29yZHMgZm9yICZxdW90O3NzaC1lZDQ0OCZxdW90OyBrZXlzIGlzIGRlc2NyaWJlZCBh cyBmb2xsb3dzLiZxdW90OyBidXQgdGhlbiBnaXZlIG9ubHkgYW4gZXhhbXBsZSBhbmQgbm90IGEg ZGVzY3JpcHRpb24gb2Ygd2hhdCB0byBkby4mbmJzcDsgV2UgbmVlZCB0byBzYXkgbW9yZSBhYm91 dCB0aGlzIHByb2NlZHVyZTxicj4NCjxicj4NCigyKSBJJ20gbm90IHN1cmUgaWYgdGhlIGNoYWlu IG9uIHRoZSBvcHNkaXIgcmV2aWV3IGdvdCBmdWxseSByZXNvbHZlZDsgc2VlIDxhIGhyZWY9Imh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY3VyZGxlL0RaYzJTcjE5eko3MW5u QzNwU0lGMHVQaGFDayIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9jdXJkbGUvRFpjMlNyMTl6Sjcxbm5DM3BTSUYwdVBoYUNrPC9hPjxicj4N CiZsdDttZ2x0Jmd0Ozxicj4NClRoZSBjdXJyZW50IHZlcnNpb24gaGFzIG5vdCBhY2NvcmRpbmds eSBiZWVuIHVwZGF0ZWQuIDxicj4NCiZsdDsvbWdsdCZndDs8YnI+DQo8YnI+DQooMykgVGhlIHNo ZXBoZXJkIHdyaXRldXAgc2F5cyB0aGF0IEJlbiBkaWQgbm90IGNvbmZpcm0gSVBSIChub24pZGlz Y2xvc3VyZSBwZXIgQkNQcyA3OCBhbmQgNzkgLS0gQmVuLCBjYW4geW91IHBsZWFzZSBkbyBzbyBu b3c/PGJyPg0KPGJyPg0KKDQpIERhbmllbCwgY2FuIHlvdSBwbGVhc2UgdXBkYXRlIHRoZSBzaGVw aGVyZCB3cml0ZXVwIHRvIHJlZmxlY3QgdGhlIGRpc2N1c3Npb25zIHdpdGggdGhlIGRpcmVjdG9y YXRlIHJldmlld2VycyBhYm91dCBkb2N1bWVudCBzdGF0dXM/Jm5ic3A7IEknbSBzdXJlIHRoYXQg c29tZSBJRVNHIG1lbWJlcnMgd2lsbCBhc2sgJnF1b3Q7d2h5IG5vdCBJbmZvcm1hdGlvbmFsPyZx dW90OyBpZiB3ZSBkb24ndCBmb3Jlc3RhbGwgdGhlbS48YnI+DQo8YnI+DQombHQ7bWdsdCZndDs8 YnI+DQpJIGhhdmUgdXBkYXRlIHRoZSBzaGVwaGVyZCBhcyBmb2xsb3dzOjxicj4NCjxicj4NCigx KSBXaGF0IHR5cGUgb2YgUkZDIGlzIGJlaW5nIHJlcXVlc3RlZCAoQkNQLCBQcm9wb3NlZCBTdGFu ZGFyZCw8YnI+DQpJbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFs LCBvciBIaXN0b3JpYyk/Jm5ic3A7IFdoeTxicj4NCmlzIHRoaXMgdGhlIHByb3BlciB0eXBlIG9m IFJGQz8mbmJzcDsgSXMgdGhpcyB0eXBlIG9mIFJGQyBpbmRpY2F0ZWQgaW4gdGhlPGJyPg0KdGl0 bGUgcGFnZSBoZWFkZXI/PGJyPg0KPGJyPg0KVGhlIHJlcXVlc3RlZCBzdGF0dXMgaXMgU3RhbmRh cmQgVHJhY2suIFRoaXMgaXMgbmVjZXNzYXJ5IGZvciA8YnI+DQppbnRlci1vcGVyYWJpbGl0eSZu YnNwOyBhbmQgYXMgc3VjaCB0aGUgU3RhbmRhcmQgVHJhY2sgc2VlbXMgdGhlIDxicj4NCm1vc3Qg YXBwcm9wcmlhdGVkIHN0YXR1cy4mbmJzcDsgPGJyPg0KPGJyPg0KVGhlIE9QUyBEaXJlY3RvcmF0 ZSB3b25kZXJlZCB3aHkgdmVyc2lvbiAwNyB3YXMgYSBTdGFuZGFyZCBUcmFjayA8YnI+DQpkb2N1 bWVudCBhbmQgbm90IGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgYXMgbm8gbm9ybWF0aXZlIDIx MTkgd29yZHMuIDxicj4NCjxicj4NClRoZSByZWFzb24gZm9yIGJlaW5nIGEgc3RhbmRhcmQgdHJh Y2sgaXMgdGhhdCB3ZSBleHBlY3QgdGhlIGltcGxlbWVudGF0aW9uIDxicj4NCnRoYXQgaW1wbGVt ZW50IFNTSCB0byBmb2xsb3cgdGhlc2UgcmVjb21tZW5kYXRpb25zLiBUaGUgY29uc2Vuc3VzIHdh cyA8YnI+DQp0byBleHBsaWNpdGx5IG1lbnRpb24gaXQgaW4gdGhlIGRvY3VtZW50IGFyb3VuZCB0 aGUgbGluZXM6PGJyPg0KPGJyPg0KJnF1b3Q7U3RhbmRhcmQgaW1wbGVtZW50YXRpb25zIG9mIFNT SCBTSE9VTEQgaW1wbGVtZW50IHRoZXNlIHNpZ25hdHVyZSBhbGdvcml0aG1zLiZxdW90Ozxicj4N CiZsdDsvbWdsdCZndDs8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KQmVuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR15MB3531792B7CB48B7E08D67E2CE3170DM6PR15MB3531namp_-- From nobody Thu Jun 6 08:00:17 2019 Return-Path: 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> <5D36713D8A4E7348A7E10DF7437A4B92902DEBEC@NKGEML515-MBX.china.huawei.com> In-Reply-To: From: Daniel Migault Date: Thu, 6 Jun 2019 10:59:52 -0400 Message-ID: To: Loganaden Velvindron Cc: Sheng Jiang , Tim Hollebeek , "ops-dir@ietf.org" , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000c9163058aa8f895" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:00:09 -0000 --0000000000000c9163058aa8f895 Content-Type: text/plain; charset="UTF-8" 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 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 > 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 >>> Sent: Thursday, January 03, 2019 8:59 AM >>> To: Daniel Migault ; 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 ; 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 >>> Sent: Wednesday, January 02, 2019 1:12 PM >>> To: Daniel Migault ; 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 On Behalf Of Daniel Migault >>> > Sent: Wednesday, January 2, 2019 10:43 AM >>> > To: Sheng Jiang ; 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 >>> > 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 >>> >> --0000000000000c9163058aa8f895 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is correct, I was looking at the wrong version 07. I = believe this issue is now closed.
Yours,=C2=A0
Daniel

On= Thu, Jun 6, 2019 at 2:13 AM Loganaden Velvindron <loganaden@gmail.com> wrote:
I believe that this c= hange already took place in rev08. What more do we need to add ?
On Wed, = Jun 5, 2019 at 5:53 PM Daniel Migault <daniel.migault@ericsson.com> wrote:<= br>
Dear co-authors of curdle-ssh-ed25519-ed448,=C2=A0

Coul= d we update the document and address the concern from Sheng ?
Yours,=C2=A0
Daniel=C2=A0

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.<= br>
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@digi= cert.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 be= tter for a "standard track" document, if it gave a little bit mor= e detailed guidance "where" and "how" a SSH implement s= hould 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&g= t;; ops-dir@ietf.org<= /a>
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 S= SH 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; <= a href=3D"mailto:curdle@ietf.org" target=3D"_blank">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 <= br> > 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 <= br> > *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}.<= br> >
> (RFC4250 and) RFC4253 provided the initial values for the Public Key registry.
> While the protocol comes with some registry values, my understanding <= br> > 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 <= br> > 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, <= br> > 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 integ= rated 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; <= a href=3D"mailto:curdle@ietf.org" target=3D"_blank">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&#= 39;s
> ongoing effort to review all IETF documents being processed by the IES= G.
> 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 co= mments.
>
> This standard track document describes the use of the Ed25519 and
> Ed448 digital signature algorithm in the Secure Shell (SSH) protocol.= =C2=A0
> 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 <= br> > "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 a= ny
> 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
--0000000000000c9163058aa8f895-- From nobody Fri Jun 7 15:26:32 2019 Return-Path: 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 2EF5D120161; Fri, 7 Jun 2019 15:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 t-S9KLn6bdec; Fri, 7 Jun 2019 15:26:28 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698571200BA; Fri, 7 Jun 2019 15:26:27 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x57MQBhD032328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 Jun 2019 18:26:14 -0400 Date: Fri, 7 Jun 2019 17:26:11 -0500 From: Benjamin Kaduk To: Daniel Migault , bjh21@bjh21.me.uk Cc: Loganaden Velvindron , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" Message-ID: <20190607222610.GH83686@kduck.mit.edu> References: <20190604174029.GC8678@prolepsis.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 22:26:31 -0000 On Thu, Jun 06, 2019 at 02:56:46PM +0000, Daniel Migault wrote: > This is correct, for some reasons I reviewed version 07. So version 08 is solving the opsdir issue. I will close the thread on the mailing list. Ah, thank you. Thanks also to Loganaden for the updates in the -08, and sorry for not having confirmed that they did address the opsdir review comment. > The SSHF Record includes the algorithm used for the public key, the type of the fingerprint. The current draft only adds a registry for the algorithm. I believe the confusion might be that the current text seems to indicate some additional changes for example in the generation of the finger print. Maybe the text below around the following lines clarifies the purpose of the changes. That seems likely. > If so, the only remaining point is the IPR declaration. [adding Ben to the To: list to try to answer this question.] -Ben > OLD: > The generation of SSHFP resource records for "ssh-ed25519" keys is > described in [RFC7479]. > > The generation of SSHFP resource records for "ssh-ed448" keys is > described as follows. > > the SSHFP Resource Record for the Ed448 public key with SHA-256 > fingerprint would be example be: > > example.com. IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f2826723 > 34d90ed316d2b818ca9580ea384d924 01 ) > > The 2 here indicates SHA-256 [RFC6594]. > > NEW: > > The generation of SSHFP resource records for "ssh-ed25519" keys is > described in [RFC7479]. > > The SSHFP resource records for "ssh-ed448" keys is generated similarly, > with the algorithm field indicating a Ed448 public key. > > The SSHFP Resource Record for the Ed448 public key with SHA-256 > fingerprint would be example be: > > example.com. IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f2826723 > 34d90ed316d2b818ca9580ea384d924 01 ) > > The 2 here indicates SHA-256 [RFC6594]. > > From: Loganaden Velvindron > Sent: Thursday, June 06, 2019 3:02 AM > To: Daniel Migault > Cc: Benjamin Kaduk ; draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org > Subject: Re: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 > > I already published rev08 to address those issues: > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-curdle-ssh-ed25519-ed448-08.txt > > On Wed, Jun 5, 2019 at 5:52 PM Daniel Migault > wrote: > Thanks Ben for the follow-up, please see my responses inline for (2) and (4). I believe a version 08 is needed to address (1) and (2). > Yours, > Daniel > > -----Original Message----- > From: Benjamin Kaduk > > Sent: Tuesday, June 04, 2019 1:41 PM > To: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org > Cc: curdle@ietf.org > Subject: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08 > > Hi all, > > I'm just about ready to send this to the IESG, but there seems to be a few things to fix, first: > > (1) In Section 8 we say "The generation of SSHFP resource records for "ssh-ed448" keys is described as follows." but then give only an example and not a description of what to do. We need to say more about this procedure > > (2) I'm not sure if the chain on the opsdir review got fully resolved; see https://mailarchive.ietf.org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uPhaCk > > The current version has not accordingly been updated. > > > (3) The shepherd writeup says that Ben did not confirm IPR (non)disclosure per BCPs 78 and 79 -- Ben, can you please do so now? > > (4) Daniel, can you please update the shepherd writeup to reflect the discussions with the directorate reviewers about document status? I'm sure that some IESG members will ask "why not Informational?" if we don't forestall them. > > > I have update the shepherd as follows: > > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in the > title page header? > > The requested status is Standard Track. This is necessary for > inter-operability and as such the Standard Track seems the > most appropriated status. > > The OPS Directorate wondered why version 07 was a Standard Track > document and not an informational document as no normative 2119 words. > > The reason for being a standard track is that we expect the implementation > that implement SSH to follow these recommendations. The consensus was > to explicitly mention it in the document around the lines: > > "Standard implementations of SSH SHOULD implement these signature algorithms." > > Thanks, > > Ben From nobody Fri Jun 7 15:35:24 2019 Return-Path: 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 BA07E1201B4; Fri, 7 Jun 2019 15:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 H2MODJd4JkhW; Fri, 7 Jun 2019 15:35:20 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B876712018F; Fri, 7 Jun 2019 15:35:20 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x57MZGET002143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 Jun 2019 18:35:18 -0400 Date: Fri, 7 Jun 2019 17:35:15 -0500 From: Benjamin Kaduk To: Hubert Kario Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, curdle@ietf.org Message-ID: <20190607223515.GI83686@kduck.mit.edu> References: <20190508150604.GB30884@kduck.mit.edu> <4446646.IAIBc4NGeb@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4446646.IAIBc4NGeb@pintsize.usersys.redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] new-AD review comments on draft-ietf-curdle-gss-keyex-sha2-08 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 22:35:23 -0000 Sorry for the slow reply -- it's been a busy month in my personal situation. On Thu, May 09, 2019 at 12:34:40PM +0200, Hubert Kario wrote: > On Wednesday, 8 May 2019 17:06:04 CEST Benjamin Kaduk wrote: > > Hi all, > > > > I'm almost ready to send draft-ietf-curdle-gss-keyex-sha2 to the IESG for > > evaluation, but would like to see a new revision posted first, mostly for > > the Abstract changes. In addition to the changes mentioned below, please > > also go ahead and make the editorial changes mentioned in the last > > call/directorate reviews. > > > > -Ben > > > > Abstract > > > > This document specifies additions and amendments to RFC4462. It > > defines a new key exchange method that uses SHA-2 for integrity and > > deprecates weak DH groups. The purpose of this specification is to > > > > I think we need to remove this statement about "deprecates weak DH groups"; > > I didn't see any further discussion of such deprecations in any revision of > > the document. > > > we've done that by not listing them, would you prefer to list them explicitly > in section 6 and Section 4 with a "MUST NOT" in "Implementation Support" and > "Implementation Recommendations"? Since we are only Update:ing 4462 and not Obsolete:ing it, we do need to explicitly say what is deprecated. The sections you list seem like fine places (note that since the IANA registry doesn't list the "implementation support" column, it seems that our request would just be to add this document as a reference for the affected entries). -Ben > > Section 2 > > > > Following the > > rationale of [RFC8268] only SHA-256 and SHA-512 hashes are used for > > DH groups. For NIST curves the same curve-to-hashing algorithm > > pairing used in [RFC5656] is adopted for consistency. > > > > 8268 doesn't provide a whole lot of rationale for using SHA-256, rather, > > the closest thing to guidance would be in Section 1 where it cites the NSA > > IAD FAQ that wants to *avoid* using SHA-256. So perhaps it's better to say > > that this just follows the practice of 8268, rather than the rationale from > > it, especially since we are just using a "consistency" argument for the > > NIST curves' hashes. > > yes, "practice" would work better in this context > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic From nobody Fri Jun 7 15:37:08 2019 Return-Path: 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 BC27512016B; Fri, 7 Jun 2019 15:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PeX-FUCaUYRh; Fri, 7 Jun 2019 15:37:04 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19964120146; Fri, 7 Jun 2019 15:37:03 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x57Max2H002535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 Jun 2019 18:37:02 -0400 Date: Fri, 7 Jun 2019 17:36:59 -0500 From: Benjamin Kaduk To: Simo Sorce Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, curdle@ietf.org Message-ID: <20190607223658.GJ83686@kduck.mit.edu> References: <20190508150604.GB30884@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] new-AD review comments on draft-ietf-curdle-gss-keyex-sha2-08 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 22:37:07 -0000 On Fri, May 10, 2019 at 10:02:36AM -0400, Simo Sorce wrote: > Answers inline. > > On Wed, 2019-05-08 at 10:06 -0500, Benjamin Kaduk wrote: > > Hi all, > > > > I'm almost ready to send draft-ietf-curdle-gss-keyex-sha2 to the IESG for > > evaluation, but would like to see a new revision posted first, mostly for > > the Abstract changes. In addition to the changes mentioned below, please > > also go ahead and make the editorial changes mentioned in the last > > call/directorate reviews. > > > > -Ben > > > > Abstract > > > > This document specifies additions and amendments to RFC4462. It > > defines a new key exchange method that uses SHA-2 for integrity and > > deprecates weak DH groups. The purpose of this specification is to > > > > I think we need to remove this statement about "deprecates weak DH groups"; > > I didn't see any further discussion of such deprecations in any revision of > > the document. > > See Hubert's question > > > Section 2 > > > > Following the > > rationale of [RFC8268] only SHA-256 and SHA-512 hashes are used for > > DH groups. For NIST curves the same curve-to-hashing algorithm > > pairing used in [RFC5656] is adopted for consistency. > > > > 8268 doesn't provide a whole lot of rationale for using SHA-256, rather, > > the closest thing to guidance would be in Section 1 where it cites the NSA > > IAD FAQ that wants to *avoid* using SHA-256. So perhaps it's better to say > > that this just follows the practice of 8268, rather than the rationale from > > it, especially since we are just using a "consistency" argument for the > > NIST curves' hashes. > > Fixed, replaced "rationale" with "practice" > > > Section 3 > > > > RFC 8174 has an updated boilerplate text to use for the BCP 14 keywords. > > Fixed > > > Section 4 > > > > The method name for each method is the concatenation of > > the family method name with the Base64 encoding of the MD5 hash > > [RFC1321] of the ASN.1 DER encoding [ISO-IEC-8825-1] of the > > underlying GSS-API mechanism's OID. [...] > > > > nit: I'd suggest using the "family name prefix" to match the table, rather > > than "family method name". > > Fixed > > > Section 5 > > > > In [RFC5656] new SSH key exchange algorithms based on Elliptic Curve > > Cryptography are introduced. We reuse much of section 4 to define > > GSS-API-authenticated ECDH Key Exchanges. > > > > nit: I think this is intended to refer to Section 4 of RFC 5656, but the > > current text reads like we are referring to Section 4 of the current > > document. > > Fixed > > > Section 5.1 > > > > For NIST Curves keys use uncompressed point representation and must > > > > nit: "the" > > > > be converted using the algorithm in Section 2.3.4 of [SEC1v2]. If > > the conversion fails or the point is trasmitted using compressed > > > > nit: "the" > > both nits Fixed > > > representation, the key exchange MUST fail. > > > > A GSS Context is established according to Section 4 of [RFC5656]; The > > client initiates the establishment using GSS_Init_sec_context() and > > the server completes it using GSS_Accept_sec_context(). For the > > > > I'm not sure what this reference was intended to be; the current one > > doesn't really seem right, though. > > > > Also, in a fully general GSS negotiation loop, the server does not > > necessarily make the last step, so "completes" may be slightly misleading. > > Would it be ok to replace "completes" with "responds to" ? I think so. (And sorry for nitpicking so much on this; you have the misfortune of having an AD who is a bit of a subject matter expert.) > > This key > > exchange process will exchange only a single token once the context > > has been established, therefore the replay_det_req_flag and > > sequence_req_flag SHOULD be set to "false". > > > > nit: "single message token", since we are not making a statement about > > context establishment tokens, and the previous text was about the context > > establishment process which might cause the reader to jump towards context > > tokens here. > > I am not sure what you are suggesting/requesting here, can you clarify? I'm suggesting s/single token/single message token/, to reiterate that these are not context tokens. > > For curve25519 and curve448 the algorithm in Section 6 > > of [RFC7748] is used instead. > > > > nits: "algorithms", "are" (since there are different procedures in > > subsections 6.1 and 6.2 for the two curves). > > Fixed > > > Section 6 > > > > It's not clear to me why the "Implementation Support" column is here -- it > > duplicates content from tables elsewhere in the document, and does not seem > > to be part of the registration template. > > Ok, I'll drop the column. > > > Section 7.3 > > > > Some GSSAPI mechanisms can optionally delegate credentials to the > > target host by setting the deleg_ret_flag. In this case extra care > > must be taken to ensure that the acceptor being authenticated matches > > the target the user intended. [...] > > > > This is a bit weird to read, since the setting of the deleg_ret_flag is not > > what effectuates the delegation of credentials; that happens by virtue of > > the exchange of context tokens. (Also, RFC 2743 only lists a > > deleg_req_flag; the acceptor-side state is passed in the deleg_state > > boolean.) A simple replacement with deleg_req_flag doesn't work, either, > > as that's not something the mechanism does, but rather the GSSAPI consumer. > > So I think we may need a broader change, like: > > > > % Some GSSAPI mechanisms can act on a request to delegate credentials to > > % the target host when the deleg_req_flag is set. In this case, extra care > > % must be taken to ensure that the acceptor being authenticated matches the > > % target the user intended. [...] > > > > (And yes, I know that I'm basically responsible for this text being > > present; it may well have been my error originally.) > > I like your wording better too, and nice catch on the flag name typo. > > Once I get answers on the remaining open questions I will include the > results of the discussion in the document[1] and issue a new draft. Thanks, and sorry again for the slow response! -Ben > Thanks, > Simo. > > [1] https://github.com/simo5/ietf/blob/master/draft-ietf-curdle-gss-keyex-sha2.xml > > -- > Simo Sorce > Sr. Principal Software Engineer > Red Hat, Inc > > From nobody Tue Jun 11 11:18:42 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 219DF120045; Tue, 11 Jun 2019 11:18:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: curdle@ietf.org Message-ID: <156027712106.30757.9607699716330574678@ietfa.amsl.com> Date: Tue, 11 Jun 2019 11:18:41 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-gss-keyex-sha2-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 18:18:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption WG of the IETF. Title : GSS-API Key Exchange with SHA2 Authors : Simo Sorce Hubert Kario Filename : draft-ietf-curdle-gss-keyex-sha2-09.txt Pages : 13 Date : 2019-06-11 Abstract: This document specifies additions and amendments to RFC4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak DH groups. The purpose of this specification is to modernize the cryptographic primitives used by GSS Key Exchanges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-gss-keyex-sha2-09 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-gss-keyex-sha2-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-gss-keyex-sha2-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 24 00:58:09 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F825120048; Mon, 24 Jun 2019 00:58:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156136308744.17526.2499755801288512746.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 00:58:07 -0700 Archived-At: Subject: [Curdle] Barry Leiba's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 07:58:08 -0000 Barry Leiba has entered the following ballot position for draft-ietf-curdle-gss-keyex-sha2-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 2 -- we propose the use of the SHA-2 [RFC6234] based hashes Two nits here: first, the second "the" seems odd. Second, "SHA-2-based hashes" needs to be hyphenated, which makes the double hyphen odd and moves the citation. I suggest, "we propose the use of hashes based on SHA-2 [RFC6234]". -- Section 4 (and also 5.2) -- Each key exchange method is implicitly registered by this document. The registration is not implicit; it's explicit in Section 7. I suggest removing "implicitly". -- Section 8.3 -- Nits: "Some mechanisms implementations" should be "Some mechanism implementations", "(like commonly used krb5 libraries)" should be "(such as commonly used krb5 libraries)", and "may results" should be "may result". From nobody Mon Jun 24 07:38:58 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B48E212012B; Mon, 24 Jun 2019 07:38:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 07:38:56 -0700 Archived-At: Subject: [Curdle] Roman Danyliw's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 14:38:57 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-curdle-gss-keyex-sha2-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 5.1, Per “The exchange hash SHOULD be kept secret”, when should it not be (i.e., why isn’t this a MUST?)? Editorial Items: ** Section 2. Provide a reference to X25519 and X448 Curves ** Section 3. Typo. s/>RFC2119/RFC2119/ ** Section 4. Editorial. The sentence “The following new key exchange …” is indented. ** Section 4 and 5.2. Per “Each key exchange method id implicitly registered by this document”, aren’t these key exchange methods explicitly registering them in IANA-KEX-NAMES per Section 7? ** Section 4. Explicitly name, number and reference the table in the text ** Section 4. Typo. s/refences/references/ ** Section 5. Editorial. s/Additionally we utilize also/Additionally, we also utilize/ ** Section 5. Editorial. s/3 classic/three classic/ ** Section 5.1. It is worth repeating (or moving the text) to Section 8 that the Security Considerations of RFC7546 apply ** Section 5.1. Typo. s/trasmitted/transmitted/ ** Section 5.1. Typo. s/estalishment/establishment/ ** Section 5.1. The various variable (e.g., V_C, V_S) are introduced early in the algorithm to construct H and the messages in page 6, but they aren’t described until the end of page 7. I wasn’t following the narrative until I hit that section. ** Section 5.2. Explicitly number the table and reference it in the text. ** Section 5.2. Typo. s/refences/references/ ** Section 6. This section references a table. Explicitly name and number that table. From nobody Mon Jun 24 08:44:03 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C412008F; Mon, 24 Jun 2019 08:44:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <156139104143.17449.9632346081496014534.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 08:44:01 -0700 Archived-At: Subject: [Curdle] Suresh Krishnan's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 15:44:02 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-curdle-gss-keyex-sha2-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 8.3 I think a pointer to DNSSEC might be relevant here in the context of spoofed DNS responses. From nobody Mon Jun 24 10:32:36 2019 Return-Path: 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 D25EA12000F; Mon, 24 Jun 2019 10:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 flYTp55ipN9C; Mon, 24 Jun 2019 10:32:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D132120120; Mon, 24 Jun 2019 10:32:32 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5OHWLPB029276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jun 2019 13:32:23 -0400 Date: Mon, 24 Jun 2019 12:32:20 -0500 From: Benjamin Kaduk To: Barry Leiba , rdd@cert.org Cc: The IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org Message-ID: <20190624173220.GC48838@kduck.mit.edu> References: <156136308744.17526.2499755801288512746.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156136308744.17526.2499755801288512746.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] Barry Leiba's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 17:32:34 -0000 (Adding Roman since he asked the same thing...) On Mon, Jun 24, 2019 at 12:58:07AM -0700, Barry Leiba via Datatracker wrote: > > -- Section 4 (and also 5.2) -- > > Each key exchange method is implicitly registered by this document. > > The registration is not implicit; it's explicit in Section 7. I suggest > removing "implicitly". It's implicit in that the registration is not producing a list of (md5 hash of OID) that are appended to the prefix and registered individually -- the prefix is being registered but not all the possible values that would go on the wire. -Ben From nobody Mon Jun 24 13:18:17 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD7F12002E; Mon, 24 Jun 2019 13:18:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 13:18:08 -0700 Archived-At: Subject: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 20:18:08 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-curdle-gss-keyex-sha2-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- "The IESG is considered to be the owner of all these key exchange methods; this does NOT imply that the IESG is considered to be the owner of the underlying GSS-API mechanism." I don't understand this text. What does it mean for the IESG to be the owner of a method? From nobody Mon Jun 24 13:20:19 2019 Return-Path: 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 6A6601200F7; Mon, 24 Jun 2019 13:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GbBXXcajK_WB; Mon, 24 Jun 2019 13:20:09 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708E5120045; Mon, 24 Jun 2019 13:20:09 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5OKJtLW005112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jun 2019 16:19:58 -0400 Date: Mon, 24 Jun 2019 15:19:55 -0500 From: Benjamin Kaduk To: Alissa Cooper Cc: The IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Message-ID: <20190624201955.GD48838@kduck.mit.edu> References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 20:20:12 -0000 On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-curdle-gss-keyex-sha2-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > "The IESG is considered to be the owner of all these key exchange > methods; this does NOT imply that the IESG is considered to be the > owner of the underlying GSS-API mechanism." > > I don't understand this text. What does it mean for the IESG to be the owner of a method? The IESG has change control for the SSH key exchange method; the IESG does not necessarily have change control for the underlying GSS-API mechanism. -Ben From nobody Mon Jun 24 14:01:35 2019 Return-Path: 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 751D91200F7; Mon, 24 Jun 2019 14:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=fS8CbVMb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DM+eX2Eq 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 pz7VbcwFsJ-u; Mon, 24 Jun 2019 14:01:32 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4252E1200B3; Mon, 24 Jun 2019 14:01:32 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0BFB522452; Mon, 24 Jun 2019 17:01:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 24 Jun 2019 17:01:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=p LHVXoQlkb0wmin+Ut5gjPWPlkoNVqLhQnj4OFitC+4=; b=fS8CbVMbt96SHA9Iw bbFpWmiPAd6BYyo0TWPHxpcY9fe+xsDPgYwlB3bJKNiycQCgGa5eVSMpmT6KRmTr SeksTGSqaIv0L89ydClFYM9fVVzdDo7fRn6dSsvNb/a3H4lI1sMJWz3tJdGykBvD +j92VAeDfBJPWS4Sse7I0KVR6gZ4+4WIzJzZUj/jeRfxNhvTzR5oVK4iau7cwLkq ruqpXlb87eF4YzYN3jpsPCUEc8xunFmxXw1iVaFZn9JUHsEtiHxh2055DVSLOYcF 5KeyQf/rWWuEHW/QExHbj0Hg2CGxQp4G2ZcqB1b+b6F5IbNxVM9phigyLJiXjS76 fFwtQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=pLHVXoQlkb0wmin+Ut5gjPWPlkoNVqLhQnj4OFitC +4=; b=DM+eX2Eq8Gf/ZDFRSnPlTsg/i64/1fmHQ93nqJ5BMJLBcZgeJ+LsZdXig EQIRKK44pT2ScvLrXSInssLD3syYE1eGI+ayOHFjOEmYTbtFFGgkEGxUSfvTMPvE h/zUVfkFxL0HP7X7IGjFXR2r/RJbxCh+2OOlpf6tZtEQfgtDvFrcbhedcdzN/3MW Ntv6x/48ueq693MYgAyaQiM4YwXgGnz6IbwbkXJ4khmxGkROFMkeAJCNsnUv9T8c vcPlEYzkmU9UYBVs/pbXqyFGibej4hqRYPkg49oOLsY3DWHO+7OvUtmTO5gMNyl0 39CVhuQ5gU90ZbCK8uCLwXsL+yu5A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddvgdduheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkedunecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-vpn4-1540.cisco.com (unknown [173.38.117.81]) by mail.messagingengine.com (Postfix) with ESMTPA id CECCC80061; Mon, 24 Jun 2019 17:01:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <20190624201955.GD48838@kduck.mit.edu> Date: Mon, 24 Jun 2019 17:01:28 -0400 Cc: IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in> References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 21:01:35 -0000 > On Jun 24, 2019, at 4:19 PM, Benjamin Kaduk wrote: >=20 > On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via = Datatracker wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-curdle-gss-keyex-sha2-09: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> "The IESG is considered to be the owner of all these key exchange >> methods; this does NOT imply that the IESG is considered to be the >> owner of the underlying GSS-API mechanism." >>=20 >> I don't understand this text. What does it mean for the IESG to be = the owner of a method? >=20 > The IESG has change control for the SSH key exchange method; the IESG = does > not necessarily have change control for the underlying GSS-API = mechanism. Thanks. I think it would be clearer to say that than to talk about = ownership. But given that the registry policy is IETF Review, is it = really appropriate to say that the IESG has change control? Would s/IESG = has change control/IETF has change control/ be more accurate? Alissa >=20 > -Ben From nobody Mon Jun 24 14:09:00 2019 Return-Path: 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 60AAF120199; Mon, 24 Jun 2019 14:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TFoNhaosZTJo; Mon, 24 Jun 2019 14:08:50 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD87120177; Mon, 24 Jun 2019 14:08:49 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5OL8cAm024460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jun 2019 17:08:40 -0400 Date: Mon, 24 Jun 2019 16:08:37 -0500 From: Benjamin Kaduk To: Alissa Cooper Cc: IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Message-ID: <20190624210837.GE48838@kduck.mit.edu> References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 21:08:52 -0000 On Mon, Jun 24, 2019 at 05:01:28PM -0400, Alissa Cooper wrote: > > > > On Jun 24, 2019, at 4:19 PM, Benjamin Kaduk wrote: > > > > On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote: > >> Alissa Cooper has entered the following ballot position for > >> draft-ietf-curdle-gss-keyex-sha2-09: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> "The IESG is considered to be the owner of all these key exchange > >> methods; this does NOT imply that the IESG is considered to be the > >> owner of the underlying GSS-API mechanism." > >> > >> I don't understand this text. What does it mean for the IESG to be the owner of a method? > > > > The IESG has change control for the SSH key exchange method; the IESG does > > not necessarily have change control for the underlying GSS-API mechanism. > > Thanks. I think it would be clearer to say that than to talk about ownership. But given that the registry policy is IETF Review, is it really appropriate to say that the IESG has change control? Would s/IESG has change control/IETF has change control/ be more accurate? I'll wait to see what the authors think about the "ownership" vs. "change control" pedagogy. With respect to IESG vs. IETF, it seems that the IESG is who is tasked with determining the consensus of the IETF, so in practice it would be the IESG with control, even if in some formal sense the authority is vested with the IETF. (I thought it was near-universal to list the IESG as the contact when the IETF is the nominal responsible party; is this case different somehow?) Thanks, Ben From nobody Mon Jun 24 14:15:45 2019 Return-Path: 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 20293120199; Mon, 24 Jun 2019 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 IHoK-ad32YD2; Mon, 24 Jun 2019 14:15:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1817B12016B; Mon, 24 Jun 2019 14:15:35 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 189FFC0546D3; Mon, 24 Jun 2019 21:15:27 +0000 (UTC) Received: from ovpn-117-91.phx2.redhat.com (ovpn-117-91.phx2.redhat.com [10.3.117.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 263F510013D9; Mon, 24 Jun 2019 21:15:23 +0000 (UTC) Message-ID: <4706ad44c52bf2a76c429fc40d8c3a64c59b2303.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk , Alissa Cooper Cc: IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Date: Mon, 24 Jun 2019 17:15:22 -0400 In-Reply-To: <20190624210837.GE48838@kduck.mit.edu> References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in> <20190624210837.GE48838@kduck.mit.edu> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 24 Jun 2019 21:15:34 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 21:15:37 -0000 On Mon, 2019-06-24 at 16:08 -0500, Benjamin Kaduk wrote: > On Mon, Jun 24, 2019 at 05:01:28PM -0400, Alissa Cooper wrote: > > > > > > > On Jun 24, 2019, at 4:19 PM, Benjamin Kaduk wrote: > > > > > > On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote: > > > > Alissa Cooper has entered the following ballot position for > > > > draft-ietf-curdle-gss-keyex-sha2-09: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > email addresses included in the To and CC lines. (Feel free to cut this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > ---------------------------------------------------------------------- > > > > > > > > "The IESG is considered to be the owner of all these key exchange > > > > methods; this does NOT imply that the IESG is considered to be the > > > > owner of the underlying GSS-API mechanism." > > > > > > > > I don't understand this text. What does it mean for the IESG to be the owner of a method? > > > > > > The IESG has change control for the SSH key exchange method; the IESG does > > > not necessarily have change control for the underlying GSS-API mechanism. > > > > Thanks. I think it would be clearer to say that than to talk about ownership. But given that the registry policy is IETF Review, is it really appropriate to say that the IESG has change control? Would s/IESG has change control/IETF has change control/ be more accurate? > > I'll wait to see what the authors think about the "ownership" vs. "change > control" pedagogy. With respect to IESG vs. IETF, it seems that the IESG > is who is tasked with determining the consensus of the IETF, so in practice > it would be the IESG with control, even if in some formal sense the > authority is vested with the IETF. (I thought it was near-universal to > list the IESG as the contact when the IETF is the nominal responsible > party; is this case different somehow?) If I remember correctly this language has been inherited untouched from the original RFC we are updating. If at all possible we'd like to maintain consistency with the previous language and not change it. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc From nobody Mon Jun 24 14:54:20 2019 Return-Path: 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 B33621201D6; Mon, 24 Jun 2019 14:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 RIsLn0yChaH0; Mon, 24 Jun 2019 14:54:10 -0700 (PDT) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) (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 638AD12017F; Mon, 24 Jun 2019 14:54:10 -0700 (PDT) Received: by mail-io1-f68.google.com with SMTP id k8so2446280iot.1; Mon, 24 Jun 2019 14:54:10 -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=v6TnoNUf4xghDRmIQN87Xwqbtp0VzfWhZxpKAbk+fc4=; b=dB7GsKn8KTyVkbAAgYbtYvwNbwkSBQZlVtKToXr3FrT9SmI5+maafV0QQDZP8CFNC3 wI6OA2SHFKDhMMHfshc9lj056oR9XdlS2hR0fh22sBmzmdDhEg5ATYIM1Z9j4z5yODid AjfuWjCwIrCXhrZ/bBuaKSBmHS4ioKAGw1Tk/7nPiRRTZIlW81uFRZj3N6h2f84JTlzr qNPWMNCrM6v8rKIqoqyKQjXVIS4cI2oSYiN+NgpSSDv8ymAhbhnxVr20lE/g7UQSocvK SYLDUK76xHzByf+vXX7GM/3iqEkM+9wnFSD+5GohwNA2wUE1BFf9zhM9UvP97WludlmN GCHw== X-Gm-Message-State: APjAAAUaaCrPksidyxjcOcW35GaNa6zDtf5peaaoBDCw7UayoZol2Q5B hW66xN56ZRy5iZ175oDMIAcmG5ho6oSWS8fmCHA= X-Google-Smtp-Source: APXvYqx2NxI0cQw33AnbukmCkd8WUoXmDN+gMuQ/S0k1mH1lpr/ng63s6B7QuTQib8NHkwZC1ILNMRZJonF63plh5Nk= X-Received: by 2002:a5d:88c6:: with SMTP id i6mr3066948iol.107.1561413249259; Mon, 24 Jun 2019 14:54:09 -0700 (PDT) MIME-Version: 1.0 References: <156136308744.17526.2499755801288512746.idtracker@ietfa.amsl.com> <20190624173220.GC48838@kduck.mit.edu> In-Reply-To: <20190624173220.GC48838@kduck.mit.edu> From: Barry Leiba Date: Mon, 24 Jun 2019 22:53:58 +0100 Message-ID: To: Benjamin Kaduk Cc: "Roman D. Danyliw" , The IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Barry Leiba's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 21:54:12 -0000 > > Each key exchange method is implicitly registered by this document. > > > > The registration is not implicit; it's explicit in Section 7. I suggest > > removing "implicitly". > > It's implicit in that the registration is not producing a list of (md5 hash > of OID) that are appended to the prefix and registered individually -- the > prefix is being registered but not all the possible values that would go on > the wire. Then I'd prefer, "Each key exchange prefix is registered...," but it's not a DISCUSS, so use good judgment. b From nobody Mon Jun 24 14:54:57 2019 Return-Path: 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 4774112017F; Mon, 24 Jun 2019 14:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 dRvWTWU0FeCR; Mon, 24 Jun 2019 14:54:53 -0700 (PDT) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) (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 E893B12004D; Mon, 24 Jun 2019 14:54:52 -0700 (PDT) Received: by mail-io1-f67.google.com with SMTP id e5so485168iok.4; Mon, 24 Jun 2019 14:54:52 -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=DEiH9YeClm2TiR8MFeeVRQiePyLbsqflaaS6xGtzyg0=; b=q7teoGbCnMkGpdHNmwNOAr3e5TUgB+r7GCkQSeOSBnSTOg3tSsVnllFPS9+OmCowLZ y7S0HuGWYttmRsXGvXroNmAGFj+p3bGWu6Z4Z5RlZ022KQ5gX35X9HnucRUdrIkcE6fy It6N3ZiRTOKd6x7cGXAo13J1hMv/ACBebFfFOoJO/3pC3Trl6rKSgaY4x8CoKiri1U9F 7OHd/RV6xJfv7e3rX5aNyg20nlF0PPPu/OXt8prnB0maC/SZCBN80hCpTQqLtEomyiPh wphCMwIqmGYtBKNUXMMBoJGWv2fKnEMOhBHs0bzf6852waL5qHfTsUdPqi7eOIFvjXHf MoQw== X-Gm-Message-State: APjAAAUuYc8vhlhyWpHkeFXXWrC4qlL+gtlBZnJlPjWsiCG0iCwnwWee 6ttmIqe5bfXuv9lL9MpEL7iPTKMakfNCUA0Z50g= X-Google-Smtp-Source: APXvYqylSITu5w5SVMgtm/b+obEBjvY+YETeLM3bN1L+LZhqjFqt+/2+NU8S3kIqj5F23wUfe39kG8voE5sYyeRpBHU= X-Received: by 2002:a05:6602:2248:: with SMTP id o8mr11749524ioo.90.1561413291894; Mon, 24 Jun 2019 14:54:51 -0700 (PDT) MIME-Version: 1.0 References: <156136308744.17526.2499755801288512746.idtracker@ietfa.amsl.com> <20190624173220.GC48838@kduck.mit.edu> In-Reply-To: From: Barry Leiba Date: Mon, 24 Jun 2019 22:54:41 +0100 Message-ID: To: Benjamin Kaduk Cc: "Roman D. Danyliw" , The IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Barry Leiba's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 21:54:55 -0000 On Mon, Jun 24, 2019 at 10:53 PM Barry Leiba wrote: > > > > Each key exchange method is implicitly registered by this document. > > > > > > The registration is not implicit; it's explicit in Section 7. I suggest > > > removing "implicitly". > > > > It's implicit in that the registration is not producing a list of (md5 hash > > of OID) that are appended to the prefix and registered individually -- the > > prefix is being registered but not all the possible values that would go on > > the wire. > > Then I'd prefer, "Each key exchange prefix is registered...," but it's > not a DISCUSS, so use good judgment. I meant to say, "Each key exchange method prefix is registered...." From nobody Mon Jun 24 20:41:47 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ADD12004D; Mon, 24 Jun 2019 20:41:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156143410480.23869.1624832796787221435.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 20:41:44 -0700 Archived-At: Subject: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 03:41:45 -0000 Adam Roach has entered the following ballot position for draft-ietf-curdle-gss-keyex-sha2-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who invested work in this document. I support Alissa's discuss, especially in light of RFC 2743 being an IETF-stream document. --------------------------------------------------------------------------- §1: > SSH GSS-API Methods [RFC4462] allows the use of GSSAPI for > authentication and key exchange in SSH. It seems that RFC 2743 needs to be included as a normative reference for GSSAPI here. --------------------------------------------------------------------------- §4: > Base64 encoding is described in > Section 6.8 of [RFC2045]. For uses outside of MIME, RFC 4648 is far more conventional to cite. You want to point to section 4. --------------------------------------------------------------------------- §5: > Additionally we utilize also the curves defined in > [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined Nit: "NIST-defined" --------------------------------------------------------------------------- §5.1: > Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 perform the > Diffie-Helman protocol using the functions X25519 and X448, > respectively. Implementations SHOULD compute these functions using > the algorithms described in [RFC7748]. I don't usually quibble of "SHOULD" versus "MUST," but it seems that any implementation that doesn't heed this "SHOULD" simply won't interoperate. Unless I'm completely misunderstanding how Diffie-Helman works, it seems that this needs to be a "MUST" (or, in extremis, "MUST compute these functions using the algorithms described in [RFC7748] or functionally equivalent algorithms.") --------------------------------------------------------------------------- §5.1: > For NIST Curves the keys use the uncompressed point representation > and must be converted using the algorithm in Section 2.3.4 of > [SEC1v2]. "must" or "MUST"? --------------------------------------------------------------------------- §5.1: > To verify the integrity of the handshake, peers use the Hash Function > defined by the selected Key Exchange method to calculate H: > > H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K). Please indicate that these variables and the "||" operator will be described later in this section. --------------------------------------------------------------------------- §5.1: > The server may responds with: Nit: "...may respond with:" --------------------------------------------------------------------------- From nobody Tue Jun 25 05:26:56 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E57B1200D6; Tue, 25 Jun 2019 05:26:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156146561413.31253.16714028392697292709.idtracker@ietfa.amsl.com> Date: Tue, 25 Jun 2019 05:26:54 -0700 Archived-At: Subject: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-curdle-gss-keyex-sha2-09=3A_=28with_COMMENT=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 12:26:54 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-curdle-gss-keyex-sha2-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alissa's discuss as I also don't understand what that means, however, I hope that's easy to resolve. From nobody Tue Jun 25 07:52:48 2019 Return-Path: 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 BFA36120383; Tue, 25 Jun 2019 07:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=ngBK3/D+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V8qD8sBX 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 nlcrmzhUpGCO; Tue, 25 Jun 2019 07:52:40 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D691200C4; Tue, 25 Jun 2019 07:52:20 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2343B210DB; Tue, 25 Jun 2019 10:52:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 25 Jun 2019 10:52:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=xSq49AWylg/35xPSYm+Lw1J yKo7Ynskslforw/i53aA=; b=ngBK3/D+PqLkRNwdPl6ZhzF87N/AjZV0VsZ5OFh mIfS9x2GNAHYAqdHGdrPgvfsf+5egzoHYj6R5//kNdnIEbmesioEWj9WImImnh1R 7v3rcrRkjhhMX1NZDAmZNBFymwYtNC1Si44Su/rhpTUWaT7mTzzQ/s5peWLlpHD+ uhVog7srCu32zQA86i9ehDkM9LAl8x1gKysTbq4kqXsQsKj7BaWrgvLpejVI9iBH BRiIlH5foVPnlJjjmok9Xu3ZoDMV9wSemEoAXYDMA/VWSbmepAKWmG/4VShbu0nV F13KUpyanyf/uxFFTVkU9DN4Bf+ItZje73wPEl2h1SEShcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xSq49A Wylg/35xPSYm+Lw1JyKo7Ynskslforw/i53aA=; b=V8qD8sBXLE0lsDmKrd21hr 3ScFytvSLH8H8dXFXlgP5pCz41w8Lds3XBo0Ew7iDBaBCiR5jrzZkHJkAQG2z2cA QHl8P/O5AHcsMLbWyoVqKDpA394EN/kGRtiRKrd2XE0PRvmbBIK7s43cT0UNA3Ao PIjnOrhYKcYFNt5NR0S587GxwSxZ8YPS6cBMaphjGLDKt3/K6GYfJkV1rcPPJsrN jmtKxo0nGTU5Tpfb3FRzY5moOHUxGPLfkfUVZMdQ6IMmVcb7tG38b4OdEzSogb5Z 1+7BrJJgkNKd1ZlpytH5OQWJBv4Jh1ERS36x6yZbN4b+nl9jc88atTBo3XbpHzYQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeggdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrghinh epihgvthhfrdhorhhgnecukfhppedutdekrdehuddruddtuddrleeknecurfgrrhgrmhep mhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsthgvrh fuihiivgeptd X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 53BF280059; Tue, 25 Jun 2019 10:52:19 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C8C09A41-A0E6-43FE-89C7-9AFB8A3AF661" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 25 Jun 2019 10:52:18 -0400 In-Reply-To: <20190624210837.GE48838@kduck.mit.edu> Cc: IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org To: Benjamin Kaduk References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in> <20190624210837.GE48838@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 14:52:46 -0000 --Apple-Mail=_C8C09A41-A0E6-43FE-89C7-9AFB8A3AF661 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 24, 2019, at 5:08 PM, Benjamin Kaduk wrote: >=20 > On Mon, Jun 24, 2019 at 05:01:28PM -0400, Alissa Cooper wrote: >>=20 >>=20 >>> On Jun 24, 2019, at 4:19 PM, Benjamin Kaduk wrote: >>>=20 >>> On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via = Datatracker wrote: >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-curdle-gss-keyex-sha2-09: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> "The IESG is considered to be the owner of all these key exchange >>>> methods; this does NOT imply that the IESG is considered to be the >>>> owner of the underlying GSS-API mechanism." >>>>=20 >>>> I don't understand this text. What does it mean for the IESG to be = the owner of a method? >>>=20 >>> The IESG has change control for the SSH key exchange method; the = IESG does >>> not necessarily have change control for the underlying GSS-API = mechanism. >>=20 >> Thanks. I think it would be clearer to say that than to talk about = ownership. But given that the registry policy is IETF Review, is it = really appropriate to say that the IESG has change control? Would s/IESG = has change control/IETF has change control/ be more accurate? >=20 > I'll wait to see what the authors think about the "ownership" vs. = "change > control" pedagogy. With respect to IESG vs. IETF, it seems that the = IESG > is who is tasked with determining the consensus of the IETF, so in = practice > it would be the IESG with control, even if in some formal sense the > authority is vested with the IETF. (I thought it was near-universal = to > list the IESG as the contact when the IETF is the nominal responsible > party; is this case different somehow?) That usually appears in an actual registration (e.g., =E2=80=9CContact: = IESG >=E2=80=9D) whereas this = registry already has a registration policy of IETF Review and this text = doesn=E2=80=99t appear in the section where the new registrations are = made, so I didn=E2=80=99t understand what it meant. I can live with = =E2=80=9Cthe IESG is the change controller=E2=80=9D though. Thanks, Alissa >=20 > Thanks, >=20 > Ben --Apple-Mail=_C8C09A41-A0E6-43FE-89C7-9AFB8A3AF661 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 24, 2019, at 5:08 PM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

On Mon, Jun 24, 2019 at 05:01:28PM -0400, Alissa Cooper = wrote:


On Jun = 24, 2019, at 4:19 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:

On = Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker = wrote:
Alissa Cooper = has entered the following ballot position for
draft-ietf-curdle-gss-keyex-sha2-09: Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sh= a2/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

"The IESG is considered to be the = owner of all these key exchange
 methods; this does = NOT imply that the IESG is considered to be the
=  owner of the underlying GSS-API mechanism."

I don't understand this text. What does it mean for the IESG = to be the owner of a method?

The= IESG has change control for the SSH key exchange method; the IESG = does
not necessarily have change control for the = underlying GSS-API mechanism.

Thanks. I think it would be clearer to say that than to talk = about ownership. But given that the registry policy is IETF Review, is = it really appropriate to say that the IESG has change control? Would = s/IESG has change control/IETF has change control/ be more accurate?

I'll wait to see what the authors = think about the "ownership" vs. "change
control" pedagogy. =  With respect to IESG vs. IETF, it seems that the IESG
is who is tasked with determining the consensus of the IETF, = so in practice
it would be the IESG with control, even if = in some formal sense the
authority is vested with the = IETF.  (I thought it was near-universal to
list the = IESG as the contact when the IETF is the nominal responsible
party; is this case different somehow?)

That = usually appears in an actual registration (e.g., =E2=80=9CContact: IESG = <iesg@ietf.org>=E2=80= =9D) whereas this registry already has a registration policy of IETF = Review and this text doesn=E2=80=99t appear in the section where the new = registrations are made, so I didn=E2=80=99t understand what it meant. I = can live with =E2=80=9Cthe IESG is the change controller=E2=80=9D = though.

Thanks,
Alissa


Thanks,

Ben

= --Apple-Mail=_C8C09A41-A0E6-43FE-89C7-9AFB8A3AF661-- From nobody Tue Jun 25 07:53:47 2019 Return-Path: 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 15962120183; Tue, 25 Jun 2019 07:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=M5EOXj/O; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D5zCpJ6C 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 FE2QC4KsuhE8; Tue, 25 Jun 2019 07:53:37 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028421205E1; Tue, 25 Jun 2019 07:53:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ECF48220FF; Tue, 25 Jun 2019 10:53:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 25 Jun 2019 10:53:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=v m8oq0eVdPoAT1I84LMjV7r2781Vsp1eicbzocjcjok=; b=M5EOXj/OmMApEwcVo pbD6X4CoMy/j70Bci0FUT4rA2Pr/Vpn0FK0m6fg7Yzi9rT/XNZc6/nYg9iFl37ED OeTxn+Un5N3zVcySn+N3oYVCgxb28rqWHg1eC6wxqe5ZwbjsLCjJ1dxCridzp2ga neulAW0ovC8PkqKur2+UChqFsDcc6RH+4SLtfvywdF3F5pINdtv6FcPCR8F5D5lU pXLTrUIcqnC0bC3CBqW169kCzoVn3uRiBeqo90vtEV8DCRFDQvzcliabytlvpnz9 qw5G3E4gMKqIWoIJJYx3fV1CJtz5xUMpj5gzjin8pPvQ2mROiqD30Jq+VRUHz1hK iKhBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=vm8oq0eVdPoAT1I84LMjV7r2781Vsp1eicbzocjcj ok=; b=D5zCpJ6CsWLLqaLG4cCZRXSv1MFdt5QOeqwA4Ubw+Kjj7iIxwNVNdy66+ y65iWBdnUPjx1lifl23M5hkXscEjU+IfJnTBJJ/36ewa/An1VSAW/pqlas+gYe91 D5ssI9XCrc7IgV27XdzbvSKWxfBuPwGVeDiIIyDR8QmDNj+y2HYKoFxc4pSu0rdU Ulm6wpLq84OdtWJu7Lj2/krxGWGLO3GlAHImzjxq0PTqUG55Xw/OjiOhCT0UPc8I LluQNA5mBXxkyyn+V8yt8aKEE4I/3yGOEBS6184gcVou8r4uqhF0QdSy+6viEtlq z/Pjk9xIia6pfdX3Jat19rT89dXRA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeggdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepuddtkedrhedurddutddurdelkeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 553D780061; Tue, 25 Jun 2019 10:53:26 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <4706ad44c52bf2a76c429fc40d8c3a64c59b2303.camel@redhat.com> Date: Tue, 25 Jun 2019 10:53:25 -0400 Cc: Benjamin Kaduk , IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in> <20190624210837.GE48838@kduck.mit.edu> <4706ad44c52bf2a76c429fc40d8c3a64c59b2303.camel@redhat.com> To: Simo Sorce X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 14:53:40 -0000 > On Jun 24, 2019, at 5:15 PM, Simo Sorce wrote: >=20 > On Mon, 2019-06-24 at 16:08 -0500, Benjamin Kaduk wrote: >> On Mon, Jun 24, 2019 at 05:01:28PM -0400, Alissa Cooper wrote: >>>=20 >>>=20 >>>> On Jun 24, 2019, at 4:19 PM, Benjamin Kaduk wrote: >>>>=20 >>>> On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via = Datatracker wrote: >>>>> Alissa Cooper has entered the following ballot position for >>>>> draft-ietf-curdle-gss-keyex-sha2-09: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to = all >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> "The IESG is considered to be the owner of all these key exchange >>>>> methods; this does NOT imply that the IESG is considered to be = the >>>>> owner of the underlying GSS-API mechanism." >>>>>=20 >>>>> I don't understand this text. What does it mean for the IESG to be = the owner of a method? >>>>=20 >>>> The IESG has change control for the SSH key exchange method; the = IESG does >>>> not necessarily have change control for the underlying GSS-API = mechanism. >>>=20 >>> Thanks. I think it would be clearer to say that than to talk about = ownership. But given that the registry policy is IETF Review, is it = really appropriate to say that the IESG has change control? Would s/IESG = has change control/IETF has change control/ be more accurate? >>=20 >> I'll wait to see what the authors think about the "ownership" vs. = "change >> control" pedagogy. With respect to IESG vs. IETF, it seems that the = IESG >> is who is tasked with determining the consensus of the IETF, so in = practice >> it would be the IESG with control, even if in some formal sense the >> authority is vested with the IETF. (I thought it was near-universal = to >> list the IESG as the contact when the IETF is the nominal responsible >> party; is this case different somehow?) >=20 > If I remember correctly this language has been inherited untouched = from > the original RFC we are updating. >=20 > If at all possible we'd like to maintain consistency with the previous > language and not change it. Since this document updates RFC 4462, would it be possible to add a note = (perhaps in Section 3) indicating that the term =E2=80=9Cowner=E2=80=9D = is synonymous with =E2=80=9Cchange controller=E2=80=9D in both = documents? Thanks, Alissa >=20 > Simo. >=20 > --=20 > Simo Sorce > RHEL Crypto Team > Red Hat, Inc >=20 >=20 >=20 >=20 From nobody Tue Jun 25 09:15:09 2019 Return-Path: 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 DB38512078A; Tue, 25 Jun 2019 09:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 OwZT_UyX5VoZ; Tue, 25 Jun 2019 09:15:04 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 737821207B0; Tue, 25 Jun 2019 09:15:02 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.0.25]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hfo5x-0001ze-Vl; Tue, 25 Jun 2019 18:14:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 25 Jun 2019 18:14:57 +0200 Cc: Simo Sorce , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org, Benjamin Kaduk , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <9663D140-33CE-49D6-B4F8-5D3A614CF4AB@kuehlewind.net> References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in> <20190624210837.GE48838@kduck.mit.edu> <4706ad44c52bf2a76c429fc40d8c3a64c59b2303.camel@redhat.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1561479302;c76d86d4; X-HE-SMSGID: 1hfo5x-0001ze-Vl Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 16:15:07 -0000 Hi all, See below. > On 25. Jun 2019, at 16:53, Alissa Cooper wrote: >=20 >=20 >=20 >> On Jun 24, 2019, at 5:15 PM, Simo Sorce wrote: >>=20 >> On Mon, 2019-06-24 at 16:08 -0500, Benjamin Kaduk wrote: >>> On Mon, Jun 24, 2019 at 05:01:28PM -0400, Alissa Cooper wrote: >>>>=20 >>>>=20 >>>>> On Jun 24, 2019, at 4:19 PM, Benjamin Kaduk wrote: >>>>>=20 >>>>> On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via = Datatracker wrote: >>>>>> Alissa Cooper has entered the following ballot position for >>>>>> draft-ietf-curdle-gss-keyex-sha2-09: Discuss >>>>>>=20 >>>>>> When responding, please keep the subject line intact and reply to = all >>>>>> email addresses included in the To and CC lines. (Feel free to = cut this >>>>>> introductory paragraph, however.) >>>>>>=20 >>>>>>=20 >>>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be found = here: >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> "The IESG is considered to be the owner of all these key exchange >>>>>> methods; this does NOT imply that the IESG is considered to be = the >>>>>> owner of the underlying GSS-API mechanism." >>>>>>=20 >>>>>> I don't understand this text. What does it mean for the IESG to = be the owner of a method? >>>>>=20 >>>>> The IESG has change control for the SSH key exchange method; the = IESG does >>>>> not necessarily have change control for the underlying GSS-API = mechanism. >>>>=20 >>>> Thanks. I think it would be clearer to say that than to talk about = ownership. But given that the registry policy is IETF Review, is it = really appropriate to say that the IESG has change control? Would s/IESG = has change control/IETF has change control/ be more accurate? >>>=20 >>> I'll wait to see what the authors think about the "ownership" vs. = "change >>> control" pedagogy. With respect to IESG vs. IETF, it seems that the = IESG >>> is who is tasked with determining the consensus of the IETF, so in = practice >>> it would be the IESG with control, even if in some formal sense the >>> authority is vested with the IETF. (I thought it was near-universal = to >>> list the IESG as the contact when the IETF is the nominal = responsible >>> party; is this case different somehow?) >>=20 >> If I remember correctly this language has been inherited untouched = from >> the original RFC we are updating. >>=20 >> If at all possible we'd like to maintain consistency with the = previous >> language and not change it. >=20 > Since this document updates RFC 4462, would it be possible to add a = note (perhaps in Section 3) indicating that the term =E2=80=9Cowner=E2=80=9D= is synonymous with =E2=80=9Cchange controller=E2=80=9D in both = documents? As I was confused by this as well but was initially actually assuming = that we talk about the registry entries, maybe it would make it clearer = to say this in the text, e.g. s/owner of all these key exchange methods/change controller of the IANA = registration of these key exchange methods/ ? Mirja >=20 > Thanks, > Alissa >=20 >>=20 >> Simo. >>=20 >> --=20 >> Simo Sorce >> RHEL Crypto Team >> Red Hat, Inc >>=20 >>=20 >>=20 >>=20 >=20 >=20 From nobody Tue Jun 25 09:49:44 2019 Return-Path: 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 A0819120075; Tue, 25 Jun 2019 09:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 CHs-FkMMgK6Y; Tue, 25 Jun 2019 09:49:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2C2BA1207EC; Tue, 25 Jun 2019 09:49:41 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x5PGnQoi051691 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Jun 2019 11:49:27 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1561481369; bh=XAluXoCjpsMMNiZ/xql/v/UhGSvuvyaqi1l4q2SOkk4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Wuxfq0jSEXKuh28vYDd695rbeIeVnRWENgpWTHCiD/hT7AI5GbWcvZTr/kj8VdWHl 5LoDMCvSDGDgNO/C0nWm135TYCARSmA3XoeFCdzvUtkBYmNxz59+jPQRHNGVeb56KJ J0sHfkoT14wVS5jk9t8t7LWmWxSRMTjsEGocmPII= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Benjamin Kaduk , Alissa Cooper Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org, curdle-chairs@ietf.org, The IESG References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> From: Adam Roach Message-ID: <7c69e798-73ea-e054-7416-20bb7632eb29@nostrum.com> Date: Tue, 25 Jun 2019 11:49:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190624201955.GD48838@kduck.mit.edu> Content-Type: multipart/alternative; boundary="------------3D17E01FD8F7DF617E7E9239" Content-Language: en-US Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 16:49:43 -0000 This is a multi-part message in MIME format. --------------3D17E01FD8F7DF617E7E9239 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/24/19 3:19 PM, Benjamin Kaduk wrote: > On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-curdle-gss-keyex-sha2-09: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> "The IESG is considered to be the owner of all these key exchange >> methods; this does NOT imply that the IESG is considered to be the >> owner of the underlying GSS-API mechanism." >> >> I don't understand this text. What does it mean for the IESG to be the owner of a method? > The IESG has change control for the SSH key exchange method; the IESG does > not necessarily have change control for the underlying GSS-API mechanism. I'm confused. Your statement would imply that one of the following is false: 1. GSS-API is authoritatively defined by RFC 2743 2. RFC 2743 is an IETF-stream document 3. The IESG is responsible for change control of IETF-stream documents Which of these have I misunderstood? /a --------------3D17E01FD8F7DF617E7E9239 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 6/24/19 3:19 PM, Benjamin Kaduk wrote:
On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote:

Alissa Cooper has entered the following ballot position for
draft-ietf-curdle-gss-keyex-sha2-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The IESG is considered to be the owner of all these key exchange
   methods; this does NOT imply that the IESG is considered to be the
   owner of the underlying GSS-API mechanism."

I don't understand this text. What does it mean for the IESG to be the owner of a method?

The IESG has change control for the SSH key exchange method; the IESG does
not necessarily have change control for the underlying GSS-API mechanism.


I'm confused. Your statement would imply that one of the following is false:

  1. GSS-API is authoritatively defined by RFC 2743
  2. RFC 2743 is an IETF-stream document
  3. The IESG is responsible for change control of IETF-stream documents

Which of these have I misunderstood?

/a

--------------3D17E01FD8F7DF617E7E9239-- From nobody Tue Jun 25 09:50:16 2019 Return-Path: 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 8B679120075; Tue, 25 Jun 2019 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 lsZ2uiY03Lpc; Tue, 25 Jun 2019 09:50:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55671120411; Tue, 25 Jun 2019 09:50:04 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BC6A230C0DCF; Tue, 25 Jun 2019 16:49:58 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id B41095D756; Tue, 25 Jun 2019 16:49:55 +0000 (UTC) From: Hubert Kario To: Roman Danyliw , Daniel Migault Cc: The IESG , curdle-chairs@ietf.org, curdle@ietf.org Date: Tue, 25 Jun 2019 18:49:48 +0200 Message-ID: <3133203.clb3pWTehh@pintsize.usersys.redhat.com> In-Reply-To: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com> References: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13945780.GNqZevmtmb"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Tue, 25 Jun 2019 16:50:03 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Roman Danyliw's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 16:50:07 -0000 --nextPart13945780.GNqZevmtmb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 24 June 2019 16:38:56 CEST Roman Danyliw via Datatracker wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-curdle-gss-keyex-sha2-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > ** Section 5.1, Per =E2=80=9CThe exchange hash SHOULD be kept secret=E2= =80=9D, when should > it not be (i.e., why isn=E2=80=99t this a MUST?)? this is reiteration of the language from RFC 4253, page 23 given how RSA signatures work, it's impossible to keep it secret in all=20 circumstances so it can't be a MUST. That being said I'm not aware of any w= ay=20 to attack the handshake if that value is exposed so it looks to be here for= =20 "abundance of caution" reason... =20 > ** Section 4 and 5.2. Per =E2=80=9CEach key exchange method id implicitly > registered by this document=E2=80=9D, aren=E2=80=99t these key exchange m= ethods explicitly > registering them in IANA-KEX-NAMES per Section 7? no, the * is a wildcard character here, we don't explicitly list names that= =20 will be used =20 > ** Section 5.1. It is worth repeating (or moving the text) to Section 8 > that the Security Considerations of RFC7546 apply repeating probably would be better > ** Section 5.1. The various variable (e.g., V_C, V_S) are introduced ear= ly > in the algorithm to construct H and the messages in page 6, but they aren= =E2=80=99t > described until the end of page 7. I wasn=E2=80=99t following the narrat= ive until > I hit that section. those come from RFC 4253, a prerequisite to implement this I-D=20 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart13945780.GNqZevmtmb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl0SUKwACgkQkqjRuAHS 9fWrEQ/+INQ4JLociMEvVueETvw6KafsO50raOc5moLNjAAg6pKoh5uQk3PDLMTS tZyC+SDnJ6H14ovQ6TASNBDa+T4hxD9EvXTTI1fZ77LV0EdzVIB8M6Gn3s2WP8vE hZUCn6TdX7DHxjOUzAIBgihmdnDu3gv29ddbgh8uLsvpxFxZ8pTOaxfLiCCZS8qC k95+uLFxFlKkL9tOTmEBj3I4XVfjhW0TQmg1v5YBcAhh1mZOjlnRktc0MEwzfdzf NYDKvJqpRiu7KZHdW7jDBrNMk9Jfd4tpwaAAvGVJdZ/lsdnGxSV4M8BR2FOhUslV sqonADfOCN49jvVq9Px2F5Bm/SEvcN/dmFgsAyHvshcY0vmpvwMoK4UJVh1MSfJF w4GFKPXPk7UEjhsPz4XEHV5JUdQXatM7xO+KvLFYoFsiZRtzAL+iXDhlIGQeXrM8 Ev/NTnWLqoH1n1kINk/8ShLXSwco60a3vlEZOYTvEGpRBM3XgJ45n9iTe2jtvo+4 /1FWO4mmcTa79S24pwA5fXCuca5DY7Siaubg5GtndX4TwvR6/ixTRuWTtRbRU/K7 1hu9ZKKb+xP3BabJHM7ZqBTaMV1M4J4Dz6LmN+BGtbeulB6QDfxIqlA0hNPPNaP/ 6J4g4PS55cIJkwfJNTrMvYZdcBuepaUfyVMdACviKFbjoSZ5n18= =eLR2 -----END PGP SIGNATURE----- --nextPart13945780.GNqZevmtmb-- From nobody Tue Jun 25 09:53:45 2019 Return-Path: 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 A3AAA120131; Tue, 25 Jun 2019 09:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 P566sJm4Ju1E; Tue, 25 Jun 2019 09:53:41 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678281208E5; Tue, 25 Jun 2019 09:53:22 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5PGr9p3007125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jun 2019 12:53:12 -0400 Date: Tue, 25 Jun 2019 11:53:09 -0500 From: Benjamin Kaduk To: Adam Roach Cc: Alissa Cooper , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org, The IESG Message-ID: <20190625165308.GT48838@kduck.mit.edu> References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> <7c69e798-73ea-e054-7416-20bb7632eb29@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c69e798-73ea-e054-7416-20bb7632eb29@nostrum.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 16:53:44 -0000 On Tue, Jun 25, 2019 at 11:49:21AM -0500, Adam Roach wrote: > On 6/24/19 3:19 PM, Benjamin Kaduk wrote: > > On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote: > >> Alissa Cooper has entered the following ballot position for > >> draft-ietf-curdle-gss-keyex-sha2-09: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> "The IESG is considered to be the owner of all these key exchange > >> methods; this does NOT imply that the IESG is considered to be the > >> owner of the underlying GSS-API mechanism." > >> > >> I don't understand this text. What does it mean for the IESG to be the owner of a method? > > The IESG has change control for the SSH key exchange method; the IESG does > > not necessarily have change control for the underlying GSS-API mechanism. > > > I'm confused. Your statement would imply that one of the following is false: > > 1. GSS-API is authoritatively defined by RFC 2743 > 2. RFC 2743 is an IETF-stream document > 3. The IESG is responsible for change control of IETF-stream documents > > Which of these have I misunderstood? None of them :) "GSS-API mechanism" is a term of art for a cryptographic service provider, identified by OID, that implements the underlyin functionality of the GSS-API. While the GSS-API framework is defined by RFC 2743, anyone that can allocate an OID can specify a GSS-API mechanism corresponding to that OID, and the IETF cannot try to assert change control over that cryptographic provider. Does that help? -Ben From nobody Tue Jun 25 10:26:13 2019 Return-Path: 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 E2860120996 for ; Tue, 25 Jun 2019 10:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 djh6JZEjwaXM for ; Tue, 25 Jun 2019 10:26:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 433D6120916 for ; Tue, 25 Jun 2019 10:26:09 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x5PHQ5xl057935 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Jun 2019 12:26:06 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1561483568; bh=yype2QVvgIebnVJ6GoidivhYm3gdrxsyG0rQAp30Jz4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Ua2KnTw9A2lP7ewg3RUB3haMQUqd3Sskx+vRFT9SVYRZjTLDxYjfaRdm65E6BCT7P 0Ig3ZnpcZMfVWTN/O+HAK9jiNEt2gQnjdS+7plWX4eP67ntoMdEXrCfm6OebA3YHAn 2lHmsb4iXqWIE7Scd10/BIM8NduZvnd/2d2H298c= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Benjamin Kaduk Cc: Alissa Cooper , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org, The IESG References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> <7c69e798-73ea-e054-7416-20bb7632eb29@nostrum.com> <20190625165308.GT48838@kduck.mit.edu> From: Adam Roach Message-ID: <00b4aa86-a4de-df63-8a0a-da45876f67fb@nostrum.com> Date: Tue, 25 Jun 2019 12:26:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190625165308.GT48838@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 17:26:11 -0000 On 6/25/19 11:53 AM, Benjamin Kaduk wrote: > On Tue, Jun 25, 2019 at 11:49:21AM -0500, Adam Roach wrote: >> On 6/24/19 3:19 PM, Benjamin Kaduk wrote: >>> On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote: >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-curdle-gss-keyex-sha2-09: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> "The IESG is considered to be the owner of all these key exchange >>>> methods; this does NOT imply that the IESG is considered to be the >>>> owner of the underlying GSS-API mechanism." >>>> >>>> I don't understand this text. What does it mean for the IESG to be the owner of a method? >>> The IESG has change control for the SSH key exchange method; the IESG does >>> not necessarily have change control for the underlying GSS-API mechanism. >> >> I'm confused. Your statement would imply that one of the following is false: >> >> 1. GSS-API is authoritatively defined by RFC 2743 >> 2. RFC 2743 is an IETF-stream document >> 3. The IESG is responsible for change control of IETF-stream documents >> >> Which of these have I misunderstood? > None of them :) > > "GSS-API mechanism" is a term of art for a cryptographic service provider, > identified by OID, that implements the underlyin functionality of the > GSS-API. While the GSS-API framework is defined by RFC 2743, anyone that > can allocate an OID can specify a GSS-API mechanism corresponding to that > OID, and the IETF cannot try to assert change control over that > cryptographic provider. > > Does that help? Oh! Yes, that's much clearer, thanks. I hear you saying that there's a one-to-one correspondence. I think replacing "underlying" with "corresponding" might avoid similar confusion by others. /a From nobody Wed Jun 26 06:57:41 2019 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EABBC120052; Wed, 26 Jun 2019 06:57:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <156155745995.20217.16123584633061089603.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2019 06:57:39 -0700 Archived-At: Subject: [Curdle] Warren Kumari's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 13:57:40 -0000 Warren Kumari has entered the following ballot position for draft-ietf-curdle-gss-keyex-sha2-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for for writing this - it was clear enough that I could understand the bits that I needed to :-) I have a few comments: "Additionally we utilize also the curves defined in [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined curves required by [RFC5656]." I checked on the status of I-D.ietf-curdle-ssh-curves - this seems to have stalled. I realize it isn't your problem, but is there a plan to progress I-D.ietf-curdle-ssh-curves ? "The parties generate each an ephemeral key pair, according to ..." I think that this would be easier to understand as: "The parties each generate an ephemeral key pair, according to ..." From nobody Thu Jun 27 18:23:35 2019 Return-Path: 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 C72CB12003F; Thu, 27 Jun 2019 18:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VtHeTAMzPLYK; Thu, 27 Jun 2019 18:23:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5E3120181; Thu, 27 Jun 2019 18:23:31 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5S1NOGu010260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 21:23:26 -0400 Date: Thu, 27 Jun 2019 20:23:24 -0500 From: Benjamin Kaduk To: Warren Kumari Cc: The IESG , draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Message-ID: <20190628012323.GT18345@kduck.mit.edu> References: <156155745995.20217.16123584633061089603.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156155745995.20217.16123584633061089603.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] Warren Kumari's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 01:23:34 -0000 On Wed, Jun 26, 2019 at 06:57:39AM -0700, Warren Kumari via Datatracker wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-curdle-gss-keyex-sha2-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for for writing this - it was clear enough that I could understand > the bits that I needed to :-) > > I have a few comments: > "Additionally we utilize also the curves defined in > [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined curves > required by [RFC5656]." I checked on the status of I-D.ietf-curdle-ssh-curves - > this seems to have stalled. I realize it isn't your problem, but is there a > plan to progress I-D.ietf-curdle-ssh-curves ? It shows up on my dashboard now, but I haven't done the research yet to see what needs to be done. There are plenty of "publication requested" documents to tend to, first... -Ben