From nobody Mon Jul 1 10:03:23 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 5CBCE120745; Mon, 1 Jul 2019 10:03:09 -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 jj6NDTWJ3Q2z; Mon, 1 Jul 2019 10:03:07 -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 D6DA712072A; Mon, 1 Jul 2019 10:03:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 993D4356C4; Mon, 1 Jul 2019 17:03:02 +0000 (UTC) Received: from ovpn-116-72.phx2.redhat.com (ovpn-116-72.phx2.redhat.com [10.3.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9843660C43; Mon, 1 Jul 2019 17:02:58 +0000 (UTC) Message-ID: From: Simo Sorce To: Roman Danyliw , The IESG , Adam Roach Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Date: Mon, 01 Jul 2019 13:02:57 -0400 In-Reply-To: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com> References: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 01 Jul 2019 17:03:06 +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: Mon, 01 Jul 2019 17:03:22 -0000 On Mon, 2019-06-24 at 07:38 -0700, Roman Danyliw via Datatracker wrote: > ** 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. On Mon, 2019-06-24 at 20:41 -0700, Adam Roach via Datatracker wrote: > §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. You both indicate these are described in later section, and although we do, we have a reference right at the start of 5.1: "This section reuses much of the scheme defined in section 2.1 of RFC4462" that reference contains explicit definitions of the symbols used and the preamble to that referenced section also points to "Section 8 of [SSH-TRANSPORT]" which also `have definitions. That reference is required pre-requisite to understand 5.1 fully so I think we have enough in place, however if you think I should move the later section 7 text up in to this already overlong paragraph I will. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc From nobody Mon Jul 1 10:21:01 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 DC338120802; Mon, 1 Jul 2019 10:20:59 -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 IGRbGIKY7oZn; Mon, 1 Jul 2019 10:20:58 -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 A5ABA1207FE; Mon, 1 Jul 2019 10:20:58 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 234987FDFB; Mon, 1 Jul 2019 17:20:42 +0000 (UTC) Received: from ovpn-116-72.phx2.redhat.com (ovpn-116-72.phx2.redhat.com [10.3.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B41B60C43; Mon, 1 Jul 2019 17:20:35 +0000 (UTC) Message-ID: <541117c239df0a1624ef1ca7d25b36188b91c867.camel@redhat.com> From: Simo Sorce To: Suresh Krishnan , The IESG Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Date: Mon, 01 Jul 2019 13:20:34 -0400 In-Reply-To: <156139104143.17449.9632346081496014534.idtracker@ietfa.amsl.com> References: <156139104143.17449.9632346081496014534.idtracker@ietfa.amsl.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 01 Jul 2019 17:20:58 +0000 (UTC) Archived-At: Subject: Re: [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 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, 01 Jul 2019 17:21:00 -0000 On Mon, 2019-06-24 at 08:44 -0700, Suresh Krishnan via Datatracker wrote: > 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. > Hi Suresh, I intentionally kept away from providing solutions in the security considerations around Delegation. Note that insecure DNS resolution is not the only issue, using insecure NIS maps for hosts brings the same issues, so I would rather you consider "DNS" here more as an example. Given that focusing too much on specific solutions might give the impression that DNS spoofing is the only issue and that DNSSEC the only solution, I decided to let the reader decide by themselves how to deal with these threats. I consider the document's job done just by warning that there is something to be aware of around name resolution. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc From nobody Mon Jul 1 10:31:05 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 B91C8120657; Mon, 1 Jul 2019 10:31:03 -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 Xgh5mlfUotbY; Mon, 1 Jul 2019 10:31:02 -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 3E615120401; Mon, 1 Jul 2019 10:30:55 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 92C433DE0E; Mon, 1 Jul 2019 17:30:53 +0000 (UTC) Received: from ovpn-116-72.phx2.redhat.com (ovpn-116-72.phx2.redhat.com [10.3.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ED1BD7A4C4; Mon, 1 Jul 2019 17:30:50 +0000 (UTC) Message-ID: From: Simo Sorce To: Roman Danyliw , The IESG Cc: draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Date: Mon, 01 Jul 2019 13:30:49 -0400 In-Reply-To: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com> References: <156138713666.17510.11504200727464931225.idtracker@ietfa.amsl.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 01 Jul 2019 17:30:54 +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: Mon, 01 Jul 2019 17:31:04 -0000 On Mon, 2019-06-24 at 07:38 -0700, Roman Danyliw via Datatracker wrote: > ** Section 5.1, Per “The exchange hash SHOULD be kept secret”, when should it > not be (i.e., why isn’t this a MUST?)? This is the same text that appears in both 4253 and 4462, it is a SHOULD because revealing the exchange hash may help an attacker to gain some information about the exchange but it is not in itself a problem if it happens. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc From nobody Mon Jul 1 18:50:30 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 3A62812018F; Mon, 1 Jul 2019 18:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 J2RH-0a5DvBT; Mon, 1 Jul 2019 18:50:26 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660107.outbound.protection.outlook.com [40.107.66.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5F612018B; Mon, 1 Jul 2019 18:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f7dZPnY6uxEM178aVs6gO+dEk1L6fIVg8jPRnPV/QBI=; b=A2EhpRqNRVNaqE+36HZiWQppmaczn31S90fDPyMQYu57EpwhY6oVeUkhjGEqRVL3Itlmlp5T0aF6/YO8CJwwIae95WKc4a9+HRxp/QZ21LNcabJcX3sUafywH0AT/RLmXGEdz4J6Wmohy5FbyA8/V395wATlyhttX70vomaWR1w= Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.45.144) by YTOPR0101MB1131.CANPRD01.PROD.OUTLOOK.COM (52.132.50.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.18; Tue, 2 Jul 2019 01:50:24 +0000 Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::20b6:a749:45f6:12ba]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::20b6:a749:45f6:12ba%3]) with mapi id 15.20.2032.019; Tue, 2 Jul 2019 01:50:24 +0000 From: Suresh Krishnan To: Simo Sorce CC: The IESG , "draft-ietf-curdle-gss-keyex-sha2@ietf.org" , "daniel.migault@ericsson.com" , "curdle-chairs@ietf.org" , "curdle@ietf.org" Thread-Topic: [Curdle] Suresh Krishnan's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT) Thread-Index: AQHVMDFbdVXQ/8QzE06ogg5wuEoX86a2kKCA Date: Tue, 2 Jul 2019 01:50:23 +0000 Message-ID: <7B5F79CB-1A3B-4994-8597-D3B5FAE68ABB@kaloom.com> References: <156139104143.17449.9632346081496014534.idtracker@ietfa.amsl.com> <541117c239df0a1624ef1ca7d25b36188b91c867.camel@redhat.com> In-Reply-To: <541117c239df0a1624ef1ca7d25b36188b91c867.camel@redhat.com> 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=Suresh@kaloom.com; x-originating-ip: [172.58.27.251] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08970550-cc7d-4bcd-aabe-08d6fe8fa61b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTOPR0101MB1131; x-ms-traffictypediagnostic: YTOPR0101MB1131: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39850400004)(396003)(376002)(136003)(366004)(189003)(199004)(229853002)(508600001)(76176011)(66446008)(2906002)(33656002)(6306002)(4326008)(6486002)(36756003)(6512007)(6246003)(25786009)(68736007)(66066001)(26005)(486006)(316002)(71190400001)(71200400001)(81156014)(91956017)(8676002)(6436002)(14444005)(6116002)(7736002)(54906003)(305945005)(102836004)(76116006)(66946007)(99286004)(6916009)(73956011)(53936002)(80792005)(5660300002)(6506007)(53546011)(186003)(3846002)(11346002)(476003)(966005)(2616005)(446003)(72206003)(14454004)(66556008)(66476007)(64756008)(8936002)(86362001)(256004)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB1131; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jCAi4MW+d99FVv6g4C5+EGoOGnsJpCEx2HBk9JaOJDvwyReiDqmola9MfO9m4nRfjMxr85nX0IEjfNLqQNNNbPB2l5z3wduMniQe4zfesnDk3otpcg4FtgSSt9dVQEscgeBlrKIi/s8GJXHG7U04G+wOv0UI/4faRtx/ZKdNfqhZ9yidlPm15qRGl6gaWeIDjMu/SHTBXMEbIyEow4ySDpKe52DiCoLnjlZ9Wukf3yuTfqIS9UklxmdzZeR+5H+oNnVyVVt6RLZ8lSJsTe7JnYY4kOCrE5zHLVR2//2JVbY5f564KguCSU41udTmCK0X/QW1QBDMgRMEcKtFporePukxrQZI1M3NCDCNQGCplIZUe+ERpPTqS7CgcjCje2+k4ubcNKKNwm3HPsMdOnDDK3xzgZIytSKRNj7XFEN512I= Content-Type: text/plain; charset="us-ascii" Content-ID: <772917206798DD47814A91CDC822C732@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08970550-cc7d-4bcd-aabe-08d6fe8fa61b X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2019 01:50:23.9833 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Suresh@kaloom.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1131 Archived-At: Subject: Re: [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 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, 02 Jul 2019 01:50:29 -0000 > On Jul 2, 2019, at 1:20 AM, Simo Sorce wrote: >=20 > On Mon, 2019-06-24 at 08:44 -0700, Suresh Krishnan via Datatracker > wrote: >> Suresh Krishnan 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.htm= l >> 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 8.3 >>=20 >> I think a pointer to DNSSEC might be relevant here in the context of spo= ofed DNS responses. >>=20 > Hi Suresh, > I intentionally kept away from providing solutions in the security > considerations around Delegation. Note that insecure DNS resolution is > not the only issue, using insecure NIS maps for hosts brings the same > issues, so I would rather you consider "DNS" here more as an example. > Given that focusing too much on specific solutions might give the > impression that DNS spoofing is the only issue and that DNSSEC the only > solution, I decided to let the reader decide by themselves how to deal > with these threats. > I consider the document's job done just by warning that there is > something to be aware of around name resolution. Thanks Simo. I understand your rationale now and my comment was non blockin= g. Regards Suresh= From nobody Tue Jul 23 12:06:39 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 4582D1200CC; Tue, 23 Jul 2019 12:06:31 -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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: curdle@ietf.org Message-ID: <156390879119.27882.13783594609543119441@ietfa.amsl.com> Date: Tue, 23 Jul 2019 12:06:31 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-gss-keyex-sha2-10.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, 23 Jul 2019 19:06:32 -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-10.txt Pages : 13 Date : 2019-07-23 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-gss-keyex-sha2-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-gss-keyex-sha2-10 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 Tue Jul 30 14:22: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 AC2C6120159; Tue, 30 Jul 2019 14:22:42 -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 5iFCG45uhq_M; Tue, 30 Jul 2019 14:22: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 D8C7B120046; Tue, 30 Jul 2019 14:22:37 -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 x6ULMX1u006623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 17:22:35 -0400 Date: Tue, 30 Jul 2019 16:22:32 -0500 From: Benjamin Kaduk To: draft-ietf-curdle-rc4-die-die-die.all@ietf.org Cc: curdle@ietf.org Message-ID: <20190730212232.GP47715@kduck.mit.edu> 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] second AD review of draft-ietf-curdle-rc4-die-die-die-15 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, 30 Jul 2019 21:22:43 -0000 Hi all, I'm just about ready to send this document into IESG Evaluation, but noticed a few nits while rereading it. Since they're in areas that I expect the IESG to be looking at, I'd like to have an updated revision of the document available before I send it out to the IESG as a whole: draft-ietf-curdle-des-des-des-die-die-die is now RFC 8429, so we can update that reference. Additionally, part of the holdup for that document was to decide whether to Obsolete RFC 4757 or move it to Historic, since we cannot do both. The Abstract of this document still says that it both Obsoletes and moves to Historic RFC 4345 (and it has the Obsoletes: header); since we decided in the RFC 8429 case to use "move to Historic", I think that's the right thing to do here as well. So we want to keep the "move to Historic" text but drop the in-document and metadata "Obsoletes:" relationship. (https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/ has some more background on the difference.) On the other hand, since we are updating RFC 4253, we do need to mention Updates: 4253 in document header. We can also update to use the RFC 8174 version of the BCP 14 boilerplate. Finally, the table in Section 3 seems to be formatted oddly, with the column break appearing in the middle of "Encryption Algorithm Name" instead of at the end of it. Thanks, Ben From nobody Tue Jul 30 14:34: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 11399120114; Tue, 30 Jul 2019 14:34:39 -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 OcMjJ7EYw2M3; Tue, 30 Jul 2019 14:34: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 CBCAF120111; Tue, 30 Jul 2019 14:34:33 -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 x6ULYJJg010973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 17:34:21 -0400 Date: Tue, 30 Jul 2019 16:34:18 -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: <20190730213418.GQ47715@kduck.mit.edu> References: <20190604174029.GC8678@prolepsis.kaduk.org> <20190607222610.GH83686@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190607222610.GH83686@kduck.mit.edu> 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: Tue, 30 Jul 2019 21:34:39 -0000 Cycling back on this, my reading of the archive suggests that we want an -09 to include Daniel's suggested text to clarify on (1), and we need to hear from Ben about (3). Does that sound right to everyone or am I missing something? Thanks, Ben On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: > 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 Tue Jul 30 14:46: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 B5913120111; Tue, 30 Jul 2019 14:46:11 -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 oWS7r7sdvpUU; Tue, 30 Jul 2019 14:46:08 -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 BA4B7120074; Tue, 30 Jul 2019 14:46:05 -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 x6ULk1W5014785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 17:46:03 -0400 Date: Tue, 30 Jul 2019 16:46:01 -0500 From: Benjamin Kaduk To: draft-ietf-curdle-ssh-kex-sha2.all@ietf.org Cc: curdle Message-ID: <20190730214600.GR47715@kduck.mit.edu> References: 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] AD Review of draft-ietf-curdle-ssh-kex-sha2-09 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, 30 Jul 2019 21:46:12 -0000 I took over as responsible AD for this draft from Eric, but I don't see any response to these review comments. I don't think we can move the document forward without some discussion (and presumably a new rev of the document). Thanks, Ben On Sat, Feb 24, 2018 at 01:28:19PM -0800, Eric Rescorla wrote: > See https://mozphab-ietf.devsvcdev.mozaws.net/D4046 for the review in > context. > > I have two high-level concerns about this document. > > The presentation is very confusing, with a lot of duplication and not much > in the way of general principles until we get to the Security > Considerations section. You should start by laying out your principles > (FFDH >= 2048, > SHA-1, ECC >= 256, etc.) and then have less text for each > of the suites unless there's something unobvious in one of them (e.g., > we're keeping it around for compatibility). > > Second, I am concerned about the appropriateness of embedding the NSA's > judgements about what algorithms are suitable for various classification > levels in an IETF RFC. First, the IETF is not a US ogranization. Second, we > are just now deprecating the suite B RFCs because NSA changed its mind > about how to structure things. I think we should largely confine our > comments to the IETF's judgements about what is or is not secure. > > *INLINE COMMENTS* > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:100 > Method Names that MUST be implemented. Over time, what was once > considered secure, is no longer considered secure. The purpose of > this RFC is to recommend that some published key exchanges be > > Nit: no comma here. > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:107 > Methods which MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be > implemented. New key exchange methods will use the SHA-2 family of > hashes found in [RFC6234] and are drawn from these ssh-curves from > > Isn't this sentence duplicative of the previous sentence? > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:128 > implementation of MUST, SHOULD, SHOULD NOT, and MUST NOT. Any method > not explicitly listed, MAY be implemented. > > Spurious comma here. > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:137 > be secure with wide enough adoption to upgrade their recommendation > from MAY to SHOULD or MUST. > > This is not a sentence. > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:141 > The Curve25519 provides strong security and is efficient on a wide > range of architectures with properties that allow better > > I would strike "The " > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:149 > Method has multiple implementations and SHOULD be implemented in any > SSH interested in using elliptic curve based key exchanges. > > "in any SSH implementation" > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:153 > The Curve448 provides very strong security. It uses SHA2-512 (also > known as SHA-256) defined in [RFC6234] for integrity. It is probably > > I would strike "The ". Also, I'm not sure characterizing 256 as "strong" > and 448 as "very strong" is that helpful. Isn't the general consensus that > 256 bits of real security is fine unless there are quantum computers, in > which case all bets are off. > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:155 > known as SHA-256) defined in [RFC6234] for integrity. It is probably > stronger and more work than is currently needed. This Key Exchange > Method is described in [I-D.ietf-curdle-ssh-curves] and is similar to > > This also seems unnecessary. > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:162 > This set of ephemerally generated key exchange groups uses SHA-1 as > defined in [RFC4419]. However, SHA-1 has security concerns provided > > The groups aren't ephemeral. The keys are. > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:185 > still need to use this key exchange, it should be removed from server > implementations as quickly as possible. > > ; instead of , > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:195 > method will transition to SHOULD NOT when SHA-2 alternatives are more > generally available. > > It would be useful to explain why SHA-1 is a concern here. Perhaps a > sentence about how SHA-1 is used? > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:215 > additional head room over the 2048-bit group14 FFC DH and the > predominate open source implementations are not adopting it. This > method MAY be implemented. > > Why do you say it doesn't provide much security over 2048? > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:226 > This modulus (4096-bit) is larger than that required by [CNSA-SUITE] > and should be sufficient to inter-operate with more paranoid nation- > states. This method SHOULD be implemented. > > interoperate does not have a hyphen > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:252 > curve may not be as useful and strong as desired for handling TOP > SECRET information for some applications. The SSH development > community is divided on this and many implementations do exist. If > > TOP SECRET seems like a very national-state specific term. Perhaps some > other term is appropriate. Is there a particular reason we are basing our > assessments on what USG likes. > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:272 > mean that this algorithm will need to be downgraded in the future > along the other ECDSA nistp curves. > > how does this cipher suite use ECDSA? You don't say. Isn't it basically the > same as ecdh-sh2-nistp256 > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:282 > hash could mean that as many as nine bits of this key could be at > risk of leaking if appropriate padding measures are not taken. This > method MAY be implemented, but is not recommended. > > Can you explain how this happens? > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:290 > security concerns [RFC6194]. It is recommended that these key > exchange groups NOT be used. This key exchange SHOULD NOT be used. > It is intended that it move to MUST NOT as soon as the majority of > > These two sentences are duplicative. > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:310 > This key exchange method is defined in [RFC4462]. This generated key > exchange groups uses SHA-1 which has security concerns [RFC6194]. If > > What's a "generated key exchange group" > > View Inline > draft-ietf-curdle-ssh-kex-sha2.txt:563 > DH groups to avoid pre-calculation attacks that are provably not > backdoored. > > This sentence doesn't make any sense: it's not attacks that are backdoored. > More generally, are there in fact concerns that the FFDH groups were > maliciously generated, or just that they are too weak against > pre-calculation From nobody Tue Jul 30 14:47:14 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 2DAF1120111; Tue, 30 Jul 2019 14:47:12 -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 QHPufy-ppklY; Tue, 30 Jul 2019 14:47:10 -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 7BF84120074; Tue, 30 Jul 2019 14:47:07 -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 x6ULl3AX015175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 17:47:05 -0400 Date: Tue, 30 Jul 2019 16:47:02 -0500 From: Benjamin Kaduk To: draft-ietf-curdle-ssh-curves.all@ietf.org Cc: draft-ietf-curdle-ssh-curves.all@ietf.org, curdle Message-ID: <20190730214702.GS47715@kduck.mit.edu> References: 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] Second AD Review: draft-ietf-curdle-ssh-curves. 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, 30 Jul 2019 21:47:12 -0000 I took over as responsible AD for this draft from Eric, but I don't see any response to this second round of review comments. Luckily there's mot much left, so hopefully we can get a new rev out quickly and move the document forward. Thanks, Ben On Mon, Dec 24, 2018 at 02:16:24PM -0800, Eric Rescorla wrote: > Thanks for addressing my comments. > > IMPORTANT > S 3. > > received public keys are not the expected lengths, or if the derived > > shared secret only consists of zero bits. No further validation is > > required beyond what is discussed in [RFC7748]. The derived shared > > secret is 32 bytes when Curve25519 is used and 56 bytes when Curve448 > > is used. The encodings of all values are defined in [RFC7748]. The > > hash used is SHA-256 for Curve25519 and SHA-512 for Curve448. > > This is true if you use the 7748 algorithm, but not necessarily > otherwise. > > Here is some OK language (from tcpcrypt) > > 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]. When they do so, > implementations MUST check whether the computed Diffie-Hellman > shared > secret is the all-zero value and abort if so, as described in > Section 6 of [RFC7748]. Alternative implementations of these > functions SHOULD abort when either input forces the shared secret > to > one of a small set of values, as discussed in Section 7 of > [RFC7748]. > COMMENTS > S 1. > > key exchange protocol described in [RFC4253] supports an extensible > > set of methods. [RFC5656] describes how elliptic curves are > > integrated in SSH, and this document reuses those protocol messages. > > > > This document describes how to implement key exchange based on > > Curve25519 and Ed448-Goldilocks [RFC7748] in SSH. For Curve25519 > > 7748 calls this Curve448 and you do so later, so please be consistent. From nobody Tue Jul 30 15:17:06 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 86FE912013F; Tue, 30 Jul 2019 15:17:04 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net 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 GQtR5GHw0tMU; Tue, 30 Jul 2019 15:17:02 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 DF562120113; Tue, 30 Jul 2019 15:17:02 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6UMDn5K010756; Tue, 30 Jul 2019 15:17:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=rRmiNxBpCkcwb4zBpy/fQhsXKRc+oCx9w4Xi9ol8D6o=; b=h7MynZXBZgspOyc6NZ/vUDVeyaZu/yyrXxUtRSVPvYg6KWQacRavgVOxtD5ggsEw7rz+ n4w9KyAOvTnSofiCLsYqfNIFfDunRXH9qN58ZnKP953XrwhTnyY4LYfXhRvmC2MhvNbm S9EIdLgUBunqUiiQVwwRVBaa3sAkdnXn02s+CWU/aaUHMSv/LT2sZVohPKM/L8tJDSIL AthHKXsrWs1orlXTE/E2UkCluf8sa5NLMqasV5CJh9rANVpfSt6RARystu0z4gGphXpL lisKsZb90BeCW8NsPwLDhE8JwLAIaGzoBupzWatR5eShLxY/NzMk86/M0Tfhad9siVyP sw== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2050.outbound.protection.outlook.com [104.47.37.50]) by mx0a-00273201.pphosted.com with ESMTP id 2u2uwy08tp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 15:17:01 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bQDvP1rB9SwsprnDDsVOUpPVVEI9GiUkz0CZMbATARS74c8lNqgj/3HWczY1wqV8QT6U/nhZ2MBbucK4u6dz/Qf8W35HotqhEr1TA5+6aeMxtyaKxxKVnGVv38f7w5fSCQY8fZTAeYwSJuISgeM8jIGElrzTse+PS1j79zk1mfDJA6YrEuUmoWztzB8GvCkrv5EpA1XyaB88OHSmwxix1UzWRvbJgbsdy1bxhbzohachLSn5h+HiHWN8fqZmNA+O4QirqNO7i/wrU6KcFnR3amuTnuGk7B2/jxCOqSO4dDMMri+suYugMnNYHr5I6xQgPdqCgYsGYXirvucs8hR9Ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rRmiNxBpCkcwb4zBpy/fQhsXKRc+oCx9w4Xi9ol8D6o=; b=g6PMghr7yISvmYgAseNSftwt/S7lMg9IeVCgWHAOvKVqHebgkj5EgfTJK+686aQ/VRZ84KKEdBb/LukV5bowePmQEQJGjeL9lwXqRfnoetS5dENDpAZM5xbrcO6h5UhXHJL8W00rQudZozz18cwAACWe/IrnItgfh3s/u7JbjfeKFVchiwV0Z2fhZQywyZh8B6OibCgriiNbFNCvRDr9BvB9GjfaIDFtwOQlKmXcY7SIVlfFC4lBDI3x+fwpX40wsBXrPM8MXDlP7XQOBvvqKdEyUI8z/pXp77YN3w/p02rY8+suivfA1C3nC8ZluqRRumiA3A6VHjthHtQQTTTx/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.12) smtp.rcpttodomain=mit.edu smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=quarantine pct=100) action=oreject header.from=juniper.net;dkim=none (message not signed);arc=none Received: from MN2PR05CA0004.namprd05.prod.outlook.com (2603:10b6:208:c0::17) by BN8PR05MB6564.namprd05.prod.outlook.com (2603:10b6:408:57::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.10; Tue, 30 Jul 2019 22:16:59 +0000 Received: from CO1NAM05FT035.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::200) by MN2PR05CA0004.outlook.office365.com (2603:10b6:208:c0::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.10 via Frontend Transport; Tue, 30 Jul 2019 22:16:59 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from P-EXFEND-EQX-01.jnpr.net (66.129.239.12) by CO1NAM05FT035.mail.protection.outlook.com (10.152.96.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2136.7 via Frontend Transport; Tue, 30 Jul 2019 22:16:59 +0000 Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 30 Jul 2019 15:16:58 -0700 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 30 Jul 2019 15:16:58 -0700 Received: from contrail-ubm16-mdb.svec1.juniper.net ([10.163.18.199]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id x6UMGvPH013368; Tue, 30 Jul 2019 15:16:57 -0700 (envelope-from mdb@juniper.net) To: Benjamin Kaduk CC: , curdle In-Reply-To: <20190730214600.GR47715@kduck.mit.edu> References: <20190730214600.GR47715@kduck.mit.edu> Comments: In-reply-to: Benjamin Kaduk message dated "Tue, 30 Jul 2019 16:46:01 -0500." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Face: #8D_6URD2G%vC.hzU Date: Tue, 30 Jul 2019 15:16:57 -0700 Message-ID: <31217.1564525017@contrail-ubm16-mdb.svec1.juniper.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(4636009)(396003)(136003)(39860400002)(376002)(346002)(2980300002)(189003)(199004)(68736007)(126002)(356004)(23726003)(316002)(8676002)(4744005)(476003)(426003)(86362001)(50226002)(8936002)(117636001)(47776003)(11346002)(70586007)(50466002)(478600001)(70206006)(81156014)(486006)(229853002)(446003)(336012)(97756001)(4326008)(2906002)(54906003)(53936002)(5660300002)(81166006)(2171002)(46406003)(6246003)(69596002)(16586007)(97876018)(26005)(6916009)(186003)(305945005)(76176011)(7696005)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR05MB6564; H:P-EXFEND-EQX-01.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 05a085d6-fa3e-44bb-2763-08d7153ba3ed X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4710121)(4711136)(1401327)(2017052603328); SRVR:BN8PR05MB6564; X-MS-TrafficTypeDiagnostic: BN8PR05MB6564: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0114FF88F6 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: NOyJgpdH2/CNWOpmk2UDAymjXwvYEd4HRYVxB0Me958/TSx82Eynk9WEhnlQvxNjwSM+q4cRP3vJhYrDdhQPtim3xw/Zq1KMLIBHBsTaQAmpDKzoyekCRgNhEXlsY1VCaQH2O/ow/eZzG9SXOwyWfxBpeW4Cwz27Q8+hjP3PxwAp6a/QPz4sMxhelGwCqb00M94fD2H2OTvPe1c9Zculs8ACAUcaR+HWmXjViwhsz6kaaBFzVPb+um/l/KUz/kAHWKI/C+sBiSfudSuTrJDcU9PhjwrE5aHW0M5M9+9TKWnjcPVB+BHHUunJfAwZ4DANvhYA44KmxN86BPTQkDjvVYBBtNvvgu6gDB2SLwLjM1Ls/CmqJEoZlqtRrQY7STc56/Eu+X6VDgxVFpqNHs5Ua3+C/K/9tPr419JFPrPWA8g= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2019 22:16:59.1935 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 05a085d6-fa3e-44bb-2763-08d7153ba3ed X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[P-EXFEND-EQX-01.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR05MB6564 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=702 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907300222 Archived-At: Subject: Re: [Curdle] AD Review of draft-ietf-curdle-ssh-kex-sha2-09 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, 30 Jul 2019 22:17:05 -0000 Hi Ben, I did send private email to Eric suggesting that this draft should wait until the other drafts had been published and all of CURdle could come to consensus on what needs to be recommended or not. My goal was to have a vehicle to deprecate diffie-hellman-group1 completely from a REQUIRED group to one that should not be supported and the rest of the document was trying more to be a best practice document. (I suspect it failed at conveying that.) -- Mark From nobody Tue Jul 30 15:23:31 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 170F41201C9; Tue, 30 Jul 2019 15:23:30 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net 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 9wfFI878BWHr; Tue, 30 Jul 2019 15:23:28 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 A2A401201C7; Tue, 30 Jul 2019 15:23:28 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6UMJVsN014904; Tue, 30 Jul 2019 15:23:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=gg4VyOToXNFivPO638v7q9A4P38AMoPZ/batDBBzSnM=; b=gKQ5kv/fsgc3jBmz8l/xi97YxnR7la/X+WjsP04IMCRYzF0clupyfWO1FiQP81XhHBMb XCILF3/n7uDriOaRK/PlomdK0gTaEPR1HbF7T38IjQ28WTQr9pmsfxLPeF5MBHruSBtL x/MTIX4v+qpNg1wragIKjxjKADOZ1nWxqoVAspBuij8EBCkdd9yWvGwlhbAmQ+/jr2jh e09opMlFI7kxKyglyo7N/jFMhPhOaDqM++zdyq6HCi1Jt181v7T60FuF8HUPBD2NJ4he 94BSh+kT3UJiC/Ed0gg3DLx9abw2DQ1XjvAkud8pG9r/LpK5BvgjJNoV8Rn+Htgbe0Ud MQ== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2057.outbound.protection.outlook.com [104.47.40.57]) by mx0a-00273201.pphosted.com with ESMTP id 2u2uwy092v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 15:23:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R/Qx9sZf6A8VFk+gchc3xt5cDwmB1LyQfsqQ0nQ4/ShUtYIsdLPHUr6CZsjCa0wr/ovgfjlWyoc+uj6m/KbjHdA3foQFyJPuNDH6N7E85xM90DDQBEMbAiSwR4oXAOMv3VsOpxHJl7zEOFqjB4wKAYu0lOdpdxmZA6Ec2SQItvEybRcybWI57njm1JYz+rlUzB3tW2fKQyF68XA0BBCvm2TooQ/0qUBN+eyJ6F/bfHky5sYz79FsVOUFigzQR+PB5rwUDHzQJDc4KYnIJsNAqm8Askeo2l/KoebQGExbtxe7mVzQPRWTsqAt1rTcvqyNV+tXPQIInQBx5cBBwqTMzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gg4VyOToXNFivPO638v7q9A4P38AMoPZ/batDBBzSnM=; b=YUyKq3d4b/36yFN3tl21NRoIoe7oEEiFv8XMM9DM6IKEDcyihFJzlR5t9FIDRSYtIVb5KJ6urEYV0PUHfp2tOlg5rggqr6r96T5g1I35EwHhGcIsSOYhhArdzRkbHlLkdKwxz59n3MPIo9HKVom7h0JaN5gPFqJMaCaKvB39K2lavjFNO03H5AoNlUohMlNjay/LVI/H1Qeu1GdMa454czGvRxmQOMC8YIhzL2XuO713AqCnWxailgD78MDq9GgLyOpdunlbnv3NlhJCbozReelI8HGfRmbecNN24hCLR99anjVUe47AOdA+h9914qaQlN/IGoYsoH6KEfs3XixYLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.12) smtp.rcpttodomain=ietf.org smtp.mailfrom=juniper.net;dmarc=fail (p=reject sp=quarantine pct=100) action=oreject header.from=juniper.net;dkim=none (message not signed);arc=none Received: from BN3PR05CA0036.namprd05.prod.outlook.com (2603:10b6:400::46) by BN7PR05MB4276.namprd05.prod.outlook.com (2603:10b6:406:f6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.9; Tue, 30 Jul 2019 22:23:25 +0000 Received: from CO1NAM05FT031.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::205) by BN3PR05CA0036.outlook.office365.com (2603:10b6:400::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.7 via Frontend Transport; Tue, 30 Jul 2019 22:23:25 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from P-EXFEND-EQX-01.jnpr.net (66.129.239.12) by CO1NAM05FT031.mail.protection.outlook.com (10.152.96.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2136.7 via Frontend Transport; Tue, 30 Jul 2019 22:23:24 +0000 Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 30 Jul 2019 15:23:24 -0700 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 30 Jul 2019 15:23:24 -0700 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 30 Jul 2019 15:23:23 -0700 Received: from contrail-ubm16-mdb.svec1.juniper.net ([10.163.18.199]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id x6UMNMd9014872; Tue, 30 Jul 2019 15:23:23 -0700 (envelope-from mdb@juniper.net) To: Benjamin Kaduk CC: , curdle In-Reply-To: <20190730214702.GS47715@kduck.mit.edu> References: <20190730214702.GS47715@kduck.mit.edu> Comments: In-reply-to: Benjamin Kaduk message dated "Tue, 30 Jul 2019 16:47:02 -0500." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31256.1564525402.1@contrail-ubm16-mdb.svec1.juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2019 15:23:22 -0700 Message-ID: <31257.1564525402@contrail-ubm16-mdb.svec1.juniper.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(136003)(376002)(346002)(2980300002)(199004)(189003)(46406003)(97756001)(54906003)(97876018)(356004)(8676002)(336012)(81166006)(316002)(47776003)(229853002)(8936002)(8746002)(81156014)(26005)(70586007)(4326008)(70206006)(86362001)(7696005)(476003)(6916009)(2171002)(69596002)(126002)(305945005)(6246003)(446003)(53936002)(11346002)(426003)(2906002)(76176011)(478600001)(5660300002)(186003)(23726003)(14444005)(50466002)(117636001)(486006)(68736007)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4276; H:P-EXFEND-EQX-01.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d77e13dd-59aa-4faa-8185-08d7153c89cd X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4710121)(4711136)(1401327)(2017052603328); SRVR:BN7PR05MB4276; X-MS-TrafficTypeDiagnostic: BN7PR05MB4276: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0114FF88F6 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: AP0lXzduHKCpTZuWfiNx246J0esMnOWZRLE2x5ZNoU3olqqsMRTjAxJqMQpQZ2v/lfo4jHnEVd3co2DY2Ujkt87H+aIUIzrTq9a4hkEG5tRcKiE7+5PG+7oZHmiRy4ZZZfR/Qo+Z17a432pzFHLxTJ5LoHi1df+FLM9odq6UmGIVRoo04U4maseTKWzpB9S+goJlKQzNLwQ1sQ3VhAzWO71HvtQMhNu0JLpb6MuJfqSSn0pVCmUipTf8zNQACkGOJAg5Z8mgX+1aV2kWszLJ5S4SH4CaUArvXc8lGwprJc9SsUv7RueWb7E3I5YAz1pV9eJ+i3jq00yzfJr4azIyOBy3b2ULQgomE4JodlEN6SIuFtq+HdDmmFbA1nF1UXVbY3xourFi7SYAcTCIGMtUdvkTYOW7cGzfw6LTdJ+5kyg= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2019 22:23:24.8520 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d77e13dd-59aa-4faa-8185-08d7153c89cd X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[P-EXFEND-EQX-01.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4276 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=774 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907300223 Archived-At: Subject: Re: [Curdle] Second AD Review: draft-ietf-curdle-ssh-curves. 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, 30 Jul 2019 22:23:30 -0000 Benjamin Kaduk writes: > I took over as responsible AD for this draft from Eric, but I don't > see any response to this second round of review comments. Luckily there= 's > mot much left, so hopefully we can get a new rev out quickly and move th= e > document forward. I do owe the AD a response to the comments and a new draft. I regret that other commitments have prevented me from this. -- Mark > Thanks, > = > Ben > = > On Mon, Dec 24, 2018 at 02:16:24PM -0800, Eric Rescorla wrote: > > Thanks for addressing my comments. > > = > > IMPORTANT > > S 3. > > = > > > received public keys are not the expected lengths, or if the > > > derived shared secret only consists of zero bits. No further > > > validation is required beyond what is discussed in [RFC7748]. > > > The derived shared secret is 32 bytes when Curve25519 is used > > > and 56 bytes when Curve448 is used. The encodings of all > > > values are defined in [RFC7748]. The hash used is SHA-256 for > > > Curve25519 and SHA-512 for Curve448. > > = > > This is true if you use the 7748 algorithm, but not necessarily > > otherwise. > > = > > Here is some OK language (from tcpcrypt) > > = > > 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]. When they do so, > > implementations MUST check whether the computed Diffie-Hellman > > shared secret is the all-zero value and abort if so, as described > > in Section 6 of [RFC7748]. Alternative implementations of these > > functions SHOULD abort when either input forces the shared secret > > to one of a small set of values, as discussed in Section 7 of > > [RFC7748]. > > > > COMMENTS > > S 1. > > > key exchange protocol described in [RFC4253] supports an extens= ible > > > set of methods. [RFC5656] describes how elliptic curves are > > > integrated in SSH, and this document reuses those protocol mess= ages. > > > > > > This document describes how to implement key exchange based on > > > Curve25519 and Ed448-Goldilocks [RFC7748] in SSH. For Curve255= 19 > > = > > 7748 calls this Curve448 and you do so later, so please be consistent. -- Mark From nobody Tue Jul 30 16:13:38 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 BEB8C120273; Tue, 30 Jul 2019 16:13:29 -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 16GECDX1x4pw; Tue, 30 Jul 2019 16:13:27 -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 70E9912007C; Tue, 30 Jul 2019 16:13: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 x6UNDMZh013608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 19:13:25 -0400 Date: Tue, 30 Jul 2019 18:13:22 -0500 From: Benjamin Kaduk To: "Mark D. Baushke" Cc: draft-ietf-curdle-ssh-curves.all@ietf.org, curdle Message-ID: <20190730231321.GU47715@kduck.mit.edu> References: <20190730214702.GS47715@kduck.mit.edu> <31257.1564525402@contrail-ubm16-mdb.svec1.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31257.1564525402@contrail-ubm16-mdb.svec1.juniper.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Curdle] Second AD Review: draft-ietf-curdle-ssh-curves. 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, 30 Jul 2019 23:13:36 -0000 On Tue, Jul 30, 2019 at 03:23:22PM -0700, Mark D. Baushke wrote: > Benjamin Kaduk writes: > > > I took over as responsible AD for this draft from Eric, but I don't > > see any response to this second round of review comments. Luckily there's > > mot much left, so hopefully we can get a new rev out quickly and move the > > document forward. > > I do owe the AD a response to the comments and a new draft. > I regret that other commitments have prevented me from this. I completely understand; my main goal is to ensure that *I* was not the one holding things up, as there are quite a few things for which that is the case at the moment. (BTW, if anyone feels there is some urgency to getting these documents published, the chairs can appoint a new document editor to handle the mechanical text juggling and document submission. That might be less feasible for the other document, though, given the volume of comments Eric made.) -Ben > > > Thanks, > > > > Ben > > > > On Mon, Dec 24, 2018 at 02:16:24PM -0800, Eric Rescorla wrote: > > > Thanks for addressing my comments. > > > > > > IMPORTANT > > > S 3. > > > > > > > received public keys are not the expected lengths, or if the > > > > derived shared secret only consists of zero bits. No further > > > > validation is required beyond what is discussed in [RFC7748]. > > > > The derived shared secret is 32 bytes when Curve25519 is used > > > > and 56 bytes when Curve448 is used. The encodings of all > > > > values are defined in [RFC7748]. The hash used is SHA-256 for > > > > Curve25519 and SHA-512 for Curve448. > > > > > > This is true if you use the 7748 algorithm, but not necessarily > > > otherwise. > > > > > > Here is some OK language (from tcpcrypt) > > > > > > 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]. When they do so, > > > implementations MUST check whether the computed Diffie-Hellman > > > shared secret is the all-zero value and abort if so, as described > > > in Section 6 of [RFC7748]. Alternative implementations of these > > > functions SHOULD abort when either input forces the shared secret > > > to one of a small set of values, as discussed in Section 7 of > > > [RFC7748]. > > > > > > COMMENTS > > > S 1. > > > > key exchange protocol described in [RFC4253] supports an extensible > > > > set of methods. [RFC5656] describes how elliptic curves are > > > > integrated in SSH, and this document reuses those protocol messages. > > > > > > > > This document describes how to implement key exchange based on > > > > Curve25519 and Ed448-Goldilocks [RFC7748] in SSH. For Curve25519 > > > > > > 7748 calls this Curve448 and you do so later, so please be consistent. > > -- Mark From nobody Tue Jul 30 16:50:01 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 2F5691200D8; Tue, 30 Jul 2019 16:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Dc03JIntKTEx; Tue, 30 Jul 2019 16:49:57 -0700 (PDT) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (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 E56D61200B9; Tue, 30 Jul 2019 16:49:56 -0700 (PDT) Received: by mail-vs1-f50.google.com with SMTP id a186so43304718vsd.7; Tue, 30 Jul 2019 16:49:56 -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=reKuSmQ/8jm0lv6xw14wBTCT6jMzoYKhLq6Q37KOmSs=; b=g9rAmkN7T6bwoP1J5d5RUdTytJb31nNAuHpaFFEF51roc/IPUWj+uoIbeyNg8gUluj 1uJSQtr5Ms+iyYfTMUSLN2u0Vlbk3qzPPTPjj62a50T8p2wWxaJ1ttbffkTRE3Zq8gKz N0gJJQTe0/Q6nk14j5Ak63hRLhbxRhL/mQ1fAneoCTge4fAosVY6xgW7lyhYmeMawXPS LVYPdxXOsbXylEmyOJMY02TgDlvZ8AWlpP1yMZRUEhTnxN9bXyMd69/LN0ufKJiqDdmf hsmtcEA1XaIdtzaEGq2QKy2xX+Tb2ahAi/2cI8AzxVywJ9sQlohk1CBBfZzT52xsrB8n azYA== X-Gm-Message-State: APjAAAWlHV2zonuoiMB8vLhb6joKcmdhiUkG62gPcliQjDuNAZEQ2EU8 rBVG+x1M8E2KZNV+k/8it/WUJ2X02IiB2z1T77o= X-Google-Smtp-Source: APXvYqya02tzRlQYvBvOA02wa8wazVWnPUhX27fx3mivsVsMLWIbDBJ41Q374eoKFASPsczxvq1SGf7lTd/A7pqcsfo= X-Received: by 2002:a67:33c1:: with SMTP id z184mr79378073vsz.169.1564530595943; Tue, 30 Jul 2019 16:49:55 -0700 (PDT) MIME-Version: 1.0 References: <20190730214702.GS47715@kduck.mit.edu> <31257.1564525402@contrail-ubm16-mdb.svec1.juniper.net> <20190730231321.GU47715@kduck.mit.edu> In-Reply-To: <20190730231321.GU47715@kduck.mit.edu> From: Daniel Migault Date: Tue, 30 Jul 2019 19:49:44 -0400 Message-ID: To: Benjamin Kaduk Cc: "Mark D. Baushke" , curdle , draft-ietf-curdle-ssh-curves.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000696432058eeeaa4f" Archived-At: Subject: Re: [Curdle] Second AD Review: draft-ietf-curdle-ssh-curves. 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, 30 Jul 2019 23:49:59 -0000 --000000000000696432058eeeaa4f Content-Type: text/plain; charset="UTF-8" I believe the easiest way to do is to let Mark update the draft when time permits. Thanks you Ben and Mark for moving these documents forward. Yours, Daniel On Tue, Jul 30, 2019 at 7:13 PM Benjamin Kaduk wrote: > On Tue, Jul 30, 2019 at 03:23:22PM -0700, Mark D. Baushke wrote: > > Benjamin Kaduk writes: > > > > > I took over as responsible AD for this draft from Eric, but I don't > > > see any response to this second round of review comments. Luckily > there's > > > mot much left, so hopefully we can get a new rev out quickly and move > the > > > document forward. > > > > I do owe the AD a response to the comments and a new draft. > > I regret that other commitments have prevented me from this. > > I completely understand; my main goal is to ensure that *I* was not the one > holding things up, as there are quite a few things for which that is the > case at the moment. > > (BTW, if anyone feels there is some urgency to getting these documents > published, the chairs can appoint a new document editor to handle the > mechanical text juggling and document submission. That might be less > feasible for the other document, though, given the volume of comments Eric > made.) > > -Ben > > > > > > Thanks, > > > > > > Ben > > > > > > On Mon, Dec 24, 2018 at 02:16:24PM -0800, Eric Rescorla wrote: > > > > Thanks for addressing my comments. > > > > > > > > IMPORTANT > > > > S 3. > > > > > > > > > received public keys are not the expected lengths, or if the > > > > > derived shared secret only consists of zero bits. No further > > > > > validation is required beyond what is discussed in [RFC7748]. > > > > > The derived shared secret is 32 bytes when Curve25519 is used > > > > > and 56 bytes when Curve448 is used. The encodings of all > > > > > values are defined in [RFC7748]. The hash used is SHA-256 for > > > > > Curve25519 and SHA-512 for Curve448. > > > > > > > > This is true if you use the 7748 algorithm, but not necessarily > > > > otherwise. > > > > > > > > Here is some OK language (from tcpcrypt) > > > > > > > > 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]. When they do so, > > > > implementations MUST check whether the computed Diffie-Hellman > > > > shared secret is the all-zero value and abort if so, as described > > > > in Section 6 of [RFC7748]. Alternative implementations of these > > > > functions SHOULD abort when either input forces the shared secret > > > > to one of a small set of values, as discussed in Section 7 of > > > > [RFC7748]. > > > > > > > > COMMENTS > > > > S 1. > > > > > key exchange protocol described in [RFC4253] supports an > extensible > > > > > set of methods. [RFC5656] describes how elliptic curves are > > > > > integrated in SSH, and this document reuses those protocol > messages. > > > > > > > > > > This document describes how to implement key exchange based on > > > > > Curve25519 and Ed448-Goldilocks [RFC7748] in SSH. For > Curve25519 > > > > > > > > 7748 calls this Curve448 and you do so later, so please be > consistent. > > > > -- Mark > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --000000000000696432058eeeaa4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the easiest way to do is to let Mark update the = draft when time permits. Thanks you Ben and Mark for moving these documents= forward.=C2=A0=C2=A0
Yours,=C2=A0
Daniel

On Tue, Jul 30= , 2019 at 7:13 PM Benjamin Kaduk <kaduk= @mit.edu> wrote:
On Tue, Jul 30, 2019 at 03:23:22PM -0700, Mark D. Baushke wrote: > Benjamin Kaduk <= kaduk@mit.edu> writes:
>
> > I took over as responsible AD for this draft from Eric, but I don= 't
> > see any response to this second round of review comments.=C2=A0 L= uckily there's
> > mot much left, so hopefully we can get a new rev out quickly and = move the
> > document forward.
>
> I do owe the AD a response to the comments and a new draft.
> I regret that other commitments have prevented me from this.

I completely understand; my main goal is to ensure that *I* was not the one=
holding things up, as there are quite a few things for which that is the case at the moment.

(BTW, if anyone feels there is some urgency to getting these documents
published, the chairs can appoint a new document editor to handle the
mechanical text juggling and document submission.=C2=A0 That might be less<= br> feasible for the other document, though, given the volume of comments Eric<= br> made.)

-Ben

>
> > Thanks,
> >
> > Ben
> >
> > On Mon, Dec 24, 2018 at 02:16:24PM -0800, Eric Rescorla wrote: > > > Thanks for addressing my comments.
> > >
> > > IMPORTANT
> > > S 3.
> > >=C2=A0 =C2=A0
> > > >=C2=A0 =C2=A0 =C2=A0 received public keys are not the ex= pected lengths, or if the
> > > >=C2=A0 =C2=A0 =C2=A0 derived shared secret only consists= of zero bits. No further
> > > >=C2=A0 =C2=A0 =C2=A0 validation is required beyond what = is discussed in [RFC7748].
> > > >=C2=A0 =C2=A0 =C2=A0 The derived shared secret is 32 byt= es when Curve25519 is used
> > > >=C2=A0 =C2=A0 =C2=A0 and 56 bytes when Curve448 is used.= The encodings of all
> > > >=C2=A0 =C2=A0 =C2=A0 values are defined in [RFC7748]. Th= e hash used is SHA-256 for
> > > >=C2=A0 =C2=A0 =C2=A0 Curve25519 and SHA-512 for Curve448= .
> > >
> > > This is true if you use the 7748 algorithm, but not necessar= ily
> > > otherwise.
> > >
> > > Here is some OK language (from tcpcrypt)
> > >
> > >=C2=A0 =C2=A0 Key-agreement schemes ECDHE-Curve25519 and ECDH= E-Curve448 perform
> > >=C2=A0 =C2=A0 the Diffie-Helman protocol using the functions = X25519 and X448,
> > >=C2=A0 =C2=A0 respectively. Implementations SHOULD compute th= ese functions
> > >=C2=A0 =C2=A0 using the algorithms described in [RFC7748]. Wh= en they do so,
> > >=C2=A0 =C2=A0 implementations MUST check whether the computed= Diffie-Hellman
> > >=C2=A0 =C2=A0 shared secret is the all-zero value and abort i= f so, as described
> > >=C2=A0 =C2=A0 in Section 6 of [RFC7748]. Alternative implemen= tations of these
> > >=C2=A0 =C2=A0 functions SHOULD abort when either input forces= the shared secret
> > >=C2=A0 =C2=A0 to one of a small set of values, as discussed i= n Section 7 of
> > >=C2=A0 =C2=A0 [RFC7748].
> > >
> > > COMMENTS
> > > S 1.
> > > >=C2=A0 =C2=A0 =C2=A0 key exchange protocol described in = [RFC4253] supports an extensible
> > > >=C2=A0 =C2=A0 =C2=A0 set of methods.=C2=A0 [RFC5656] des= cribes how elliptic curves are
> > > >=C2=A0 =C2=A0 =C2=A0 integrated in SSH, and this documen= t reuses those protocol messages.
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 This document describes how to impl= ement key exchange based on
> > > >=C2=A0 =C2=A0 =C2=A0 Curve25519 and Ed448-Goldilocks [RF= C7748] in SSH.=C2=A0 For Curve25519
> > >
> > > 7748 calls this Curve448 and you do so later, so please be c= onsistent.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mark

_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--000000000000696432058eeeaa4f-- From nobody Tue Jul 30 16:56:25 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 8F1721200A4; Tue, 30 Jul 2019 16:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Jz1lbMKMJwAi; Tue, 30 Jul 2019 16:56:20 -0700 (PDT) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 2D6C112004E; Tue, 30 Jul 2019 16:56:20 -0700 (PDT) Received: by mail-vs1-f46.google.com with SMTP id y16so44879987vsc.3; Tue, 30 Jul 2019 16:56:20 -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=K6zQ9hBL9yWwWTluUChG86Hx0RTZychPnmVgAaTMiFg=; b=jCrVHghjE5S/zTnygPTR60+wcKJhnQESbBatDbjvwRReyn1TU/8S6wI6uSaeb6OTyc HO8sRejhsF8KOZDVkft0w46vyjwQvbqAd2NlrmEtlhHHujqM6yp4juMTqEE0+EgaT/M9 oLuMsw7A8KAoCL3QoN52Pq1OcGngDQtvhEg4T0+4nY+3JlfeeTX3U0NVWtdrxlx/rCE+ lq+rPcapZpvTgUZ+SAE5k44J7HtmwJTmqTwcBr4JRJ4KoN3Sv/VqKvJ1lf2uZrlgp+DU GU2e3dbEz9MAw6mgvl6sVO7c6AwtDzXhmehkn8K8C5Z4RpJcsA8yfmEzJDq9kPmhvfKP eWZQ== X-Gm-Message-State: APjAAAURWFFVDGM2YEA/mrF4OHgN3KT7fqBbTgcnR+yTtnATQG+wWSNT pAQ9UweTwPpUJ6uQh3u7xv3FXXq4ebcmHlEiQYs= X-Google-Smtp-Source: APXvYqzRKJ14CL71cAz2PcGi2gw15iqh8ptKYG5zCmvaI1z5WMUODEN7RySZIMpkPUfX619osjej8z4uWyeBcUymT8Q= X-Received: by 2002:a67:33c1:: with SMTP id z184mr79389501vsz.169.1564530979239; Tue, 30 Jul 2019 16:56:19 -0700 (PDT) MIME-Version: 1.0 References: <20190604174029.GC8678@prolepsis.kaduk.org> <20190607222610.GH83686@kduck.mit.edu> <20190730213418.GQ47715@kduck.mit.edu> In-Reply-To: <20190730213418.GQ47715@kduck.mit.edu> From: Daniel Migault Date: Tue, 30 Jul 2019 19:56:08 -0400 Message-ID: To: bjh21@bjh21.me.uk Cc: Loganaden Velvindron , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000041fd74058eeec111" 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: Tue, 30 Jul 2019 23:56:22 -0000 --00000000000041fd74058eeec111 Content-Type: text/plain; charset="UTF-8" Hi Ben, In order to move the document forward, it would be helpful if you could state if you are aware of any IPR related to the document. Yours, Daniel On Tue, Jul 30, 2019 at 5:34 PM Benjamin Kaduk wrote: > Cycling back on this, my reading of the archive suggests that we want an > -09 to include Daniel's suggested text to clarify on (1), and we need to > hear from Ben about (3). > > Does that sound right to everyone or am I missing something? > > Thanks, > > Ben > > On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: > > 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 < > daniel.migault@ericsson.com> 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 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 > --00000000000041fd74058eeec111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,=C2=A0

In order to move the docu= ment forward, it would be helpful if you could state if you are aware of an= y IPR related to the document.=C2=A0

Yours,=C2=A0<= /div>
Daniel


<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 30, 2019 at 5:34 PM Benjam= in Kaduk <kaduk@mit.edu> wrote:<= br>
Cycling back on = this, my reading of the archive suggests that we want an
-09 to include Daniel's suggested text to clarify on (1), and we need t= o
hear from Ben about (3).

Does that sound right to everyone or am I missing something?

Thanks,

Ben

On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote:
> On Thu, Jun 06, 2019 at 02:56:46PM +0000, Daniel Migault wrote:
> > This is correct, for some reasons I reviewed version 07. So versi= on 08 is solving the opsdir issue. I will close the thread on the mailing l= ist.
>
> Ah, thank you.=C2=A0 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, t= he type of the fingerprint. The current draft only adds a registry for the = algorithm. I believe the confusion might be that the current text=C2=A0 see= ms to indicate some additional changes for example in the generation of the= finger print.=C2=A0 Maybe the text below around the following lines clarif= ies 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&qu= ot; keys is
> >=C2=A0 =C2=A0 described in [RFC7479].
> >
> >=C2=A0 =C2=A0 The generation of SSHFP resource records for "s= sh-ed448" keys is
> >=C2=A0 =C2=A0 described as follows.
> >
> >=C2=A0 =C2=A0 the SSHFP Resource Record for the Ed448 public key w= ith SHA-256
> >=C2=A0 =C2=A0 fingerprint would be example be:
> >
> >=C2=A0 =C2=A0 example.com.=C2=A0 IN SSHFP TBD 2 ( a87f1b687ac0e57d2a0= 81a2f2826723
> >=C2=A0 =C2=A0 34d90ed316d2b818ca9580ea384d924 01 )
> >
> >=C2=A0 =C2=A0 The 2 here indicates SHA-256 [RFC6594].
> >
> > NEW:
> >
> > The generation of SSHFP resource records for "ssh-ed25519&qu= ot; keys is
> >=C2=A0 =C2=A0 described in [RFC7479].
> >
> > The SSHFP resource records for "ssh-ed448" keys is gene= rated 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.=C2=A0 IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f2826723<= br> > > 34d90ed316d2b818ca9580ea384d924 01 )
> >
> > The 2 here indicates SHA-256 [RFC6594].
> >
> > From: Loganaden Velvindron <loganaden@gmail.com>
> > Sent: Thursday, June 06, 2019 3:02 AM
> > To: Daniel Migault <daniel.migault@ericsson.com>
> > Cc: Benjamin Kaduk <kaduk@mit.edu>; draft-ietf-curdle-ssh-ed25519-ed= 448.all@ietf.org; = curdle@ietf.org
> > Subject: Re: new AD review comments on draft-ietf-curdle-ssh-ed25= 519-ed448-08
> >
> > I already published rev08 to address those issues:
> > https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2= =3Ddraft-ietf-curdle-ssh-ed25519-ed448-08.txt
> >
> > On Wed, Jun 5, 2019 at 5:52 PM Daniel Migault <daniel.migault@ericsson.c= om<mailto:daniel.migault@ericsson.com>> 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 <kaduk@mit.edu<mailto:kaduk@mit.edu>>
> > Sent: Tuesday, June 04, 2019 1:41 PM
> > To: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org<mailto:draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org>
> > Cc: curdle@i= etf.org<mailto:= 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 seem= s to be a few things to fix, first:
> >
> > (1) In Section 8 we say "The generation of SSHFP resource re= cords for "ssh-ed448" keys is described as follows." but the= n give only an example and not a description of what to do.=C2=A0 We need t= o say more about this procedure
> >
> > (2) I'm not sure if the chain on the opsdir review got fully = resolved; see https://mailar= chive.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)d= isclosure 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?=C2= =A0 I'm sure that some IESG members will ask "why not Informationa= l?" 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,<= br> > > Internet Standard, Informational, Experimental, or Historic)?=C2= =A0 Why
> > is this the proper type of RFC?=C2=A0 Is this type of RFC indicat= ed in the
> > 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<= br> > > most appropriated status.
> >
> > The OPS Directorate wondered why version 07 was a Standard Track<= br> > > document and not an informational document as no normative 2119 w= ords.
> >
> > The reason for being a standard track is that we expect the imple= mentation
> > 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 sign= ature algorithms."
> > </mglt>
> > Thanks,
> >
> > Ben
--00000000000041fd74058eeec111-- From nobody Tue Jul 30 16:57:50 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 CCF2A1200A4; Tue, 30 Jul 2019 16:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 3OdjiXv3DYpH; Tue, 30 Jul 2019 16:57:46 -0700 (PDT) Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (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 18C5912004E; Tue, 30 Jul 2019 16:57:46 -0700 (PDT) Received: by mail-ua1-f44.google.com with SMTP id j21so26271855uap.2; Tue, 30 Jul 2019 16:57:46 -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=gzvF0JAe5uTse8ZJl7fmPVvBuktPU3CKTR7mOvwmcRE=; b=qeipEpEZJxq/ys76I8bZbfHaCjIC8b3PLleO70igGG2kK1LrKfmDy6IWyRAmvf9j8m F38+sb4AeXomhT/uV5LF0FGHoMFYEqaVBxS3UdUUF2J+DeEdZCXAHFGDfK63gT10OjxV 85zqTIe2/25UWwu22BXIG3eNFS0+VM38d1Hq7S66ulBLwU0EudieBcAbio9UuQsv76EL Wdk6lEUYNhShILgQtqolSanBBGe+4Xf0vCkPTVecJsC1ed/opZYfx604e2SS1/vO24DN WrMAV4kc3BIGoMCGNj66PNvqZHHeLSNTHPgrkuFFpIXtWHPTnVwqpBa/oMY8eE0l2t3e XBfg== X-Gm-Message-State: APjAAAWMNo3PsaztRWWjGkhkYMMnMt5tYcSLYoJBdePp95ZJC09fpnfu eTxpDsKc2ezOO6NucZU0WFDMV/B9l6XpLjmcynQ= X-Google-Smtp-Source: APXvYqxuWO3L2isMUmyP+tsDOktLU/uPUJFeENZ7CCNx33O2lBwT12TrYCsf/PEr/GtzpZPaxraJ4VdDnjsVKbv1dRU= X-Received: by 2002:ab0:70ab:: with SMTP id q11mr21649806ual.88.1564531065135; Tue, 30 Jul 2019 16:57:45 -0700 (PDT) MIME-Version: 1.0 References: <20190604174029.GC8678@prolepsis.kaduk.org> <20190607222610.GH83686@kduck.mit.edu> <20190730213418.GQ47715@kduck.mit.edu> In-Reply-To: <20190730213418.GQ47715@kduck.mit.edu> From: Daniel Migault Date: Tue, 30 Jul 2019 19:57:34 -0400 Message-ID: To: Benjamin Kaduk Cc: bjh21@bjh21.me.uk, Loganaden Velvindron , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary="00000000000060c808058eeec63d" 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: Tue, 30 Jul 2019 23:57:49 -0000 --00000000000060c808058eeec63d Content-Type: text/plain; charset="UTF-8" Hi, I believe that is all we need to do. Yours, Daniel On Tue, Jul 30, 2019 at 5:34 PM Benjamin Kaduk wrote: > Cycling back on this, my reading of the archive suggests that we want an > -09 to include Daniel's suggested text to clarify on (1), and we need to > hear from Ben about (3). > > Does that sound right to everyone or am I missing something? > > Thanks, > > Ben > > On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: > > 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 < > daniel.migault@ericsson.com> 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 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 > --00000000000060c808058eeec63d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I believe that is all we need= to do.=C2=A0

Yours,=C2=A0
Daniel
<= /div>
O= n Tue, Jul 30, 2019 at 5:34 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Cycling back on this, my reading of the archive sugges= ts that we want an
-09 to include Daniel's suggested text to clarify on (1), and we need t= o
hear from Ben about (3).

Does that sound right to everyone or am I missing something?

Thanks,

Ben

On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote:
> On Thu, Jun 06, 2019 at 02:56:46PM +0000, Daniel Migault wrote:
> > This is correct, for some reasons I reviewed version 07. So versi= on 08 is solving the opsdir issue. I will close the thread on the mailing l= ist.
>
> Ah, thank you.=C2=A0 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, t= he type of the fingerprint. The current draft only adds a registry for the = algorithm. I believe the confusion might be that the current text=C2=A0 see= ms to indicate some additional changes for example in the generation of the= finger print.=C2=A0 Maybe the text below around the following lines clarif= ies 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&qu= ot; keys is
> >=C2=A0 =C2=A0 described in [RFC7479].
> >
> >=C2=A0 =C2=A0 The generation of SSHFP resource records for "s= sh-ed448" keys is
> >=C2=A0 =C2=A0 described as follows.
> >
> >=C2=A0 =C2=A0 the SSHFP Resource Record for the Ed448 public key w= ith SHA-256
> >=C2=A0 =C2=A0 fingerprint would be example be:
> >
> >=C2=A0 =C2=A0 example.com.=C2=A0 IN SSHFP TBD 2 ( a87f1b687ac0e57d2a0= 81a2f2826723
> >=C2=A0 =C2=A0 34d90ed316d2b818ca9580ea384d924 01 )
> >
> >=C2=A0 =C2=A0 The 2 here indicates SHA-256 [RFC6594].
> >
> > NEW:
> >
> > The generation of SSHFP resource records for "ssh-ed25519&qu= ot; keys is
> >=C2=A0 =C2=A0 described in [RFC7479].
> >
> > The SSHFP resource records for "ssh-ed448" keys is gene= rated 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.=C2=A0 IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f2826723<= br> > > 34d90ed316d2b818ca9580ea384d924 01 )
> >
> > The 2 here indicates SHA-256 [RFC6594].
> >
> > From: Loganaden Velvindron <loganaden@gmail.com>
> > Sent: Thursday, June 06, 2019 3:02 AM
> > To: Daniel Migault <daniel.migault@ericsson.com>
> > Cc: Benjamin Kaduk <kaduk@mit.edu>; draft-ietf-curdle-ssh-ed25519-ed= 448.all@ietf.org; = curdle@ietf.org
> > Subject: Re: new AD review comments on draft-ietf-curdle-ssh-ed25= 519-ed448-08
> >
> > I already published rev08 to address those issues:
> > https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2= =3Ddraft-ietf-curdle-ssh-ed25519-ed448-08.txt
> >
> > On Wed, Jun 5, 2019 at 5:52 PM Daniel Migault <daniel.migault@ericsson.c= om<mailto:daniel.migault@ericsson.com>> 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 <kaduk@mit.edu<mailto:kaduk@mit.edu>>
> > Sent: Tuesday, June 04, 2019 1:41 PM
> > To: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org<mailto:draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org>
> > Cc: curdle@i= etf.org<mailto:= 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 seem= s to be a few things to fix, first:
> >
> > (1) In Section 8 we say "The generation of SSHFP resource re= cords for "ssh-ed448" keys is described as follows." but the= n give only an example and not a description of what to do.=C2=A0 We need t= o say more about this procedure
> >
> > (2) I'm not sure if the chain on the opsdir review got fully = resolved; see https://mailar= chive.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)d= isclosure 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?=C2= =A0 I'm sure that some IESG members will ask "why not Informationa= l?" 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,<= br> > > Internet Standard, Informational, Experimental, or Historic)?=C2= =A0 Why
> > is this the proper type of RFC?=C2=A0 Is this type of RFC indicat= ed in the
> > 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<= br> > > most appropriated status.
> >
> > The OPS Directorate wondered why version 07 was a Standard Track<= br> > > document and not an informational document as no normative 2119 w= ords.
> >
> > The reason for being a standard track is that we expect the imple= mentation
> > 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 sign= ature algorithms."
> > </mglt>
> > Thanks,
> >
> > Ben
--00000000000060c808058eeec63d-- From nobody Tue Jul 30 23:33:56 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 D90C812004F; Tue, 30 Jul 2019 23:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 2Sts8PAEnyAb; Tue, 30 Jul 2019 23:33:52 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 43CCB120047; Tue, 30 Jul 2019 23:33:52 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id j6so14072153ioa.5; Tue, 30 Jul 2019 23:33:52 -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:content-transfer-encoding; bh=CCxEmboml3DhxnAQbKNwdVb4yMvajOpel5ZAyI7aSNY=; b=BcUfO0K34p3y9BAItQm6QtziJgPcFf0xH5WvHVHsS9yeigC/TZxgm0fHdVcOZ0hRpS rTWCMito7IWozMr5I6n74KAn9vh6kEJPnVz/Y9dLoZGuElNRhNUywDfPEfDKSAXHutc7 qJaIzYft6pGCx2CNQfU9lo7qafHUC8JLb+m+GfZUCgzu7YeI2YyK9mmvpd42w3HY2rgP EGmkRjxRV+7qAuRcJe6fzn0uK6bEvpy8K1KqJ8dGBufzalH8JFmBK5WYVdWiJlIENdMK df/lo/TinJ43gTgnro3n5vG7Ghrxyo5E1OdjKfCfw3iZURfH/dPpAZcsiR1gVLfUC6A6 P9rw== 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:content-transfer-encoding; bh=CCxEmboml3DhxnAQbKNwdVb4yMvajOpel5ZAyI7aSNY=; b=AX0P7TvXde0/hpku+qffT97aSlPmiGKIumwdwdyFn2N1cQ9oHGexwLvsOSrfIaoMgG Xbf7Qp+CpnvcAhCGIiqfG4OiFiOkFLvfAA0r0uZi7P5Kp42inGAFKsKAPi4WvlaEmzbd nm4hSrvu7yrA/FfeSNCoN3cvrXP0Oh0ygu0+WUhef89M5F5bbHLmKsHZB26RyapzADb3 YFN02krOst+UO5AInCsr4PjityQb1J/Z/Tvbmfp5xkiMfYeY9ZCUBLtTNcmOxfFOqKdV IC7EkB82z/uajFtlPQNJPylA0b32RqSUYafABYAn6pIaV7u+QSsvwO1rSPRWcL8Tdzu3 AK5Q== X-Gm-Message-State: APjAAAUV2wDiPfjxAPpS1s4HvYSJYu4bLC2Xl3xjuguB7sVG0B2P35rS bcNc1nabYyuGNDOxNyF4JmP+MWBGiRfRccA8KOKyv2nXGfc= X-Google-Smtp-Source: APXvYqzef5/0FxJMom0gjVcRDcKzjs+fbgrpG0SkWhx6sSRDeSL6rRqcXlBTW50znUReC7xE2CwLyqt+59DYHXLg8KI= X-Received: by 2002:a02:ab99:: with SMTP id t25mr38904398jan.113.1564554831613; Tue, 30 Jul 2019 23:33:51 -0700 (PDT) MIME-Version: 1.0 References: <20190604174029.GC8678@prolepsis.kaduk.org> <20190607222610.GH83686@kduck.mit.edu> <20190730213418.GQ47715@kduck.mit.edu> In-Reply-To: <20190730213418.GQ47715@kduck.mit.edu> From: Loganaden Velvindron Date: Wed, 31 Jul 2019 10:33:39 +0400 Message-ID: To: Benjamin Kaduk Cc: Daniel Migault , bjh21@bjh21.me.uk, "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 31 Jul 2019 06:33:55 -0000 On Wed, Jul 31, 2019 at 1:34 AM Benjamin Kaduk wrote: > > Cycling back on this, my reading of the archive suggests that we want an > -09 to include Daniel's suggested text to clarify on (1), and we need to > hear from Ben about (3). > > Does that sound right to everyone or am I missing something? > I would suggest standards track given that ed25519 is already public key is already implemented by OpenSSH. http://www.openssh.com/txt/release-6.5 > Thanks, > > Ben > > On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: > > 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 0= 8 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, an= d > > 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 t= ype of the fingerprint. The current draft only adds a registry for the algo= rithm. I believe the confusion might be that the current text seems to ind= icate some additional changes for example in the generation of the finger p= rint. Maybe the text below around the following lines clarifies the purpos= e 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 similarl= y, > > > 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-ed4= 48.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=3D--hwdiff&url2=3Ddraft-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-ed44= 8-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 a= nd not a description of what to do. We need to say more about this procedu= re > > > > > > (2) I'm not sure if the chain on the opsdir review got fully resolved= ; see https://mailarchive.ietf.org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uPh= aCk > > > > > > The current version has not accordingly been updated. > > > > > > > > > (3) The shepherd writeup says that Ben did not confirm IPR (non)discl= osure 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 sur= e that some IESG members will ask "why not Informational?" if we don't fore= stall 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 implement= ation > > > 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 alg= orithms." > > > > > > Thanks, > > > > > > Ben From nobody Wed Jul 31 00:26:43 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 B4F91120098; Wed, 31 Jul 2019 00:26:39 -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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: curdle@ietf.org Message-ID: <156455799959.27579.10618139364811412851@ietfa.amsl.com> Date: Wed, 31 Jul 2019 00:26:39 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rc4-die-die-die-16.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: Wed, 31 Jul 2019 07:26:40 -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 : Deprecating RC4 in Secure Shell (SSH) Authors : Luis Camara Loganaden Velvindron Filename : draft-ietf-curdle-rc4-die-die-die-16.txt Pages : 5 Date : 2019-07-31 Abstract: This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves to Historic RFC4345. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-rc4-die-die-die-16 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rc4-die-die-die-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rc4-die-die-die-16 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 Wed Jul 31 00:31: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 9D7411200C1; Wed, 31 Jul 2019 00:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 5KEzTSkdmqTE; Wed, 31 Jul 2019 00:30:56 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 9EF03120098; Wed, 31 Jul 2019 00:30:56 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id g20so134138281ioc.12; Wed, 31 Jul 2019 00:30:56 -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=5ucLo8g0Hi9+S6GDFQCF4zkw9uc7ctQ2afNh8lP8qWY=; b=ac6+hN74MJ8aAqgyIyAtRHJuFpRktz2csbMsVq+DMuxl/+Xuq5m2DtLgsW83s/P5Es 7r+kznl975OcbsMdvA3KpWANJvaggwmODzCTyA9OlubiE/7w63NGTvbFUuSgRGCACdtJ N0flf6RgUmzFfzAWgxlkxA0v8SMsb2M1XZY6uLLKgHBN/YxCMnjbjz4Np2Jb1uPS030k DVkj7zdJLGlzJq9ibJuJenXlp15D9Js21ck81eRIjcrdlVzOgPyFugdq+pRiXAYIhWlo snbZQrEqVpyOir4+rtJDau6yUw5JBiyO6a0ooAEzhVzm1pttLu1M7zzfT1FkkWT59d1s 5u2Q== 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=5ucLo8g0Hi9+S6GDFQCF4zkw9uc7ctQ2afNh8lP8qWY=; b=C1P9oqEcHeOvKHmhqiXsmqTlbvNFI8oJhBVGV7jcREwjDXfY84uebM0xYbzLBXURxr nVn9gtuH5biRUjyDygEFg9iwqfPPM+Blw3ZMkmuNK0b39KP2aSBu48MotQHHbgkdlWti 6ad89NYCId9Z3gpdFqucEM4qWVxYkamySPEvJ+t39mbe4wO1rFg4hHa9/AGigdQr1bLx APTWeH0MDwqPnkOEagyQLcSD4Gk4xx/amUIWhf5a7W5tIJK+I5aa2XodMNE84uzOPz+0 McoZUJ91UmLK8g07J8KpNJV2pPfIqNDBGaq1nH7fn38jcjWLembWKqCMbaBpguyVNB9F j9zQ== X-Gm-Message-State: APjAAAWwUy2p0wKsPVSAlaV5e+cm2rPlMy9lMXxf41ymD51bylsT4647 CU6s97cpNn7DamLRFKM81v2F2Ptgv8iLxdfb/OI= X-Google-Smtp-Source: APXvYqxta1mq1kcstjm+p06GFr7z87CJW1sLAlLpnrkkg9ZMfzUZL4/BQC6maEfKqMDZj+YdCfP1XUdqPG8tCEIgUHY= X-Received: by 2002:a5d:9550:: with SMTP id a16mr72646867ios.106.1564558255989; Wed, 31 Jul 2019 00:30:55 -0700 (PDT) MIME-Version: 1.0 References: <20190730212232.GP47715@kduck.mit.edu> In-Reply-To: <20190730212232.GP47715@kduck.mit.edu> From: Loganaden Velvindron Date: Wed, 31 Jul 2019 11:30:42 +0400 Message-ID: To: Benjamin Kaduk Cc: draft-ietf-curdle-rc4-die-die-die.all@ietf.org, curdle Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] second AD review of draft-ietf-curdle-rc4-die-die-die-15 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, 31 Jul 2019 07:30:59 -0000 On Wed, Jul 31, 2019 at 1:22 AM Benjamin Kaduk wrote: > > Hi all, > > I'm just about ready to send this document into IESG Evaluation, but > noticed a few nits while rereading it. Since they're in areas that I > expect the IESG to be looking at, I'd like to have an updated revision of > the document available before I send it out to the IESG as a whole: > > draft-ietf-curdle-des-des-des-die-die-die is now RFC 8429, so we can update > that reference. > > Additionally, part of the holdup for that document was to decide whether to > Obsolete RFC 4757 or move it to Historic, since we cannot do both. The > Abstract of this document still says that it both Obsoletes and moves to > Historic RFC 4345 (and it has the Obsoletes: header); since we decided in > the RFC 8429 case to use "move to Historic", I think that's the right thing > to do here as well. So we want to keep the "move to Historic" text but > drop the in-document and metadata "Obsoletes:" relationship. > (https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/ has > some more background on the difference.) > > On the other hand, since we are updating RFC 4253, we do need to mention > Updates: 4253 in document header. > > We can also update to use the RFC 8174 version of the BCP 14 boilerplate. > > Finally, the table in Section 3 seems to be formatted oddly, with the > column break appearing in the middle of "Encryption Algorithm Name" instead > of at the end of it. > Thank you Benjami. I've sent in -16. See the diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rc4-die-die-die-16 > Thanks, > > Ben From nobody Wed Jul 31 02:27:43 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 D70EA120159; Wed, 31 Jul 2019 02:27:34 -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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: curdle@ietf.org Message-ID: <156456525482.27655.9963578267128269655@ietfa.amsl.com> Date: Wed, 31 Jul 2019 02:27:34 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-ed448-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: Wed, 31 Jul 2019 09:27:35 -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 : Ed25519 and Ed448 public key algorithms for the Secure Shell (SSH) protocol Authors : Ben Harris Loganaden Velvindron Filename : draft-ietf-curdle-ssh-ed25519-ed448-09.txt Pages : 7 Date : 2019-07-31 Abstract: This document describes the use of the Ed25519 and Ed448 digital signature algorithm in the Secure Shell (SSH) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ed25519-ed448/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-ed448-09 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ed25519-ed448-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ed25519-ed448-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 Wed Jul 31 02:34: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 4395F1201A0; Wed, 31 Jul 2019 02:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 wxC0wzxYF3-V; Wed, 31 Jul 2019 02:34:51 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 54BAA120159; Wed, 31 Jul 2019 02:34:51 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id i10so21473897iol.13; Wed, 31 Jul 2019 02:34:51 -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:content-transfer-encoding; bh=KThJ39zCFCaQdZo5mn7lk0Rd28KV94gpAWVHCVBtQ/s=; b=AJfqmSfu3D1MciElhTpqhFoX7c7nK+jq+zJNI4WfoObNRt36tOKnBaWX/pB2evq2wp PKY54DNvS3Cb1rqPnyF9dKO2EYlkweezyPZdr9/ek3vlsJTIYLH3TOANCJVh9oUpse12 FIJLLjJt12QlXgxZioQ2NaO012io0EskmiKvnzCuFYS/eceODOd3XNkZLOUidNzyZFNp A/6/7JUCCy+cdpupeLcBXzmp5tOGs3qBKz2wb138A9lNXCZs3bdLZhpHslj2SAd4JkEw X6virTzS71gr42TW3XhlE1LaD95PhAOIRAW6yJvomLVJdbGv+j+o1FVi9XQMtPeKBw2A c0Hg== 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:content-transfer-encoding; bh=KThJ39zCFCaQdZo5mn7lk0Rd28KV94gpAWVHCVBtQ/s=; b=sDHg1P1xxZ/Ei97T3T0d6kDnm44uRnQJIbp+cyBFUL4Q0i9JgXHVEVlDvvUn5pJo6+ tiJPQnZNou0wLHBOqJCyBqenfZdedlMHXYTCxeKPrm31ZkimD9edePD6jvO8zSeawvAo 1Bme4XvGj9IdKitsHK48O/o11OHJNCUQ7ZGC7sNG3cktXaH0MHniIvNNtUz6TYEwaKwF /EtV58xBP2ByiC7F97NyeYLAGl8VCxUYeLnrGnYW4y9IrbfMhUBp/hg9GxqAQq49n/Jt h6z+WJ7FbwM6QHB4dqy4LnB9SQCB6qv0oAvlYS0gSK5yaT1hXy4Ta1JHOiVqmQYKMh6I kReg== X-Gm-Message-State: APjAAAW+deqvJYibXqjJ3gslSj7PFvjAvJHHtCqoG9kmNLJA4v67OvmE KRyLpVxVcaZHUpufVHci0Nkes9XISXmoYEqusrI= X-Google-Smtp-Source: APXvYqyCMXoIN6+nIRxhl7TLDUJvrlCtMgZyfoYhU73ZMF0uebra1w8Eacf3Jndv0nCWkrKmCprRJeMcRWJHGmSche8= X-Received: by 2002:a5d:994b:: with SMTP id v11mr65624803ios.165.1564565690625; Wed, 31 Jul 2019 02:34:50 -0700 (PDT) MIME-Version: 1.0 References: <20190604174029.GC8678@prolepsis.kaduk.org> <20190607222610.GH83686@kduck.mit.edu> <20190730213418.GQ47715@kduck.mit.edu> In-Reply-To: From: Loganaden Velvindron Date: Wed, 31 Jul 2019 13:34:38 +0400 Message-ID: To: Daniel Migault Cc: Benjamin Kaduk , bjh21@bjh21.me.uk, "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 31 Jul 2019 09:34:54 -0000 On Wed, Jul 31, 2019 at 3:57 AM Daniel Migault wrote: > > Hi, > > I believe that is all we need to do. > Please find the diff with the changes including fixing a mistake: 114-octet signature for ed448. https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-ssh-ed25519-ed448-09 > Yours, > Daniel > > On Tue, Jul 30, 2019 at 5:34 PM Benjamin Kaduk wrote: >> >> Cycling back on this, my reading of the archive suggests that we want an >> -09 to include Daniel's suggested text to clarify on (1), and we need to >> hear from Ben about (3). >> >> Does that sound right to everyone or am I missing something? >> >> Thanks, >> >> Ben >> >> On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: >> > 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, a= nd >> > 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 alg= orithm. I believe the confusion might be that the current text seems to in= dicate some additional changes for example in the generation of the finger = print. Maybe the text below around the following lines clarifies the purpo= se 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 similar= ly, >> > > 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-ed= 448.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=3D--hwdiff&url2=3Ddraft-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-ed4= 48-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 fo= r "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 proced= ure >> > > >> > > (2) I'm not sure if the chain on the opsdir review got fully resolve= d; see https://mailarchive.ietf.org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uP= haCk >> > > >> > > The current version has not accordingly been updated. >> > > >> > > >> > > (3) The shepherd writeup says that Ben did not confirm IPR (non)disc= losure per BCPs 78 and 79 -- Ben, can you please do so now? >> > > >> > > (4) Daniel, can you please update the shepherd writeup to reflect th= e discussions with the directorate reviewers about document status? I'm su= re that some IESG members will ask "why not Informational?" if we don't for= estall 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 th= e >> > > 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 word= s. >> > > >> > > The reason for being a standard track is that we expect the implemen= tation >> > > that implement SSH to follow these recommendations. The consensus wa= s >> > > to explicitly mention it in the document around the lines: >> > > >> > > "Standard implementations of SSH SHOULD implement these signature al= gorithms." >> > > >> > > Thanks, >> > > >> > > Ben From nobody Wed Jul 31 04:57:38 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 8B9F0120145; Wed, 31 Jul 2019 04:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 aoH9m9BIiMDx; Wed, 31 Jul 2019 04:57:34 -0700 (PDT) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (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 62E691200F6; Wed, 31 Jul 2019 04:57:34 -0700 (PDT) Received: by mail-vs1-f50.google.com with SMTP id r3so45923351vsr.13; Wed, 31 Jul 2019 04:57:34 -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=A7Nt3yoqBPOCTcVQrQ4tXo+0S7QiU9Smcky9bK47xWU=; b=iajziaH9orIGGXzpt2/H1h5g8FRERj1qnPQqNSVdMS3PsVifVLfQTMBBZdCQAlZs0T YEVkuGkFNNrYc9NIi0gjDIE57+mvIfiN2ng3EaDjEJGV0LTcGtGHu4Seyk7Pv73W58G0 PRQyA8KRJl9Mcma+uNTGQ49lxKEk8lc0wBNF0h6qHYwSGqRC2I7Xl7eVSANSTpyEC5aP JaaPuI+Ewmh5YKpQdnqZ9NRXg7buHh56hwVS54JXqZCz8BzGjUW1gxZP96QUoyiLvpAW eRRpDYkX0/vqU9TdiB38WTZ6QF2UBsCvOpXWwCtgQPO9pfYkyG83x9Lfd+DaA2u4TGqH jDrA== X-Gm-Message-State: APjAAAVN+BRq0LQtSKYjKPtscKEPXEFBGtaIdSsNFnn6EM7WPkd6x3f/ T4xFgcBz9fyO25qE9tE3S+avge5lRY7gI74dGbU= X-Google-Smtp-Source: APXvYqycwo+LqFZIUpD/XpPoC3iIZE3ky+HdfxcxRNLl/vHD/LI6gQg4TKMFIp/uMygiF2HkLyjv3aHy2CI8gy0lSZo= X-Received: by 2002:a67:f998:: with SMTP id b24mr27279017vsq.180.1564574253522; Wed, 31 Jul 2019 04:57:33 -0700 (PDT) MIME-Version: 1.0 References: <20190604174029.GC8678@prolepsis.kaduk.org> <20190607222610.GH83686@kduck.mit.edu> <20190730213418.GQ47715@kduck.mit.edu> In-Reply-To: From: Daniel Migault Date: Wed, 31 Jul 2019 07:57:22 -0400 Message-ID: To: Loganaden Velvindron Cc: Benjamin Kaduk , bjh21@bjh21.me.uk, "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009b2166058ef8d40b" 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, 31 Jul 2019 11:57:37 -0000 --0000000000009b2166058ef8d40b Content-Type: text/plain; charset="UTF-8" Thanks Logan. I believe we are all set except for IPR disclosure from Ben. Yours, Daniel On Wed, Jul 31, 2019 at 5:34 AM Loganaden Velvindron wrote: > On Wed, Jul 31, 2019 at 3:57 AM Daniel Migault > wrote: > > > > Hi, > > > > I believe that is all we need to do. > > > > Please find the diff with the changes including fixing a mistake: > 114-octet signature for ed448. > > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ed25519-ed448-09 > > > Yours, > > Daniel > > > > On Tue, Jul 30, 2019 at 5:34 PM Benjamin Kaduk wrote: > >> > >> Cycling back on this, my reading of the archive suggests that we want an > >> -09 to include Daniel's suggested text to clarify on (1), and we need to > >> hear from Ben about (3). > >> > >> Does that sound right to everyone or am I missing something? > >> > >> Thanks, > >> > >> Ben > >> > >> On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: > >> > 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 --0000000000009b2166058ef8d40b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Logan. I believe we are all set except for IPR disc= losure from Ben.
Yours,=C2=A0
Daniel

On Wed, Jul 31, 20= 19 at 5:34 AM Loganaden Velvindron <loganaden@gmail.com> wrote:
On Wed, Jul 31, 2019 at 3:57 AM Daniel Migault
<daniel= .migault@ericsson.com> wrote:
>
> Hi,
>
> I believe that is all we need to do.
>

Please find the diff with the changes including fixing a mistake:
114-octet signature for ed448.

https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-curdle-ssh-ed25519-ed448-09

> Yours,
> Daniel
>
> On Tue, Jul 30, 2019 at 5:34 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>>
>> Cycling back on this, my reading of the archive suggests that we w= ant an
>> -09 to include Daniel's suggested text to clarify on (1), and = we need to
>> hear from Ben about (3).
>>
>> Does that sound right to everyone or am I missing something?
>>
>> Thanks,
>>
>> Ben
>>
>> On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: >> > On Thu, Jun 06, 2019 at 02:56:46PM +0000, Daniel Migault wrot= e:
>> > > 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
--0000000000009b2166058ef8d40b-- From nobody Wed Jul 31 16:19:27 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 607AA1200FF; Wed, 31 Jul 2019 16:19:25 -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 ZX_FURgbyWxI; Wed, 31 Jul 2019 16:19:22 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 9CE4F1200B5; Wed, 31 Jul 2019 16:19:22 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id j19so33556525otq.2; Wed, 31 Jul 2019 16:19:22 -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=norOYDFxH4s130tMUIr7lDyXoiLCe3qOkzQ6jahv2Cc=; b=aRJk05xLmiUCutD73Oq0+dBti5ljnqXREVAOcv4iJ+pBphgwtiaF2Sg27En9Uil9m4 QWx5gQxg7m5sXrfHPaAXfPXnjfu+S3i0AZVg0XwB7nvx/Wd6dGJmkKTBzKqSPgoaWMHp CI5MGZOpApbIP7i00epM9bvsvAr+5Had1C6AXvMIGydHbT2AM5TMHqbyOqey4Q9qJV6+ a7qJa22wPYtswa9Ed6eRqcpNITTWY9/nmae20RaOmDNwaPh+UEOVB/VSK+d6fJbHqBA8 Jq4rDdTaZzHwfcrDI9mOhIUUpPPDmT42sSmen7xzYa8aHlsuna1yHDyRys6NE0gzfC14 fvYw== 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=norOYDFxH4s130tMUIr7lDyXoiLCe3qOkzQ6jahv2Cc=; b=ZwGB8qdWaZvrZSK3dPLoYpqxE3tdxNMcMAKv2dXMsfwZB5nYY3YmTff4R3+J1BgyP0 QZZV/zhhu659Y+cCcoz1wsOLx6Tj9hofkyQKe78MatIdBuFlEDKPPPl26BpyJRV4kLaQ ALx0U0Vfrnv7ImlmYWiek1YBKDDeTqPKjmBmHg/hAshQo/OEXgHP+ZNBXefS0ajO7Pfu BvdsxMrAU0QNB6fk4r6VaGrFdwrh/spS1nQnzy9XHcREgcQ2CAAz4qI63Rku9IDlYNSX b0ning0a9z0/mCjCeEyVyp+QzdoJx85SqMez6SWZv+q/k26NckAWbTnVnDzMk20ysBWw Y2fw== X-Gm-Message-State: APjAAAUdbQgd8ThqwKEZoXRQPD5rickid4QxmXiRvpFRhgxyfjx+SsCr HS6lN5j/DMGSw2a+qtcLcjkH+q5ZoqKF+pobPJY= X-Google-Smtp-Source: APXvYqyLPDMCkZCLAXELj/UeMr+3ONJvOyHCNHl7aDocjhM6anvNVCx52vdl6fK1AvHeY7B+qdQ3dykBtNK9D9tbpPk= X-Received: by 2002:a05:6830:13d9:: with SMTP id e25mr62246444otq.197.1564615161938; Wed, 31 Jul 2019 16:19:21 -0700 (PDT) MIME-Version: 1.0 References: <20190604174029.GC8678@prolepsis.kaduk.org> <20190607222610.GH83686@kduck.mit.edu> <20190730213418.GQ47715@kduck.mit.edu> In-Reply-To: From: denis bider Date: Wed, 31 Jul 2019 18:19:10 -0500 Message-ID: To: Loganaden Velvindron Cc: Benjamin Kaduk , "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , Daniel Migault , "curdle@ietf.org" , bjh21@bjh21.me.uk Content-Type: multipart/alternative; boundary="000000000000f00711058f025aab" 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, 31 Jul 2019 23:19:26 -0000 --000000000000f00711058f025aab Content-Type: text/plain; charset="UTF-8" > I would suggest standards track given that ed25519 > is already public key is already implemented by OpenSSH. Just to confirm, there are other implementations too. For example, Ed25519 was introduced in Bitvise SSH Server and SSH Client in versions 7.21 (released end of 2016): https://www.bitvise.com/ssh-server-version-history-7 denis On Wed, Jul 31, 2019 at 1:34 AM Loganaden Velvindron wrote: > On Wed, Jul 31, 2019 at 1:34 AM Benjamin Kaduk wrote: > > > > Cycling back on this, my reading of the archive suggests that we want an > > -09 to include Daniel's suggested text to clarify on (1), and we need to > > hear from Ben about (3). > > > > Does that sound right to everyone or am I missing something? > > > I would suggest standards track given that ed25519 is already public key is > already implemented by OpenSSH. > > http://www.openssh.com/txt/release-6.5 > > > Thanks, > > > > Ben > > > > On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: > > > 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 < > daniel.migault@ericsson.com> 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 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 > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --000000000000f00711058f025aab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I would suggest standards track given t= hat ed25519
> is already public key is already implemented by OpenSSH.

Just to= confirm, there are other implementations too.

For= example, Ed25519 was introduced in Bitvise SSH Server and SSH Client in ve= rsions 7.21 (released end of 2016):


denis

On Wed, = Jul 31, 2019 at 1:34 AM Loganaden Velvindron <loganaden@gmail.com> wrote:
= On Wed, Jul 31, 2019 at 1:34 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> Cycling back on this, my reading of the archive suggests that we want = an
> -09 to include Daniel's suggested text to clarify on (1), and we n= eed to
> hear from Ben about (3).
>
> Does that sound right to everyone or am I missing something?
>
I would suggest standards track given that ed25519 is already public key is=
already implemented by OpenSSH.

http://www.openssh.com/txt/release-6.5

> Thanks,
>
> Ben
>
> On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote:
> > 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 mail= ing list.
> >
> > Ah, thank you.=C2=A0 Thanks also to Loganaden for the updates in = the -08, and
> > sorry for not having confirmed that they did address the opsdir r= eview
> > comment.
> >
> > > The SSHF Record includes the algorithm used for the public k= ey, 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=C2= =A0 seems to indicate some additional changes for example in the generation= of the finger print.=C2=A0 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-ed255= 19" keys is
> > >=C2=A0 =C2=A0 described in [RFC7479].
> > >
> > >=C2=A0 =C2=A0 The generation of SSHFP resource records for &q= uot;ssh-ed448" keys is
> > >=C2=A0 =C2=A0 described as follows.
> > >
> > >=C2=A0 =C2=A0 the SSHFP Resource Record for the Ed448 public = key with SHA-256
> > >=C2=A0 =C2=A0 fingerprint would be example be:
> > >
> > >=C2=A0 =C2=A0 example.com.=C2=A0 IN SSHFP TBD 2 ( a87f1b687ac0e5= 7d2a081a2f2826723
> > >=C2=A0 =C2=A0 34d90ed316d2b818ca9580ea384d924 01 )
> > >
> > >=C2=A0 =C2=A0 The 2 here indicates SHA-256 [RFC6594].
> > >
> > > NEW:
> > >
> > > The generation of SSHFP resource records for "ssh-ed255= 19" keys is
> > >=C2=A0 =C2=A0 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.=C2=A0 IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f282= 6723
> > > 34d90ed316d2b818ca9580ea384d924 01 )
> > >
> > > The 2 here indicates SHA-256 [RFC6594].
> > >
> > > From: Loganaden Velvindron <loganaden@gmail.com>
> > > Sent: Thursday, June 06, 2019 3:02 AM
> > > To: Daniel Migault <daniel.migault@ericsson.com>
> > > Cc: Benjamin Kaduk <kaduk@mit.edu>; draft-ietf-curdle-ssh-ed255= 19-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=3D--hwdiff&u= rl2=3Ddraft-ietf-curdle-ssh-ed25519-ed448-08.txt
> > >
> > > On Wed, Jun 5, 2019 at 5:52 PM Daniel Migault <daniel.migault@erics= son.com<mailto:daniel.migault@ericsson.com>> 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).<= br> > > > Yours,
> > > Daniel
> > >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>>
> > > Sent: Tuesday, June 04, 2019 1:41 PM
> > > To: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.= org<mailto:draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.o= rg>
> > > Cc: cur= dle@ietf.org<mailto:curdle@ietf.org>
> > > Subject: new AD review comments on draft-ietf-curdle-ssh-ed2= 5519-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 resour= ce records for "ssh-ed448" keys is described as follows." bu= t then give only an example and not a description of what to do.=C2=A0 We n= eed to say more about this procedure
> > >
> > > (2) I'm not sure if the chain on the opsdir review got f= ully resolved; see https://m= ailarchive.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 re= flect the discussions with the directorate reviewers about document status?= =C2=A0 I'm sure that some IESG members will ask "why not Informati= onal?" if we don't forestall them.
> > >
> > > <mglt>
> > > I have update the shepherd as follows:
> > >
> > > (1) What type of RFC is being requested (BCP, Proposed Stand= ard,
> > > Internet Standard, Informational, Experimental, or Historic)= ?=C2=A0 Why
> > > is this the proper type of RFC?=C2=A0 Is this type of RFC in= dicated in the
> > > title page header?
> > >
> > > The requested status is Standard Track. This is necessary fo= r
> > > inter-operability=C2=A0 and as such the Standard Track seems= the
> > > most appropriated status.
> > >
> > > The OPS Directorate wondered why version 07 was a Standard T= rack
> > > document and not an informational document as no normative 2= 119 words.
> > >
> > > The reason for being a standard track is that we expect the = implementation
> > > that implement SSH to follow these recommendations. The cons= ensus was
> > > to explicitly mention it in the document around the lines: > > >
> > > "Standard implementations of SSH SHOULD implement these= signature algorithms."
> > > </mglt>
> > > Thanks,
> > >
> > > Ben

_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--000000000000f00711058f025aab-- From nobody Wed Jul 31 16:38:50 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 DC4441200A1; Wed, 31 Jul 2019 16:38:48 -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 cMWR0rPbPQ-m; Wed, 31 Jul 2019 16:38:47 -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 4925F120043; Wed, 31 Jul 2019 16:38:47 -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 x6VNcgbc000310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 19:38:45 -0400 Date: Wed, 31 Jul 2019 18:38:42 -0500 From: Benjamin Kaduk To: Loganaden Velvindron Cc: draft-ietf-curdle-rc4-die-die-die.all@ietf.org, curdle Message-ID: <20190731233841.GO1006@kduck.mit.edu> References: <20190730212232.GP47715@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] second AD review of draft-ietf-curdle-rc4-die-die-die-15 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, 31 Jul 2019 23:38:49 -0000 On Wed, Jul 31, 2019 at 11:30:42AM +0400, Loganaden Velvindron wrote: > On Wed, Jul 31, 2019 at 1:22 AM Benjamin Kaduk wrote: > > > > Hi all, > > > > I'm just about ready to send this document into IESG Evaluation, but > > noticed a few nits while rereading it. Since they're in areas that I > > expect the IESG to be looking at, I'd like to have an updated revision of > > the document available before I send it out to the IESG as a whole: > > > > draft-ietf-curdle-des-des-des-die-die-die is now RFC 8429, so we can update > > that reference. > > > > Additionally, part of the holdup for that document was to decide whether to > > Obsolete RFC 4757 or move it to Historic, since we cannot do both. The > > Abstract of this document still says that it both Obsoletes and moves to > > Historic RFC 4345 (and it has the Obsoletes: header); since we decided in > > the RFC 8429 case to use "move to Historic", I think that's the right thing > > to do here as well. So we want to keep the "move to Historic" text but > > drop the in-document and metadata "Obsoletes:" relationship. > > (https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/ has > > some more background on the difference.) > > > > On the other hand, since we are updating RFC 4253, we do need to mention > > Updates: 4253 in document header. > > > > We can also update to use the RFC 8174 version of the BCP 14 boilerplate. > > > > Finally, the table in Section 3 seems to be formatted oddly, with the > > column break appearing in the middle of "Encryption Algorithm Name" instead > > of at the end of it. > > > > Thank you Benjami. > > I've sent in -16. See the diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rc4-die-die-die-16 Thanks; I'll be sending both of these documents to the IESG shortly! -Ben From nobody Wed Jul 31 21:28:06 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 6C24612013B for ; Wed, 31 Jul 2019 21:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net 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 JuwUmB1dNuGQ for ; Wed, 31 Jul 2019 21:28:02 -0700 (PDT) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 930FC120139 for ; Wed, 31 Jul 2019 21:28:02 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id k8so31563680plt.3 for ; Wed, 31 Jul 2019 21:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y3vV2oZMWmqWiODVJHK4dn+t91Bf0Ox22BOcEGCLoto=; b=d3HIbkYDK0yWzZcF8aeDnCW3wk5pwrkc5V3VdVkM3Op0l9KSB7TNqR71BICqE4tQGG wfhShhHxPFRUhevar2ppkFNDallyweh/7zjBslD7C54ihQSLC+2w8iP9jzu+c/4SJHak HjyPOBIRU4XAHZGdKndR5Ft6djd1zTIdBNFTw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y3vV2oZMWmqWiODVJHK4dn+t91Bf0Ox22BOcEGCLoto=; b=lcyN6IereGMtiy/XolxpTNxDpnyQ2sHjH6YTlJUmZus/6slEOAPV5DkVh35LVXUTKu 7++0XDDIczmH0QZ6HV51oCMPOfo1IW0JR+tJF0Ilm90709gbq/dm/L4qJP5sTE8jtim7 yQKB70zlbS3AxUCmnvIwRH9+9G7LjT29fDNH8hr/efdpF4Ee1iR+YFf8G+FQpHxNQmIu wH/SMTn8UDIb6D6oVUBY/25tO8V2NXy16doA8439ucQDxZewNPGtyxKPOdp4BBxDrAHy nb/ZkvUg1eNB96ha/AeU8aML3R3nDA/VjBoUQCdVnpeTJyqo8jK8LnAc9F3iPVGMubiK 4/ww== X-Gm-Message-State: APjAAAWXbarSgHAJ0y0SPvd9JpNvttqRJ/dERs/1npxfpGTl+Dqqqi0r hqWu3EPgoEdMGsKgDZ6ja9Y= X-Google-Smtp-Source: APXvYqyyRdreW7oIU5mkuMzw3Sd7sk7iTRvoRIBeyP82xQAGSAXMSGTC7KXDsb3b26oeTo0rypa64Q== X-Received: by 2002:a17:902:7887:: with SMTP id q7mr5756738pll.129.1564633681812; Wed, 31 Jul 2019 21:28:01 -0700 (PDT) Received: from connect.timeheart.net.0.4.a.f.8.1.4.2.0.3.3.0.6.2.ip6.arpa ([2603:3024:18fa:4000::2]) by smtp.gmail.com with ESMTPSA id x67sm74552432pfb.21.2019.07.31.21.28.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 21:28:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Ron Frederick In-Reply-To: Date: Wed, 31 Jul 2019 21:27:59 -0700 Cc: "draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org" , Daniel Migault , "curdle@ietf.org" , Benjamin Kaduk , bjh21@bjh21.me.uk Content-Transfer-Encoding: quoted-printable Message-Id: <7103DFAE-92F8-4727-8F8E-3CE33E18B540@timeheart.net> References: <20190604174029.GC8678@prolepsis.kaduk.org> <20190607222610.GH83686@kduck.mit.edu> <20190730213418.GQ47715@kduck.mit.edu> To: denis bider , Loganaden Velvindron X-Mailer: Apple Mail (2.3445.104.11) 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, 01 Aug 2019 04:28:06 -0000 On Jul 31, 2019, at 4:19 PM, denis bider = wrote: > > I would suggest standards track given that ed25519 > > is already public key is already implemented by OpenSSH. >=20 > Just to confirm, there are other implementations too. >=20 > For example, Ed25519 was introduced in Bitvise SSH Server and SSH = Client in versions 7.21 (released end of 2016): >=20 > https://www.bitvise.com/ssh-server-version-history-7 AsyncSSH also has implementations of both ssh-ed25519 (in version 1.0.0 = from April 2015) and ssh-ed448 (in version 1.16.0 from March 2019). See = https://asyncssh.readthedocs.io/en/latest/changes.html for details. I = tested the AsyncSSH ssh-ed448 support against the Erlang SSH library, = which supports both ssh-ed25519 and ssh-ed448. Other implementations of = ssh-ed25519 are listed at = https://ssh-comparison.quendi.de/comparison/hostkey.html. > On Wed, Jul 31, 2019 at 1:34 AM Loganaden Velvindron = wrote: > On Wed, Jul 31, 2019 at 1:34 AM Benjamin Kaduk wrote: > > > > Cycling back on this, my reading of the archive suggests that we = want an > > -09 to include Daniel's suggested text to clarify on (1), and we = need to > > hear from Ben about (3). > > > > Does that sound right to everyone or am I missing something? > > > I would suggest standards track given that ed25519 is already public = key is > already implemented by OpenSSH. >=20 > http://www.openssh.com/txt/release-6.5 >=20 > > Thanks, > > > > Ben > > > > On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote: > > > 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=3D--hwdiff&url2=3Ddraft-ietf-curdl= e-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 --=20 Ron Frederick ronf@timeheart.net