From nobody Mon Jul 3 06:41:55 2017 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 30C43131622; Mon, 3 Jul 2017 06:41:54 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149908931415.4101.1944080878925130516@ietfa.amsl.com> Date: Mon, 03 Jul 2017 06:41:54 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rc4-die-die-die-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 13:41:54 -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 of the IETF. Title : Deprecating RC4 in all IETF Protocols Author : Luis Camara Filename : draft-ietf-curdle-rc4-die-die-die-00.txt Pages : 13 Date : 2017-07-03 Abstract: RC4 is extremely weak as shown by RFC 6649 and RFC 7457, is prohibited in TLS by RFC 7465, is prohibited in Kerberos by RFC xxxx and it needs to be prohibited in all IETF protocols. Documents that provide technology that can only use RC4 are obsoleted by this document, so this document obsoletes and moves to Historic RFC 3078 "Microsoft Point-to-Point Encryption (MPPE) Protocol" (only supports RC4, RFC 3079 that is also part of that protocol is also obsoleted), RFC 4345 "Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol" (note Arcfour and RC4 are synonymous), RFC 4757 "The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows" (only supports RC4) and RFC 6229 "Test Vectors for the Stream Cipher RC4" (provides test vectors for historic cryptography). RFC 2118, RFC 3501, RFC 3961, RFC 4120, RFC 4253, RFC 6150, RFC 6649, RFC 6733, RFC 7457, RFC 7905 and RFC xxxx are updated to note the deprecation of RC4 in all IETF protocols. (Please do not confuse RFC 4757 with RFC 7457.) 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rc4-die-die-die-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 16:19:50 2017 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 44D5513172D; Mon, 3 Jul 2017 16:19:48 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912398826.16176.10478215253595868540@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:19:48 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 23:19:48 -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 of the IETF. Title : Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-05.txt Pages : 17 Date : 2017-07-03 Abstract: This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 22:12:07 2017 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 64F04127876; Mon, 3 Jul 2017 22:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 dPqs43nIF-UF; Mon, 3 Jul 2017 22:12:04 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEEE124D6C; Mon, 3 Jul 2017 22:12:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499145111; h=from:subject:to:date:message-id; bh=6bHIRI2h9vSe6vHE5MXhoCEbcNxY0aVhw4vypkaw+Vk=; b=N04nnwpylAxLZnRaxng/Tr7kdBgeM3ESWuVhDr5vLIQcFYOX6OnWVAeegBOqy+Pobn9+DqobunO msvSfbzcPUmUQM2NOQKPxErmglX5jPBy6bdDESZ61rsJNGM0dL7hZ2Ba0N2681qZU0PChnwWBV86R VNaYv/r7VhEEJ+2sLjAWuXFfHApp4mtuwhXUNObHTCATE/c49Eqp4++Jcp0/7QZasm7LW6RWj69Xa b8hNCOyRtmPVufUtU+VhKmplcElMUlgNHHSHTfiHMxqpm5t9OLI4KGzhvq/Kdub7KF2ntJFx9S/k/ Ix1L0D3P4hLa7sUEcTiTumdRhy2G96vymHag== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 3 Jul 2017 22:11:50 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 3 Jul 2017 22:11:47 -0700 From: Jim Schaad To: , CC: References: <149912398826.16176.10478215253595868540@ietfa.amsl.com> In-Reply-To: <149912398826.16176.10478215253595868540@ietfa.amsl.com> Date: Mon, 3 Jul 2017 22:11:52 -0700 Message-ID: <006b01d2f484$0dfcfdf0$29f6f9d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGPmIcxc03UZmGGNghHMcFo/h+BfaLJ1qtQ X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 05:12:06 -0000 I think that I have addressed the open issues from the AD review document EXCET for the following. Brian Smith wants to have a full test set at the end of the document. I do not believe that it is appropriate for this document and therefore have only included a couple of test that demonstrate errors. Jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, July 3, 2017 4:20 PM To: i-d-announce@ietf.org Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt 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 of the IETF. Title : Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-05.txt Pages : 17 Date : 2017-07-03 Abstract: This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-05 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/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Jul 4 07:46:16 2017 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 85D74131934; Tue, 4 Jul 2017 07:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 WXCWrFNWWWmD; Tue, 4 Jul 2017 07:46:14 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 EA9D813190C; Tue, 4 Jul 2017 07:46:13 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v64Efr3M019506; Tue, 4 Jul 2017 15:45:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=t6RRXSrZc/XDtTKTjENVqQc8j5uvf5QhHfjFiaZv4bk=; b=VS1CjiImwhvEuTSM849/K0RdLQrsPPjJaMsm80ycTIKbhqHKjXWc/x3GYXwo+MrSBqE8 +5ZsvJuTygxLhYsia/gaAJIla+1Nje8mGjors2WVbt7BxWu7Al4r050IucgEdb+Z9+AK xpao8yE8TYEK9Oqbf7qrMvdVYm5Sb3wdOKwqJfquOfxNEarnGVvpu81bcPn/xt59HsB8 wZhqRRzY83kP1ERwabnjA7KOZKOlSIJ6wVfgGuzjXkGNc8R9nf8sjwOA3crt9KPtobQC lCX5QCIdqJ8p/oH6sBPCH1y+D4mlQMLtBdSi9ZMkn8KCVTi6WZOmc/1DmlcwsbCmeDvn Fg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2be394dptd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Jul 2017 15:45:42 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v64EeeIE019541; Tue, 4 Jul 2017 10:45:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72u7c66-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 04 Jul 2017 10:45:40 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 4 Jul 2017 10:45:40 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 4 Jul 2017 10:45:40 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 4 Jul 2017 10:45:39 -0400 From: "Salz, Rich" To: Jim Schaad , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt Thread-Index: AQHS9FLfVRGZHuhgPEe/AXyTC5D9N6JDYoAAgABdJyA= Date: Tue, 4 Jul 2017 14:45:39 +0000 Message-ID: <600eb1cae49c4993a11d477c2036ef2e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149912398826.16176.10478215253595868540@ietfa.amsl.com> <006b01d2f484$0dfcfdf0$29f6f9d0$@augustcellars.com> In-Reply-To: <006b01d2f484$0dfcfdf0$29f6f9d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.178] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707040252 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707040253 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:46:16 -0000 > Brian Smith wants to have a full test set at the end of the document. I = do not > believe that it is appropriate for this document and therefore have only > included a couple of test that demonstrate errors. Is there anyone else in the WG who shares Brian's opinion? From nobody Tue Jul 4 08:32:41 2017 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 B430D132098; Tue, 4 Jul 2017 08:32:40 -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, FREEMAIL_FROM=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 jmCukMg30PlM; Tue, 4 Jul 2017 08:32:39 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 A8BD913195C; Tue, 4 Jul 2017 08:32:38 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id j85so27055479wmj.0; Tue, 04 Jul 2017 08:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eLqWuyWJu7XBooU1wf8BZ1qVssKB3LNCMdcRvn4K2mA=; b=ZBA34jTpMPrsccGZQa1HG3kFjiACnY5cUqGQw3G7bkeF8hebWF3kTzW2nvc9QQwv30 QH0xzD2IT5Z2ztM0UtfONmOHmu4Mzc0hp0v1ziYB3iSHGIREjjhak20KJYNIeVS4LL8+ 56tcClDMjt+Jw3RrMK9z4uqo2p7bftZWa3A2FQr65pwP9hIF0ycidwCd5Dyemz8jxkY2 5sGb/gbCpc3OAkyDnGyjJqbqN7hCGYBA2yqajENkol168ogNe3iU+c0lmYp0V4hlrYwD jFqmewTa9O9Vv5IX85stSkAs9khdcBPQ4Zhdne09n87doWpNtuyo+gvbF9/TuHgGrwWb tAig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eLqWuyWJu7XBooU1wf8BZ1qVssKB3LNCMdcRvn4K2mA=; b=hYzQ+hTWoERxckhULJn4vasunevNeCEdUzs41oAd7k8qWIIEqIDgY8m4TvdNJ6FjB/ hPjVc5HXVV5rwGZeq2sOwv9AxXm+/rr5qImpH/BB4LKvyIbEIOgBPdI2F6epia7zIJ9Q UD/s1+Mz3kA0nNv7kro9jUevKnNGMqy5DWn25NLICHABjwLpWD6albaX62n/hbtFUHjp RJp5zXNhhHW1HKmyWExfkAdI2Z2CX/i2endqWNX/iyMUpFKsZn8BGVPPjFxb/OMlnJke wGuxZVbe3rM7zrNvx8BGzKVqXw1wglt4J1YQ3UPxHdR5tkCx/hYMQbvQ5bCEnEqfTyuM MehA== X-Gm-Message-State: AKS2vOzn2wkzcQ+TN9vnwK30RaCCWb076IL6OkkO6f8+Ao+mhkBD9hRs TN5eZyaEInf7Zg== X-Received: by 10.80.134.141 with SMTP id r13mr19121340eda.77.1499182357250; Tue, 04 Jul 2017 08:32:37 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 2sm23728554edt.36.2017.07.04.08.32.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 08:32:36 -0700 (PDT) From: Yoav Nir Message-Id: <52B36760-2973-4781-A677-F273DC0F28D7@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_38B1A65D-FF68-4D7E-AD58-DC3FF4BC8136"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 4 Jul 2017 18:32:33 +0300 In-Reply-To: <600eb1cae49c4993a11d477c2036ef2e@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: Jim Schaad , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" , "curdle@ietf.org" To: Rich Salz References: <149912398826.16176.10478215253595868540@ietfa.amsl.com> <006b01d2f484$0dfcfdf0$29f6f9d0$@augustcellars.com> <600eb1cae49c4993a11d477c2036ef2e@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 15:32:41 -0000 --Apple-Mail=_38B1A65D-FF68-4D7E-AD58-DC3FF4BC8136 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Jul 2017, at 17:45, Salz, Rich wrote: >=20 >> Brian Smith wants to have a full test set at the end of the document. = I do not >> believe that it is appropriate for this document and therefore have = only >> included a couple of test that demonstrate errors. >=20 > Is there anyone else in the WG who shares Brian's opinion? IMO the examples in section 10 are sufficient. A full test is = appropriate the an algorithm RFC such as 8032 (for EdDSA) and 7748 (for = Curve25519 and Curve448) RFC 8032 has a good set of test vectors. RFC 7748 has a rather small = set, but even if it=E2=80=99s not enough, I don=E2=80=99t think a PKIX = update is the place to fix it. Yoav --Apple-Mail=_38B1A65D-FF68-4D7E-AD58-DC3FF4BC8136 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZW7USAAoJELhJCxUKWMyZp6UH/RzTeytfA/N1APBt0BwfjTIl Adqyt7ofCC21p0bMKmq1FoztfSkcSA0nL4sJ5Nwyt2FPRQNXEPPwJ7FMJ4G1eNrv 3slEZm0zw5C9MBTkxrloaUVOPKGKj3OIvCMtgK0V6FKYzjCuS633OFCHyoNPPHxr IqgWo8WiJvgNxCuugYUfn5ochBF6TBtfcnz5Zas2XH+y/vtfqkkaIdJIyB8DNxR6 ZPoefDhGR6pWxgHfoMM4sInGbyZvjFDcmdLpVAW3ey6K0ZCA+Gf+g8/m4UrNanPq JiRftfe1gHv2ooQOIPzlTb0c+Z0WhhD/3xLeNlEbTJW4M5soljDQllJ0rYNXME8= =kVha -----END PGP SIGNATURE----- --Apple-Mail=_38B1A65D-FF68-4D7E-AD58-DC3FF4BC8136-- From nobody Thu Jul 6 09:01:56 2017 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 7D206131630; Thu, 6 Jul 2017 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 GLuypDPaTwGA; Thu, 6 Jul 2017 09:01:53 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 8D0DB12EBFE; Thu, 6 Jul 2017 09:01:52 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id h22so6699089lfk.3; Thu, 06 Jul 2017 09:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uwpUJYZNlL9l/SHA8riXNBcIUHUtst5Sm1coraIHTgA=; b=EdqDeqT25FbhyM8KyTDDO8kVbfUIdR92hq4rMHtTWsiuoC9utHryGqQ6lVLzgqzx+0 j+XEC8672QPFnXt3yc/BSzaD/+lB5dHrrsIUjR3Btu6JEHtb13dZyOHSY3bvuGnsxCnH Qdnxcb1KyDIkHMl+hFSNsQfnts2CC0J0msOpj/b0Md3wIR+cL3ac/wgBVfRrgLJAgzNg s6FnCW3pi3yv/Iv9DxP8/15rK43fsRt4GyJd6qHNL76F92VuO+pZCRudb2wArWihEzRt T0LjAvUE/lWX6nyYC1DdwJ+Juk9ycse3/uIE/YQALyuvza69/yOIsF0vKq7Hr+tta8F/ 24/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uwpUJYZNlL9l/SHA8riXNBcIUHUtst5Sm1coraIHTgA=; b=NhdJfnWlJ/F8VZMi1TtAMMcEPywgswLpzyLLHQBF+uVWIobQTlG8F/euIF2MLL53wJ 6s+0VUQH/Gw7zV2neLnpc/mVbumj0Yad+DZO1oC+twCO/NGQ9NA//rHS2fepjTM1ZJjC 7gihXEZpAIAa+aP1vtvOFiz81mxijtWuuxv4z9WrALniDwxTHPLIWcc+6n415mL+MUUK QEtZ7OvwS3nY8P8jUiKnRYo4GAdjHucGILrhjUZaAS6YHZB3nx8p3U+fdtJGTxuBc6OV SwKAqTmWEysdABeFuUldlkyc38nOSbyWOyFq0g7LIwDj+GNa4p4CJItbwv5dkeWEFSUA sqow== X-Gm-Message-State: AKS2vOw7sDzkmU6VCGdqDDwuSCMf0vZtQlGTr6OpWZ66G0kQyCpSJtHq V9fSz4WQwUq4Gu0m0Cx35T2qXJP+bg== X-Received: by 10.46.22.5 with SMTP id w5mr14244174ljd.26.1499356910766; Thu, 06 Jul 2017 09:01:50 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.5.20 with HTTP; Thu, 6 Jul 2017 09:01:49 -0700 (PDT) In-Reply-To: <20170626021135.GF17840@kduck.kaduk.org> References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> <20170626021135.GF17840@kduck.kaduk.org> From: Daniel Migault Date: Thu, 6 Jul 2017 12:01:49 -0400 X-Google-Sender-Auth: E2b5Z0emWnIB45XGF_HeUQvh4SM Message-ID: To: Benjamin Kaduk Cc: Martin Rex , jaltman@secure-endpoints.com, kitten@ietf.org, curdle Content-Type: multipart/alternative; boundary="f403045fbada0ed3e90553a83c36" Archived-At: Subject: Re: [Curdle] [kitten] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:01:55 -0000 --f403045fbada0ed3e90553a83c36 Content-Type: text/plain; charset="UTF-8" Hi, Thank you for the discussion. It seems that overall the current draft has a reached consensus. Are we ready to move the draft forward or do we need any additional discussions ? If you think more discussion is needed please let us know as soon as possible. Unless concerns are raised, I am planning to set the shepherd write up early next week. Regards, Daniel On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk wrote: > Hi Martin, > > On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote: > > Benjamin Kaduk wrote: > > > > > > It sounds like you are asking for the addition of some text along > > > the lines of: > > > > > > Software support is only a bare minimum requirement for deprecating > > > RC4 enctypes; there may be additional logistical considerations > > > involved such as provisioning AES keys for all principals and > > > updating software configuration to enable AES and disable deprecated > > > encryption types. > > > > > > Is that something you are asking for? > > > > Yes, thank your. This sounds good to me. I consider it even more > > helpful than the reference to particular versions of particular > > OpenSource Kerberos implementations, because this is a characteristic > > that is sort-of implied by how kerberos-enctypes keys are created > > (derived by string2key) and probably affect all implementations of > > Kerberos, yet it is non-obvious to consumers of the technology. > > Thank you for clarifying your comment into a request. > > > > > There is a substantial difference between cipher suites in TLS, where > > key length, strength and algorithm for the symmetric crypto is mostly > > irrelevant to the (PKI) credentials, and where using new TLS cipher > suites > > and deprecating old TLS cipher suites does not have a rekeying > requirement. > > To some extent this is inherent in Kerberos's use of symmetric crypto for > authentication, as opposed to TLS which uses asymmetric crypto for > authentication and switches to symmetric crypto for efficiency for > bulk data transfer. > > > (Jeffrey Altman wrote:) > % In my opinion, such text is inappropriate for an RFC. The deprecation > % of the encryption type is a protocol action. The RFC is not guidance > % for system administrators. Such guidance should come from the protocol > % implementations. > % > % As such I believe the addition of text similar to the above is > % unnecessary for publication. > > > > > I do believe that it is very appropriate to provide such kind of a > > guidance in an RFC, so that it this recommendation for deprecation > > becomes more comprehensible and the trade-offs clearer to mere consumers > > of the Kerberos technology, readers that aren't Kerberos protocol experts > > and senior Kerberos implementers. > > In general I tend to hew more to Jeffrey's track that protocol > specifications > should limit themseles to protocol-level work. I could see some grounds > for an exception here, though, in that the deployment difficulties are > inherent to any Kerberos deployment that follows best practice of not > storing > user passwords (only derived keys). > > Given Jeffrey's reasoning, I do not think my above "proposed text" > (to get clarification from Martin) should be used as-is; if we do want > to provide the clarification that Martin wants, I would want to rephrase > things somewhat. But, it still seems unclear where the WG consensus lies > on the question of including any guidance at all, here. Can others > please weigh in? > > > > When making admins sufficiently aware of predictable interop-problems, > > we may actually see more administrative deprecation of weak Kerberos > > enctypes than leaving them in the dark, and it helps reducing the amount > > of stumped users, helpdesks and admins. > > Admins are more likely to read software-provided documentation than > protocol specs; this argument seems speculative to me. > > -Ben > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045fbada0ed3e90553a83c36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for the discussion. It see= ms that overall the current draft has a reached consensus. Are we ready to = move the draft forward or do we need any additional discussions ? If you th= ink more discussion is needed please let us know as soon as possible. Unles= s concerns are raised, I am planning to set=C2=A0 the shepherd write up ear= ly next week.

Regards,
Daniel

On Sun, Jun 25, 2017 at 10:11 = PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Martin,

On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote:
> Benjamin Kaduk wrote:
> >
> > It sounds like you are asking for the add= ition of some text along
> > the lines of:
> >
> >=C2=A0 =C2=A0Software support is only a bare minimum requirement f= or deprecating
> >=C2=A0 =C2=A0RC4 enctypes; there may be additional logistical cons= iderations
> >=C2=A0 =C2=A0involved such as provisioning AES keys for all princi= pals and
> >=C2=A0 =C2=A0updating software configuration to enable AES and dis= able deprecated
> >=C2=A0 =C2=A0encryption types.
> >
> > Is that something you are asking for?
>
> Yes, thank your.=C2=A0 This sounds good to me.=C2=A0 I consider it eve= n more
> helpful than the reference to particular versions of particular
> OpenSource Kerberos implementations, because this is a characteristic<= br> > that is sort-of implied by how kerberos-enctypes keys are created
> (derived by string2key) and probably affect all implementations of
> Kerberos, yet it is non-obvious to consumers of the technology.

Thank you for clarifying your comment into a request.

>
> There is a substantial difference between cipher suites in TLS, where<= br> > key length, strength and algorithm for the symmetric crypto is mostly<= br> > irrelevant to the (PKI) credentials, and where using new TLS cipher su= ites
> and deprecating old TLS cipher suites does not have a rekeying require= ment.

To some extent this is inherent in Kerberos's use of symmetric c= rypto for
authentication, as opposed to TLS which uses asymmetric crypto for
authentication and switches to symmetric crypto for efficiency for
bulk data transfer.


(Jeffrey Altman wrote:)
% In my opinion, such text is inappropriate for an RFC.=C2=A0 The deprecati= on
% of the encryption type is a protocol action.=C2=A0 The RFC is not guidanc= e
% for system administrators.=C2=A0 Such guidance should come from the proto= col
% implementations.
%
% As such I believe the addition of text similar to the above is
% unnecessary for publication.

>
> I do believe that it is very appropriate to provide such kind of a
> guidance in an RFC, so that it this recommendation for deprecation
> becomes more comprehensible and the trade-offs clearer to mere consume= rs
> of the Kerberos technology, readers that aren't Kerberos protocol = experts
> and senior Kerberos implementers.

In general I tend to hew more to Jeffrey's track that protocol s= pecifications
should limit themseles to protocol-level work.=C2=A0 I could see some groun= ds
for an exception here, though, in that the deployment difficulties are
inherent to any Kerberos deployment that follows best practice of not stori= ng
user passwords (only derived keys).

Given Jeffrey's reasoning, I do not think my above "proposed text&= quot;
(to get clarification from Martin) should be used as-is; if we do want
to provide the clarification that Martin wants, I would want to rephrase things somewhat.=C2=A0 But, it still seems unclear where the WG consensus l= ies
on the question of including any guidance at all, here.=C2=A0 Can others please weigh in?


> When making admins sufficiently aware of predictable interop-problems,=
> we may actually see more administrative deprecation of weak Kerberos > enctypes than leaving them in the dark, and it helps reducing the amou= nt
> of stumped users, helpdesks and admins.

Admins are more likely to read software-provided documentation than<= br> protocol specs; this argument seems speculative to me.

-Ben

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--f403045fbada0ed3e90553a83c36-- From nobody Thu Jul 6 12:34:08 2017 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 0616113187D for ; Thu, 6 Jul 2017 12:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kkKRsfz57Vxl for ; Thu, 6 Jul 2017 12:34:04 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 D9333131442 for ; Thu, 6 Jul 2017 12:34:03 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id h22so10342045lfk.3 for ; Thu, 06 Jul 2017 12:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=2pJng4eLs/ctCbM+OJqHn7r8TV6Nto4LyoRQCH+KK44=; b=EznIqDn4sx1HSHmvIfwUNQZk5kjF3W6gATZVdVjmmOfswTWRClwk7InvAuKAyqXjHe WcGlo6K1hg1kBsqrTKICt+DVudRols3Ou1lFbeMY17+2zdbtXukjQCeRDXicVpcKng4k U7ro3QLm7/xzsUFIhBD5v54+wpXDeX6kZwfluS9qva1iIiR+uz7CHWVxTUC8Ulyx3++w dQlezgQjYjFxzQA8xNuGX6RY4HARXRAerAcL190j2YZVUPUd2xKiWlqi1OhmHQnoWSrV PtXfIrhusmMIaGCRdoO2QTGNuaviVvlo01C8ZfsrDs4eVmTrQYUBA8q/N6tkoTzwE78M Hvkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=2pJng4eLs/ctCbM+OJqHn7r8TV6Nto4LyoRQCH+KK44=; b=mmzUv30sJ8FRtxlA8o1wY7mLzOWFRJlSEusBy0reu035mYr1HZc0zKFNTyyiKL5ugq ujS6wtbeyxq5tj5K3d+d6J9MKaWxz58PCC3ZSESO0ccRdmSFlgu5lM+fgFoS5WHJo1GD CCcXNqn+Ko4Hdqk4kmGWMv8z8aDHnT+dn65rHSgH2laGwgkLATzq9KzoYIQpu9EICtrO siXotcCjDEQdqPo4UtJv0zDnvn9ktBQrUIK6CgLRuUuAnJGYWSGwI+/EDWFwnih5HahT A3aXo1mFItCGHajP7nmRQ0s7y2EhZrvoUCYWFZpTvn13VGFPdsuHkpi3s7oUq/gedo6+ utuQ== X-Gm-Message-State: AIVw111q5mz2WoOo3ZUHOw7LxKXvu6quLtRX5i2QW1OQx4zW9twTp+5P 1Gu+Gh8kaEo+D+BnVhZkzUoEU2Kq8JbZ X-Received: by 10.46.87.76 with SMTP id r12mr2729990ljd.128.1499369641941; Thu, 06 Jul 2017 12:34:01 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.5.20 with HTTP; Thu, 6 Jul 2017 12:34:01 -0700 (PDT) In-Reply-To: <149811737863.30580.17844240860986769225@ietfa.amsl.com> References: <149811737863.30580.17844240860986769225@ietfa.amsl.com> From: Daniel Migault Date: Thu, 6 Jul 2017 15:34:01 -0400 X-Google-Sender-Auth: 0cM5amE2o9RnR723SdEpnUQUmjQ Message-ID: To: curdle Content-Type: multipart/alternative; boundary="f403045f88bce520990553ab3280" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-04.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 19:34:07 -0000 --f403045f88bce520990553ab3280 Content-Type: text/plain; charset="UTF-8" Hi, The current draft seems to have reached consensus. I am willing to move it forward early next week, if you have any concerns please let us know. Yours, Daniel I only have a minor editorial comment OLD [RFC4419] specifies a recommended minimum size of 1024 bits for k, which is the modulus length of the DH Group. It also suggests that in all cases, the size of the group needs be at least 1024 bits.This document updates as described below: section 3 Paragraph 9: Servers and clients SHOULD support groups with a modulus length of k bits where 2048 <= k <= 8192. The recommended minimum values for min and max are 2048 and 8192, respectively. This document also updates Section 3 Paragraph 11 as follows: In all cases, the size of the group SHOULD be at least 2048 bits. NEW [RFC4419] specifies a recommended minimum size of 1024 bits for k, which is the modulus length of the DH Group. It also suggests that in all cases, the size of the group needs be at least 1024 bits.This document updates as described below: section 3 Paragraph 9: Servers and clients SHOULD support groups with a modulus length of k bits where 2048 <= k <= 8192. The recommended minimum values for min and max are 2048 and 8192, respectively. Section 3 Paragraph 11: In all cases, the size of the group SHOULD be at least 2048 bits. On Thu, Jun 22, 2017 at 3:42 AM, wrote: > > 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 of the IETF. > > Title : Increase SSH minimum recommended DH modulus size > to 2048 bits > Authors : Loganaden Velvindron > Mark D. Baushke > Filename : draft-ietf-curdle-ssh-dh-group-exchange-04.txt > Pages : 4 > Date : 2017-06-22 > > Abstract: > The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) > Transport layer Protocol specifies that servers and clients should > support groups with a modulus length of k bits, where the recommended > minumum value is 1024 bits. Recent security research has shown that > a minimum value of 1024 bits is insufficient against state-sponsored > actors. As such, this document formally updates the specification > such that the minimum recommended value for k is 2048 bits and the > group size is 2048 bits at minimum. This RFC updates RFC4419 which > allowed for DH moduli less than 2048 bits. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-04 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle- > ssh-dh-group-exchange-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-dh- > group-exchange-04 > > > 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/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045f88bce520990553ab3280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The current draft seems to hav= e reached consensus. I am willing to move it forward early next week, if yo= u have any concerns please let us know.

Yours,
Daniel

I only have a minor editorial comment

OLD=
=C2=A0=C2=A0=C2=A0 <t>
[RFC4419] specifies
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 a recommended minimum size of 1024 bits for k,
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 which is the modulus length of the DH Group.=C2=A0 It= also suggests that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in all cases, the siz= e of the group needs be at least 1024 bits.This
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 document updates=C2=A0 <xref target=3D"RFC4419"/> as= described below:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 section 3 Paragraph 9:= Servers and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clients SHOULD support= groups with a modulus length of k
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = bits where 2048 &lt;&#61; k &lt;&#61; 8192.=C2=A0 The recom= mended
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 minimum values for min and m= ax are 2048 and 8192,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 respectively.= =C2=A0 This document also updates <xref target=3D"RFC4419"/>= ; Section 3
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Paragraph 11 as follows= : In all cases, the size of the group SHOULD be
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 at least 2048 bits.
=C2=A0=C2=A0=C2=A0=C2=A0 </t>
= =C2=A0=C2=A0=C2=A0 =C2=A0

NEW
=C2=A0=C2=A0=C2=A0 <t>
[RF= C4419] specifies
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a recommended minimum s= ize of 1024 bits for k,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 which is the modu= lus length of the DH Group.=C2=A0 It also suggests that
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 in all cases, the size of the group needs be at least 1024 = bits.This
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document updates=C2=A0 <xref= target=3D"RFC4419"/> as described below:

=C2=A0=C2=A0= =C2=A0 =C2=A0 <list style=3D"symbols">
=C2=A0=C2=A0=C2= =A0 =C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <t>section 3 Paragraph = 9: Servers and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clients SHOULD suppo= rt groups with a modulus length of k
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 bits where 2048 &lt;&#61; k &lt;&#61; 8192.=C2=A0 The r= ecommended
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 minimum values for min a= nd max are 2048 and 8192,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 respectiv= ely.</t>

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 <t> Section 3=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Paragraph 11: In all cases, the size= of the group SHOULD be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at least 20= 48 bits. </t>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 </list>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 </t>
=C2=A0=C2=A0=C2=A0 =C2=A0

On Thu= , Jun 22, 2017 at 3:42 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the CURves, Deprecating and a Little more Encr= yption of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Increase SSH minimum recommended DH modulus size to 2048 bits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Loga= naden Velvindron
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Mark D. Baushke
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-curdle-ssh-dh-group-exchange-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-22

Abstract:
=C2=A0 =C2=A0The Diffie-Hellman (DH) Group Exchange for the Secure Shell (S= SH)
=C2=A0 =C2=A0Transport layer Protocol specifies that servers and clients sh= ould
=C2=A0 =C2=A0support groups with a modulus length of k bits, where the reco= mmended
=C2=A0 =C2=A0minumum value is 1024 bits.=C2=A0 Recent security research has= shown that
=C2=A0 =C2=A0a minimum value of 1024 bits is insufficient against state-spo= nsored
=C2=A0 =C2=A0actors.=C2=A0 As such, this document formally updates the spec= ification
=C2=A0 =C2=A0such that the minimum recommended value for k is 2048 bits and= the
=C2=A0 =C2=A0group size is 2048 bits at minimum.=C2=A0 This RFC updates RFC= 4419 which
=C2=A0 =C2=A0allowed for DH moduli less than 2048 bits.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.or= g/doc/draft-ietf-curdle-ssh-dh-group-exchange/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-04
https://datatracker.= ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchange-04<= br>
A diff from the previous version is available at:
https://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-curdle-ssh-dh-group-exchange-04


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--f403045f88bce520990553ab3280-- From nobody Fri Jul 7 06:01:58 2017 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 29935120721 for ; Fri, 7 Jul 2017 06:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.20150623.gappssmtp.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 P_QGyHVJ129E for ; Fri, 7 Jul 2017 06:01:54 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 C122D1201F8 for ; Fri, 7 Jul 2017 06:01:54 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id 191so26816964oii.2 for ; Fri, 07 Jul 2017 06:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NfNjkBKge9F6gGEFP47VCfh6SidN8GMXM/q0kCHpK0Q=; b=uyWi7wBrLOw3MfX1ic2Io+3BhbLb3SyJ6vJxCO1noTASJ3shX9woEkz7HgRZAVZwh4 b8AEu8x0FS+H7VDziW2qIbFV7bTOVbQgjXSmgNbmXBanBqqOxKtd0J1YGuk0uDc8HuIR RuCo9WGau9cAW0d+zjCAA65Y/RlXr9PoVp3L5q5Gk0ezCmMKq/av+4zvnYgZIEe/DBhl ijXNUgd6FmWiWkmzUbfrCnD1DPe8rgNON0Ew22sKVnLzX5n8mYqv0ZkyXV4NK+FX+BJp HLjB/1qXDhBAiWhoKdFokx0Tn0iJqDDaPBy8aNrDAou5FvzL3RILRdjFFRPLYjwmqtiY 1Apw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NfNjkBKge9F6gGEFP47VCfh6SidN8GMXM/q0kCHpK0Q=; b=BsEalCKF74bi3cU+IpsECz1bgBjcV/adaAkppA6HsP1rXyrozUJdtYeLLfhGewnTfc QymfZXKG7SA0GUCNK/ol37oTJr6LunH702bgQPzDACMiAXgOsBBFnInVuqHTlnV3m8/Y hEDSPcWJjkhecfoMv6fMKtjFxeOe7CJSW3gig5tPuyrteGq7YM4AfWLnPDtB8xaP9cEH P5Fp4nE18T3tubML1xRI9dSo1qM8U1s2DJjOUIXjmdL0GQ+FrmMCCE6jZ76o0fyPkBwc NH9iLuyK0JjyAfQuAUkUbX8fkerzFCR5Xo5We+BAX31j9n+P61uj5leexyK3u/WTZI3E 6TfQ== X-Gm-Message-State: AIVw110pn1r9c9PSM+wIpYxpO4NcxDpnAMas7MQPqOW6AgN9OSBYAA6K 7TUcyOlSaqcD/BjTUmiaGeqIEPF8JVV+ X-Received: by 10.202.83.143 with SMTP id h137mr651151oib.77.1499432513974; Fri, 07 Jul 2017 06:01:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.115.2 with HTTP; Fri, 7 Jul 2017 06:01:51 -0700 (PDT) In-Reply-To: References: <149811737863.30580.17844240860986769225@ietfa.amsl.com> From: Loganaden Velvindron Date: Fri, 7 Jul 2017 17:01:51 +0400 Message-ID: To: Daniel Migault Cc: curdle Content-Type: multipart/mixed; boundary="001a1147c00e5c6f8c0553b9d699" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-04.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:01:57 -0000 --001a1147c00e5c6f8c0553b9d699 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 6, 2017 at 11:34 PM, Daniel Migault wrote: > Hi, > > The current draft seems to have reached consensus. I am willing to move it > forward early next week, if you have any concerns please let us know. > > Yours, > Daniel > > I only have a minor editorial comment > > OLD > > [RFC4419] specifies > a recommended minimum size of 1024 bits for k, > which is the modulus length of the DH Group. It also suggests that > in all cases, the size of the group needs be at least 1024 bits.This > document updates as described below: > section 3 Paragraph 9: Servers and > clients SHOULD support groups with a modulus length of k > bits where 2048 <= k <= 8192. The recommended > minimum values for min and max are 2048 and 8192, > respectively. This document also updates > Section 3 > Paragraph 11 as follows: In all cases, the size of the group SHOULD > be > at least 2048 bits. > > > > NEW > > [RFC4419] specifies > a recommended minimum size of 1024 bits for k, > which is the modulus length of the DH Group. It also suggests that > in all cases, the size of the group needs be at least 1024 bits.This > document updates as described below: > > > > section 3 Paragraph 9: Servers and > clients SHOULD support groups with a modulus length of k > bits where 2048 <= k <= 8192. The recommended > minimum values for min and max are 2048 and 8192, > respectively. > > Section 3 > Paragraph 11: In all cases, the size of the group SHOULD be > at least 2048 bits. > > > > Dear Daniel, I have made the modifications, as requested, but I cannot upload it as it will be unlocked after the 16th. Meanwhile, I have attached it. --001a1147c00e5c6f8c0553b9d699 Content-Type: text/xml; charset="ISO-8859-1"; name="draft-ietf-curdle-ssh-dh-group-exchange-05.xml" Content-Disposition: attachment; filename="draft-ietf-curdle-ssh-dh-group-exchange-05.xml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j4tvd4tq0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pg0KPCFET0NUWVBFIHJm YyBTWVNURU0gInJmYzI2MjkuZHRkIiBbDQoNCjwhRU5USVRZIFJGQzIxMTkgU1lTVEVNICJodHRw Oi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjIxMTku eG1sIj4NCjwhRU5USVRZIFJGQzQ0MTkgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9w dWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjQ0MTkueG1sIj4NCl0+DQo8P3htbC1zdHls ZXNoZWV0IHR5cGU9J3RleHQveHNsJyBocmVmPSdyZmMyNjI5LnhzbHQnID8+DQo8P3JmYyBzdHJp Y3Q9InllcyIgPz4NCjw/cmZjIHRvYz0ibm8iPz4NCjw/cmZjIHRvY2RlcHRoPSI0Ij8+DQo8P3Jm YyBzeW1yZWZzPSJ5ZXMiPz4NCjw/cmZjIHNvcnRyZWZzPSJ5ZXMiID8+DQo8P3JmYyBjb21wYWN0 PSJ5ZXMiID8+DQo8P3JmYyBzdWJjb21wYWN0PSJubyIgPz4NCjxyZmMgY2F0ZWdvcnk9InN0ZCIN CiAgICAgZG9jTmFtZT0iZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLWRoLWdyb3VwLWV4Y2hhbmdlLTA1 Ig0KICAgICB1cGRhdGVzPSI0NDE5Ig0KICAgICBpcHI9InByZTUzNzhUcnVzdDIwMDkwMiI+DQoN CiA8ZnJvbnQ+DQoNCiAgIDx0aXRsZSBhYmJyZXY9IlJlY29tbWVuZGVkIG1pbmltdW0gbW9kdWx1 cyBzaXplIj4NCiAgICAgSW5jcmVhc2UgU1NIIG1pbmltdW0gcmVjb21tZW5kZWQgREggbW9kdWx1 cyBzaXplIHRvIDIwNDggYml0cw0KICAgPC90aXRsZT4NCg0KICAgPGF1dGhvciBmdWxsbmFtZT0i TG9nYW5hZGVuIFZlbHZpbmRyb24iIGluaXRpYWxzPSJMLlYuIg0KICAgICAgICAgICBzdXJuYW1l PSJWZWx2aW5kcm9uIj4NCiAgICAgPG9yZ2FuaXphdGlvbj5IYWNrZXJzLm11IDwvb3JnYW5pemF0 aW9uPg0KICAgICA8YWRkcmVzcz4NCiAgICAgICA8cG9zdGFsPg0KICAgICAgICAgPHN0cmVldD44 OCwgQXZlbnVlIERlIFBsZXZpdHo8L3N0cmVldD4NCiAgICAgICAgIDxjaXR5PlJvY2hlcyBCcnVu ZXM8L2NpdHk+DQogICAgICAgICA8cmVnaW9uPjwvcmVnaW9uPg0KICAgICAgICAgPGNvZGU+PC9j b2RlPg0KICAgICAgICAgPGNvdW50cnk+TVU8L2NvdW50cnk+DQogICAgICAgPC9wb3N0YWw+DQog ICAgICAgPHBob25lPisyMzAgNTk3NjI4MTc8L3Bob25lPg0KICAgICAgIDxlbWFpbD5sb2dhbkBo YWNrZXJzLm11PC9lbWFpbD4NCiAgICAgPC9hZGRyZXNzPg0KICAgPC9hdXRob3I+DQogICA8YXV0 aG9yIGluaXRpYWxzPSJNLiBELiIgc3VybmFtZT0iQmF1c2hrZSIgZnVsbG5hbWU9Ik1hcmsgRC4g QmF1c2hrZSI+DQogICAgIDxvcmdhbml6YXRpb24+SnVuaXBlciBOZXR3b3JrcywgSW5jLjwvb3Jn YW5pemF0aW9uPg0KICAgICA8YWRkcmVzcz4NCiAgICAgICA8ZW1haWw+bWRiQGp1bmlwZXIubmV0 PC9lbWFpbD4NCiAgICAgPC9hZGRyZXNzPg0KICAgPC9hdXRob3I+DQoNCiAgIDxkYXRlIHllYXI9 IjIwMTciIC8+DQoNCiAgIDxhcmVhPkdlbmVyYWw8L2FyZWE+DQoNCiAgIDx3b3JrZ3JvdXA+SW50 ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZTwvd29ya2dyb3VwPg0KDQogICA8YWJzdHJhY3Q+ DQogICAgIDx0Pg0KICAgICAgIFRoZSBEaWZmaWUtSGVsbG1hbiAoREgpIEdyb3VwIEV4Y2hhbmdl IGZvciB0aGUgU2VjdXJlIFNoZWxsIChTU0gpDQogICAgICAgVHJhbnNwb3J0IGxheWVyIFByb3Rv Y29sIHNwZWNpZmllcyB0aGF0IHNlcnZlcnMgYW5kIGNsaWVudHMNCiAgICAgICBzaG91bGQgc3Vw cG9ydCBncm91cHMgd2l0aCBhIG1vZHVsdXMgbGVuZ3RoIG9mIGsgYml0cywgd2hlcmUgdGhlDQog ICAgICAgcmVjb21tZW5kZWQgbWludW11bSB2YWx1ZSBpcyAxMDI0IGJpdHMuICBSZWNlbnQgc2Vj dXJpdHkgcmVzZWFyY2gNCiAgICAgICBoYXMgc2hvd24gdGhhdCBhIG1pbmltdW0gdmFsdWUgb2Yg MTAyNCBiaXRzIGlzIGluc3VmZmljaWVudA0KICAgICAgIGFnYWluc3Qgc3RhdGUtc3BvbnNvcmVk IGFjdG9ycy4gIEFzIHN1Y2gsIHRoaXMgZG9jdW1lbnQgZm9ybWFsbHkNCiAgICAgICB1cGRhdGVz IHRoZSBzcGVjaWZpY2F0aW9uIHN1Y2ggdGhhdCB0aGUgbWluaW11bSByZWNvbW1lbmRlZCB2YWx1 ZQ0KICAgICAgIGZvciBrIGlzIDIwNDggYml0cyBhbmQgdGhlIGdyb3VwIHNpemUgaXMgMjA0OCBi aXRzIGF0IG1pbmltdW0uDQogICAgICAgVGhpcyBSRkMgdXBkYXRlcyBSRkM0NDE5IHdoaWNoIGFs bG93ZWQgZm9yIERIIG1vZHVsaSBsZXNzIHRoYW4NCiAgICAgICAyMDQ4IGJpdHMuDQogICAgIDwv dD4NCiAgIDwvYWJzdHJhY3Q+DQogPC9mcm9udD4NCg0KIDxtaWRkbGU+DQogICA8c2VjdGlvbiB0 aXRsZT0iSW50cm9kdWN0aW9uIj4NCiAgICAgICA8dD4NCiAgICAgICAgIDx4cmVmIHRhcmdldD0i UkZDNDQxOSIvPiBzcGVjaWZpZXMgYSByZWNvbW1lbmRlZCBtaW5pbXVtIHNpemUNCiAgICAgICAg IG9mIDEwMjQgYml0cyBmb3Igaywgd2hpY2ggaXMgdGhlIG1vZHVsdXMgbGVuZ3RoIG9mIHRoZSBE SA0KICAgICAgICAgR3JvdXAuICBJdCBhbHNvIHN1Z2dlc3RzIHRoYXQgaW4gYWxsIGNhc2VzLCB0 aGUgc2l6ZSBvZiB0aGUNCiAgICAgICAgIGdyb3VwIG5lZWRzIGJlIGF0IGxlYXN0IDEwMjQgYml0 cy4gIFRoaXMgZG9jdW1lbnQgdXBkYXRlcw0KICAgICAgICAgPHhyZWYgdGFyZ2V0PSJSRkM0NDE5 Ii8+IHNvIHRoYXQgdGhlIG1pbmltdW0gcmVjb21tZW5kZWQgc2l6ZSBiZQ0KICAgICAgICAgMjA0 OCBiaXRzLiBUaGlzIHJlY29tbWVuZGF0aW9uIGlzIGJhc2VkIG9uIHJlY2VudCByZXNlYXJjaCA8 eHJlZiB0YXJnZXQ9IkxPR0pBTSIvPiBvbg0KICAgICAgICAgREggR3JvdXAgd2Vha25lc3Nlcy4g DQogICAgICAgPC90Pg0KDQoNCiAgICAgPHNlY3Rpb24gdGl0bGU9IlJlcXVpcmVtZW50cyBMYW5n dWFnZSI+DQogICAgICAgPHQ+DQogICAgICAgICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1Qg Tk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMDQogICAgICAgICBOT1QiLCAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kDQogICAgICAgICAiT1BU SU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzDQogICAgICAg ICBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMTE5Ij5SRkMgMjExOTwveHJlZj4uDQog ICAgICAgPC90Pg0KICAgICA8L3NlY3Rpb24+DQogICA8L3NlY3Rpb24+DQoNCiAgIDxzZWN0aW9u IHRpdGxlPSIyMDQ4IGJpdHMgREggR3JvdXAiPg0KICAgICA8dD4NCiAgICAgICBSZWNlbnQgcmVz ZWFyY2ggPHhyZWYgdGFyZ2V0PSJMT0dKQU0iLz4gc3Ryb25nbHkgc3VnZ2VzdHMNCiAgICAgICB0 aGF0IERIIGdyb3VwcyB0aGF0IGFyZSAxMDI0IGJpdHMgY2FuIGJlIGJyb2tlbiBieSBzdGF0ZQ0K ICAgICAgIGFjdG9ycywgYW5kIHBvc3NpYmx5IGFuIG9yZ2FuaXphdGlvbiB3aXRoIGVub3VnaCBj b21wdXRpbmcNCiAgICAgICByZXNvdXJjZXMuICBUaGUgYXV0aG9ycyBzaG93IGhvdyB0aGV5IGFy ZSBhYmxlIHRvIGJyZWFrIDc2OA0KICAgICAgIGJpdHMgREggZ3JvdXAgYW5kIGV4dHJhcG9sYXRl IHRoZSBhdHRhY2sgdG8gMTAyNCBiaXRzIERIDQogICAgICAgZ3JvdXBzLiAgSW4gdGhlaXIgYW5h bHlzaXMsIHRoZXkgc2hvdyB0aGF0IGJyZWFraW5nIDEwMjQNCiAgICAgIGJpdHMgY2FuIGJlIGRv bmUgd2l0aCBlbm91Z2ggY29tcHV0aW5nIHJlc291cmNlcy4gDQogICAgIFRoaXMgZG9jdW1lbnQg cHJvdmlkZXMgdGhlIGZvbGxvd2luZyByZWNvbW1lbmRhdGlvbjogU1NIIA0KICAgICBTZXJ2ZXJz IGFuZCBTU0ggY2xpZW50cyBTSE9VTEQgc3VwcG9ydCBncm91cHMgd2l0aCBhIG1vZHVsdXMgbGVu Z3RoDQogICAgIG9mIGsgYml0cyB3aGVyZSAyMDQ4ICZsdDsmIzYxOyBrICZsdDsmIzYxOyA4MTky LiAgDQogICAgIDwvdD4NCiAgICAgPHQ+DQpbUkZDNDQxOV0gc3BlY2lmaWVzIA0KICAgICAgYSBy ZWNvbW1lbmRlZCBtaW5pbXVtIHNpemUgb2YgMTAyNCBiaXRzIGZvciBrLA0KICAgICAgd2hpY2gg aXMgdGhlIG1vZHVsdXMgbGVuZ3RoIG9mIHRoZSBESCBHcm91cC4gIEl0IGFsc28gc3VnZ2VzdHMg dGhhdA0KICAgICAgaW4gYWxsIGNhc2VzLCB0aGUgc2l6ZSBvZiB0aGUgZ3JvdXAgbmVlZHMgYmUg YXQgbGVhc3QgMTAyNCBiaXRzLlRoaXMNCiAgICAgIGRvY3VtZW50IHVwZGF0ZXMgIDx4cmVmIHRh cmdldD0iUkZDNDQxOSIvPiBhcyBkZXNjcmliZWQgYmVsb3c6IA0KICAgICAgPGxpc3Qgc3R5bGU9 InN5bWJvbHMiPg0KICAgICAgPHQ+DQogICAgICAgc2VjdGlvbiAzIFBhcmFncmFwaCA5OiBTZXJ2 ZXJzIGFuZA0KICAgICAgIGNsaWVudHMgU0hPVUxEIHN1cHBvcnQgZ3JvdXBzIHdpdGggYSBtb2R1 bHVzIGxlbmd0aCBvZiBrDQogICAgICAgYml0cyB3aGVyZSAyMDQ4ICZsdDsmIzYxOyBrICZsdDsm IzYxOyA4MTkyLiAgVGhlIHJlY29tbWVuZGVkDQogICAgICAgbWluaW11bSB2YWx1ZXMgZm9yIG1p biBhbmQgbWF4IGFyZSAyMDQ4IGFuZCA4MTkyLA0KICAgICAgIHJlc3BlY3RpdmVseS4gDQogICAg ICAgPC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgU2VjdGlvbiAzDQogICAgICAgUGFyYWdyYXBo IDExOiBJbiBhbGwgY2FzZXMsIHRoZSBzaXplIG9mIHRoZSBncm91cCBTSE9VTEQgYmUNCiAgICAg ICBhdCBsZWFzdCAyMDQ4IGJpdHMuDQogICAgICAgPC90Pg0KICAgICAgIDwvbGlzdD4NCg0KICAg ICA8L3Q+DQogICA8L3NlY3Rpb24+DQogICA8c2VjdGlvbiB0aXRsZT0iSW50ZXJvcGVyYWJpbGl0 eSI+DQogICAgPHQ+DQogICBUaGlzIGRvY3VtZW50IGtlZXBzIHRoZSA8eHJlZiB0YXJnZXQ9IlJG QzQ0MTkiLz4gcmVxdWlyZW1lbnQgIlRoZSBzZXJ2ZXIgc2hvdWxkDQogICByZXR1cm4gdGhlIHNt YWxsZXN0IGdyb3VwIGl0IGtub3dzIHRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHNpemUgdGhlDQog ICBjbGllbnQgcmVxdWVzdGVkLiBJZiB0aGUgc2VydmVyIGRvZXMgbm90IGtub3cgYSBncm91cCB0 aGF0IGlzIGxhcmdlcg0KICAgdGhhbiB0aGUgY2xpZW50IHJlcXVlc3QsIHRoZW4gaXQgU0hPVUxE IHJldHVybiB0aGUgbGFyZ2VzdCBncm91cCBpdA0KICAga25vd3MuIiBhbmQgdXBkYXRlcyB0aGUg c2VudGVuY2UgdGhhdCBmb2xsb3dzIHRvIHJlYWQ6ICJJbiBhbGwgY2FzZXMsDQogICB0aGUgc2l6 ZSBvZiB0aGUgcmV0dXJuZWQgZ3JvdXAgU0hPVUxEIGJlIGF0IGxlYXN0IDIwNDggYml0cy4iDQog ICAgPC90Pg0KPC9zZWN0aW9uPg0KDQogICA8c2VjdGlvbiBhbmNob3I9IlNlY3VyaXR5IiB0aXRs ZT0iU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiPg0KICAgICA8dD4NCiAgICAgICBUaGlzIGRvY3Vt ZW50IGRpc2N1c3NlcyBzZWN1cml0eSBpc3N1ZXMgb2YgREggZ3JvdXBzIHRoYXQgYXJlDQogICAg ICAgMTAyNCBiaXRzIGluIHNpemUsIGFuZCBmb3JtYWxseSB1cGRhdGVzIHRoZSBtaW5pbXVtIHNp emUgb2YgREgNCiAgICAgICBncm91cHMgdG8gYmUgMjA0OCBiaXRzLiAgQSBob3N0aWxlIG9yICJv d25lZCIgU2VjdXJlIFNoZWxsIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBjb3VsZA0KICAgIHBvdGVu dGlhbGx5IHVzZSBCYWNrZG9vcmVkIERpZmZpZS1IZWxsbWFuIHByaW1lcyB1c2luZyB0aGUgbWV0 aG9kcw0KICAgIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9IkJhY2tkb29yLURIIi8+IHRvIHBy b3ZpZGUgdGhlIGcscCB2YWx1ZXMNCiAgICB0byBiZSB1c2VkLiBPciwgdGhleSBjb3VsZCBqdXN0 IHNlbmQgdGhlIGNhbGN1bGF0ZWQgc2VjcmV0IHRocm91Z2ggYQ0KICAgIGNvdmVydCBjaGFubmVs IG9mIHNvbWUgc29ydCB0byBhIHBhc3NpdmUgbGlzdGVuZXIuDQogICAgIDwvdD4NCiAgIDwvc2Vj dGlvbj4NCg0KPHNlY3Rpb24gdGl0bGU9IklBTkEgQ29uc2lkZXJhdGlvbnMiIGFuY2hvcj0ic2Vj LWlhbmEiPg0KDQogIDx0PlRoaXMgZG9jdW1lbnQgY29udGFpbnMgbm8gY29uc2lkZXJhdGlvbnMg Zm9yIElBTkEuPC90Pg0KDQo8L3NlY3Rpb24+DQoNCjwvbWlkZGxlPg0KDQogPGJhY2s+DQoNCiAg IDxyZWZlcmVuY2VzIHRpdGxlPSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+DQoNCiAgICAgJlJGQzIx MTk7DQoNCiAgIDwvcmVmZXJlbmNlcz4NCg0KICAgPHJlZmVyZW5jZXMgdGl0bGU9IkluZm9ybWF0 aXZlIFJlZmVyZW5jZXMiPg0KDQogICAgIDwhLS0gTE9HSkFNIGlzIGFuIGluZm9ybWF0aXZlIHJh dGhlciB0aGFuIGEgTm9ybWF0aXZlIFJlZmVyZW5jZSAtLT4NCg0KICAgICA8cmVmZXJlbmNlDQog ICAgICAgICBhbmNob3I9IkxPR0pBTSINCiAgICAgICAgIHRhcmdldD0iaHR0cHM6Ly93ZWFrZGgu b3JnL2ltcGVyZmVjdC1mb3J3YXJkLXNlY3JlY3ktY2NzMTUucGRmIj4NCiAgICAgICA8ZnJvbnQ+ DQogICAgICAgICA8dGl0bGU+DQogICAgICAgICAgIEltcGVyZmVjdCBGb3J3YXJkIFNlY3JlY3k6 IEhvdyBEaWZmaWUtSGVsbG1hbiBGYWlscyBpbiBQcmFjdGljZQ0KICAgICAgICAgPC90aXRsZT4N CiAgICAgICAgIDxhdXRob3Igc3VybmFtZT0iQWRyaWFuIiBpbml0aWFscz0iRC4iIGZ1bGxuYW1l PSJEYXZpZCBBZHJpYW4iPg0KICAgICAgICAgICA8b3JnYW5pemF0aW9uPlVuaXZlcmlzdHkgb2Yg TWljaGlnYW48L29yZ2FuaXphdGlvbj4NCiAgICAgICAgIDwvYXV0aG9yPg0KICAgICAgICAgPGF1 dGhvciBzdXJuYW1lPSJCaGFyZ2F2YW4iIGluaXRpYWxzPSJLLiINCiAgICAgICAgICAgICAgICAg ZnVsbG5hbWU9IkthcnRoaWtleWFuIEJoYXJnYXZhbiI+DQogICAgICAgICAgIDxvcmdhbml6YXRp b24+SU5SSUEgUGFyaXMtUm9jcXVlbmNvdXJ0PC9vcmdhbml6YXRpb24+DQogICAgICAgICA8L2F1 dGhvcj4NCiAgICAgICAgIDxhdXRob3Igc3VybmFtZT0iRHVydW1lcmljIiBpbml0aWFscz0iWi4i IGZ1bGxuYW1lPSJaYWtpciBEdXJ1bWVyaWMiPg0KICAgICAgICAgICA8b3JnYW5pemF0aW9uPlVu aXZlcmlzdHkgb2YgTWljaGlnYW48L29yZ2FuaXphdGlvbj4NCiAgICAgICAgIDwvYXV0aG9yPg0K ICAgICAgICAgPGF1dGhvciBzdXJuYW1lPSJHYXVkcnkiIGluaXRpYWxzPSJQLiIgZnVsbG5hbWU9 IlBpZXJyaWNrIEdhdWRyeSI+DQogICAgICAgICAgIDxvcmdhbml6YXRpb24+DQogICAgICAgICAg ICAgSU5SSUEgTmFuY3ktR3JhbmQgRXN0LCBDTlJTLCBhbmQgVW5pdmVyc2l06SBkZSBMb3JyYWlu ZQ0KICAgICAgICAgICA8L29yZ2FuaXphdGlvbj4NCiAgICAgICAgIDwvYXV0aG9yPg0KICAgICAg ICAgPGF1dGhvciBzdXJuYW1lPSJHcmVlbiIgaW5pdGlhbHM9Ik0uIiBmdWxsbmFtZT0iTWF0dGhl dyBHcmVlbiI+DQogICAgICAgICAgIDxvcmdhbml6YXRpb24+Sm9obnMgSG9wa2luczwvb3JnYW5p emF0aW9uPg0KICAgICAgICAgPC9hdXRob3I+DQogICAgICAgICA8YXV0aG9yIHN1cm5hbWU9Ikhh bGRlcm1hbiIgaW5pdGlhbHM9IkouIEEuIg0KICAgICAgICAgICAgICAgICBmdWxsbmFtZT0iSi4g QWxleCBIYWxkZXJtYW4iPg0KICAgICAgICAgICA8b3JnYW5pemF0aW9uPlVuaXZlcmlzdHkgb2Yg TWljaGlnYW48L29yZ2FuaXphdGlvbj4NCiAgICAgICAgIDwvYXV0aG9yPg0KICAgICAgICAgPGF1 dGhvciBzdXJuYW1lPSJIZW5pbmdlciIgaW5pdGlhbHM9Ik4uIiBmdWxsbmFtZT0iTmFkaWEgSGVu aW5nZXIiPg0KICAgICAgICAgICA8b3JnYW5pemF0aW9uPiBVbml2ZXJzaXR5IG9mIFBlbm5zeWx2 YW5pYTwvb3JnYW5pemF0aW9uPg0KICAgICAgICAgPC9hdXRob3I+DQogICAgICAgICA8YXV0aG9y IHN1cm5hbWU9IlNwcmluZ2FsbCIgaW5pdGlhbHM9IkQuIiBmdWxsbmFtZT0iRHJldyBTcHJpbmdh bGwiPg0KICAgICAgICAgICA8b3JnYW5pemF0aW9uPlVuaXZlcmlzdHkgb2YgTWljaGlnYW48L29y Z2FuaXphdGlvbj4NCiAgICAgICAgIDwvYXV0aG9yPg0KICAgICAgICAgPGF1dGhvciBzdXJuYW1l PSJUaG9t6SIgaW5pdGlhbHM9IkUuIiBmdWxsbmFtZT0iRW1tYW51ZWwgVGhvbekiPg0KICAgICAg ICAgICA8b3JnYW5pemF0aW9uPg0KICAgICAgICAgICAgIElOUklBIE5hbmN5LUdyYW5kIEVzdCwg Q05SUywgYW5kIFVuaXZlcnNpdOkgZGUgTG9ycmFpbmUNCiAgICAgICAgICAgPC9vcmdhbml6YXRp b24+DQogICAgICAgICA8L2F1dGhvcj4NCiAgICAgICAgIDxhdXRob3Igc3VybmFtZT0iVmFsZW50 YSIgaW5pdGlhbHM9IkwuIiBmdWxsbmFtZT0iTHVrZSBWYWxlbnRhIj4NCiAgICAgICAgICAgPG9y Z2FuaXphdGlvbj4gVW5pdmVyc2l0eSBvZiBQZW5uc3lsdmFuaWE8L29yZ2FuaXphdGlvbj4NCiAg ICAgICAgIDwvYXV0aG9yPg0KICAgICAgICAgPGF1dGhvciBzdXJuYW1lPSJWYW5kZXJTbG9vdCIg aW5pdGlhbHM9IkIuIg0KICAgICAgICAgICAgICAgICBmdWxsbmFtZT0iQmVuamFtaW4gVmFuZGVy U2xvb3QiPg0KICAgICAgICAgICA8b3JnYW5pemF0aW9uPlVuaXZlcmlzdHkgb2YgTWljaGlnYW48 L29yZ2FuaXphdGlvbj4NCiAgICAgICAgIDwvYXV0aG9yPg0KICAgICAgICAgPGF1dGhvciBzdXJu YW1lPSJXdXN0cm93IiBpbml0aWFscz0iRS4iIGZ1bGxuYW1lPSJFcmljIFd1c3Ryb3ciPg0KICAg ICAgICAgICA8b3JnYW5pemF0aW9uPlVuaXZlcmlzdHkgb2YgTWljaGlnYW48L29yZ2FuaXphdGlv bj4NCiAgICAgICAgIDwvYXV0aG9yPg0KICAgICAgICAgPGF1dGhvciBzdXJuYW1lPSJaYW5lbGxh LULpZ3VlbGluIiBpbml0aWFscz0iUy4iDQogICAgICAgICAgICAgICAgIGZ1bGxuYW1lPSJTYW50 aWFnbyBaYW5lbGxhLULpZ3VlbGluIj4NCiAgICAgICAgICAgPG9yZ2FuaXphdGlvbj5NaWNyb3Nv ZnQgUmVzZWFyY2g8L29yZ2FuaXphdGlvbj4NCiAgICAgICAgIDwvYXV0aG9yPg0KICAgICAgICAg PGF1dGhvciBzdXJuYW1lPSJaaW1tZXJtYW5uIiBpbml0aWFscz0iUC4iDQogICAgICAgICAgICAg ICAgIGZ1bGxuYW1lPSJQYXVsIFppbW1lcm1hbm4iPg0KICAgICAgICAgICA8b3JnYW5pemF0aW9u PlVuaXZlcmlzdHkgb2YgTWljaGlnYW48L29yZ2FuaXphdGlvbj4NCiAgICAgICAgIDwvYXV0aG9y Pg0KICAgICAgICAgPGRhdGUgeWVhcj0iMjAxNSIvPg0KICAgICAgIDwvZnJvbnQ+DQogICAgICAg PHNlcmllc0luZm8NCiAgICAgICAgICAgbmFtZT0iQUNNIENvbmZlcmVuY2Ugb24gQ29tcHV0ZXIg YW5kIENvbW11bmljYXRpb25zIFNlY3VyaXR5IChDQ1MpIg0KICAgICAgICAgICB2YWx1ZT0iMjAx NSIgLz4NCiAgICAgPC9yZWZlcmVuY2U+DQoNCiAgPHJlZmVyZW5jZQ0KICAgICAgYW5jaG9yPSJC YWNrZG9vci1ESCINCiAgICAgIHRhcmdldD0iaHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDE2LzY0 NC5wZGYiPg0KICAgIDxmcm9udD4NCiAgICAgPHRpdGxlPkhvdyB0byBCYWNrZG9vciBEaWZmaWUt SGVsbG1hbjwvdGl0bGU+DQogICAgIDxhdXRob3Igc3VybmFtZT0iV29uZyIgaW5pdGlhbHM9IkQu IiBmdWxsbmFtZT0iRGF2aWQgV29uZyI+DQogICAgIDwvYXV0aG9yPiANCiAgICAgPGRhdGUgbW9u dGg9Ikp1bmUiIHllYXI9IjIwMTYiLz4NCiAgICA8L2Zyb250Pg0KICAgIDxzZXJpZXNJbmZvIG5h bWU9IkNyeXB0b2xvZ3kgZVByaW50IEFyY2hpdmUiIHZhbHVlPSJSZXBvcnQgMjAxNi82NDQiLz4N CiAgIDwvcmVmZXJlbmNlPg0KDQogICAgICZSRkM0NDE5Ow0KDQogICA8L3JlZmVyZW5jZXM+DQoN Cg0KICAgPCEtLSBDaGFuZ2UgTG9nDQoNCnYwMCAyMDE3LTA1LTEyICBMViAgICBUcmFuc2ZlciB0 byBjdXJkZWwgV0cNCg0KVjAxIDIwMTctMDUtMTcgIE1EQiAgIENsZWFuIHVwIG5pdHMuDQoNClYw MiAyMDE3LTA2LTIxIExWIEFkZCBzZWN0aW9uIG9uIEJhY2tkb29yLURILCBBZGQgc2VjdGlvbiBv biBpbnRlcm9wZXJhYmlsaXR5LCBmaXggY2hhcmFjdGVyIGVuY29kaW5nICYgYWRkIExPR0pBTSBp biBpbnRyb2R1Y3Rpb24uDQpWMDMgMjAxNy0wNi0yMSBMViBJbmNsdWRlIFNTSCBpbiB0aXRsZSwg YW5kIHJld29yayBzZWN0aW9uIDIsIGludG8gMiBwYXJhZ3JhcGhzLg0KVjA0IDIwMTctMDYtMjIg TFYgYWRkIHhyZWYgYW5kIGZpeCBjb2xvbg0KVjA1IDIwMTYtMDctMDcgTFYgYWRkIGxpc3QgcmVj b21tZW5kZWQgYnkgRGFuaWVsDQogICAtLT4NCiA8L2JhY2s+DQo8L3JmYz4NCg== --001a1147c00e5c6f8c0553b9d699-- From nobody Fri Jul 7 06:40:40 2017 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 C37F512EC0C for ; Fri, 7 Jul 2017 06:40:38 -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_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 Aixh3ZYcVfLB for ; Fri, 7 Jul 2017 06:40:36 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 CB781131546 for ; Fri, 7 Jul 2017 06:40:36 -0700 (PDT) X-AuditID: c618062d-dc5689c000002716-5a-595fa4b845a8 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 80.30.10006.8B4AF595; Fri, 7 Jul 2017 17:11:52 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0352.000; Fri, 7 Jul 2017 09:40:35 -0400 From: Daniel Migault To: Loganaden Velvindron CC: curdle Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-04.txt Thread-Index: AQHS6ys5I3kuoQSVvkWcSXsIPuq+oKJHilqAgAEkw4D//70hQA== Date: Fri, 7 Jul 2017 13:40:34 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CBB323@eusaamb107.ericsson.se> References: <149811737863.30580.17844240860986769225@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXSPn+6OJfGRBj9/yFtsXTiL2eLrxPms Dkwee7ctYvVYsuQnUwBTFJdNSmpOZllqkb5dAlfGrr5jTAUvpCq2T13I1sA4QaqLkZNDQsBE ov/kRKYuRi4OIYGjjBI72t5BOcsYJf69/8EIUsUmYCTRdqifvYuRg0NEQFui72ABSJhZQEai 7ecnJhBbWCBIYnXDJ2YQW0QgWOLk312MELaTxNRnH8FqWARUJOZ8fcAIMoZXwFfi2qp6iFWX GCUenX/JClLDKRAo0TflMJjNKCAm8f3UGiaIXeISt57MZ4I4WkBiyZ7zzBC2qMTLx/9YIWwl iTmvrzGDzGcW0JRYv0sfolVRYkr3Q3YQm1dAUOLkzCcsExhFZyGZOguhYxaSjllIOhYwsqxi 5CgtLsjJTTcy2MQIjIRjEmy6OxjvT/c8xCjAwajEw7uuJz5SiDWxrLgy9xCjBAezkghvszdQ iDclsbIqtSg/vqg0J7X4EKM0B4uSOO+E8xcihATSE0tSs1NTC1KLYLJMHJxSDYwTb958u2Nr /4cpabdKT+dNnqujXh74m8eLzX7zv/uMGn6rr0ulr1hy4nrC84lLC16enLB+58ykE9nWNVof Zkar/G86u3ClsVD3Xt7XWtmBp9qC/rV+mRLKozL5scQOSXe/clGezUZmO7ZOfSGv1xJ1h/mH Q9iMvuXLdgk4J8dG5zNwzN+e7K6kxFKckWioxVxUnAgAbMCBRIACAAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-04.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:40:39 -0000 VGhhbmsgeW91LiBUaGUgdXBsb2FkIGlzIGJsb2NrZWQgdHdvIHdlZWtzIHByaW9yIHRoZSBJRVRG LCBidXQgeW91ICB3aWxsIGJlIGFibGUgdG8gdXBsb2FkIGl0IHJpZ2h0IGFmdGVyIHRoZSBJRVRG IHN0YXJ0cywgaS5lIE1vbmRheSAxNy4NCg0KWW91cnMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IExvZ2FuYWRlbiBWZWx2aW5kcm9uIFttYWlsdG86bG9nYW5AaGFja2Vycy5t dV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMDcsIDIwMTcgOTowMiBBTQ0KVG86IERhbmllbCBNaWdh dWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+DQpDYzogY3VyZGxlIDxjdXJkbGVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0N1cmRsZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jdXJk bGUtc3NoLWRoLWdyb3VwLWV4Y2hhbmdlLTA0LnR4dA0KDQpPbiBUaHUsIEp1bCA2LCAyMDE3IGF0 IDExOjM0IFBNLCBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPiB3 cm90ZToNCj4gSGksDQo+DQo+IFRoZSBjdXJyZW50IGRyYWZ0IHNlZW1zIHRvIGhhdmUgcmVhY2hl ZCBjb25zZW5zdXMuIEkgYW0gd2lsbGluZyB0byANCj4gbW92ZSBpdCBmb3J3YXJkIGVhcmx5IG5l eHQgd2VlaywgaWYgeW91IGhhdmUgYW55IGNvbmNlcm5zIHBsZWFzZSBsZXQgdXMga25vdy4NCj4N Cj4gWW91cnMsDQo+IERhbmllbA0KPg0KPiBJIG9ubHkgaGF2ZSBhIG1pbm9yIGVkaXRvcmlhbCBj b21tZW50DQo+DQo+IE9MRA0KPiAgICAgPHQ+DQo+IFtSRkM0NDE5XSBzcGVjaWZpZXMNCj4gICAg ICAgYSByZWNvbW1lbmRlZCBtaW5pbXVtIHNpemUgb2YgMTAyNCBiaXRzIGZvciBrLA0KPiAgICAg ICB3aGljaCBpcyB0aGUgbW9kdWx1cyBsZW5ndGggb2YgdGhlIERIIEdyb3VwLiAgSXQgYWxzbyBz dWdnZXN0cyB0aGF0DQo+ICAgICAgIGluIGFsbCBjYXNlcywgdGhlIHNpemUgb2YgdGhlIGdyb3Vw IG5lZWRzIGJlIGF0IGxlYXN0IDEwMjQgYml0cy5UaGlzDQo+ICAgICAgIGRvY3VtZW50IHVwZGF0 ZXMgIDx4cmVmIHRhcmdldD0iUkZDNDQxOSIvPiBhcyBkZXNjcmliZWQgYmVsb3c6DQo+ICAgICAg IHNlY3Rpb24gMyBQYXJhZ3JhcGggOTogU2VydmVycyBhbmQNCj4gICAgICAgIGNsaWVudHMgU0hP VUxEIHN1cHBvcnQgZ3JvdXBzIHdpdGggYSBtb2R1bHVzIGxlbmd0aCBvZiBrDQo+ICAgICAgICBi aXRzIHdoZXJlIDIwNDggJmx0OyYjNjE7IGsgJmx0OyYjNjE7IDgxOTIuICBUaGUgcmVjb21tZW5k ZWQNCj4gICAgICAgIG1pbmltdW0gdmFsdWVzIGZvciBtaW4gYW5kIG1heCBhcmUgMjA0OCBhbmQg ODE5MiwNCj4gICAgICAgIHJlc3BlY3RpdmVseS4gIFRoaXMgZG9jdW1lbnQgYWxzbyB1cGRhdGVz IDx4cmVmIA0KPiB0YXJnZXQ9IlJGQzQ0MTkiLz4gU2VjdGlvbiAzDQo+ICAgICAgICBQYXJhZ3Jh cGggMTEgYXMgZm9sbG93czogSW4gYWxsIGNhc2VzLCB0aGUgc2l6ZSBvZiB0aGUgZ3JvdXAgDQo+ IFNIT1VMRCBiZQ0KPiAgICAgICAgYXQgbGVhc3QgMjA0OCBiaXRzLg0KPiAgICAgIDwvdD4NCj4N Cj4NCj4gTkVXDQo+ICAgICA8dD4NCj4gW1JGQzQ0MTldIHNwZWNpZmllcw0KPiAgICAgICBhIHJl Y29tbWVuZGVkIG1pbmltdW0gc2l6ZSBvZiAxMDI0IGJpdHMgZm9yIGssDQo+ICAgICAgIHdoaWNo IGlzIHRoZSBtb2R1bHVzIGxlbmd0aCBvZiB0aGUgREggR3JvdXAuICBJdCBhbHNvIHN1Z2dlc3Rz IHRoYXQNCj4gICAgICAgaW4gYWxsIGNhc2VzLCB0aGUgc2l6ZSBvZiB0aGUgZ3JvdXAgbmVlZHMg YmUgYXQgbGVhc3QgMTAyNCBiaXRzLlRoaXMNCj4gICAgICAgZG9jdW1lbnQgdXBkYXRlcyAgPHhy ZWYgdGFyZ2V0PSJSRkM0NDE5Ii8+IGFzIGRlc2NyaWJlZCBiZWxvdzoNCj4NCj4gICAgICAgPGxp c3Qgc3R5bGU9InN5bWJvbHMiPg0KPg0KPiAgICAgICA8dD5zZWN0aW9uIDMgUGFyYWdyYXBoIDk6 IFNlcnZlcnMgYW5kDQo+ICAgICAgICBjbGllbnRzIFNIT1VMRCBzdXBwb3J0IGdyb3VwcyB3aXRo IGEgbW9kdWx1cyBsZW5ndGggb2Ygaw0KPiAgICAgICAgYml0cyB3aGVyZSAyMDQ4ICZsdDsmIzYx OyBrICZsdDsmIzYxOyA4MTkyLiAgVGhlIHJlY29tbWVuZGVkDQo+ICAgICAgICBtaW5pbXVtIHZh bHVlcyBmb3IgbWluIGFuZCBtYXggYXJlIDIwNDggYW5kIDgxOTIsDQo+ICAgICAgICByZXNwZWN0 aXZlbHkuPC90Pg0KPg0KPiAgICAgICAgPHQ+IFNlY3Rpb24gMw0KPiAgICAgICAgUGFyYWdyYXBo IDExOiBJbiBhbGwgY2FzZXMsIHRoZSBzaXplIG9mIHRoZSBncm91cCBTSE9VTEQgYmUNCj4gICAg ICAgIGF0IGxlYXN0IDIwNDggYml0cy4gPC90Pg0KPiAgICAgICAgPC9saXN0Pg0KPg0KPiAgICAg ICAgPC90Pg0KPg0KDQpEZWFyIERhbmllbCwgSSBoYXZlIG1hZGUgdGhlIG1vZGlmaWNhdGlvbnMs IGFzIHJlcXVlc3RlZCwgYnV0IEkgY2Fubm90IHVwbG9hZCBpdCBhcyBpdCB3aWxsIGJlIHVubG9j a2VkIGFmdGVyIHRoZSAxNnRoLg0KDQpNZWFud2hpbGUsIEkgaGF2ZSBhdHRhY2hlZCBpdC4NCg== From nobody Tue Jul 11 06:36:34 2017 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 D8241127058; Tue, 11 Jul 2017 06:36:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.55.3 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, draft-ietf-curdle-cms-eddsa-signatures@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149978019287.12434.7085644541279119670.idtracker@ietfa.amsl.com> Date: Tue, 11 Jul 2017 06:36:32 -0700 Archived-At: Subject: [Curdle] Last Call: (Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 13:36:33 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jul 11 23:31:21 2017 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 3AD5C12F280 for ; Tue, 11 Jul 2017 23:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.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 yuad9fbFn_Oz for ; Tue, 11 Jul 2017 23:31:18 -0700 (PDT) Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) (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 469C112F290 for ; Tue, 11 Jul 2017 23:31:17 -0700 (PDT) Received: by mail-wr0-f181.google.com with SMTP id r103so19281891wrb.0 for ; Tue, 11 Jul 2017 23:31:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=gkW7xyAMMg+h5XYsmk+0hE2EQBkgsSb5jk9YM3110Vo=; b=Ph563X5oE043KCVhfC39IBaynt8Dgl5DnIaTUe2gDlg3aZ51EgTY+wBCJeZ5LoHk83 dM/H86jpO9L07zN6rApZKIWP1mPtWBvy/MVJm2oTY+KLCIvt02eELKLf89XFFqNPO21i 51x4kqTtomaQkrMOgPv82qmUA+pItdTBfAyKiVRSgvY5MakdJQOizEvxCvd+7qtkX1Vx 5uOPOzarX3w9YIg67jg1+9qNhuUM8c17mtcvQptkfphnWv9JGK0GFS7CHlHOGHKltSrf vz4tM/LErS/3OQMPVyeju0a2IO8M25/MTFVfbI+iUepYAwz/vq8IH3xwcfWXPOIuexzF WmrA== X-Gm-Message-State: AIVw112TFiIgZQxSOeu81+KY+a8rXaUyaqtGQui/WIoaspp8uPCPHA0Y 9LLZMERFgeOADob3p4pmJw== X-Received: by 10.223.129.6 with SMTP id 6mr1704376wrm.23.1499841076013; Tue, 11 Jul 2017 23:31:16 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id e31sm2095388wre.54.2017.07.11.23.31.14 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Jul 2017 23:31:15 -0700 (PDT) Message-ID: <1499841074.3198.6.camel@redhat.com> From: Nikos Mavrogiannopoulos To: curdle@ietf.org Date: Wed, 12 Jul 2017 08:31:14 +0200 In-Reply-To: <149912398826.16176.10478215253595868540@ietfa.amsl.com> References: <149912398826.16176.10478215253595868540@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 06:31:20 -0000 On Mon, 2017-07-03 at 16:19 -0700, internet-drafts@ietf.org wrote: > 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 of the IETF. > >         Title           : Algorithm Identifiers for Ed25519, Ed448, > X25519 and X448 for use in the Internet X.509 Public Key > Infrastructure >         Authors         : Simon Josefsson >                           Jim Schaad > Filename        : draft-ietf-curdle-pkix-05.txt > Pages           : 17 > Date            : 2017-07-03 > > Abstract: >    This document specifies algorithm identifiers and ASN.1 encoding >    formats for Elliptic Curve constructs using the curve25519 and >    curve448 curves.  The signature algorithms covered are Ed25519 and >    Ed448.  The key agreement algorithm covered are X25519 and > X448.  The >    encoding for Public Key, Private Key and EdDSA digital signature >    structures is provided. Minor request. It would be nice if the certificate issuer of the cert in 10.2 was included in the document. That would provide a certificate with a ed25519 key, and would allow testing certificate chain verification. regards, Nikos From nobody Wed Jul 12 08:43:29 2017 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 9DB1412F257; Wed, 12 Jul 2017 08:43:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dME6fKOuRVnV; Wed, 12 Jul 2017 08:43:25 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 0E063126C3D; Wed, 12 Jul 2017 08:43:24 -0700 (PDT) X-AuditID: c618062d-a05ff70000002716-3e-5966593054ef Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 1E.5E.10006.03956695; Wed, 12 Jul 2017 19:15:28 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0352.000; Wed, 12 Jul 2017 11:43:22 -0400 From: Daniel Migault To: curdle CC: "curdle-chairs@ietf.org" Thread-Topic: Curdle meeting IETF99 Thread-Index: AdL7JDYH8MZzW1pCQbGXoiiTCQcjSw== Date: Wed, 12 Jul 2017 15:42:58 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CBE339@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CBE339eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPgq5BZFqkQcMkbYuZPRuYLbYunMXs wOSxZMlPpgDGKC6blNSczLLUIn27BK6Mz8vesxVsCK34Pb+dtYHxt3cXIyeHhICJxLW/z9m7 GLk4hASOMko8vdnJCOEsZ5RoXdXEAlLFJmAk0Xaonx3EFhGQkXjdfZe5i5GDg1nAVKKzqwQk LCwgJ9G5qpMNokRZomX5aqhyPYlbS+eAxVkEVCXWN/9mBrF5BXwl3s+fAzaeUUBM4vupNUwg NrOAuMStJ/OZII4TkFiy5zwzhC0q8fLxP1YIW0lizutrzBD1+RK3Ni9lg5gpKHFy5hOWCYxC s5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0uCAnN93IYBMjMAaO SbDp7mC8P93zEKMAB6MSD+8yn7RIIdbEsuLK3EOMEhzMSiK85U5AId6UxMqq1KL8+KLSnNTi Q4zSHCxK4rwTzl+IEBJITyxJzU5NLUgtgskycXBKNTDWtDxlvLJvt7HGn5n9/47eFL24xptd g3+1w9FnXt88dHYobOo5+PvfN8agiXtntbXP1jnyMWargNcpp92XP2Ud6UiwPDr3wtapJ7JK zx+8/9ezxUPk/X8277lR89jK92QkxXUuOZCyuLjx5hTh38c43k+uDlZ6mPF/DudxhgUvtkdE Tlov8EZgqRJLcUaioRZzUXEiAPPkzSF9AgAA Archived-At: Subject: [Curdle] Curdle meeting IETF99 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 15:43:28 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CBE339eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI, Please find the draft presentation [1]. Comments are welcome! During the Curdle session we would like to: * Discuss draft-ietf-curdle-ssh-kex-sha2-08 and see if it is ready to b= e sent to the IESG. Feed backs on the ML are more than welcome. * Discuss what the next steps are for the WG. Feel free to discuss how = you see gaps should be filled or not..... If there are any specific topic you would like to discuss, please let us kn= ow asap. Yours, Rich and Daniel [1] https://docs.google.com/presentation/d/1bYCjm7G39u3XsgK8khsatF_GEo-Kqgl= VvQ6iUDGBXgs/edit?usp=3Dsharing [Ericsson] DANIEL MIGAULT Researcher Research Ericsson 8500 Boulevard Decarie H4P 2N2 Montreal, Canada Phone +1 514 345 7900 46628 Mobile +1 514 452 2160 daniel.migault@ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign] Legal entity: Ericsson Canada Inc., registered office in Montreal. This Com= munication is Confidential. We only send and receive email on the basis of = the terms set out at www.ericsson.com/email_disclaimer --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CBE339eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI,

 

Please find the draft presentation [1]. Comments are= welcome!

 

During the Curdle session we would like to:

  • Discuss draft-ietf-curdle-ssh-kex-sha2-08 and see if it is ready to b= e sent to the IESG. Feed backs on the ML are more than welcome.<= /li>
  • Discuss what the next steps are for the WG. Feel free to discuss = how you see gaps should be filled or not…..

 

If there are any specific topic you would like to di= scuss, please let us know asap.

 

Yours,

Rich and Daniel

 

[1] https://docs.google.com/presentation/d/1bYCjm7G3= 9u3XsgK8khsatF_GEo-KqglVvQ6iUDGBXgs/edit?usp=3Dsharing

 

 

3D"Ericsson"

DANIEL MIGAULT
Researcher
Research


Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
daniel.migault@ericsson.com
www.ericsson.com



3D"http://www.eric=

 

Legal entity: Ericsson Canada Inc., regi= stered office in Montreal. This Communication is Confidential. We only send= and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CBE339eusaamb107erics_-- From nobody Wed Jul 12 10:21:55 2017 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 20C50129AD1 for ; Wed, 12 Jul 2017 10:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.20150623.gappssmtp.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 y1s3zve4t6eH for ; Wed, 12 Jul 2017 10:21:51 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 49C2D126B7E for ; Wed, 12 Jul 2017 10:21:51 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id p188so25456823oia.0 for ; Wed, 12 Jul 2017 10:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q59uG1gZR63qmX9fwjT60DG3QCGy1GSbT91PfUqD598=; b=WdNaEOrQhpocaoqPA3C42rVQf3BQzNN8/UPqw8fnr3tDtH0FOw9QllZjA1IS0aq9VB h52GMuYKniDw4rv+NENU//KyiKw9ZvaTAXU4zFbxcOyDnK1vYR235T1x6Yu4FmaF8bcl DIGSpCEzq+Z99o6+fux4G57bfHXqC/pJxcBWKomR7FBVKPP9ZQO3HP4k/7B4M0wppQPE 88Pz/cUlTKCV6k+kd5bCyuuRoBsNpcKc0Fnfxqa9Y8m/Csz2gaRJR9gvXQGBVvKolHpW g6dQTRyLWijpk/YUDzKM/UF6AsCM5/wUO7QMFJheOL+GY/ddO8t3REgHVx2xENRNZWZb rBIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q59uG1gZR63qmX9fwjT60DG3QCGy1GSbT91PfUqD598=; b=L2DQ97u3vcRNw3RkKjpZKlruNLKn/znhku9GTe10dfIDIDW5RHEMaR/41PeFm8eA0Z wyiGaaYf8FpgzPXrIwAXBKXYrvuiVq+Fp2Mg9uCcm5hPHilRmB3JPvPPo7Rspzw2A8bK Csz01Bov3prhpgr8UT8IZVqeF26X0fOE3fPTkKEedm6Zw28o8So2BEISuDN1IuxnEFew DUg3dHgO3TZtgELYV1luti2ZMDwo+q6Qe7i55/21+XLVej0JtC3m9B45kDjEl/3MBRfp C8l/KkQsiN9Htp/kYEK0HQ2niNoKTjru4PbFCmY8nABGhf3FLoY9ZZL2Fto8XYVGhIZC 7+gQ== X-Gm-Message-State: AIVw113L/7JgdvYiTWBQC27NHZyYplQ2TGYmVbxdhQG+1+F+HnSjYWxD +WiT/thW7q8tnblSwhAcFMBMJpwzxnCh X-Received: by 10.202.222.212 with SMTP id v203mr4055763oig.88.1499880110604; Wed, 12 Jul 2017 10:21:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.139.156 with HTTP; Wed, 12 Jul 2017 10:21:50 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118CBE339@eusaamb107.ericsson.se> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118CBE339@eusaamb107.ericsson.se> From: Loganaden Velvindron Date: Wed, 12 Jul 2017 21:21:50 +0400 Message-ID: To: Daniel Migault Cc: curdle , "curdle-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a113d5d7032dd400554220db3" Archived-At: Subject: Re: [Curdle] Curdle meeting IETF99 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 17:21:54 -0000 --001a113d5d7032dd400554220db3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 12, 2017 at 7:42 PM, Daniel Migault wrote: > HI, > > > > Please find the draft presentation [1]. Comments are welcome! > > > > During the Curdle session we would like to: > > - Discuss draft-ietf-curdle-ssh-kex-sha2-08 and see if it is ready to > be sent to the IESG. Feed backs on the ML are more than welcome. > - Discuss what the next steps are for the WG. Feel free to discuss how > you see gaps should be filled or not=E2=80=A6.. > > > > If there are any specific topic you would like to discuss, please let us > know asap. > > > > > Hi, This looks good to me. I have a small question: Will there be someone who can take questions from remote participants ? --001a113d5d7032dd400554220db3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 12, 2017 at 7:42 PM, Daniel Migault <<= a href=3D"mailto:daniel.migault@ericsson.com" target=3D"_blank">daniel.miga= ult@ericsson.com> wrote:

HI,

=C2=A0

Please find the draft presentation [1]. Comments are= welcome!

=C2=A0

During the Curdle session we would like to:

  • Discuss draft-ietf-curdle-ssh-kex-sha2-08 and= see if it is ready to be sent to the IESG. Feed backs on the ML are more t= han welcome.
  • Discuss what the ne= xt steps are for the WG. Feel free to discuss how you see gaps should be fi= lled or not=E2=80=A6..

=C2=A0

If there are any specific topic you would like to di= scuss, please let us know asap.

=C2=A0



Hi,=C2=A0

This looks good to me. I have a small q= uestion: Will there be someone who can take questions from remote participa= nts ?



--001a113d5d7032dd400554220db3-- From nobody Wed Jul 12 16:00:24 2017 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 A21CB129482; Wed, 12 Jul 2017 16:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 bqu8c8ue2DMw; Wed, 12 Jul 2017 16:00:14 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 6901B12F258; Wed, 12 Jul 2017 16:00:13 -0700 (PDT) X-AuditID: 12074424-35bff70000001405-92-5966a9fb13e1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 74.57.05125.CF9A6695; Wed, 12 Jul 2017 19:00:12 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v6CN0A75026325; Wed, 12 Jul 2017 19:00:11 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6CN06JS009804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2017 19:00:08 -0400 Date: Wed, 12 Jul 2017 18:00:06 -0500 From: Benjamin Kaduk To: Daniel Migault Cc: Martin Rex , kitten@ietf.org, curdle Message-ID: <20170712230006.GD80947@kduck.kaduk.org> References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> <20170626021135.GF17840@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrftnZVqkwckjwhZbF85itpgyfQ+b xdHNq1gsen/vYHZg8fj19Sqbx5IlP5k8pnzeyhjAHMVlk5Kak1mWWqRvl8CV8WzHTdaCl+oV yzr/MDcw/pTrYuTgkBAwkfg0TbeLkYtDSGAxk8TFpS8YIZyNjBJrd79jg3CuMknMfLGYBaSD RUBV4u9J/i5GTg42ARWJhu7LzCC2iICBxMsJO9lAbGYBD4mFm76wgpQLC8RKtC/UAgnzAu16 PPEVO0hYSOAGo8R6Q4iwoMTJmU9YIDq1JG78e8kEUsIsIC2x/B8HSJhTIFDi2qXDjCC2qICy xN/D91gmMArMQtI9C0n3LITuBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3 MYKCl91FZQdjd4/3IUYBDkYlHl4OzbRIIdbEsuLK3EOMkhxMSqK8KsFAIb6k/JTKjMTijPii 0pzU4kOMEhzMSiK8di1AOd6UxMqq1KJ8mJQ0B4uSOK+4RmOEkEB6YklqdmpqQWoRTFaGg0NJ gtdjBVCjYFFqempFWmZOCUKaiYMTZDgP0PD8JSDDiwsSc4sz0yHypxgVpcR5n4E0C4AkMkrz 4HpByUUie3/NK0ZxoFeEeactB6riASYmuO5XQIOZgAavyU4BGVySiJCSamDczxS+ozt7qsPM /qVWFn/UFURfLosPWRMYceljE+/bvM8XZMwePN788Evobv0guUOPZzl7BC+VeSrwpNfonP91 pfe79/NXpDdG633Wy3hTkrZR5lKf2XEBt9fHJeLlRDbZ1/hv37B5guPsfy7rW56EPhSpF9rj 3TS7fEXIJM21rEEv+K/7sNxQYinOSDTUYi4qTgQAI4YMwwkDAAA= Archived-At: Subject: Re: [Curdle] [kitten] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 23:00:17 -0000 On Thu, Jul 06, 2017 at 12:01:49PM -0400, Daniel Migault wrote: > Hi, > > Thank you for the discussion. It seems that overall the current draft has a > reached consensus. Are we ready to move the draft forward or do we need any > additional discussions ? If you think more discussion is needed please let > us know as soon as possible. Unless concerns are raised, I am planning to > set the shepherd write up early next week. (Intentionally retaining quoted text below.) I think we're ready to move the draft forward (as-is). Having reviewed the extra comments, as well as the current text, I don't think that there is a need to add something along the lines of what Martin had proposed. If I was going to add anything, it would be along the lines of: Administrators are additionally expected to be capable of designing rollout plans that minimize disruption, provisioning keys with the new enctypes before enabling new enctypes in configuration. (at the end of section 5.4). But it's not clear that this is really adding value. -Ben > On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk wrote: > > > Hi Martin, > > > > On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote: > > > Benjamin Kaduk wrote: > > > > > > > > It sounds like you are asking for the addition of some text along > > > > the lines of: > > > > > > > > Software support is only a bare minimum requirement for deprecating > > > > RC4 enctypes; there may be additional logistical considerations > > > > involved such as provisioning AES keys for all principals and > > > > updating software configuration to enable AES and disable deprecated > > > > encryption types. > > > > > > > > Is that something you are asking for? > > > > > > Yes, thank your. This sounds good to me. I consider it even more > > > helpful than the reference to particular versions of particular > > > OpenSource Kerberos implementations, because this is a characteristic > > > that is sort-of implied by how kerberos-enctypes keys are created > > > (derived by string2key) and probably affect all implementations of > > > Kerberos, yet it is non-obvious to consumers of the technology. > > > > Thank you for clarifying your comment into a request. > > > > > > > > There is a substantial difference between cipher suites in TLS, where > > > key length, strength and algorithm for the symmetric crypto is mostly > > > irrelevant to the (PKI) credentials, and where using new TLS cipher > > suites > > > and deprecating old TLS cipher suites does not have a rekeying > > requirement. > > > > To some extent this is inherent in Kerberos's use of symmetric crypto for > > authentication, as opposed to TLS which uses asymmetric crypto for > > authentication and switches to symmetric crypto for efficiency for > > bulk data transfer. > > > > > > (Jeffrey Altman wrote:) > > % In my opinion, such text is inappropriate for an RFC. The deprecation > > % of the encryption type is a protocol action. The RFC is not guidance > > % for system administrators. Such guidance should come from the protocol > > % implementations. > > % > > % As such I believe the addition of text similar to the above is > > % unnecessary for publication. > > > > > > > > I do believe that it is very appropriate to provide such kind of a > > > guidance in an RFC, so that it this recommendation for deprecation > > > becomes more comprehensible and the trade-offs clearer to mere consumers > > > of the Kerberos technology, readers that aren't Kerberos protocol experts > > > and senior Kerberos implementers. > > > > In general I tend to hew more to Jeffrey's track that protocol > > specifications > > should limit themseles to protocol-level work. I could see some grounds > > for an exception here, though, in that the deployment difficulties are > > inherent to any Kerberos deployment that follows best practice of not > > storing > > user passwords (only derived keys). > > > > Given Jeffrey's reasoning, I do not think my above "proposed text" > > (to get clarification from Martin) should be used as-is; if we do want > > to provide the clarification that Martin wants, I would want to rephrase > > things somewhat. But, it still seems unclear where the WG consensus lies > > on the question of including any guidance at all, here. Can others > > please weigh in? > > > > > > > When making admins sufficiently aware of predictable interop-problems, > > > we may actually see more administrative deprecation of weak Kerberos > > > enctypes than leaving them in the dark, and it helps reducing the amount > > > of stumped users, helpdesks and admins. > > > > Admins are more likely to read software-provided documentation than > > protocol specs; this argument seems speculative to me. > > > > -Ben > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > From nobody Sun Jul 16 02:07:47 2017 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 6E28E127180; Sun, 16 Jul 2017 02:07:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150019606540.8757.5932850604404568252.idtracker@ietfa.amsl.com> Date: Sun, 16 Jul 2017 02:07:45 -0700 Archived-At: Subject: [Curdle] Last Call: (Deprecate 3DES and RC4 in Kerberos) to Best Current Practice X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 16 Jul 2017 09:07:45 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'Deprecate 3DES and RC4 in Kerberos' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. Accordingly, RFC 4757 is moved to Obsolete status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc3961: Encryption and Checksum Specifications for Kerberos 5 (Proposed Standard - IETF stream) rfc4120: The Kerberos Network Authentication Service (V5) (Proposed Standard - IETF stream) From nobody Sun Jul 16 02:08:16 2017 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 6239A127058; Sun, 16 Jul 2017 02:08:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150019609530.8783.6309060226178830592.idtracker@ietfa.amsl.com> Date: Sun, 16 Jul 2017 02:08:15 -0700 Archived-At: Subject: [Curdle] Last Call: (More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 16 Jul 2017 09:08:15 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Jul 16 02:08:49 2017 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 28729127058; Sun, 16 Jul 2017 02:08:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-ssh-ext-info@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150019612816.8839.70342246711743958.idtracker@ietfa.amsl.com> Date: Sun, 16 Jul 2017 02:08:48 -0700 Archived-At: Subject: [Curdle] Last Call: (Extension Negotiation in Secure Shell (SSH)) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 16 Jul 2017 09:08:48 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'Extension Negotiation in Secure Shell (SSH)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Jul 16 02:09:27 2017 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 A43401318AA; Sun, 16 Jul 2017 02:09:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, draft-ietf-curdle-ssh-dh-group-exchange@ietf.org, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150019616166.8774.5393420529621277591.idtracker@ietfa.amsl.com> Date: Sun, 16 Jul 2017 02:09:21 -0700 Archived-At: Subject: [Curdle] Last Call: (Increase SSH minimum recommended DH modulus size to 2048 bits) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 16 Jul 2017 09:09:22 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'Increase SSH minimum recommended DH modulus size to 2048 bits' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minumum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Jul 16 11:47:07 2017 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 0970712F3D0 for ; Sun, 16 Jul 2017 11:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 8iWKh_KklYzc for ; Sun, 16 Jul 2017 11:47:03 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id CFB91129AA0 for ; Sun, 16 Jul 2017 11:47:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5CA2A3538A; Sun, 16 Jul 2017 21:47:00 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id ZLF4hAbePqS9; Sun, 16 Jul 2017 21:46:59 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id AE24E2317; Sun, 16 Jul 2017 21:46:55 +0300 (EEST) Date: Sun, 16 Jul 2017 21:46:55 +0300 From: Ilari Liusvaara To: Yoav Nir Cc: Rich Salz , Jim Schaad , "curdle@ietf.org" Message-ID: <20170716184655.tius2wcdbp3bumou@LK-Perkele-VII> References: <149912398826.16176.10478215253595868540@ietfa.amsl.com> <006b01d2f484$0dfcfdf0$29f6f9d0$@augustcellars.com> <600eb1cae49c4993a11d477c2036ef2e@usma1ex-dag1mb1.msg.corp.akamai.com> <52B36760-2973-4781-A677-F273DC0F28D7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52B36760-2973-4781-A677-F273DC0F28D7@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 16 Jul 2017 18:47:05 -0000 On Tue, Jul 04, 2017 at 06:32:33PM +0300, Yoav Nir wrote: > > > On 4 Jul 2017, at 17:45, Salz, Rich wrote: > > > >> Brian Smith wants to have a full test set at the end of the > >> document. I do not believe that it is appropriate for this > >> document and therefore have only included a couple of test > >> that demonstrate errors. > > > > Is there anyone else in the WG who shares Brian's opinion? > > IMO the examples in section 10 are sufficient. A full test is > appropriate the an algorithm RFC such as 8032 (for EdDSA) and 7748 > (for Curve25519 and Curve448) > > RFC 8032 has a good set of test vectors. RFC 7748 has a rather small > set, but even if it’s not enough, I don’t think a PKIX update is the > place to fix it. Furthermore, all these concern private key formatting, which I regard as some of the least important things in this document (I am even not sure if the private key examples already are useful or not). So I do not consider more examples here important. Also, what's going on with the draft? Its status was set over two months ago (and to value I consider rather bizarre), and since there only has been a version bump. -Ilari From nobody Mon Jul 17 03:06:23 2017 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 2739912F28A for ; Mon, 17 Jul 2017 03:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 Mq-Z4X2KqTEJ for ; Mon, 17 Jul 2017 03:06:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 36A4412EB99 for ; Mon, 17 Jul 2017 03:06:20 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v6HA6FdM018518 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 Jul 2017 13:06:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6HA6F5t008612; Mon, 17 Jul 2017 13:06:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22892.35863.542104.942153@fireball.acr.fi> Date: Mon, 17 Jul 2017 13:06:15 +0300 From: Tero Kivinen To: curdle@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 8 min Archived-At: Subject: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 10:06:22 -0000 I think it is bad idea to go from MUST to implement algorithm to MUST NOT implement in one step. Especially as this will make all current ssh implementations non-conforming as they do still implement diffie-hellman-group1-sha1 even when it might be disabled by default. We are defining here a MUST implement and MUST not implement, not MUST use and MUST NOT use recommendations. In IPsec we moved from MUST to SHOULD NOT just because that reason, i.e., we didn't want to make all implementations non-conforming, and forbid backwards compatibility with old implementations which might only support previous MUST implement algorithm. Also I guess there is quite a lot of ssh implementations in routers and other devices which might not get updates very quickly, and they might only support diffie-hellman-group1-sha1, and with this change, new implementations cannot talk to them, as new implementations MUST NOT implement diffie-hellman-group1-sha1. I would suggest changing it to SHOULD NOT and say that in future it might be changed to MUST NOT. -- kivinen@iki.fi From nobody Mon Jul 17 04:39:41 2017 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 7B43812420B for ; Mon, 17 Jul 2017 04:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7hvP_CUsjKvV for ; Mon, 17 Jul 2017 04:39:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43065131B33 for ; Mon, 17 Jul 2017 04:39:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 59E6530056B for ; Mon, 17 Jul 2017 07:39:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fQ0Tkbjzngov for ; Mon, 17 Jul 2017 07:39:36 -0400 (EDT) Received: from dhcp-88c4.meeting.ietf.org (dhcp-88c4.meeting.ietf.org [31.133.136.196]) by mail.smeinc.net (Postfix) with ESMTPSA id 86A7E300288; Mon, 17 Jul 2017 07:39:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <22892.35863.542104.942153@fireball.acr.fi> Date: Mon, 17 Jul 2017 07:39:32 -0400 Cc: curdle@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <22892.35863.542104.942153@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 11:39:40 -0000 I agree with Tero. However, I like the use of SHOULD+ and MUST- to = signal to project and product planners what is coming. =20 Russ > On Jul 17, 2017, at 6:06 AM, Tero Kivinen wrote: >=20 > I think it is bad idea to go from MUST to implement algorithm to MUST > NOT implement in one step. Especially as this will make all current > ssh implementations non-conforming as they do still implement > diffie-hellman-group1-sha1 even when it might be disabled by default. >=20 > We are defining here a MUST implement and MUST not implement, not MUST > use and MUST NOT use recommendations. >=20 > In IPsec we moved from MUST to SHOULD NOT just because that reason, > i.e., we didn't want to make all implementations non-conforming, and > forbid backwards compatibility with old implementations which might > only support previous MUST implement algorithm. >=20 > Also I guess there is quite a lot of ssh implementations in routers > and other devices which might not get updates very quickly, and they > might only support diffie-hellman-group1-sha1, and with this change, > new implementations cannot talk to them, as new implementations MUST > NOT implement diffie-hellman-group1-sha1. >=20 > I would suggest changing it to SHOULD NOT and say that in future it > might be changed to MUST NOT. > --=20 > kivinen@iki.fi From nobody Mon Jul 17 04:52:25 2017 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 2DCF9131B3C; Mon, 17 Jul 2017 04:52:22 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150029234215.14941.8137441539904277441@ietfa.amsl.com> Date: Mon, 17 Jul 2017 04:52:22 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-dh-group-exchange-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 11:52:22 -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 of the IETF. Title : Increase SSH minimum recommended DH modulus size to 2048 bits Authors : Loganaden Velvindron Mark D. Baushke Filename : draft-ietf-curdle-ssh-dh-group-exchange-05.txt Pages : 4 Date : 2017-07-17 Abstract: The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) Transport layer Protocol specifies that servers and clients should support groups with a modulus length of k bits, where the recommended minimum value is 1024 bits. Recent security research has shown that a minimum value of 1024 bits is insufficient against state-sponsored actors, and possibly an organization with enough computing resources. As such, this document formally updates the specification such that the minimum recommended value for k is 2048 bits and the group size is 2048 bits at minimum. This RFC updates RFC4419 which allowed for DH moduli less than 2048 bits. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-dh-group-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-dh-group-exchange-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-dh-group-exchange-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-dh-group-exchange-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 17 05:25:42 2017 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 5E9D0131B35 for ; Mon, 17 Jul 2017 05:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 ahQURWJhSuHW for ; Mon, 17 Jul 2017 05:25:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 553D9131B14 for ; Mon, 17 Jul 2017 05:25:38 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v6HCPXEq014494 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Jul 2017 15:25:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6HCPX4N016948; Mon, 17 Jul 2017 15:25:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22892.44221.173699.599992@fireball.acr.fi> Date: Mon, 17 Jul 2017 15:25:33 +0300 From: Tero Kivinen To: Russ Housley Cc: curdle@ietf.org In-Reply-To: References: <22892.35863.542104.942153@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 12:25:40 -0000 Russ Housley writes: > I agree with Tero. However, I like the use of SHOULD+ and MUST- to > signal to project and product planners what is coming. Actually it is much better to explain that kind of things in the actual text. For example: 3.5. diffie-hellman-group14-sha1 This method uses [RFC3526] group14 (a 2048-bit MODP group) which has no concerns. This generated key exchange group uses SHA-1 which has security concerns [RFC6194]. However, this group is still strong enough and is widely deployed. This method is being moved from MUST to SHOULD- to aid in transition to stronger SHA-2 based hashes. This method will transition to MUST NOT when SHA-2 alternatives are more generally available. Gives much better information what to expect than SHOULD- in table. SHOULD+, SHOULD- were useful when we only had table of requirement levels. Now when we have the text about each algorithm explain the reasoning, those + and - characters are getting more and more meaningless. For example the SHOULD- is defined in section 2 to mean that this algorithm will be deprecated to MAY in future version, but in practice we quite often go from SHOULD- to SHOULD NOT (or even MUST NOT, as the text above suggests). Anyways this is separate issue than wheter we should make implementations having code for diffie-hellman-group1-sha1 non-conforming by publishing that implementations MUST NOT implement diffie-hellman-group1-sha1... -- kivinen@iki.fi From nobody Mon Jul 17 08:27:45 2017 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 8AE6B131C6C for ; Mon, 17 Jul 2017 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=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 Z6qnXo4d3VSA for ; Mon, 17 Jul 2017 08:27:41 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0116.outbound.protection.outlook.com [104.47.40.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B37131C62 for ; Mon, 17 Jul 2017 08:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H1e37GNWRa+r/jU/juKbplmky+1b0zyVN4LTvMi0On4=; b=CdkKMDfX+NSvtZHRWDRl2CpwtKk9dQGjepUSm6Tsumxu7yrtScRR6OhJg7Ko4Uu400peUY0WPJQGYCQrJepHxA1ZO9cJ9uBtfq1BIhZtF3pzKimiMBjTYvgiCmCG+S29aidgSgvQ0Wpch9OLATgwUQeywVbjvopboMFEsj/P7+o= Received: from CO2PR05CA0068.namprd05.prod.outlook.com (10.166.88.164) by MWHPR05MB3326.namprd05.prod.outlook.com (10.174.174.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 17 Jul 2017 15:27:30 +0000 Received: from DM3NAM05FT061.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::204) by CO2PR05CA0068.outlook.office365.com (2603:10b6:102:2::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4 via Frontend Transport; Mon, 17 Jul 2017 15:27:30 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT061.mail.protection.outlook.com (10.152.98.179) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1261.15 via Frontend Transport; Mon, 17 Jul 2017 15:27:29 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Jul 2017 08:27:29 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v6HFRSWW021678; Mon, 17 Jul 2017 08:27:28 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 0BAB91141B; Mon, 17 Jul 2017 08:27:28 -0700 (PDT) To: Tero Kivinen CC: In-Reply-To: <22892.35863.542104.942153@fireball.acr.fi> References: <22892.35863.542104.942153@fireball.acr.fi> Comments: In-reply-to: Tero Kivinen message dated "Mon, 17 Jul 2017 13:06:15 +0300." From: "Mark D. Baushke" Date: Mon, 17 Jul 2017 08:27:28 -0700 Message-ID: <82005.1500305248@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain 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)(6009001)(39860400002)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(2980300002)(199003)(189002)(9170700003)(4743002)(8936002)(6246003)(53936002)(55016002)(76506005)(626005)(53416004)(106466001)(356003)(47776003)(229853002)(38730400002)(7846003)(6392003)(105596002)(5003940100001)(81166006)(110136004)(8676002)(48376002)(50466002)(305945005)(189998001)(230783001)(2950100002)(5660300001)(7126002)(2906002)(6916009)(7696004)(117636001)(76176999)(6266002)(86362001)(97876018)(54356999)(50986999)(4326008)(2810700001)(77096006)(478600001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3326; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT061; 1:yUdvXp2ns+VE3pt9oF5NI/lH8IhD7W1RKvE40/ywZNYUhAd86scsFUIOPay2Ls2/E7/U7kB0dZDXiiIsYq2NjuFaTwqmS4vD/uxwKO7WHJGOCqNQEtaV+RZffgCboqQJah3jpx0kjL4bSCWRcWYoYxD4IwKqxH8CqSSFE0bJadrQ+OO/l2FMM2iE+NyVWLV7xos3fyAP4nxPRQdTy6tUF7Uf0UdsAzj3ySnrib4kXyoLB06MUrTEcPqRZhaFctOYp04iQQxsNX1MWNvNeKfij3X59ybM5tTtP5yLJYi6+F2w7v257bBpja2Nx2OU2B6bwfFmSb2h16ODGer38leffqkb+8pqUtcmgoyFi6UGV+tWVfYM1BA988j0k38oe3LU4JnDKr0Vwe8rojzqXtrg1inef5JQM8Ii2hzg81MBRy6xkBbOki2RBJfoO25AZuJM5bkTeMuObJmpHyitIdsbm0zP0kUHfYFLWgq5WP2XixpA9wPmdd1HnZqgWY/0BMkOUCPmYyCMYopQfhaVSct/4DqCgOqfx06jOp6N+htc5wv4E1MIGNHwDM5EV9ooY8pgz1fcSIDtqE1C4ZxpOh5NuUUc4YcmLVSdr+EcNxY8bdWR1CbJQ7AfsZKv+KVi1WEDl7+xOwSDnyjxsnTeKG6eG1a1mmlW/M9bvjPrNbQTWY/xFAwaGeAles22/U1kDRSrsH4nMAWV5PZflPnA5jjZpldSRdN39g7qpKTazNHs6ilVHZkgaJLKXYYKtJhf0Zlm8CpA52Z+8lDniZkeOg5j5bGZSzGd+x64+uDnGKY+w9NTk6xJ3Bhk1tYiR+FBy5Tau0jZOsTq3qkfsEoqyVvVGStZSQ78HPCWe9/YL0Jk3rQ4AwxWT+eo+77C8cszguhpvZTXpvmdcIi7Mgnz71a2ww== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 468b1a81-dca8-492d-fa85-08d4cd2856b3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR05MB3326; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3326; 3:hsGQFNeDd4mxZ2dCgeRVACzJDajOLpy6ROl6lttreYOt8Xc7qyRuQTyq94CX/zo/5NXuGZ7bPnh1zdYMj8aRW8/2ipEv9Kl/BXWh8aZoNupvb7IniLwoAJAqrELuS9L1eo4x7yWHf4K3nyMUFnilW67rnmDDtDEmQbLRzTIZCxr1zFRvjXrODKX2ag5+Y2gIBNiDjLc0lPL/Cdun9N8PTxjOASb/i8nt5AEq9sr9K/rJ0FJ1BEZanawkbG7dAerd2O0pHwd5THFhOmJZjuZG4xMrZdd3BHpueArCxyRufX3/f/XbN9e8qRHWuHvqKbxWu2aLu2ChzkomOv3FmoAC88V0jZMwLGMRSG8yA69YCs2WWbWr7P/PGrZ1sf4HVEh+V+eyNU+08j/GNeD8iHrdaZlyPI8pza5uB8GPUHYN/jiEnnNK2vrsbjPXImadKwFTMaXqhMuiAWIHt0pY3mMzUcQCmCWkhA34/OORtBk/kr8bAMPpQSVuDU7C8CxcXqeh/XOiQA45RduKeWWH8lt8TqtMFvAf5CdHpXXRchxi/In4eZJjPKry9Ebox8JVfdPN42Be4NQPfQ5NScEMQRIEOLnqlj4gIN54BCgnBOJqdCZGxSawmtkAb7wHcY9kBSaVjC9/geSd3QTye4VTXnIldjUE+3V7cZ95ZB2aXsg15AQkoMq2K2Svl+U8udpznbRXSFsrkS8XLFKDhgCo9Uzx09LtkY1fSC41Sfppmc3pw8zBFqPiGVVxB8Ihcg/IXia2A7cqh19umf6VvjDMH+IJjyxFun5U8bRVovPa6fawaQTv+Z+4i4Wnaahw3nP4BMZgvQFhKjMI0cTM6Vs1tt4sq7Ht4fU6rizJNR4uz3vdsBO8Z2B8BohRfGXUhIQv0mXJe9wk12wfy9amfTMGXO3uIw== X-MS-TrafficTypeDiagnostic: MWHPR05MB3326: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3326; 25:CFBdPyj4dzfafh3PJAAMowOp4UAxAPIpDwiB07C2VbzHbHdxCnReKcsqVRMq0cR8ar6aKtGF19tmCIZDhqv9kpuB7pnGu79FPi64UrK7UJOtmS5NxSA6eWj5D3ke/ic50QUaHTgMImVurVDpldFIHTq9ZE94oDLS5tAh7vtaoQ1EiviQ39yelwY2pX0Hpe7n6s/bJ6Smp4eLd3VUUYh19sl07PtCEcXKyOwE44g97Pur4N4fhchh8+93n0QSTrlB9dw5QNGIcC6r8YsDVoqRr9Dp/nWOTPaxRkCKI/RJagwJI+Wr2GeYUd9V+fffan+DLxjNEq1QbHWRcwbDbax9VR2sdnh/Yp9BCataZE9wQZX3lSVTSmlv/YNlgpJM8dMa8PJG75LLYDj7vmSHx6claONfUzyDDITpAz7JTetZ7ZJI6zSmv00G5VoTl5ns3mt552nCWHwhAzQPYxeNSaQT255YIaKxNL6cfTZBbG4n0C5oEQ3sQI2jyV8R/Bh8bNxqTKuPezKnmIwvWOH96HI12DKX58P4UzbUvMUjaoJoGSAz4FU075OnFQOv5kZrtxjkFdOhWRo4t0oRVkErZQaaiCVLIArod0T9iEI22clmSUTWGlY0npFEfYX6SbJIg/8DAy+i7VCcWgwDfBtZCbs7SPGq3q5tVNmx6q5z1DDOUlz3RAahNNZfM1JDoPpu6DrTY+ZS4Lg9Nwjwejj+mLvOdRlwdBp5xZj0R5brvKuOkARw9Ytm0BlOL5ffQzTvEP9dPXSeoxECANBKzKQHYnO94D0dez1X1sINItw67F4W4FnT4oyKEsnZgnBPNMAyQHLd6geWM+rQcp+XQgfUXqVkl2aYtgfrmtvmRO/bljB1aJxiGwYp8Lg685m1J8VFdMGw9r8mJsp12PjXAgxBlbFg5/ZpZZP77z1fLUVBxZT4ex0= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3326; 31:qWJkx4BOaKotDM3FTDyXU3sSeQaTj3igN56ubsI7Kz/n1qYa95IPcALV174rh8pLRIYWYLHhGPb5EbG9tryueknMSUg368CjI5TibtG7YEd5FV386LDt55hKI3vvdvN5lSNb15HnE63cLlJ8OZwCXBWEw5+OLWt4+BnaxA+rMP8266rM4rrKltQzWUL77/+N2rq1ymm/3BMBfShmfk/dFCUfsj8K1qFImiwYl5A9FUL3mgA19lwrLhcuABfdK9M+CBQ/vA89VvyAIW2RzM64CcLt3leRoS3/ubYjf0Q9b/q87dbjd5pyu+PKP807bPRwVQT4K8+SoZhALn1n1y8IYSxHmIqo99gP3zxC9vyHbLCdEKGWZTearuj+WOCiR88ur5ITyUVYJ3tLfpFE0O7f4oIBnGogr9xn0usVdQbd8ppaVvwVJd4i0UJgR5E4s7yI0BMszoO9iXiFsgNrc0L4e2lcw9Hv8IsTIBdBcfXdnzHpCmTAfMVDPTB6d4LPQZunXKp7SrNwExfFnHB2acOm2QojUmRvdftpdzaF3eCHHVBxkE7FQhwYbhgsyHam18P8cedJb9lpdtMvcqG+UGRKMvQPFxO4dWR6IIr8pWdn7e5ErH3ucoDi2mvb/iGYRGmRSV2XOvfVkJu/NhttGn7VU728fxK8BYKV48m4dsdv+V7eGpMpplumzruPWs9GAH4oAMPwQWFkBzkS28EU+m8Oxw== X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3326; 20:1nmU0AJhrTe71OY0IqbYPjaiPp3oKUd+e6mPVYltdK47HWUTUhzxEVNynp8+Lzz+W1QwhROQhIDKc+HXxkNTXtML4eziP1pIUan5ssaonAUga04EZcN1VxQGsgCuiWABCkq4U6jTbpB4DU2/dEv2BTCe/h2zWYmPRi8UQFCu4gsLdCG5edRKEqR7uMui6+e/CzKYzFzpEt+lAwHwKqWr4UPkvNtpZTn0OUs0OkOfeadcCFd7uAdZhFRtpzn1LT32tFNnaYevooFqTTNJ48MzAEWLi3k+4Kx8MguY7V5QnwFsFLzfWqiBcz8zhnJe/UeCBQ5cYB6PdMJuKoAlyb9t9emKlO+09NuBrWgDs1jGxWVyDSQ7IqozW9PuRZSsb4dQpZ35UogxZBX0JK2iPS8F7dMPqWWmE4AE8dUZ7XCD0OxFCD3VuQMhua4EKkxMH1ge21YmZmFLBbmma1+RH8uL0k26JpBk6g+VH7Bf0uaMto1gAF611Nhvpdr+gNISO/ud X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(192374486261705)(48057245064654)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(13016025)(8121501046)(2017060910075)(13018025)(93006095)(93003095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3326; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3326; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3326; 4:wcRsqfco+doXHhegJhHZFGiBHrMskxU433NquQ0sSA?= =?us-ascii?Q?6r+AG586zIQIzW3WkLjLEY3raNvdxMc/0cQ0Z1o0RbycxrcI+PcQuIX0WP3f?= =?us-ascii?Q?NFKvkExzeX/mCP3ohnV2OlGP+2zUXu6d7ar9f6hTxgzyBdIRn33dnS7wYlP3?= =?us-ascii?Q?pDs2InLix45o56Ec6o0IpL1wHyRuXonejWxTHB4BTJnEjqP5NgvA4AsH/n71?= =?us-ascii?Q?glSO/fWs865WNSUIDbiQIN83moFuRljVrljaZYpDs7XUbbIs+YKWeMdV1i0R?= =?us-ascii?Q?2Lug4b+ZTcY+NxfF5PB6n5hMuR/h2aTrY2k5lwUZ6te8etn3QS38gc00YrPa?= =?us-ascii?Q?8tELk76QMj3DBheNVP+vpcSehiUUAtvLoASL9zLonhn7LA5cmVu/5hOQ8H8X?= =?us-ascii?Q?Fen7+4Agdjaz6/im89EIYoqq3GF3nRS6IZrpsCJPrIauibQM9f6H4j7Jk8JN?= =?us-ascii?Q?FTHuT6muN906Gg20g+SySSYb9yYS7F7tB68JB/5VYnLBDmxBmqtWtHEPwbze?= =?us-ascii?Q?2pfrcQJgxRvxTlaGavO5Os/1vHbo4btak0bIz2n/zBIGVOrgbrv912tkhfYC?= =?us-ascii?Q?qOLKAxlNdjyL/V3RzNU898KiP/jo9jEF8FB7c9cvcDz0x4eWa7CZ8qJw49Gn?= =?us-ascii?Q?ZgIv8oflwhzhLJSROS+D96OInYZG+jr8Wjt4zGMHbeBIfNRnzk6W0T/owjX7?= =?us-ascii?Q?0paoq0TLEQkfOyCy23sPCmxqiZVExA3Ne4us/NxoxFygzzhuooxz8Yph5Kax?= =?us-ascii?Q?bZIVX1j2Ti77IzOXvP8yTLvUTvn8tOge4xyOlYEPRnzac0/hGaI3WxpjAPJV?= =?us-ascii?Q?B6zSREFHT4vWTUpcntn7Kgran00gGwy04xNcD4M44bvcuEKulSrjT9xWN8F+?= =?us-ascii?Q?C7PheqESJm1/UZnCMYFmEO9E2bWnLk4LvwPqTiyhOHQu8osNhQhbKvWIHqof?= =?us-ascii?Q?AdTpAXqFddWY6jXILQUGKBefglGeGPnBP+R76yFc9i7ddQgm9JfWsf1QF/jF?= =?us-ascii?Q?AequFWzoIKfuZFSzRv9lHCCeqivnlfO6NxZlcQTmv28BL1NGvYk4aOIHQEdH?= =?us-ascii?Q?nBjKR3uDJCJZ8ftF3JgT2zIZsfcIkr17diD9UytcCkXfd0sEkorirO1iJNII?= =?us-ascii?Q?ntPYO2AibjNpmdUebkFwQec+1cdgK/gLYBFB6nhKC6SCAP35Mz3gAq65DNoK?= =?us-ascii?Q?qo+y+fSMIYPeZF4GrQCiqap/YgNsxxTy04CWrL0O7roLLfx5ZkNoRkzKRYWb?= =?us-ascii?Q?wpy9GpL2Uve1RrIdWWa4N/o4Ccktuygmf5IGU0xcAQlQuZSeSkDbzitOE1+m?= =?us-ascii?Q?TglnSHKHI/2KAl7ZZUitB+lXYNXmtBz4E5IjuhIVCtrFfR5LzrPBkjq/AKuL?= =?us-ascii?Q?nuzslWwe007QfUdJsk49uKoDM=3D?= X-Forefront-PRVS: 0371762FE7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3326; 23:z5/OBQUvpdtwJFBomUEwEkGvK7Ynu4j4xxgGD4eNo?= =?us-ascii?Q?k5Y+AbwGpOBm3r3qyZ8n/YghAdIMYyspszme7WEh5q47Aykacx417JQujMb/?= =?us-ascii?Q?tUdtefF81sh38Z/UQ7DeCqNCWC7QvOnB/niDQnpEVBtHpjq5H2h90BAaXMR5?= =?us-ascii?Q?GmcED+13f6Ufu5Hwelop3gCCtnZ49Vd0mC9b9RfgKDiAEx2OKO4E1uttYE+N?= =?us-ascii?Q?b8p/QArf1XstTzc47y2D4WvH3a4tUiYeHwPVAndhvkihWmsZ775gUfjUqZFC?= =?us-ascii?Q?hoK1zW+D5uXhsevOxNJ52EhSmuUnBEaqFuD/PAN01hXqUFKqtUDGUxBYb1Fl?= =?us-ascii?Q?4wnqxtiLnQRJoKye1ZSyp/bml4gTD/JbShksUTn3C2uz1/2y8fQM/ilm1830?= =?us-ascii?Q?quKAdW/gIBXmmWHhu13nsPlEg+0KPBRSTFs8HVK9Q4bBgLvU/9b6hyiLADxP?= =?us-ascii?Q?tmarRdCC6JnyF3w6wq43aQ5K0pf5FJNyJBahOKp9MzBIDvJKVAq3Q798KIzN?= =?us-ascii?Q?OLpjFeseWSQKdmFYkd08xJbu0UU+movXjcAnaxYJQrjWReHqmTY3Ads96YR6?= =?us-ascii?Q?DTa4HcSUl575bZLVH4eUZeRW/5oG+1eAU4c4+0hytubxK38tW8gbodzZd+2t?= =?us-ascii?Q?+86cdRLogvurJ1BAXHikZvDRQ6TLS9cNZ+M+uCYJufRwx23MgQp1jvQ6TRRl?= =?us-ascii?Q?/YH+cNRPTqDlgSVjykff6cZo6JUIKtIXJ5iWvq1Kamfw5enpd2puBkJywdZt?= =?us-ascii?Q?NNAzw3GG1vWXbv4WyhBCw2NRfveyUOVWPQUDyL1ZfS2st/IRZSg6cFQ/86IZ?= =?us-ascii?Q?5OKFu2thVparZUQQrPauHIygGviICebSTVBOhmGY21r1QcguPFdvo3mr1i+2?= =?us-ascii?Q?6XCKyB5gICf50+05W4xhEW/barlDj7GDc1ZoTMogdVSYegOgnaPp9ZjQBG4e?= =?us-ascii?Q?NRSYusXoI6PCpVaE6PtF3WSQXRm5J79ErCq1uAZaMuJkj/vO7IUjDrAicaC6?= =?us-ascii?Q?Tv72xGaXRlZ2U+wR2ui1o80qzGji8XMz47BgUC7+mfU0WAC/xqLF/CVDuymQ?= =?us-ascii?Q?tAvmnTrETEW4V1tfjyyfuPRSqms5wmOWyyD+0qak5tYsBPEN9yySum6pzmSD?= =?us-ascii?Q?4s+6WasPp0Jjtt6Vfq+6zV1IJbVUJ/3p6TPg+tCTGi1hkwYxLUYT3Hs48mBp?= =?us-ascii?Q?u3lXoCAuxw7qX2mb7EC/8o44P0hxaHNCmXNY9pOhAbTWqsKn329MurixVxkm?= =?us-ascii?Q?jPFtfldlFAJWrIM9auHuTxh2cgMu4gKMSgLcLz3q83YRxvVjxNlgJwFfFNNx?= =?us-ascii?Q?ya/U1qU7Ve/sNjdtyrrIGg=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3326; 6:wVulzEir3WzGFJqSZvQXbFlg2i7bg+Nigl8nr1Dtpw?= =?us-ascii?Q?vLbWKeo5gX2Lop5hJThjOH5qiwWyBUrlLDNBKjylAOOQUVbQAlToaGn6Qx+D?= =?us-ascii?Q?HKVEUVZivBSiLfz1u+rlv4tFAIbKWJ7Br7hfR7zYXiCTd2jzXDP6u18RbwRj?= =?us-ascii?Q?TyGcW4tcXFJFcOU3mqrxC5D/9QWY51MBiafVauyMWQsQw78f2iRFmc/fxw2s?= =?us-ascii?Q?skL8UDWV25eeTkSxpjR4w3VfduxLeI/t5sxq6xXYlGltpaLZP2tjhq2TB5y8?= =?us-ascii?Q?BHCX8YGp3yr5yz2UwK1tniyUuM23xfHG5n0lVkBhlEHEROCgSg5mKQrS3PNc?= =?us-ascii?Q?f4LSvQWNQVFWsWyLCRrKoA406vcVskHe6+GEryP1mkR+KZTUd8WwulQ4in7a?= =?us-ascii?Q?I+6tfQ5b5V32AxqKNwh1Ai4XHLOsUCzSryVmoFrl619dgv09XBQDBNpvpbyM?= =?us-ascii?Q?+o5ujUDt1VxdRF9+oZN8g/y21OZmf1hwTtj/mp1hhda5YuL72vVIh69zCJX+?= =?us-ascii?Q?wdga7AtL9tu7l3HA0DUvrzNHrgYo1ycMqK3biFqFk6p5Jpv96l5oMRzY+2gp?= =?us-ascii?Q?0thYrMcr9Lpbp8UDYdmzcfSJBevPZTAi6GzeOMjCZ/o+9//qBwk9QyUbU9w2?= =?us-ascii?Q?BnF8j5pNW8Evn9dlyu3WMialRt4WBqvT7wrFQNj5bs+JZz6zq17+dsKYGaJB?= =?us-ascii?Q?tp6Bc6H5yDGdkRRW69Xl9ifuIcBla8Jiy2XUL4q678O2+ukUmUIZ68CBM3ch?= =?us-ascii?Q?GXc4D3WFw43wP5z/wnSPJw4EBr04SwInVfobGPTLEK28NsDgNcrhfjE263T5?= =?us-ascii?Q?AbsNY5eYVVBqikBvcSfm0QisS1sjq4CV68ilx5bZZ6E/NkvPk4wzmoKOGyHq?= =?us-ascii?Q?Nwa/nlJ4qOxkyeefRCa0wqydVK3JVY/tH4vFbjoecgdwS5iDMv2npS927ey1?= =?us-ascii?Q?RI7nDzMGEwUf2I/Tn6mgW113fL0ItwFZf2qgemhRw2ZzuzGPOoumRwFCefCe?= =?us-ascii?Q?xZf9RVfoM6AOu4Nn7maVAa?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3326; 5:j4CVePWkR9geFY2a6sW1GJ66bp4VibXs1f5sjndXr20cDvoc9rfRHcUAUncKXYAZeIXlilb9NgX6LLCRXroLJHSyS+4iGhcJDYE4x5zL1Q7f0tN73pQZsRA2G4je99HIyT8+ui+vuqmReJgIgK5Am1x3GeQPuKfHp6HEWEW4lyuWfmKhKtrTG7D//0NvUQl0duJdnKr7X4cVunxCDlb2N5jPZlcW52lOHDif2qiPW7Y/ldV1bn6OxNoFXeOeQI7O/WnLqQDdQZ0FYRwsxISoFh9xkNB5EMJJNYxAiC4AMml6T6Nqfi71qoh7E03wBJuq4eqEfuBChSmypwbnk+Uyllgzr4JpSjjyAkiH9d3Zh0f6vo196vSZR4Y7q+nwZqmI7YbwM+BDDlXkosWAfxi8/w3EdYYT+bZwp9SvzMt4Mlk7jyodIPbz10JsblWXWsm9JHCkc8hSsnlVemcSkeF+8m6vhyFj9dcugB6nvCfd21cLYm4pXMGmNOe1P1YZsLw1; 24:I8hhriO7+Qlt4OC5TANuQG8wu8aoTx88JVzdQQgpeKNfj1sfpCRlFnHRMKDREn7cdB/OwT28PulNKybVdJVVw5i6WQF2ZZdQpvZK7ecHWo8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3326; 7:4QR/D2p378FDXUOMj4C2KeIB/TpI/+cm65HUFMdp1ofwUgB2QE6tvA7LLZnVDOS13h4+kxw09qXUggIqzrzx2xSRaw268HljyncHZrcmvKMiO8XypSUXKu7de/jMyHIM1FqN+DKQddyWUDWn0ewCoV1wqfxdcmbG3UzeFnzLtMnlIsee9CCYUPQ34MGtOcmCERveWTLy/TMZcNbPmQ1HFLBrKhVkwstLqTVsL5TJ6hURvTXUDJfenh3XtFRcp/GmBEc6SrOGLwOSWU9BDnVlnM+Dg0nkgwirO+tH9bw7wxzZSOJ30Wr7wR1vI44sF8yDl1+IrGG4tSRBwYCX6f4CNxkhYRpQ6ofBqkGAbODwt/Usx3x3Ou3lE+3HiWvnEWIV4ipGK1aFYwvjTuk2MO6i2a5r9nUnuPs7OGlRcEe+QNLTlGnIz16w2moKHyyW8tvat90usTjntnsa3U5wIH2gQpJE95W9yej7l4odGzYzjzfLBMOFSJueiYgZsUL0o0Dh7YOqz3J7xwpBfjPUceuAXFo8LcuSSAlj0rQd3apao7RJH3JVCMs3HPZSaAwqeW+8gAsnNgLOiy950kwesWoylShFmzyZvJ9pWL6DXVrIadBEiwcmDAKxsoFzBQ9lJHYRVC7kxUb7YXnVSYZmAtD8i3//cX59c0yR+JUOaZlsuT+C+fmppivVBxFql+v9t9fULk1ZL14jjnrdE7jn6r/4Oir7ldmyBxbA+751Tp5/SXBvp5PLeNwxiIG8X+MHI7VNN2VSR72Ci8SXKOrzBFqIwLHUpIe4OWHnnWuRQUlPbfo= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:27:29.9978 (UTC) 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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3326 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 15:27:43 -0000 Hi Tero, Tero Kivinen writes: > I think it is bad idea to go from MUST to implement algorithm to MUST > NOT implement in one step. Especially as this will make all current > ssh implementations non-conforming as they do still implement > diffie-hellman-group1-sha1 even when it might be disabled by default. I see your point. > We are defining here a MUST implement and MUST not implement, not MUST > use and MUST NOT use recommendations. For reference, there are five key exchanges that draft-ietf-curdle-ssh-kex-sha2-08 marks as "MUST NOT" Key Exchange Method Name Reference Implement ---------------------------------- ---------- --------- diffie-hellman-group1-sha1 RFC4253 MUST NOT diffie-hellman-group-exchange-sha1 RFC4419 MUST NOT gss-gex-sha1-* RFC4462 MUST NOT gss-group1-sha1-* RFC4462 MUST NOT rsa1024-sha1 RFC4432 MUST NOT Of these, only diffie-hellman-group1-sha1 is moving from MUST to MUST NOT. Due to 1024-bit Diffie-Hellman being considered by many as having too little security (the same would be true of gss-group1-sha1-*). What transition period is desirable for taking group1 "MUST" to "SHOULD NOT" to "MUST NOT" ? Is it possible to codify both "SHOULD NOT" and "MUST NOT" time frames into one RFC? While we are on the topic of this draft, let me point out that the SHOULD- are on the way to SHOULD NOT and the SHOULD+ may be heading to MUST. Do folks agree with these choices? They are really more of a guide to best practices than they are to implementors who have already implemented the older Key exchanges. There are three which are marked as "SHOULD-" Key Exchange Method Name Reference Implement ---------------------------------- ---------- --------- diffie-hellman-group14-sha1 RFC4253 SHOULD- ecdh-sha2-nistp256 RFC5656 SHOULD- gss-group14-sha1-* RFC4462 SHOULD- There are four that are marked as "SHOULD+" Key Exchange Method Name Reference Implement ---------------------------------- ---------- --------- curve25519-sha256 ssh-curves SHOULD+ diffie-hellman-group16-sha512 new-modp SHOULD+ ecdh-sha2-nistp384 RFC5656 SHOULD+ gss-group16-sha512-* gss-keyex SHOULD+ The draft defines SHOULD+ and SHOULD- as: SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. I have received one piece of private feedback that the IESG may not want SHOULD- and SHOULD+ in this document. -- Mark From nobody Mon Jul 17 08:46:13 2017 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 80838131C73 for ; Mon, 17 Jul 2017 08:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-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=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 KWcXEAdmzP1A for ; Mon, 17 Jul 2017 08:46:10 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0131.outbound.protection.outlook.com [104.47.38.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB6E12EC12 for ; Mon, 17 Jul 2017 08:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zzjPS5/xJ05zVzJ6iKsg1WU0sxsxTjQOBFWq2mta9Gg=; b=KjKRLoM2srB9acIXDb9aRAt/OvARvQFH/ybZ3+d3xi3jkPR6gkZzMn0h9qmXgVXCRQZeGq4fs5t99ZhmAsAyibSqRHrPOtmjaqfjGW5upJJr4ai+Y+ubmlGLls1jvvUm/SPWRAfk9j3MVm8DOcBGZCfTLCt89RLpMC/SPOC1vOw= Received: from BN6PR05CA0003.namprd05.prod.outlook.com (10.174.92.144) by BY2PR05MB2312.namprd05.prod.outlook.com (10.166.112.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 17 Jul 2017 15:46:07 +0000 Received: from DM3NAM05FT063.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::209) by BN6PR05CA0003.outlook.office365.com (2603:10b6:405:39::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4 via Frontend Transport; Mon, 17 Jul 2017 15:46:06 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT063.mail.protection.outlook.com (10.152.98.182) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1261.15 via Frontend Transport; Mon, 17 Jul 2017 15:46:06 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Jul 2017 08:45:36 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v6HFjZR6025578; Mon, 17 Jul 2017 08:45:35 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 8657411446; Mon, 17 Jul 2017 08:45:33 -0700 (PDT) To: Tero Kivinen CC: Russ Housley , In-Reply-To: <22892.44221.173699.599992@fireball.acr.fi> References: <22892.35863.542104.942153@fireball.acr.fi> <22892.44221.173699.599992@fireball.acr.fi> Comments: In-reply-to: Tero Kivinen message dated "Mon, 17 Jul 2017 15:25:33 +0300." From: "Mark D. Baushke" Date: Mon, 17 Jul 2017 08:45:33 -0700 Message-ID: <82617.1500306333@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain 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)(6009001)(39400400002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(2980300002)(199003)(189002)(9170700003)(50986999)(54356999)(76176999)(345774005)(2906002)(189998001)(48376002)(117636001)(230783001)(77096006)(2810700001)(76506005)(106466001)(5003940100001)(105596002)(53416004)(97876018)(86362001)(478600001)(4743002)(7126002)(47776003)(38730400002)(305945005)(110136004)(6266002)(6246003)(6916009)(2950100002)(5660300001)(7696004)(229853002)(55016002)(54906002)(53936002)(4326008)(8936002)(8676002)(356003)(81166006)(626005)(7846003)(6392003)(50466002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2312; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT063; 1:TMQHldUosOP4PqS+p/zK1rtaDBVGOmwmdHbmtFz3bW4daQBRi6bV9PmgZ2f9eOsUvMm2G6PvSX48h10DxJLsrLuQiNxx0kBm7UBt13EVwh6+k9OtuwF6KPuuFpaAE+FquO8KCkc4Yo/H/iDQmawyWA832S1dMXcUPYuYx2awKW1gfAAW9RjuceOvILCpl0WzROFSMk8nQOti61/ArXoFqbk74WiCKAbEZvAf0HtWEXt05mVsb/VHRfoL9zs/qfbWUfQ0s6Qk8ONgkd8obrT7MQUowRd7Y3WRVMb5h37Wn3BnJf4isx5iiz+6tvQArm2vUi/GQWjUaSe1wFLyNtQ3pqXBtcXWMbyMEAE8HCHPOPFZQAnF4C8gm4WTNFWM3is5mf0vH4mvBIshMVXwVcIbra/IWbedmRIGcL96Vqe693347qtxDQsdkEIe5YdS4WGm2ro8zqVwJrMoajYWHbe28FjGBmgM+8GBbcOdCo9IRiG6RSInmxjjshaoMbed/jaKohHAy+RjvfzsIoMLYIQa3C+0tzgja1e2bmHLiJJhrYyR2aaiEjQZXhgnKI2MEYLQmz5Dz75royDnv8pI2HVrpewFlX/maxnW1lp2LtA2Q4RJwnlKA0AFN0497FYV18Dn/BfFzrt8W0eSBeeCFmb3l2SxPPa+OEUxt8dlAB8ywVj5QUnp09Bolvdnfwjx+giyVBPnhK4p6rznlDwz28AQ5iaQ5dYF+SY8mvn70XQNnnpIYQqQaT6veAQfTTNi3sWBbSVm5IedKWpp6FoU8VyGbUsWWM5+aFPxfW8g8umwjj971JvC/G+xncozaZq0zFwqNToYOxTuKu3hsaw367h0pKl9yjJture+CDefgw1Osdael0cYc4hhDykGkUWlHGeVLVdcoQS3J5qkKSv82IMvkQ== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2cd04f95-f3f2-4519-0e00-08d4cd2af01c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR05MB2312; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2312; 3:DuwWiGC7BEzfJjsbisSK3vMzNbTheiLR7OGFDmpJdDj5O6kwlmSvWuS49EvWGX3J5K1diZ4zgs4tuIYSul9KtDZURp5uHJpj+niNehtK8r97loUeX1gxV4g7oSvY/i96yXYg75nBVu2vg/ey+vhi+jjNZlXGjq/iqC3Izt+AWBuWFI+IqOy2CTQlr7fbK53E6HbWBUyrCJPhGA0exvym4nWAzibKOWsTJQ07o4SVRQNZv0p42zw0+jleguhhJDl+xXvqOMR8R6CgvLvqch+WZy/If/UwPEbIq+yGdQdH6WFSfaFep+UVctZCnogV4bFp43tj4f2jyC1UoTGqDrf9gxEQpqqeqI3F1l54iKBB0aIHOWSntpY2SvHvZcjTY9LK9W/n9v7lZCPTY8pHgX5ZjPS/d7LdP9uglaDmJz5C4Q3dHY8SqDU/y6Na3oxsV7Ty+D9aLsNSU5QhCQh8zEda16i+wYXL9RMP0ASOU4OZCvZ43NxCUBPrH6blkNb4lAAbdHsNnrquuqH25dVIpo0gGeVaZc1cOYQT6rbJcxTQd97Ynp/e+hHC+PNKjXot+YLcUZnKlPyR5CoCWIOaUlmU9JurVAwK7aGtfHV0VtTpzZwmWgUayZDeVbFKBrExmrAK4FzLFlSuH15VE8oy81XDYZ0W1Y3tnvu1dKscW/mqM60xyq1GCkK64EOc9XmVmh62jfnjDNbOnP63Ael1f+drVIFvwe/u1kDyqN+SbZvQu2CLSBSvjtrESwYHcONU5Y2+4Lm2t2gnkpejnPpVp0/D6RqQzuXne0+I9zxKIlx3fqMzkXbEKx80VVFiDp137KQkSVCJe0i8hRvAnyMVYSk88HPuiOmsbWaq7X9WpyMCteav6svkPHMqCZ59KPETqLnw/w+O+dzMNDAFrHFffIaYOw== X-MS-TrafficTypeDiagnostic: BY2PR05MB2312: X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2312; 25:zXcJ1fNE7/aB14h2iB+htSMWbu5tO5r+Y7stCzlhpd+fuMnrLBmHxCPrLDkrzdd0X5h5lZ0SG9H8vQAt599PMQi1qs6TwXQqhHlJeSaffU/Vxc3QAVVKSISBYb22wbVpr0sGTZG+g5RveEMX/i/QP36oC0ShL42YHPVDxMhMSaPki201HrK3r5F1Ejw5vGqv1BdNDpiB1WNLYqbauGpJ3nu5yHyQ5IDRvR1CI0hauBB1E0+WASYcxLIq+j8iD4PQX6YfMOLQlBYsmCQd3dYkhD7fhntMwnn2Lt8L9m6bEpOrRcKA5d1eHle/T0/tddtorze3Mrpnsw/mfNKjGgM2HUSh0Fad14FQlK5ixk9WI+Q2TPDM/Z8PCU3y/Zo6Ykd3NCNt2rbRnYeRTzK+NwsEQ8VKQMa8NCI22bO5855xVbys72885H3jjNd1diTa8LsIcSAxURFwjdtFEs8qpn2inxjMG9whQqaV+MGRF4IqB++zMJySkB8fh8U5CEwLxs9qtKhS1l5dcqRlKol/eRd97rXDKcPoto+RKPeucFz1OwTrxrMG//8VbQu1hHraci3ClsmtV169TQDbRYCxnIoMR+0QWzXANEM0EF5Pq1PPE7PsVED+7PIBoGQBt6TAmE/S5dq8YCb4RLvq2qRAYiVl8zhnygbvqpqv56nZMBfb5FPcxZ1YqLhN7oK8YiH7/bxML2/sUC94+FPmYFfw2C5QzbKbOH/no17D7KXELQTZ4SKSgZMwqzKbfeVnuGz2lJ3X6MGb3S6py/tNoRQ5yEzfEX6oRDFj9IqUn+7gXKZEz14Ddhc+fbpbf0ek2PjQxTx8VsI0k2sE+qdiZQowa2yV1ADYmsR2mN1bQ6KTmwmSYjH6Ac4iadtlN2eY+ERdDBNgmyssmx1atXyIM7p2rRncnFjckwoFpGtthFqEyNLV3HE= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2312; 31:kdBPjDAFD/IDzW5qAgws7TpnTnE2vvZt1O7pyGUSTH+RWmVcxG/Nz/i+n6zZQSt25FExV4gQxg4WNFfZwhaF6YUHcfEMdTSdcBCSFKEG7EUplVNmt7VTYtcKnBVC8v70l+PmWWmPSfEfesuc8q8+8RBeGPwwYao08skqyP5XOA1nrt7Udadl0lMAqx6JeuRGbqU8B6idluvNzlm1BSJzqbSp1+4hNU3/WsukCadm0wnVARUpA4QTK22Kk3zLlhfU4gTO+CZ5jQS7tH/31Io/nNMoTfaY2KnpSQc5OSvMss3vJRNlmOjC3sfl4eJtP0xJ2MMG+BmcL67+/z6pVxDILgrWQFStGnS4LsfsWY/AL1mCvghn3FrewmX9Ltw852kUrrsnb5RnwIeOxG3QyBJz4o+BqpWxrO1GbJ/3bzz9+HBVwzdP0EEbld8gjlmcXUFu/xe+pROU4bw1jdN1UfdpScgt5TDqKwNMgRtelGEpB3LYFzv/yEXcD/s/wM8SrYxyTj7PGijJMW+FQNvbfNqY3FUwiiHe79C2Y2TWwygkXgIX0u5rJq3VYL6jTAK6O9pvJJb8AUzj9O4tcFcuwgnIq0vQKZrT6m1gOjOmcrKVDVAgxurA4vXPHz+7mqEhtAp7E5hiTITHFXZb/QPv3u5KdO7gapo8wdluwJuRseGvmLKU67Ve0QcFnPMDDQN/TH2DiEifHVn8MaYVzhYcIm0Z5Q== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2312; 20:zw5VC/kv8Xn/YCOkWEr1lS09SJynxwjXOYVVVDjB9tA6/3B2SWJtpGz+bRC5dRfq7Abtt2tad/YPqYkU4dEYC1HZgiNROgfR4WS1xX/kl9WZykdUgNa/Jr5gBS+ZOVlK/84G4Xx8RrJ1E59NchswjwTYfKyL6ecxGOZKBRJSyBS1yYn7Ul9BQa44F0nuaxaclMWNhtdi+cm1S9lpVe4W0b3LAwwi+FliNpiMxR1qxWOXzrLD6hywI8vlXFsVGMFJpyHS8bblHAZdHZqiRnmz0L0ye6W9IvSLlAXmj2vu9VJRDPWANl/PrVNvtFvKe+5WLk/yN7Lxs4ugynjftYvi/tx2x07DZck9XeEiHswT0+/CD0Nyx9Q33/q2K+gm2vuneKQLT9U6B3ohvp3IGfu4oRVQ643IuvMiO03yBOcSffsNO9WpCw4cCVr9p2ViR2y4ckc+jcg+Zpx/Bel6ZXz0tn3+TmkIeR3aoVPt4OzzQOQVplj3L799uBElyRgqt+DA X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(236129657087228)(192374486261705)(209349559609743); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(13018025)(13016025)(5005006)(2017060910075)(93006095)(93003095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR05MB2312; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR05MB2312; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2312; 4:n+ZR6zdJ8ZkDZRTKFTwKxhExQJFZSItGh1jJNTzG4e?= =?us-ascii?Q?YT+W6P3Pj/+AMdKn56nvbvxEUtoe6LMQudHOBDbe+YnAfaEeiVRwV75Z8cs6?= =?us-ascii?Q?uIVBGUVLCx9ZmHXtmx7/VnvoOO1pQsaKEgz82kreS8xCutM1HWrFF1z7plHu?= =?us-ascii?Q?Cg5AiVnwX2ZsT29m1OKs7IOR5d4XsIuthhDQ0JMLZ59IrfTwg61zY3k6XqFE?= =?us-ascii?Q?ZGKdtV9P1S1nhLmMu9BM8oNoaVOjRa+XfWfsGnxC+FlVWCQVsy8+R1iwGgtb?= =?us-ascii?Q?485QXpqwGKPXlWtRXbUAT7aqhAlsAJGYri2JGI9eb0XVSqM8uRkf7UrwjdqU?= =?us-ascii?Q?kNI2I06jCZ8TLFOrGOfmOgVZ1D4q5S91h9Hcj4oggVNiMiF3ZYOdoG20pAHA?= =?us-ascii?Q?EBkYxxn06rJTgMp2DINRxGMpUWplTMiQT6j5ZbQsL9nYZFme7djTNSpmOizK?= =?us-ascii?Q?i6GpZG8rd+TMfA4Ujg1w/RApf4H6TAeX/Ko7jDRskTGbpIQWPLfH5G4FGcZo?= =?us-ascii?Q?mEkUCO/89MmoAa6EoBPcQ+M11xwDyJJEpeKtvSrEhEMJ3qEVPN2tp62r10iO?= =?us-ascii?Q?Shwa84IrTxFp5rAVz/08r8EWyJtzh2uxkYZgAyHW9MaNyGBCT0l3mNgaLo5X?= =?us-ascii?Q?sIGTfKFo4xXyp9Cj13fUtOZqlO5ay/HRJYerQi3Z2SgqCwTIb16jZ83EJrlx?= =?us-ascii?Q?edXQun2bVD7fmDop0buTKDRGusHVWv6ckzu97gTbrPz/ll62cmL5U+bNasLQ?= =?us-ascii?Q?YICg6wfuCA0aEttbXOr8tJMdLf5pMcJ3vlrKWKj05tA1sBrUx8/N1tirhVR3?= =?us-ascii?Q?IEESy6nRQkKred9EX91MWh95X8xVcAcQpKJwi9BI7OMtR3deLwzzKsjTKgRr?= =?us-ascii?Q?5RcZR3lrmvd5HsU83ZyREEYA/bhtkI07IAf8aFQfDN1V+tlQ+x0lxhWz1abT?= =?us-ascii?Q?NmMImBB0Xqhebkp8TmMe+yVb8xloyqYBcHcxkinIqxb7wzh11dcyoDHdRGFb?= =?us-ascii?Q?VgrwTCxab2wasCFIAo/8oo7VTbIQ/96hJG0G9MXpSraZNaD6DmCLEGlelUfi?= =?us-ascii?Q?66wLAfSG3l3hrUSpI+GW6oJF7b3G8446XgRMI7JeKDP6mCspw3mKX0gMms74?= =?us-ascii?Q?H6vRL8uC2xs+QlgHdUQc0Oi+aCBTl8dtxxArlRC193FYySPFJDB+k/9UZVUc?= =?us-ascii?Q?MmopUilK1fdFpCuxPwsuCkreg4gwxgpE9b2o2SQs99WAfc46y85TGYusnhmK?= =?us-ascii?Q?cSCHWarqDN7ROAlmnhxuy0u+5ap6JPO4vwn57GjIbDKsr6Y8KsMcxFuSyinL?= =?us-ascii?Q?cfEiOM9v9amwv1KczgpqqKJZ2iGY1UXyMoayZNFwAJ+w/INKLtq0TsgkbFhe?= =?us-ascii?Q?Z9wPYR+nae0soQmsZm0VgQnWE=3D?= X-Forefront-PRVS: 0371762FE7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2312; 23:JlNwL+xBdsYqw4WFBzzH11CHl6RRWeuBvKeswD5T0?= =?us-ascii?Q?4r5SagtrJ1tDaOjFOZKDecRYiQEuhziriaWOR9A9DSRBjboNvw7GqhvRvnr2?= =?us-ascii?Q?TXJsyeNNLg0rq2wizo8BK+/V+TYBh/JCGeDZ+vIG0s71C1ve/mnAL4U6+CAA?= =?us-ascii?Q?fEreAzFOsnqiImYlaLOaED5iAnbfRuVy1n8tJUQm44x0V1jnHxKNd0JTYnMN?= =?us-ascii?Q?+A54CPn6t30PUUSapQ1NhqRg8ZNQ5eX8DZyOFZnofgbdwDyrq9LTIyc1FfVb?= =?us-ascii?Q?8UQlMEw545Ri4YJZxuNPEOHzooIEuDphjZsN03gwsezrXKDcDoiMovY8xHdv?= =?us-ascii?Q?B+O/d4+5mN4bBq1RM0saC67FU64B8nWqxKqy5/InneIIEC8lQk/LylF5isNr?= =?us-ascii?Q?TJCyft09eEC2/K7SejxhYlNs4jpySFsTacB66mAzGL3PlxVxRmCqS9E6YYqM?= =?us-ascii?Q?t51E6UD/JOANSBIPJI6AU6pkn6XNu3EROiALLNh85PPX0S089aweymEmz07h?= =?us-ascii?Q?kIRPNEjy8WnKDFSQ8b+HzyKDG5QyxrBixhFxZB6fPNHzViYi2wnX5OzijZf3?= =?us-ascii?Q?zwJNS7aG8vA6zSpRcRGRfnCzE6xzqeRdleueU3CNzFvNcl9wYWa5RwC0RY3l?= =?us-ascii?Q?Hu15WS++3UUVyQ9JqBSgc89ImHuOdl2A51cer2zmy76e743SxLrQ8/JKxiXe?= =?us-ascii?Q?y/g7niZ52ZlZgjTOAcJiOfn0eMt9JXglH4zUZ4kywRiCX5pIk2sCXvm1KiVw?= =?us-ascii?Q?f/YXo6ZpNYjigiGkC1Nwb6ZJds6PfZ/C+5JW60prqDQhFhn3ARAGT/aAzP05?= =?us-ascii?Q?aZQ4MEXx6d0s0WuwY1H1JdqwLvQ7VuOu7pM9stllPLgeWrPfEYnXaCaz+Uwa?= =?us-ascii?Q?uJv2LL/6rdOTjS1ZxPa55PdNovLY93VGD3ZT0nFscxwPN4mwQOdO6gJYPRw7?= =?us-ascii?Q?rD/pBU05hlp65vCqyxFAD16i+47t+yiEZWloKJ1U++qUxbOFmPbwxFY2+yNr?= =?us-ascii?Q?N7yJr85jsQxCZGFHyy2QgUzWObjxhciAueUrbDcaSt2UrodFy8XRL8m2piR9?= =?us-ascii?Q?3arOkZ+gpoOYuRABHXWwvOUo5UJxV5ERS4Y2GioyIMddmcgHBwkvirfps4gt?= =?us-ascii?Q?HFSq+wvZIeh16v4yoqB+Ec0dbokeoGaaDrNCF9457x4S4HqfuLKEISelZkH6?= =?us-ascii?Q?CevTguYwVNq/sMjuo95t7hMUyr4p8z3uHPmpunVD8RGcewbWDvUIFV4a+tQa?= =?us-ascii?Q?CtkJFBtXlZltvEsgi+0EYVvY0wn62ugDUHe4g20Iqrs3KYLSzK6lQOehYxfn?= =?us-ascii?Q?XfCb+i/RJeYLA8zwzNnclglvsxmjsRsWEjTSUx6FgaYw4gNWDN9/wVaYlyU0?= =?us-ascii?Q?s/jPA=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2312; 6:X4gIjzwyZH+kwV2rEqXgbwnK2pfk7KUeO8uRLZi3XU?= =?us-ascii?Q?SdLcfrm3VcruMcvbjEl11p5wVlx9P2o4ow+7qXktuiaj+8UlF70DAf2dWF01?= =?us-ascii?Q?0qZBRRgH5Dsnn0Zs8ZKY6wLKYADljEClb9Foli6DaPEECzeuCDbWOGuhc606?= =?us-ascii?Q?D1oWAMJTj9WhpDNi4pc8vfSJfM4irN3xXxsb9ro26ZkyF+XPs+ZlN598aofO?= =?us-ascii?Q?X7p54+6uIIvA1FSJNb82ZWCbTUDSc9uhOXqmx+h2T7uuKaqP4SfWWsyEzSz9?= =?us-ascii?Q?JSk7x6A2oLozat7EyhZDuqEtZzGGQEb/m0iCsV5p4NHPxhMjVLqRDYfOzCcr?= =?us-ascii?Q?hIoYyJEoytPYYFs3l+DLIx0c8o2XsHHdNr8g/VEPh9JDh/tqjgUGULCRhTMf?= =?us-ascii?Q?0JxI9KhlHrya+VG2uId2gV3jSEWNokxqd3q7ZS2hu+JeG7Emn1cett0MJymO?= =?us-ascii?Q?umf10CENfeazF1RZgBNkgr8uVmBM6M0TllzJ/2Hxv3V3xmPQSIc8nMnAfVOe?= =?us-ascii?Q?orBlGOVAFGLTnyppMlZu9F8fn5m85oGT6/pkBvtEF0Cs5OCk1oZ4aZGjL8nl?= =?us-ascii?Q?9jioWSzBXVDMbNmoaQECsGCR7PDz6yEukPSXNnde0Pxg0LfDor1uo4VKzraT?= =?us-ascii?Q?g3nlOXC2BU2nEk9ZZB5mAX4nc0NkV2IATViFBKtbiepZMOpPT7c6ay/nJp9N?= =?us-ascii?Q?aM7MLc55JqCoz9S1dHnFFIw0sOwR7uTxAhTZRV+6kJPUYansL+DvlHYp721Y?= =?us-ascii?Q?J9XXtsuv5sbb3gYOmgRb5SgXinRjr2pzjd4bikvFXZkQsDF2t7kVpq3FyR+J?= =?us-ascii?Q?qeyU7MODom38shMgbCAN9FqI16DQ03vei3DlQJUNThfzy25RdK6MVQor7Cpa?= =?us-ascii?Q?8SlSCITdNpNO/Mj7l4dNMXCmTuHl50u9VkLy+hV3B0L87LMh5oeaf+rIDxAX?= =?us-ascii?Q?+OfbfJBJ9RsieB3cKcFBc1B+BKxg3ECy9OKyjod6XAm74n0DglIrBZxSJgF2?= =?us-ascii?Q?5dO2PDwLeKqmp3MIh1V5t1?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2312; 5:+ZLC6nmuoQEdV46Z3ZQEAe3daIcRGhAM8HGjasg6tn/WbSVjfq1PzHbtiN2eAiVR2wGGvqaXf8LxBWEl/pGsEeZu5n435lAEHEWmDgeQYYDOUMTxGFX4m41TlnLPcpfSVEXYrhV9QHSk2OBjAib9rUNbgBMkbgY4d4Q9oDyARzWVhH39Fs5VXaJY/SCU6IjomlozD7Rk0Cu3U1F/P4kyn8V/Ny0ZFkQfObZus3I6D1KQy/sShQxWYM1aOWfbhLwRW9KhZ1l/RKrSJ4Z3teMBtZzwwUuQVU+tPdWuVciDqHrnwhcCW2/bKklBLcVgmkAghQ9z5u0woHeCoPBpppwkJ+yU98iFj4TiPJUGjwKhndCEBb22v6OnLcJU0xqDLqarKzDJppiee7AB6X8NkHsXai4x4cXLcan5cw2IzNiiuag4Fs4mam6RnRF908RfV6CJkCyL7+iaQheDAh3pNWFWkVBO9f+dJkfcBgP2YVLlcbFtklNg5+iPPppIF9sQ9DfE; 24:BjhW0vavcvKA7UMCrR/p5TA6eZXT3IZzqvMGFc9HOz+qW+7fXnqeTpjMxZtH/hyvp+1WCcYcm6Q389gnJIW6IPCcE6iLRxCq5L2m6dRFoxo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2312; 7:GpNRRDBrxQ9tf4PuPNUXPhFFkT0h1vc2IfacLXUgZ6MxssS9tYg6mzbzV/pv3LmpSdGtX3dcYvslvVWsh4hNS8XskuwYhbpGMJCxSFAKiLrQNLG62HWyhsPMBQbdIA1pTTW00a/x2pmTV+paRfdKM5rB0uSXbN9jeTeyvXxVIJlhsY8WHgk68ef6EW2N3fxZBcXddSu/WDEeIE9MsXdt/ekv4BlvrGGa8e7uEC3ONSZHtBZXIWcsFOpZYdQyNNT+YORb9Z4X6f0bp1XO8r1B5oEi8lgcMGTfxNYYl0/gKMhLDhxzwiJWty8A4C2dgxG3gH8d2xp8ydjgBKAYjwAPZigzQkkibW3Yk+Xl+/xcYVTnycB3/kLkY+CA5DmmO+qU3eUak/bQpV6s5WUfcICaed153qppZV6VWp1wowz6Wmb6CKKQIeABfyiO197P1w/+KDABACa3/oLjAwlxEmod+Ogjet0Po0dD023vqJbYtxgz7t0obyS8Q4wBAt2jGgjlxVyuR01+PZubbGLFzAjsGQ9CmY3WD/qc4Op3aWgPYy7vshePoQ2EskcaXF9KxX5eSurZ2UJSdsdIvi/5gsLbaYHmUlX6H/dqbd9KcZm2SQyLRE4TVlkLNEylteHmNGBUUuKtOYcNOtXckKJI9PIc3n2ATgE2K5Ci5Tn2PQL4Rzu4B5CPplIeaJX6orJDRUgP3zTjVi4VdVJhoV3MDUJuwWrhfD2nFKT1LBQbHHAQbQZl2zlnxeWbbOEhDzeEbPLQFhe+0q/b8XjO08w8d0CNbg6VXO/o5VwtTQw1Sfh2f4A= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:46:06.3648 (UTC) 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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2312 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 15:46:13 -0000 Tero Kivinen writes: > Russ Housley writes: > > I agree with Tero. However, I like the use of SHOULD+ and MUST- to > > signal to project and product planners what is coming. Thank you for the feedback. > Actually it is much better to explain that kind of things in the > actual text. For example: > > 3.5. diffie-hellman-group14-sha1 > > This method uses [RFC3526] group14 (a 2048-bit MODP group) which has > no concerns. This generated key exchange group uses SHA-1 which has > security concerns [RFC6194]. However, this group is still strong > enough and is widely deployed. This method is being moved from MUST > to SHOULD- to aid in transition to stronger SHA-2 based hashes. This > method will transition to MUST NOT when SHA-2 alternatives are more > generally available. > > > Gives much better information what to expect than SHOULD- in table. > SHOULD+, SHOULD- were useful when we only had table of requirement > levels. Now when we have the text about each algorithm explain the > reasoning, those + and - characters are getting more and more > meaningless. If I add "SHOULD NOT-" to the list and move diffie-hellman-group1-sha1 to it with this text: This method uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 [RFC6194] and with MODP groups with less than 2048 bits [NIST-SP-800-131Ar1], this method is considered insecure. This method is being moved from MUST to SHOULD NOT- instead of MUST NOT only to allow a transition time to get rid of it. It should be removed from server implementations as quickly as possible. > For example the SHOULD- is defined in section 2 to mean that this > algorithm will be deprecated to MAY in future version, but in practice > we quite often go from SHOULD- to SHOULD NOT (or even MUST NOT, as the > text above suggests). Does this change make more sense? SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- will be deprecated to a MAY in a future version of this document. SHOULD NOT- This term means the same as SHOULD NOT. However, an algorithm marked as SHOULD NOT- will be deprecated to a MUST NOT in a future version of this document. > Anyways this is separate issue than wheter we should make > implementations having code for diffie-hellman-group1-sha1 > non-conforming by publishing that implementations MUST NOT implement > diffie-hellman-group1-sha1... Okay. I can make this change later today. I will probably also add the SHOULD NOT- unless there is strong objection. -- Mark From nobody Mon Jul 17 09:33:20 2017 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 4304C131CB7 for ; Mon, 17 Jul 2017 09:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 cEVVC_pPJY8e for ; Mon, 17 Jul 2017 09:33:17 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 5A919131CC1 for ; Mon, 17 Jul 2017 09:32:54 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v6HGWo0w024993 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Jul 2017 19:32:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6HGWngE027472; Mon, 17 Jul 2017 19:32:49 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22892.59057.959364.772229@fireball.acr.fi> Date: Mon, 17 Jul 2017 19:32:49 +0300 From: Tero Kivinen To: "Mark D. Baushke" Cc: In-Reply-To: <82005.1500305248@eng-mail01.juniper.net> References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 14 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 16:33:19 -0000 Mark D. Baushke writes: > > We are defining here a MUST implement and MUST not implement, not MUST > > use and MUST NOT use recommendations. > > For reference, there are five key exchanges that > draft-ietf-curdle-ssh-kex-sha2-08 marks as "MUST NOT" > > Key Exchange Method Name Reference Implement > ---------------------------------- ---------- --------- > diffie-hellman-group1-sha1 RFC4253 MUST NOT > diffie-hellman-group-exchange-sha1 RFC4419 MUST NOT > gss-gex-sha1-* RFC4462 MUST NOT > gss-group1-sha1-* RFC4462 MUST NOT > rsa1024-sha1 RFC4432 MUST NOT > > Of these, only diffie-hellman-group1-sha1 is moving from MUST to MUST > NOT. Due to 1024-bit Diffie-Hellman being considered by many as having > too little security (the same would be true of gss-group1-sha1-*). I think diffie-hellman-group1-sha1 is the only one where there is any real issues, and only because it used to be mandatory. But of course there might be others who want to keep some of the others in their codebase too... > What transition period is desirable for taking group1 "MUST" to "SHOULD > NOT" to "MUST NOT" ? Is it possible to codify both "SHOULD NOT" and > "MUST NOT" time frames into one RFC? In IPsec we decided that unless algoritm is really broken (i.e., there has been demonstration how it can be broken in public) we keep it SHOULD NOT. 786-bit Diffie-Hellman got MUST NOT because it was considered broken. The another 1024-bit Diffie-Hellman group which was generated so that we cannot be sure it is not backdoored, and which is not used at all, also got marked as MUST NOT, but the same group 1024-bit group we are talking here was left as SHOULD NOT. I am not familiar enough about the embedded ssh2 implementations to know what they really support, and when we can go forward. In most cases where we have been trying to guess when things are going away, we have been wrong, so I wouldn't even try to do that, and it is better to see what happens, and come back later when we see that those algorithms are no longer used ever... -- kivinen@iki.fi From nobody Mon Jul 17 14:07:09 2017 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 33C5912741D for ; Mon, 17 Jul 2017 14:07:08 -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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi1x58JmMpzV for ; Mon, 17 Jul 2017 14:07:06 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 298931243F6 for ; Mon, 17 Jul 2017 14:07:06 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id w187so570901ybc.0 for ; Mon, 17 Jul 2017 14:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7b9zxoMS7uOZiXeYS73+1QEiLDVhUYWejtCayfFI6pc=; b=GbFI1Drz3QcNQde3JeCYeqEUp3hxlH2cpHvBEGJkp93obS4qdjKbPiMiyVkbbZqliE WbfDNrWJV0hDaQvfXjc3IsSjg4Z8GHX8XVLBKnuijAPQ/QRRN1j3DTV7b6WzP/HZfqgF mryDcuO//+YBHNYMbUkb0848ReXtTC97kc16Y1ffRL7cgMk+MvHGFGDxt94bdTXyHkyz yNPLURoGR7tzjurprNnJt5cgN1rk4yNo6k6bfmY4Oaw/2kTbig0EXfcf4wWy6FFDB1z8 9ocqJNoYNVx4ES7xSe+Mj2DpzFOeS082wgWTs+a2rBi8vj25c53DTn/TDxhNCHIAnPzR OSEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7b9zxoMS7uOZiXeYS73+1QEiLDVhUYWejtCayfFI6pc=; b=aOuAzXPSu9ZNg2aAPvHXw09hXCFlFuL3Kq/n5qj9SxOc4vio+f32i8SD+87LRZ6aIe BzQ14PRrjhcUFMc5VMJRo9iZig/RjRu+0MSwxeiveNtv8hm5NkDIyy8Ip2hf4U8ELrwQ thPXEYVg8+qVRXlR/FVAWvUiHxQLEcVq2kRiGUdMHYxqB64aw7qckJfkygKug/gcpWzN 9NymGE/w6DH9TpbJxWOM+guiZ54VvvryEXvDhBOR1PgruW2Nju068SBZTV7rNqU+fNTR 6Dj3DWJQh9qGObPcJ7pJt1VkilV4/PG/zAPIG+U2zO5qQCCMZEnCx08pCyfaVSWnmaQ8 Py3g== X-Gm-Message-State: AIVw1115tH8UpW+ddUtYPW48RwRFw4NyZrSrrky13wxG4atK9FVcXB0B pAI1sgoGVpV9uvwurMaQAeCpYa8IMg== X-Received: by 10.37.176.154 with SMTP id f26mr19491292ybj.246.1500325625331; Mon, 17 Jul 2017 14:07:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.131 with HTTP; Mon, 17 Jul 2017 14:07:04 -0700 (PDT) In-Reply-To: <22892.59057.959364.772229@fireball.acr.fi> References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net> <22892.59057.959364.772229@fireball.acr.fi> From: denis bider Date: Mon, 17 Jul 2017 15:07:04 -0600 Message-ID: To: Tero Kivinen Cc: "Mark D. Baushke" , curdle Content-Type: multipart/alternative; boundary="f403045f2754f20d69055489c7d6" Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 21:07:08 -0000 --f403045f2754f20d69055489c7d6 Content-Type: text/plain; charset="UTF-8" I think Tero's assessments make sense. I can provide anecdotal feedback that we still receive questions from users about "how do I make this connection work?" where the problem is that the other party supports only diffie-hellman-group1-sha1, and nothing else, so the algorithm needs to be enabled. Users SHOULD upgrade, of course, but in practice, many systems appear to be upgraded at 10-year intervals. I expect we will continue to see occasional demand for diffie-hellman-group1-sha1 for at least some 5 years. Although it is off by default, we will be compelled to support it, simply because despite its shortcomings, it is better than plaintext (by far). denis On Mon, Jul 17, 2017 at 10:32 AM, Tero Kivinen wrote: > Mark D. Baushke writes: > > > We are defining here a MUST implement and MUST not implement, not MUST > > > use and MUST NOT use recommendations. > > > > For reference, there are five key exchanges that > > draft-ietf-curdle-ssh-kex-sha2-08 marks as "MUST NOT" > > > > Key Exchange Method Name Reference Implement > > ---------------------------------- ---------- --------- > > diffie-hellman-group1-sha1 RFC4253 MUST NOT > > diffie-hellman-group-exchange-sha1 RFC4419 MUST NOT > > gss-gex-sha1-* RFC4462 MUST NOT > > gss-group1-sha1-* RFC4462 MUST NOT > > rsa1024-sha1 RFC4432 MUST NOT > > > > Of these, only diffie-hellman-group1-sha1 is moving from MUST to MUST > > NOT. Due to 1024-bit Diffie-Hellman being considered by many as having > > too little security (the same would be true of gss-group1-sha1-*). > > I think diffie-hellman-group1-sha1 is the only one where there is any > real issues, and only because it used to be mandatory. But of course > there might be others who want to keep some of the others in their > codebase too... > > > What transition period is desirable for taking group1 "MUST" to "SHOULD > > NOT" to "MUST NOT" ? Is it possible to codify both "SHOULD NOT" and > > "MUST NOT" time frames into one RFC? > > In IPsec we decided that unless algoritm is really broken (i.e., there > has been demonstration how it can be broken in public) we keep it > SHOULD NOT. 786-bit Diffie-Hellman got MUST NOT because it was > considered broken. The another 1024-bit Diffie-Hellman group which was > generated so that we cannot be sure it is not backdoored, and which is > not used at all, also got marked as MUST NOT, but the same group > 1024-bit group we are talking here was left as SHOULD NOT. > > I am not familiar enough about the embedded ssh2 implementations to > know what they really support, and when we can go forward. In most > cases where we have been trying to guess when things are going away, > we have been wrong, so I wouldn't even try to do that, and it is > better to see what happens, and come back later when we see that those > algorithms are no longer used ever... > -- > kivinen@iki.fi > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045f2754f20d69055489c7d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Tero's assessments make sense.

<= div>I can provide anecdotal feedback that we still receive questions from u= sers about "how do I make this connection work?" where the proble= m is that the other party supports only diffie-hellman-group1-sha1, and not= hing else, so the algorithm needs to be enabled.

U= sers SHOULD upgrade, of course, but in practice, many systems appear to be = upgraded at 10-year intervals. I expect we will continue to see occasional = demand for diffie-hellman-group1-sha1 for at least some 5 years. Although i= t is off by default, we will be compelled to support it, simply because des= pite its shortcomings, it is better than plaintext (by far).

=
denis


<= div class=3D"gmail_quote">On Mon, Jul 17, 2017 at 10:32 AM, Tero Kivinen <kiv= inen@iki.fi> wrote:
Mark D. Baushke writes:
> > We are defining here a MUST implement and MUST not implement, not= MUST
> > use and MUST NOT use recommendations.
>
> For reference, there are five key exchanges that
> draft-ietf-curdle-ssh-kex-sha2-08 marks as "MUST NOT" >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Key Exchange Method Name=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reference=C2=A0 Implement
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------------= ---- ---------- ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diffie-hellman-group1-sha1=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC4253=C2=A0 =C2=A0 MUST NOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diffie-hellman-group-exchange-= sha1 RFC4419=C2=A0 =C2=A0 MUST NOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gss-gex-sha1-*=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC4462=C2=A0= =C2=A0 MUST NOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gss-group1-sha1-*=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC4462=C2=A0 =C2=A0 MUST= NOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rsa1024-sha1=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC4432= =C2=A0 =C2=A0 MUST NOT
>
> Of these, only diffie-hellman-group1-sha1 is moving from MUST to MUST<= br> > NOT. Due to 1024-bit Diffie-Hellman being considered by many as having=
> too little security (the same would be true of gss-group1-sha1-*).

I think diffie-hellman-group1-sha1 is the only one where there is an= y
real issues, and only because it used to be mandatory. But of course
there might be others who want to keep some of the others in their
codebase too...

> What transition period is desirable for taking group1 "MUST"= to "SHOULD
> NOT" to "MUST NOT" ? Is it possible to codify both &quo= t;SHOULD NOT" and
> "MUST NOT" time frames into one RFC?

In IPsec we decided that unless algoritm is really broken (i.e., the= re
has been demonstration how it can be broken in public) we keep it
SHOULD NOT. 786-bit Diffie-Hellman got MUST NOT because it was
considered broken. The another 1024-bit Diffie-Hellman group which was
generated so that we cannot be sure it is not backdoored, and which is
not used at all, also got marked as MUST NOT, but the same group
1024-bit group we are talking here was left as SHOULD NOT.

I am not familiar enough about the embedded ssh2 implementations to
know what they really support, and when we can go forward. In most
cases where we have been trying to guess when things are going away,
we have been wrong, so I wouldn't even try to do that, and it is
better to see what happens, and come back later when we see that those
algorithms are no longer used ever...
--
kivinen@iki.fi

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--f403045f2754f20d69055489c7d6-- From nobody Mon Jul 17 14:55:43 2017 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 CB7C4131CC7 for ; Mon, 17 Jul 2017 14:55:41 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 MnxYRfeTp6_G for ; Mon, 17 Jul 2017 14:55:39 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 B371C1296C6 for ; Mon, 17 Jul 2017 14:55:39 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HLq1Fb012324 for ; Mon, 17 Jul 2017 22:55:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=e5TLRECrdfAVSqt3P3L6UBCqiX8+rbS7MGYZ+afjh3E=; b=SEnqAc2C3QIfDFW6ItFmEqwzr2i6tDhOoOAtyqBuB4tlw84Mw/7IdcfEv8vzGBzmoW/d w3hlZ1Vm+tdzp+OtgCIgvJzXZlbe1OER8VW6Z15Si4fEAoFpMadkg9112H6lXi8Dox4i 8iW2IJqw/o8SZ+s0j1UgJ4Pin0JOVBryqXUk+v5+P1u/2ozL5EGzW1ga/yUA18QJ8Y9H A+0qT+INEqwZsUbn1mDWid0tyWy8fa6PntDLlpfoNMJykHEqZ86FN8BiaI4GN11sku/0 1ZUEfeUOA8Lu7JQ2UriTCFbOBc2S4XQ8sq1ecNuAgh+/nK5J6fzjiqssfuehghnaCn3i Sg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84da3s5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 17 Jul 2017 22:55:38 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HLtPVE024730 for ; Mon, 17 Jul 2017 17:55:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecu5xxx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 17 Jul 2017 17:55:37 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 17:55:37 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Mon, 17 Jul 2017 17:55:37 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: Minutes Thread-Index: AQHS/uQSxcnlLN8uzk+HqwdTzOQMZKJYkO8Q Date: Mon, 17 Jul 2017 21:55:37 +0000 Message-ID: <6cf2b3b564504e4a85edde6ccdd10326@usma1ex-dag1mb3.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.163] Content-Type: multipart/alternative; boundary="_000_6cf2b3b564504e4a85edde6ccdd10326usma1exdag1mb3msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170354 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170353 Archived-At: Subject: [Curdle] FW: Minutes X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 21:55:42 -0000 --_000_6cf2b3b564504e4a85edde6ccdd10326usma1exdag1mb3msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RHJhZnQgbWludXRlcyBmcm9tIFBoaWwuICBQbGVhc2UgcG9zdCBhbnkgY29ycmVjdGlvbnMgYmVm b3JlIHRoZSBlbmQgb2YgdGhlIHdlZWsuICBUaGFuayB5b3UuDQoNCi0tDQpTZW5pb3IgQXJjaGl0 ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpNZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW0NCklNOiBy aWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg0KRnJvbTogaGFsbGFtQGdtYWls LmNvbSBbbWFpbHRvOmhhbGxhbUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBQaGlsbGlwIEhhbGxh bS1CYWtlcg0KU2VudDogTW9uZGF5LCBKdWx5IDE3LCAyMDE3IDEyOjA0IFBNDQpUbzogU2Fseiwg UmljaCA8cnNhbHpAYWthbWFpLmNvbT4NClN1YmplY3Q6IE1pbnV0ZXMNCg0KQ1VSRExFDQoNCkRv Y3VtZW50IFN0YXR1czoNCkNNUyAvIEtlcmJlcm9zIHRvIElFU0cNClBLSVggbmVlZHMgd29yaw0K U1NIIG9uZSBpbiBsYXN0IGNhbGwuDQpSQzQtZGllLWRpZS1kaWUgYXdhaXRpbmcgYWRvcHRpb24N Cg0KRHJhZnQgdG8gY29uc2lkZXIgaXMgdGhlIFNTSCBrZXkgZXhjaGFuZ2UNCkRpZmZpZSBIZWxs bWFuIE5JU1QgUDI1NiAvIFdoZW4gMjU1MTkgaXMgZGVwbG95ZWQgZXZlcnl3aGVyZSwgY2FuIGNo YW5nZS4gS2VlcCBhcyBzaG91bGQgbm90IFNob3VsZC0gdW50aWwgMjU1MTkgaXMgZGVwbG95ZWQg ZXZlcnl3aGVyZS4NCkVLUjogQWxzbyBwdXp6bGVkIGJ5IE5JU1QgY3VydmVzLiBGaW5lIHRvIHNh eSBOSVNUIHVubG92ZWQuIERlcHJlY2F0aW5nIG5vdCBqdXN0aWZpZWQgdGVjaG5pY2FsbHkNCkRl YiBDb2xsaWUgTlNBOiBEaWZmaWUgaGVsbG1hbiBncm91cCBjaG9pY2VzIGluIHRoZSBkcmFmdHMg YXJlIGluY29uc2lzdGVudC4NCk1hcnRpbjogQ2hvaWNlcyBhcmUgdGhlIG9uZXMgd2l0aCBub3Jt YXRpdmUgbGFuZ3VhZ2UgYXR0YWNoZWQsIHRoZSBvdGhlcnMgbWVyZWx5IGV4aXN0Lg0KRUtSOiBS ZWFzb24gZm9yIFNIQTUxMiBvdmVyIDI1NiBpcyByaXNrIG9mIEdyb3ZlcnMgYWxnb3JpdGhtIGNv bGxpc2lvbnMuIFdvdWxkIGJlIGdvb2QgaWYgSUVURiBzYWlkIG91ciB0aGVvcnkgb24gUXVhbnR1 bSBDcnlwdG8gaXMgWC4NClRlcm86IFRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgbGlzdGVkIG9uIHNs aWRlcyBpcyBvbmx5IGZvciBTSE9VTEQtIGFuZCBhYm92ZSwgYW55dGhpbmcgZWxzZSBpcyBNQVkN ClBIQjogUXVhbnR1bSBDcnlwdG8gaXMgZm9yIElSVEYNCkVLUjogV2Ugc2hvdWxkIGhhdmUgYW4g YWdyZWVtZW50IG9uIDI1NiBiaXRzIGJlaW5nIGdvb2QgZW5vdWdoIGZvciBpbmRlZmluaXRlIGZ1 dHVyZS4NCk1hcnRpbiBUaG9tcHNvbjogMjU2IGJpdHMgZm9yIG5vdywgbWF5IGNoYW5nZSBpbiBm dXR1cmUuDQpUZXJvOiBEb27igJl0IGdvIGZyb20gTXVzdCB0byBNdXN0IE5vdCwgYmV0dGVyIE11 c3QgdG8gU2hvdWxkIE5vdC4gUHJvYmxlbWF0aWMgYmVjYXVzZSBpdCBicmVha3MgYmFja3dhcmRz IGNvbXBhdGliaWxpdHkuDQpSaWNoIFNhbHR6OiBJcyBjb25zZW5zdXMgUDI1NiBPSw0KRGViOiBl Y2RoLXNoYTItbmlzdHAyNTYgc2hvdWxkIG5vdCBiZSBTaG91bGQtIHNob3VsZCBiZSBhdCBsZWFz dCBhIFNIT1VMRA0KRUtSOiBqdXN0IHN3YXAgcGx1cyBhbmQgbWludXMgb24gZWNkaC1zaGEyLW5p c3RwMjU2IGVjZGgtc2hhMi1uaXN0cDM4NA0KRGViOiBKdXN0IGdldCByaWQgb2YgcGx1cyBhbmQg bWludXMuDQoNCkNoYXJ0ZXIgZGlzY3Vzc2lvbg0KDQpUYWJsZSBvZiB3b3JrLg0KQXJlIHdlIGRv bmU/DQpLZXJiZXJvcyBtaXNzaW5nIEVkMjU1MTkNCkRlYjogU2hvdWxkbuKAmXQgdGhhdCBiZSBk b25lIGluIGtpdHRlbg0KQW5vbjogS2l0dGVuIHNob3VsZCBiZSBydW4gb3Zlci4gQ2hhaXIgc2Fp ZCBwbGVhc2UgZG8gaW4gQ3VyZGxlLg0KTWFydGluIFRob21wc29uOiBKb3NlIGxpbmUsIHNvbWUg aW50ZXJlc3QgaW4gV2ViIENyeXB0byBYMjU1MTkgYW5kIFg0NDguIE5vIHJlYXNvbiB3ZSBjYW7i gJl0IGRvIGl0LiBJbnRlcmZhY2VzIHdpdGggVzNDIFdlYiBjcnlwdG8uDQpbU2VhcmNoIGZvciBh IHZvbHVudGVlcl0NCllvYXY6IFNTSCBDaGFjaGEgUG9seSBhbHJlYWR5IGV4aXN0cyBpbiBjb2Rl Lg0KUEhCOiBNYXkgaGF2ZSBKT1NFIGNvZGUuDQoNCg0K --_000_6cf2b3b564504e4a85edde6ccdd10326usma1exdag1mb3msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRyYWZ0IG1pbnV0ZXMgZnJvbSBQaGlsLiZuYnNwOyBQbGVh c2UgcG9zdCBhbnkgY29ycmVjdGlvbnMgYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHdlZWsuJm5ic3A7 IFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LS0mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VuaW9yIEFyY2hpdGVj dCwgQWthbWFpIFRlY2hub2xvZ2llczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWVtYmVyLCBPcGVuU1NMIERldiBUZWFtPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J TTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBoYWxsYW1AZ21haWwuY29tIFttYWls dG86aGFsbGFtQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbGxpcCBIYWxsYW0t QmFrZXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdWx5IDE3LCAyMDE3IDEyOjA0IFBNPGJy Pg0KPGI+VG86PC9iPiBTYWx6LCBSaWNoICZsdDtyc2FsekBha2FtYWkuY29tJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBNaW51dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Q1VSRExFPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Eb2N1bWVudCBT dGF0dXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNNUyAvIEtlcmJl cm9zIHRvIElFU0c8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UEtJWCBu ZWVkcyB3b3JrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNTSCBvbmUg aW4gbGFzdCBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SQzQt ZGllLWRpZS1kaWUgYXdhaXRpbmcgYWRvcHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkRyYWZ0IHRvIGNvbnNpZGVyIGlzIHRoZSBTU0gga2V5IGV4Y2hhbmdlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRpZmZpZSBIZWxsbWFuIE5JU1QgUDI1NiAvIFdoZW4g MjU1MTkgaXMgZGVwbG95ZWQgZXZlcnl3aGVyZSwgY2FuIGNoYW5nZS4gS2VlcCBhcyBzaG91bGQg bm90IFNob3VsZC0gdW50aWwgMjU1MTkgaXMgZGVwbG95ZWQgZXZlcnl3aGVyZS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RUtSOiBBbHNvIHB1enpsZWQgYnkgTklTVCBj dXJ2ZXMuIEZpbmUgdG8gc2F5IE5JU1QgdW5sb3ZlZC4gRGVwcmVjYXRpbmcgbm90IGp1c3RpZmll ZCB0ZWNobmljYWxseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWIg Q29sbGllIE5TQTogRGlmZmllIGhlbGxtYW4gZ3JvdXAgY2hvaWNlcyBpbiB0aGUgZHJhZnRzIGFy ZSBpbmNvbnNpc3RlbnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ TWFydGluOiBDaG9pY2VzIGFyZSB0aGUgb25lcyB3aXRoIG5vcm1hdGl2ZSBsYW5ndWFnZSBhdHRh Y2hlZCwgdGhlIG90aGVycyBtZXJlbHkgZXhpc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkVLUjogUmVhc29uIGZvciBTSEE1MTIgb3ZlciAyNTYgaXMgcmlzayBvZiBH cm92ZXJzIGFsZ29yaXRobSBjb2xsaXNpb25zLiBXb3VsZCBiZSBnb29kIGlmIElFVEYgc2FpZCBv dXIgdGhlb3J5IG9uIFF1YW50dW0gQ3J5cHRvIGlzIFguDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGVybzogVGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBsaXN0ZWQgb24g c2xpZGVzIGlzIG9ubHkgZm9yIFNIT1VMRC0gYW5kIGFib3ZlLCBhbnl0aGluZyBlbHNlIGlzIE1B WTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QSEI6IFF1YW50dW0gQ3J5 cHRvIGlzIGZvciBJUlRGPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkVL UjogV2Ugc2hvdWxkIGhhdmUgYW4gYWdyZWVtZW50IG9uIDI1NiBiaXRzIGJlaW5nIGdvb2QgZW5v dWdoIGZvciBpbmRlZmluaXRlIGZ1dHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+TWFydGluIFRob21wc29uOiAyNTYgYml0cyBmb3Igbm93LCBtYXkgY2hhbmdlIGlu IGZ1dHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGVybzogRG9u 4oCZdCBnbyBmcm9tIE11c3QgdG8gTXVzdCBOb3QsIGJldHRlciBNdXN0IHRvIFNob3VsZCBOb3Qu IFByb2JsZW1hdGljIGJlY2F1c2UgaXQgYnJlYWtzIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5Lg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJpY2ggU2FsdHo6IElzIGNv bnNlbnN1cyBQMjU2IE9LPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRl YjogZWNkaC1zaGEyLW5pc3RwMjU2IHNob3VsZCBub3QgYmUgU2hvdWxkLSBzaG91bGQgYmUgYXQg bGVhc3QgYSBTSE9VTEQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RUtS OiBqdXN0IHN3YXAgcGx1cyBhbmQgbWludXMgb24gZWNkaC1zaGEyLW5pc3RwMjU2IGVjZGgtc2hh Mi1uaXN0cDM4NDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWI6IEp1 c3QgZ2V0IHJpZCBvZiBwbHVzIGFuZCBtaW51cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkNoYXJ0ZXIgZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGFibGUgb2Yg d29yay4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcmUgd2UgZG9u ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+S2VyYmVyb3MgbWlzc2lu ZyBFZDI1NTE5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRlYjogU2hv dWxkbuKAmXQgdGhhdCBiZSBkb25lIGluIGtpdHRlbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5Bbm9uOiBLaXR0ZW4gc2hvdWxkIGJlIHJ1biBvdmVyLiBDaGFpciBzYWlk IHBsZWFzZSBkbyBpbiBDdXJkbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk1hcnRpbiBUaG9tcHNvbjogSm9zZSBsaW5lLCBzb21lIGludGVyZXN0IGluIFdlYiBDcnlw dG8gWDI1NTE5IGFuZCBYNDQ4LiBObyByZWFzb24gd2UgY2Fu4oCZdCBkbyBpdC4gSW50ZXJmYWNl cyB3aXRoIFczQyBXZWIgY3J5cHRvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5bU2VhcmNoIGZvciBhIHZvbHVudGVlcl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+WW9hdjogU1NIIENoYWNoYSBQb2x5IGFscmVhZHkgZXhpc3RzIGluIGNvZGUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBIQjogTWF5IGhhdmUgSk9T RSBjb2RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6cf2b3b564504e4a85edde6ccdd10326usma1exdag1mb3msgcorpak_-- From nobody Mon Jul 17 20:58:25 2017 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 C29EE12EC0C for ; Mon, 17 Jul 2017 20:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 2GeUnxgwOODi for ; Mon, 17 Jul 2017 20:58:22 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0458E127601 for ; Mon, 17 Jul 2017 20:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500350302; x=1531886302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CldSYfxGXjl1CsTpksb0hmV5wvr1jCk3bhmYW5N5//o=; b=dL6H08DxtrKIyf6Ouxerl5NxQh4k9gFUJRTa2hOc+6uMyvCI3x3aCVaa 966TvgGZTY64XHD8ixevQoqejAO2uHiZ8Ji7LPI1Y/D5zeXs6NfeHpYsv 4EL8BpNveLkpx69Ih37g9VJI+JKbYpTbEEG0beERNBeYrJVvHHJY1DRJy PoYn4fEOBQiRVuf2RKERMGXJb4wRqM7UTqcJGtE2kgmZdEqomGeyhxMpM 3mABuHxoEb2wcFbNCaa2RElzMFGXjB39aPIlzO/ZhNxwg0ltaZXoaOEPh ufUe3VHZ6lKTCY+7OyZ5lgEH9+E1vlFcSE+Ma1qUlBQ8WXpN6Z90YVaR8 g==; X-IronPort-AV: E=Sophos;i="5.40,376,1496059200"; d="scan'208";a="166181381" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Jul 2017 15:58:20 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Jul 2017 15:58:20 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Tue, 18 Jul 2017 15:58:20 +1200 From: Peter Gutmann To: denis bider , Tero Kivinen CC: curdle , "Mark D. Baushke" Thread-Topic: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) Thread-Index: AQHS/uRqIUk+oZW8gEGT/Uz9xKfLk6JYJMoP//9I6oCAAEygAIABO9Hu Date: Tue, 18 Jul 2017 03:58:19 +0000 Message-ID: <1500350283776.13722@cs.auckland.ac.nz> References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net> <22892.59057.959364.772229@fireball.acr.fi>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 03:58:24 -0000 denis bider writes:=0A= =0A= >I can provide anecdotal feedback that we still receive questions from user= s=0A= >about "how do I make this connection work?" where the problem is that the= =0A= >other party supports only diffie-hellman-group1-sha1, and nothing else, so= the=0A= >algorithm needs to be enabled.=0A= >=0A= >Users SHOULD upgrade, of course, but in practice, many systems appear to b= e=0A= >upgraded at 10-year intervals. I expect we will continue to see occasional= =0A= >demand for diffie-hellman-group1-sha1 for at least some 5 years. =0A= =0A= +1 on all of that, matches my experience exactly, and not just diffie-hellm= an-=0A= group-exchange-sha1 but diffie-hellman-group14-sha1 as well. There's even = a=0A= large router manufacturer whose name rhymes with Frisco whose *security=0A= appliances* only support diffie-hellman-group1-sha1 on some of their device= s=0A= (yeah, that's so bad that I'm not going to grant them anonymity :-).=0A= =0A= Oh, and another router vendor who until a few years ago was using an ssh.co= m=0A= implementation from 1999.=0A= =0A= And who knows what else is out there, I've got so many bug-workarounds enab= led=0A= by now that I don't see half the problems any more.=0A= =0A= Peter.=0A= From nobody Mon Jul 17 22:52:34 2017 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 8C736129459; Mon, 17 Jul 2017 22:52:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Jaeggli To: Cc: draft-ietf-curdle-des-des-des-die-die-die.all@ietf.org, curdle@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150035715254.11356.14739890140093835216@ietfa.amsl.com> Date: Mon, 17 Jul 2017 22:52:32 -0700 Archived-At: Subject: [Curdle] Opsdir last call review of draft-ietf-curdle-des-des-des-die-die-die-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 05:52:32 -0000 Reviewer: Joel Jaeggli Review result: Ready Hello, I have reviewed this document for operational considerations as part of the IETF last call. Depreciation of the listed encryption algorithms when it occurs will leave behind certain legacy systems with respect to interoperability. This is expected and normal. There are not other serious problems anticipated with the advice provided in this document. I believe that it is ready for publication. Regards Joel From nobody Wed Jul 19 13:17:20 2017 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 0525C128AB0 for ; Wed, 19 Jul 2017 13:17:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 isEBl5x-WANf for ; Wed, 19 Jul 2017 13:17:16 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 1AFFA12ECB7 for ; Wed, 19 Jul 2017 13:17:16 -0700 (PDT) X-AuditID: c618062d-a05ff70000002716-9a-596fd425df12 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id F7.43.10006.524DF695; Wed, 19 Jul 2017 23:50:29 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 16:17:14 -0400 From: Daniel Migault To: curdle Thread-Topic: Curdle IETF99 report Thread-Index: AdMAxXxxh3dTQSoUTCe4cScfZ/7dpAABnMyw Date: Wed, 19 Jul 2017 20:17:13 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EA@eusaamb107.ericsson.se> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118CC82CF@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118CC82CF@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/mixed; boundary="_004_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EAeusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyuXRPoK7qlfxIg2PtVhZbF85idmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuO/22wFM7czVlz6UdfAuGgRYxcjJ4eEgInE1T2HgGwuDiGB o4wSH+59YoVwljNKPNyxBayKTcBIou1QPzuILSIgI/G6+y5zFyMHh7CArMSaN0UQYSWJ9tX/ oEqMJHa2bGIFsVkEVCUmPlnGDGLzCvhKLPw6HSwuBGS/29DAAmJzCvhJTJp5BmwVo4CYxPdT a5hAbGYBcYlbT+YzQRwqIvHw4mk2CFtU4uXjf6wQtpLEnNfXmCHqMyVWnpvJDrFLUOLkzCcs ExiFZyEZNQtJ2SwkZRDxfIk3f6+wQtg6Egt2f2KDsLUlli18zQxjnznwmAlTXFfiyPlj7BC2 okTb9magXi4gewWjxPH7/6GGWkvcOnyXCaZoSvdD9gWMvKsYOUqLC3Jy040MNjECo/SYBJvu Dsb70z0PMQpwMCrx8BZfzo8UYk0sK67MPcSoAtT6aMPqC4xSLHn5ealKIrxVu4DSvCmJlVWp RfnxRaU5qcWHGKU5WJTEeSecvxAhJJCeWJKanZpakFoEk2Xi4JRqYFwSumB/waGvxi+OWWfv 5pVk/l3ZGzrN79AUxxCzkr2Bfy7Fv3h89EeBjMYE6w03rE9qfZx26co0twiTshbe5Ckfrmgv UGVX5rk8UbSZK2nVOsvl7jn7Njas/HxVfB7fzX///iwyT72goldbf2y38P2T/Oq2K5bFV7W4 zLxeb/0x7FLjqerfzy2VWIozEg21mIuKEwHJ4VHm2gIAAA== Archived-At: Subject: [Curdle] Curdle IETF99 report X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 20:17:18 -0000 --_004_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EAeusaamb107erics_ Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EAeusaamb107erics_" --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EAeusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Curdle WG met on Monday July 17 from 11:30 - 12:00 The following drafts have been sent to the IESG: * draft-ietf-curdle-cms-ecdh-new-curves-09 * draft-ietf-curdle-cms-eddsa-signatures-06 * draft-ietf-curdle-des-des-des-die-die-die-03 * draft-ietf-curdle-pkix-05 * draft-ietf-curdle-rsa-sha2-09 * draft-ietf-curdle-ssh-curves-05 * draft-ietf-curdle-ssh-dh-group-exchange-04 hC * draft-ietf-curdle-ssh-ext-info-10 * draft-ietf-curdle-ssh-modp-dh-sha2-07 The following drafts are in WGLC: * draft-ietf-curdle-ssh-kex-sha2-08 * draft-schaad-curdle-oid-registry-01 * draft-ietf-curdle-gss-keyex-sha2-02 The following draft will be called for adoption: * draft-ietf-curdle-rc4-die-die-die-00 The following draft will be revived: * draft-ietf-curdle-ssh-ed25519-00 The scope of curdle was limited to ECDHE, EdDSA with Curve25519 and Curve44= 8, Chacha20Poly1305, AES-CCM, AES-GCM. * Introduction of the new curves is done or ongoing for SSH / DNSSEC / = PKIX / CMS / Kerberos * For SSH, the WG needs to evaluate if AES-CCM and Chacha20Poly1305 wil= l be done. Signature and DH key exchange have been updated / deprecated. * For Kerberos, recommendations on DH is ongoing. the WG needs to evalu= ate if AES-CCM/GCM and Chacha20Poly1305 will be done. * The WG is looking at providing some cryptographic recommendation poli= cies. * Protocols XML, JSON have not yet been considered. --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EAeusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Curdle WG met on Monday July 17 from 11:30 ̵= 1; 12:00

 

The following drafts have been sent to the IESG:

  • draft-ietf-curdle-cms-ecdh-new-curves-09
  • draft-ietf-cu= rdle-cms-eddsa-signatures-06
  • draft-ie= tf-curdle-des-des-des-die-die-die-03
  • draft-ietf-cu= rdle-pkix-05
  • draft-ietf-curdle-rsa-sha2-09
  • draft-ietf-curdle-ssh-curves-05
  • draft-ietf-curdle-ssh= -dh-group-exchange-04 hC
  • draft-ietf-curdle-ssh-ext-info-1= 0
  • draft-ietf-curdle-ssh-modp-dh-sha2-07

    •  

    The following drafts are in WGLC:

    • draft-ietf-curdle-ssh-kex-sha2-08
    • draft-schaad-curdle-oid-registry-01
    • draft-ietf-curdle-gss-keyex-sha2-02

     

    The following draft will be called for adoption:

    • draft-ietf-curdle-rc4-die-die-die-00

     

    The following draft will be revived:

    • draft-ietf-curdle-ssh-ed25519-00

     

    The scope of curdle was limited to ECDHE, EdDSA with= Curve25519 and Curve448, Chacha20Poly1305, AES-CCM, AES-GCM.

    • Introduction of the new curves is done or ongoing for SSH / DNSSEC / PKI= X / CMS / Kerberos
    • For SSH, the WG needs to evaluate if A= ES-CCM and Chacha20Poly1305 will be done. Signature and DH key exchange hav= e been updated / deprecated.
    • For Kerberos, recommendations on DH is ongoing. the WG n= eeds to evaluate if AES-CCM/GCM and Chacha20Poly1305 will be done.
    • The WG is looking at providing some cryptographic recommendation = policies.
    • Protocols XML, JSON have not yet been considere= d.

     

      

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EAeusaamb107erics_-- --_004_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EAeusaamb107erics_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Wed, 19 Jul 2017 20:16:17 GMT"; modification-date="Wed, 19 Jul 2017 20:16:17 GMT" Content-ID: <6B682B7AFC2E474A9759D5A081888326@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhYWcgbWFp bGluZyBsaXN0DQpzYWFnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhYWcNCg== --_004_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82EAeusaamb107erics_-- From nobody Wed Jul 19 18:00:24 2017 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 A1392126E64 for ; Wed, 19 Jul 2017 18:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 V_fb-fvcClEZ for ; Wed, 19 Jul 2017 18:00:19 -0700 (PDT) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB001200ED for ; Wed, 19 Jul 2017 18:00:18 -0700 (PDT) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id v6K10FAU039353; Thu, 20 Jul 2017 11:00:16 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id v6K10Fov051621 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 11:00:15 +1000 Received: from haru.mindrot.org (haru.mindrot.org [130.102.96.5]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id v6K10Emw029534; Thu, 20 Jul 2017 11:00:14 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by haru.mindrot.org (OpenSMTPD) with ESMTP id 1da6fc08; Thu, 20 Jul 2017 10:59:39 +1000 (AEST) Date: Thu, 20 Jul 2017 10:59:39 +1000 (AEST) From: Damien Miller To: "Mark D. Baushke" cc: curdle@ietf.org In-Reply-To: <82005.1500305248@eng-mail01.juniper.net> Message-ID: References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1500512416 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 01:00:23 -0000 On Mon, 17 Jul 2017, Mark D. Baushke wrote: > Hi Tero, > > Tero Kivinen writes: > > > I think it is bad idea to go from MUST to implement algorithm to MUST > > NOT implement in one step. Especially as this will make all current > > ssh implementations non-conforming as they do still implement > > diffie-hellman-group1-sha1 even when it might be disabled by default. > > I see your point. > > > We are defining here a MUST implement and MUST not implement, not MUST > > use and MUST NOT use recommendations. > > For reference, there are five key exchanges that > draft-ietf-curdle-ssh-kex-sha2-08 marks as "MUST NOT" > > Key Exchange Method Name Reference Implement > ---------------------------------- ---------- --------- > diffie-hellman-group1-sha1 RFC4253 MUST NOT > diffie-hellman-group-exchange-sha1 RFC4419 MUST NOT > gss-gex-sha1-* RFC4462 MUST NOT > gss-group1-sha1-* RFC4462 MUST NOT > rsa1024-sha1 RFC4432 MUST NOT > > Of these, only diffie-hellman-group1-sha1 is moving from MUST to MUST > NOT. Due to 1024-bit Diffie-Hellman being considered by many as having > too little security (the same would be true of gss-group1-sha1-*). > > What transition period is desirable for taking group1 "MUST" to "SHOULD > NOT" to "MUST NOT" ? Is it possible to codify both "SHOULD NOT" and > "MUST NOT" time frames into one RFC? Anecdata: OpenSSH has disabled diffie-hellman-group1-sha1 by default for approximately two years in the client and for considerably longer in the server. Opinion: there's still enough old junk out there that optional support for diffie-hellman-group1-sha1 is probably necessary for a while longer. IMO this is probably worth an explicit note in the draft. -d From nobody Wed Jul 19 19:51:37 2017 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 96970129ACD for ; Wed, 19 Jul 2017 19:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 r7tJxtpZJtc3 for ; Wed, 19 Jul 2017 19:51:33 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6B2129AAD for ; Wed, 19 Jul 2017 19:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500519093; x=1532055093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KmUdeCNnCZNeTLTMygT8XNWSK7BsEvdy4ts8S5eQdEQ=; b=nC/lEb8pwc75MWJ931rGECQtQ93he8o7ULUMKe9iO4YD7EeWuHo6XbEU e9TwjaSP0Tyu7EKNgt/3n3fomfvgKIproGc4j8Xg0i95NiPj3E/FI8kId JAk3vWQ8f/fLWadPdgzeGfHuCKr/OfNV/8Fvkc/MqWNXLplvjaVemKv8I CfPwmg+EEVyb+znFPIucXy6Fycm7lE5RASMfaYz4DkeGtz//VjkYJWDlo t5DQ6abQuZXAb4Bpp9+P1vJk40+BBt1rC7sybUKTZItqriHjtCarXhSnD jhDtaoX7ak6+C3Xnjlo0JbRdUEWl8d8xH54knxsVRy9wccEbp/a9Z+u35 A==; X-IronPort-AV: E=Sophos;i="5.40,382,1496059200"; d="scan'208";a="166754832" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Jul 2017 14:51:30 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 14:51:30 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 14:51:30 +1200 From: Peter Gutmann To: Damien Miller , "Mark D. Baushke" CC: "curdle@ietf.org" Thread-Topic: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) Thread-Index: AQHS/uRqIUk+oZW8gEGT/Uz9xKfLk6JYJMoPgAL7L4CAAOggyg== Date: Thu, 20 Jul 2017 02:51:29 +0000 Message-ID: <1500519070842.37117@cs.auckland.ac.nz> References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 02:51:36 -0000 Damien Miller writes:=0A= =0A= >Opinion: there's still enough old junk out there that optional support for= =0A= >diffie-hellman-group1-sha1 is probably necessary for a while longer. IMO t= his=0A= >is probably worth an explicit note in the draft.=0A= =0A= That's the catch-22 with something like this, on the one hand you want to m= ake=0A= it MUST NOT so you've got something to hit vendors over the head with when= =0A= they keep using RSA512 with MD5, on the other hand if they've got existing= =0A= equipment they're just going to demand that you change your code to work wi= th=0A= it.=0A= =0A= As an aside, it would be nice if OpenSSH had some single enable-legacy-mode= =0A= switch to re-enable all the MUST algorithms that are currently disabled,=0A= having to send people to https://www.openssh.com/legacy.html so they can=0A= figure out by trial and error which incantation they need to use each time= =0A= they can't interop with current versions of OpenSSH is a pain. Or at least= =0A= change the error message to tell people what to do to make it work.=0A= =0A= Peter.= From nobody Wed Jul 19 20:51:16 2017 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 6B5CB126DFF for ; Wed, 19 Jul 2017 20:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Vdt80XGMzxyM for ; Wed, 19 Jul 2017 20:51:12 -0700 (PDT) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBCA126C23 for ; Wed, 19 Jul 2017 20:51:12 -0700 (PDT) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id v6K3p9oC043233; Thu, 20 Jul 2017 13:51:09 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id v6K3p8ma021393 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 13:51:09 +1000 Received: from haru.mindrot.org (haru.mindrot.org [130.102.96.5]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id v6K3p8Kp024877; Thu, 20 Jul 2017 13:51:08 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by haru.mindrot.org (OpenSMTPD) with ESMTP id efc4471a; Thu, 20 Jul 2017 13:50:33 +1000 (AEST) Date: Thu, 20 Jul 2017 13:50:33 +1000 (AEST) From: Damien Miller To: Peter Gutmann cc: "Mark D. Baushke" , "curdle@ietf.org" In-Reply-To: <1500519070842.37117@cs.auckland.ac.nz> Message-ID: References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net>, <1500519070842.37117@cs.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1500522669 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 03:51:15 -0000 On Thu, 20 Jul 2017, Peter Gutmann wrote: > Damien Miller writes: > > >Opinion: there's still enough old junk out there that optional support for > >diffie-hellman-group1-sha1 is probably necessary for a while longer. IMO this > >is probably worth an explicit note in the draft. > > That's the catch-22 with something like this, on the one hand you want to make > it MUST NOT so you've got something to hit vendors over the head with when > they keep using RSA512 with MD5, on the other hand if they've got existing > equipment they're just going to demand that you change your code to work with > it. > > As an aside, it would be nice if OpenSSH had some single enable-legacy-mode > switch to re-enable all the MUST algorithms that are currently disabled, > having to send people to https://www.openssh.com/legacy.html so they can > figure out by trial and error which incantation they need to use each time > they can't interop with current versions of OpenSSH is a pain. Or at least > change the error message to tell people what to do to make it work. When I wrote legacy.html I tried to SEO it so it was the first search result for the error message in question (it seems to have worked -- for now). The error message does include the set of algorithms that the user would need to add, but I don't want to include cookbook instructions in the error message because users will too-often just do what the cookbook says without understanding the tradeoff they are making. -d From nobody Wed Jul 19 21:15:42 2017 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 93FA912EAAA for ; Wed, 19 Jul 2017 21:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 WCnwvJEYOUAh for ; Wed, 19 Jul 2017 21:15:39 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F24129B7A for ; Wed, 19 Jul 2017 21:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500524138; x=1532060138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IOfRz62nom3AZnxT7fhWfEJXpl/6CBldf9zB/+c1dJw=; b=VJZ/07cqTP+1+gYs59zzMBeQqDqNyrVXZq/VLwKAufVz8tF7Ys3kOmvE XXJdkyDD1FUiPqqVjQKUeINH0i95m2z4iTiaTrmnMRaO8T+Gkc465fOIk 9xUWA1vRUwc5Ri/ZJGit/QEdGSvwuAwk63JoEMhXrQWQmaZd9JJmosDFU 8ky+67/3iUNUib/iUNNY3fFnmYOoTEd+Qf2rizG8i6A2awGfU/b4gFVc8 +ugNZ7JmQKJ6a1zf9NNpKrfWxGGNkUvQuHpdzMP4CbptpwR+25Upw3OLI yC3IHuhh1lkxuWfS+6cDB63kC8t5+2pmJJSsQMzThHvHeBTFXbTtjHpNR g==; X-IronPort-AV: E=Sophos;i="5.40,382,1496059200"; d="scan'208";a="166777677" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Jul 2017 16:15:36 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 16:15:35 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 16:15:35 +1200 From: Peter Gutmann To: Damien Miller CC: "Mark D. Baushke" , "curdle@ietf.org" Thread-Topic: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) Thread-Index: AQHS/uRqIUk+oZW8gEGT/Uz9xKfLk6JYJMoPgAL7L4CAAOggyv//R6CAgADQGr8= Date: Thu, 20 Jul 2017 04:15:34 +0000 Message-ID: <1500524115986.58764@cs.auckland.ac.nz> References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net>, <1500519070842.37117@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 04:15:41 -0000 Damien Miller writes:=0A= =0A= >When I wrote legacy.html I tried to SEO it so it was the first search resu= lt=0A= >for the error message in question (it seems to have worked -- for now).=0A= =0A= That assumes OpenSSH is the client. When I run into it it's always the=0A= server, so there's no error message or other information available.=0A= =0A= Peter.=0A= From nobody Thu Jul 20 17:54:53 2017 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 3401E131BBB for ; Thu, 20 Jul 2017 17:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 6NckEBXbv9Sa for ; Thu, 20 Jul 2017 17:54:49 -0700 (PDT) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 956B7131B6F for ; Thu, 20 Jul 2017 17:54:49 -0700 (PDT) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id v6L0sjrX029145; Fri, 21 Jul 2017 10:54:45 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id v6L0sjdb064796 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 10:54:45 +1000 Received: from haru.mindrot.org (haru.mindrot.org [130.102.96.5]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id v6L0sitc007386; Fri, 21 Jul 2017 10:54:44 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by haru.mindrot.org (OpenSMTPD) with ESMTP id 0b32225a; Fri, 21 Jul 2017 10:54:09 +1000 (AEST) Date: Fri, 21 Jul 2017 10:54:09 +1000 (AEST) From: Damien Miller To: Peter Gutmann cc: "curdle@ietf.org" , "Mark D. Baushke" In-Reply-To: <1500524115986.58764@cs.auckland.ac.nz> Message-ID: References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net>, <1500519070842.37117@cs.auckland.ac.nz>, <1500524115986.58764@cs.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1500598485 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 00:54:52 -0000 On Thu, 20 Jul 2017, Peter Gutmann wrote: > Damien Miller writes: > > >When I wrote legacy.html I tried to SEO it so it was the first search result > >for the error message in question (it seems to have worked -- for now). > > That assumes OpenSSH is the client. When I run into it it's always the > server, so there's no error message or other information available. Isn't it the client's job to generate a useful error then? From nobody Thu Jul 20 20:21:53 2017 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 AE4CC131D69 for ; Thu, 20 Jul 2017 20:21:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 3h-qqKyLqKP1 for ; Thu, 20 Jul 2017 20:21:49 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8AC131D38 for ; Thu, 20 Jul 2017 20:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500607309; x=1532143309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MBCQFY/4rzEV6YG7HXFWTERxILbaGknMTnsJpkjoD0E=; b=kxYqvjJraXr0Up/jMuZmbO64m0h3NXHcb11CQc67gX9GIbZgQTXOs0Yd 2kMe/xaWNptRu52W68mzxsLexUToDWjkHI9IYYS8oKqrQCETY7U35ZWQ0 q/5FmND7FImZ1TWi3l6Eptt5AdHG/5w35N+Y1iC/GPIdJzfQProlV548p m1Ec+YTYI6weNUPKectyo7S6Exu9XuNqMzxzF1YjpJFAJ0rTkSZaCkff0 5sKHVsjDzlf/UefnS3o9yGRkjkDurLUfkTGiIZFmHlcOWvdQdBWzRQ+6v V1AqiFstEuMo3sTAGSsHG1B8rGqkhNMcuh2BGw+2mY9l4Ixge5XJEaOzl Q==; X-IronPort-AV: E=Sophos;i="5.40,387,1496059200"; d="scan'208";a="167044757" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Jul 2017 15:21:46 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 21 Jul 2017 15:21:46 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Fri, 21 Jul 2017 15:21:46 +1200 From: Peter Gutmann To: Damien Miller CC: "curdle@ietf.org" , "Mark D. Baushke" Thread-Topic: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) Thread-Index: AQHS/uRqIUk+oZW8gEGT/Uz9xKfLk6JYJMoPgAL7L4CAAOggyv//R6CAgADQGr+AAJDygIAA8W2t Date: Fri, 21 Jul 2017 03:21:45 +0000 Message-ID: <1500607284832.92144@cs.auckland.ac.nz> References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net>, <1500519070842.37117@cs.auckland.ac.nz>, <1500524115986.58764@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 03:21:52 -0000 Damien Miller writes:=0A= =0A= >On Thu, 20 Jul 2017, Peter Gutmann wrote:=0A= >=0A= >> That assumes OpenSSH is the client. When I run into it it's always the= =0A= >> server, so there's no error message or other information available.=0A= >=0A= >Isn't it the client's job to generate a useful error then?=0A= =0A= What error message could the client display? All it knows is that the remo= te=0A= server claims to be OpenSSH, and it shut down the connection after getting = the=0A= client hello. At which point you're back to trial-and-error with the serve= r=0A= admin to try and get them to figure out a config that works.=0A= =0A= And then the next server.=0A= =0A= And then the next server.=0A= =0A= And then the next one.=0A= =0A= Peter.=0A= From nobody Thu Jul 20 21:15:12 2017 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 89BA3126C2F for ; Thu, 20 Jul 2017 21:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 NCQfiFgzSqPv for ; Thu, 20 Jul 2017 21:15:09 -0700 (PDT) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 06E4512441E for ; Thu, 20 Jul 2017 21:15:08 -0700 (PDT) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id v6L4F4FX004854; Fri, 21 Jul 2017 14:15:04 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id v6L4F4S0038490 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 14:15:04 +1000 Received: from haru.mindrot.org (haru.mindrot.org [130.102.96.5]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id v6L4F2mN011131; Fri, 21 Jul 2017 14:15:03 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by haru.mindrot.org (OpenSMTPD) with ESMTP id 34be3c8a; Fri, 21 Jul 2017 14:14:27 +1000 (AEST) Date: Fri, 21 Jul 2017 14:14:27 +1000 (AEST) From: Damien Miller To: Peter Gutmann cc: "curdle@ietf.org" , "Mark D. Baushke" In-Reply-To: <1500607284832.92144@cs.auckland.ac.nz> Message-ID: References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net>, <1500519070842.37117@cs.auckland.ac.nz>, <1500524115986.58764@cs.auckland.ac.nz>, <1500607284832.92144@cs.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1500610504 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 04:15:12 -0000 On Fri, 20 Jul 2017, Peter Gutmann wrote: > Damien Miller writes: > > >On Thu, 20 Jul 2017, Peter Gutmann wrote: > > > >> That assumes OpenSSH is the client. When I run into it it's always the > >> server, so there's no error message or other information available. > > > >Isn't it the client's job to generate a useful error then? > > What error message could the client display? All it knows is that the remote > server claims to be OpenSSH, and it shut down the connection after getting the > client hello. At which point you're back to trial-and-error with the server > admin to try and get them to figure out a config that works. The server doesn't shut down the connection before sending its own KEXINIT that includes the set of supported algorithms. -d From nobody Sun Jul 23 04:07:41 2017 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 D8CEC129B4C; Sun, 23 Jul 2017 04:07:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: draft-ietf-curdle-cms-ecdh-new-curves.all@ietf.org, curdle@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150080805984.31280.7261458746599663122@ietfa.amsl.com> Date: Sun, 23 Jul 2017 04:07:39 -0700 Archived-At: Subject: [Curdle] Genart telechat review of draft-ietf-curdle-cms-ecdh-new-curves-09 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Jul 2017 11:07:40 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-curdle-cms-ecdh-new-curves-09 Reviewer: Roni Even Review Date: 2017-07-23 IETF LC End Date: 2017-05-28 IESG Telechat date: 2017-08-17 Summary: The document is ready for publication as standard track RFC. Major issues: Minor issues: Nits/editorial comments: From nobody Sun Jul 23 08:11:16 2017 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 0E38A1200C1 for ; Sun, 23 Jul 2017 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 axUVSX1R65Z8 for ; Sun, 23 Jul 2017 08:11:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B84C129B2A for ; Sun, 23 Jul 2017 08:11:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D2C7030054B for ; Sun, 23 Jul 2017 11:11:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DGqw7shZQaSi for ; Sun, 23 Jul 2017 11:11:11 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6622F300424; Sun, 23 Jul 2017 11:11:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <150080805984.31280.7261458746599663122@ietfa.amsl.com> Date: Sun, 23 Jul 2017 11:11:10 -0400 Cc: IETF Gen-ART , curdle Content-Transfer-Encoding: 7bit Message-Id: References: <150080805984.31280.7261458746599663122@ietfa.amsl.com> To: Roni Even X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Genart telechat review of draft-ietf-curdle-cms-ecdh-new-curves-09 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Jul 2017 15:11:15 -0000 Thanks for taking the time to review the document. Russ > On Jul 23, 2017, at 7:07 AM, Roni Even wrote: > > Reviewer: Roni Even > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-curdle-cms-ecdh-new-curves-09 > Reviewer: Roni Even > Review Date: 2017-07-23 > IETF LC End Date: 2017-05-28 > IESG Telechat date: 2017-08-17 > > Summary: The document is ready for publication as standard track RFC. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > From nobody Sun Jul 23 13:41:35 2017 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 CB775129B5B; Sun, 23 Jul 2017 13:41:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen To: Cc: draft-ietf-curdle-cms-eddsa-signatures.all@ietf.org, curdle@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150084248880.31306.450946335865671294@ietfa.amsl.com> Date: Sun, 23 Jul 2017 13:41:28 -0700 Archived-At: Subject: [Curdle] Genart last call review of draft-ietf-curdle-cms-eddsa-signatures-06 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Jul 2017 20:41:29 -0000 Reviewer: Jouni Korhonen Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-curdle-cms-eddsa-signatures-?? Reviewer: Jouni Korhonen Review Date: 2017-07-23 IETF LC End Date: 2017-07-25 IESG Telechat date: Not scheduled for a telechat Summary: Ready to ship. Good that Proto Write-up took care of explaining downrefs. Major issues: None. Minor issues: None. Nits/editorial comments: I just have one question whether the use of RFC2119 language in Section 5 Security Considerations is intentional? I mean here that sometimes e.g. "must" is in lower case and sometimes other keywords are in upper case e.g. "SHOULD NOT". From nobody Sun Jul 23 20:26:13 2017 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 9498B126B71 for ; Sun, 23 Jul 2017 20:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 mzv2Uz_n1ScM for ; Sun, 23 Jul 2017 20:26:09 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15254120227 for ; Sun, 23 Jul 2017 20:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BbXDO31CYcWCn/VqMQ+jc0DIVl/bZEGrRzvUN8c6PPQ=; b=JA/hmJfVl4vMQ2S6Gyf4DAq/fYc/hmcO99m+lCsV8CmtEe0cyUdjzkaz3x6DB6MYkh9hx7DZtHjTIavvyf/jfDk1omjauk5adiaQJXyZD7ZAXcsC75kZsjCQ49ETbP9cPcsfHGer+e1MxA/uL4guqq5KGp62ea4kdypTnsRrS2Q= Received: from DM5PR05CA0002.namprd05.prod.outlook.com (10.173.226.12) by BY2PR05MB2310.namprd05.prod.outlook.com (10.166.112.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Mon, 24 Jul 2017 03:26:06 +0000 Received: from CO1NAM05FT009.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::208) by DM5PR05CA0002.outlook.office365.com (2603:10b6:3:d4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10 via Frontend Transport; Mon, 24 Jul 2017 03:26:06 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT009.mail.protection.outlook.com (10.152.96.116) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1261.15 via Frontend Transport; Mon, 24 Jul 2017 03:26:06 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 23 Jul 2017 20:26:05 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v6O3Q4TL020221; Sun, 23 Jul 2017 20:26:04 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 7D74E1144E; Sun, 23 Jul 2017 20:26:03 -0700 (PDT) To: "curdle@ietf.org" CC: Peter Gutmann , Damien Miller , Deb Cooley , Tero Kivinen , denis bider , Russ Housley , Eric Rescorla In-Reply-To: References: <22892.35863.542104.942153@fireball.acr.fi> <82005.1500305248@eng-mail01.juniper.net>, <1500519070842.37117@cs.auckland.ac.nz>, <1500524115986.58764@cs.auckland.ac.nz>, <1500607284832.92144@cs.auckland.ac.nz> Comments: In-reply-to: Damien Miller message dated "Fri, 21 Jul 2017 14:14:27 +1000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU Sender: MIME-Version: 1.0 Content-Type: text/plain 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)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(2980300002)(199003)(189002)(305945005)(53936002)(4743002)(6266002)(38730400002)(93886004)(6246003)(110136004)(229853002)(7846003)(117636001)(47776003)(6392003)(2501003)(39060400002)(356003)(106466001)(6916009)(2950100002)(2351001)(478600001)(76176999)(4326008)(50986999)(2906002)(8936002)(97876018)(81166006)(69596002)(81156014)(189998001)(1730700003)(50226002)(86362001)(2810700001)(5003940100001)(105596002)(76506005)(53416004)(5660300001)(77096006)(48376002)(7696004)(68736007)(230783001)(54906002)(5640700003)(626005)(7126002)(50466002)(55016002)(97736004)(8676002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2310; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT009; 1:CBiMMKjSAhCGgIt+QlVdvGEDHY6ohnXGsE5St4iWCKseaU/XXNp1D3Y7Me88iIVrherfH5D6tj/J5Kg2Sltcy8GAsztrgoVhYBkpEjreRRkKUixbY0s6S6+jr5wQCi/n0iM9CxoYl7lpTGYEyhLJk18a5TN8pyvp7N4GaoO0Z+R2Top81mwyXX5bq+TEw8/QhqDVFXnu9RGCAvOU+P0X9D9Ejb5sz9+JiavChMQJ4wjlMt1kKZBAJrigChWOyQlApClwFmGdXuXgjmGOTy6qpKlH7pc6gD31WrOE3vSKoHWccqv/eHe4r+NQXivVkzElUSkUzow8FoQrtluZYRPGBJkP1QymDJymjpgIeyvwWva1dKl8wHY+Xef86sV4r18cbdhpwoY5zohwD84PeAD3A/RCpHDNjO2OD8eHlBNCn/h1gBaSkgOwBh0yRmO5779avsw7K068gXLGLbSR1lE1Mz2UjeG7YCcJvk1s/zDQAcK1ofmhvzZqJZsR6S01Qi36Oacr6XsRT0pjmT6qIUjIsFPp1Jg46cnXARxrsd9u85nhB3t0WfxzIuD+BdWKF63iM1gYYWYVH5Nm1TOk1NiItvnj8GXMLwVtP+YmMiLr07M02V6601/bNAwDvT8LqUXN8G/GOMzKrL0e/iSYWrIL7t153jsmQQlgg6kIH24UlXvtb5NhOrTlNfl20VYW+qGbDJGw0KphKkZ1fh97I44+jcSTmhEQtAoPfeXHqQHqzGp/LunZx5ROT7e6KcdNv0qHORFI25Qdvw3WRq/O5EeRcygIhbaL2ll5A3dFF9DaEiyQA9+VwRX07r9eKk++hlSnEDwNqSNzmCf/qsgr4aJdz13t0ZO00nhqURQiMz1wbO4fDE18cMF7RO/jVbmwCMr32k1ZTwqYq3r3o9T+86GUoA== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 28830a13-ff20-4863-a1ff-08d4d243b868 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR05MB2310; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2310; 3:yDRPDjDfkS8m/6nYcwWjOe0rujwElX1gZbCQymvZ+NawZvBYpn3DcziASi0Bwg3LZYD8FcxXARKY+qbLWWNrdFN8RrbHalbKCyHjHy+qM4u0KgscgpMbC7UzXOJrV5P1hPZYdUQ1Jg4u0ZpdtwE2NRxJOZjKHaGwSqIx8NZz80t0RY1b+CY8BWmNWoil+s8bad9aOBc1AQrFUc7QfOBOLz/Efwu1CD+6PeF3rjAQAkjQZx2/HCdb6RGNwbadqHN+/MJ2isqxVzozZW6bt7wXWe7HK32nqDItozJtQZZ1WpRB9+JT6fPCdoe7RRUBEW/BpnifFIpYajAnv50/Xj4KrA8+1JsUPIMMXTZx+8ECngNIuhbpd/seFmAGtYMqe7g9+YWlM0i+IZM8DewlCReKqLyGRiQApMHnay9tN3qEFhSa/bAwzuCQWc6GMN+xIfvxwvSiUhVo8rpNBtt6hv7f0LTf79zXcfwR+HX8nP82E/f4g/3hud/QE+e4AEVoR+zUOiyUAmy7+B4Ut6vYgkkRCSeCxnJh7fMJJ4jpSROt21M8x9Hjf8gejNKkuNl31QyYQrHh1OS1Xmu5HEzhAYL2V+XbnTS9hUny1DLJ15DqkGPD5eR5ZuuHN7RBg2oEWJOc6K2YSEXbZv5rMTjBk8zlJ8GvymQ60P1fkrEO5wX9BYn0UhH0JBcNJyDsUY4NFoBud6D27+I2cGR80Ei1Db/7QLFFuYScr6NOMo2NwNuNO1lU++vKqhF5VM7ukgPMU58aOdFP2xopnuMI2zBsJGu3ERo3zT6VewJtm91+tign6eOPfufwHAA6pBCuzlaAqkP1F6DLgxLQBr7a8eEU0TP3QjAXgf1H1Hqh3xNI6AAr0JiPraEOISpbBXqLDlDorRYP8XHYrDBNAV2jNlGSxQV3Ew== X-MS-TrafficTypeDiagnostic: BY2PR05MB2310: X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2310; 25:TERJZy7dVefPYZJVx+1fN+UfpICcKreS2kodF2eIQMtiaYN3IiiCiy4KzXJ3xoT24ej+tpCP0xEm1fsBMGrgl2U8c49jeMhqUaJze3HdYpBFXFheZtREKFSuzEuqDXOIVcRy9XJFJo4ZNbjmm8GY8Zu8yyJje7RudaVbgXk+uSfM5oSiXsrwxoTTKwD/NRK9dVFFNS0hSULyJecgWqiJpNwqy8dL3UDWTxsnq5ndQUBpiMiYOAYlHu3oimgZ5twzqD9oXaICDVu4Lg2/tTsUO52ZGcoPW1qj3LSdSLCdeV04bcLFNXnhJO0jOQUm3hPR1JtowOlx1es8zlk5ONEDlMthSlXiBEntijRIii4JNOev4d+aO+DfQ0PpNdi0W47F6l7Hj922HolX4oi9dS0z/bxh8bmn5DDBBOfEoeDLWd0HMff/QdJNeOBNgsUiyED1cRSlcvAjttsMmdYc8uq7cHd5xm8JVjcZ3BeY2JSX1YOnZFifBtiLeOFnCZqR+te5tpdgVtyA9U/hhWu/SH9HWUS00fMNciWcaCOUY5/NstDs+yOM2OMNIVOFaRpqn0gfIdhafTBMYEwE+f/TYoZ9+N8Wn/b1tswLLWl9RSrfdhquawRXOOeb3K96lJGKCoijjtoSG8QD2zMc2mDEXRrviYzJ2rIqN8PI0FPzansozsPRXdWt75m05EIJgOwaozwIw+MHBROt1DYqXBmJ6n91cilRHP4tEOtVtfQQFOIPfwMdkOdHWEuiGilPXaD/NiFmOPx0I4ZmbUwdmIdAehG7hmmWGBjJrfVB9vIT1q+Xs7yQQX4m1rVDvNA7MfQRflROBIQGfwywmIN1utScH8MdF9G36OiQYX81fs7DRoWVnfupoID2g44Tbm/fOaE72YmXGyvvV57dtSC1ZFE8SJIAwqO5AhdjsVuPkNNg94mfO/I= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2310; 31:YHWMsG3sjdG3xrDO389BFMKeYZ5POCi7UufEwJUxYai1+DKGtmWu6wCiG+Xt5yx3uLvMI/QE3bdv0qMwrm/7tFA3o/CImG4VhizZJuRTah0kxdkSid5Nek0svfMg2BPy65Ujgofzz85+Fyq85MoUM6gA8gZib6sEJ0Nb30aGVQQPPydU1qFKT9r+tas8lSfu1ElEIEqRFBsRyNUv6iPXWrWhtAL3H0qLvpbYT4fvn4s82VOr5vw5CLHLN/anSaT5RU4WVc/1cCwBoezSMQ7FTwtPMyknoG3fLeyvpYb9YZnpmI8BbIL7ZPTSCj1Kerm+4dLuDYG/Uo3QuWYz69xSy/AMojj3JDfrvvEh022WY8NyEszokNliw4exMlSCRqsgjr6Q6ABnOQ69rVX++hsSgDwcwCJQx5aESA4IeGVYvoU7GF6nE9M3Xoh8gIYYiShJZSUtZzYG/VAdG++UL1MDRA2UBK8BYPUoOXEJ01TkcAxEE9xzwppHkhKXnmURmHgiOBYZRsV58PnV+RddKugbxjp3Pxeh9A3Txvx7/1dPb2wKz9yk4q33SC1S49ksIuKnyH6VBu1hpG3XaCt0WI1vHpZ6A5XnSeMykJw9i0BJhablyZgBCNEiZsrJN76lQ8Iqbxa5CQ1kkRUBTFCfXz1Vf/tzqXvBO2Hgk3ncrDLq1OiThjhHGHfvDNbTzV/KUOGhd67Kv3samT0l0CvFYnkxZw== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2310; 20:SJZ74fjSnjQFoTIZtdjFujlV1SQURyddFoIn5LfIxUjgb+luFIBmxQZuXNBlr3UcEwYrJSG7qdGg5mIehKBET//HFiFTnn0xKTvn1jdoF9lf3DZgBMNKExw5G0Ton73Qlel0qGU+G2FIYjX7bJZ5I0KRxXIfQ75jtkjg4yUB9L15tyxU8h43src/QEmg/exeh8pCQqOj7F0cyMROIAeShx42XUzCH2v2FRBHkHSU/A0IGtdBOrBsEAkHtQ9/aIwm2UMNQE4JW+K/MPg+++T2RiqPru+ZLmRikiW7ijJrKhnq/XkQzZvp7AIk6JQnlHCXH5/KBmd5zODNECMUFd471CP98xJjFOx85PQ5hSwJa5ore1iyw8I8HGBbQsDtVYhspgkH/NViBAfwAcKEvT2UtUiWn89Y2nqTTSN8p3k/OBDwG7VHrKaijZRHg6Kt5Mju/JARCZ/VPlR4/yXVNGlhbYz31m7iphuQRhijQmsiKmNC3in3CSR7Chcro5vKSJc+ X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(100405760836317); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(8121501046)(13016025)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93003095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR05MB2310; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR05MB2310; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2310; 4:yo+om0KmTY3hYFB6/pfE7Q/vvYlXayXr1KIhzjygeV?= =?us-ascii?Q?lfLYWkGxnQ7tTws6SV360owJ9+55QzLBMHy9ilITjer6TjkY/d9HgvkDx9wu?= =?us-ascii?Q?FdcoO2rt0tXr6lDDTfNcxt6EK4bl4CDDVuBnT8OgorEiCkyePg8s3svWbpCR?= =?us-ascii?Q?UNY4bAELyAmMlgM17lZY/ytLOBqcJahLPq33VUjvfYsZuUvn3pKqwpZwXwrf?= =?us-ascii?Q?jrRKdH7EFNBaGgHkA71dnJxb5EGMpsa4XGpauwQnLmSiBcvUx9WmyvU/ilaO?= =?us-ascii?Q?6jXWW2WADshGtDpCkB8tBGH6CoaPFhb/ha9GXjWl8xg4wFvkjqKIVFYNU5Z7?= =?us-ascii?Q?IAIMBb4/RnuXiaOwS2QgNXOJOZ7J0gu/eyUXuIxFIEYSeHvnZULHsefJI4KM?= =?us-ascii?Q?r6ibkslzFQ0Yb/DfZIFzg8is4aJg5kvVp/+JVUCB6mUZFOw6n2nQRYkc7pqi?= =?us-ascii?Q?GDINfPbFY5lGCx1RL7K7oGRm1ceXFo7g4kBDs9AbvgURpXuA2L68e07pmYGn?= =?us-ascii?Q?/Cvjp2JqV83QDDmcwbgldjfVInrMWhJFkRnFCk3yqiXO7HGoWMjIpDwQThI+?= =?us-ascii?Q?KPjOUq4j3FeY0Mz//BTIGo6AimjhdI95EYwjPwH9C1wGL9IoLz8zgk2nGSgQ?= =?us-ascii?Q?WWJROtn+zMKPHbeLJY3Zp6YomtBKWTFugqM8OuOFL9Ytf8/MQTui3M9OXOrT?= =?us-ascii?Q?lN5Rvb0P3gcXlSKkhG8h0zor9H0hsRzmATSh/M4huMQ+7RkJZCbkfdh4IQUj?= =?us-ascii?Q?gO4oNDXFkDM0+HbNUuaQxL0yd4RDTVkunqlpyTRTf+sJ/Ui7uERSSV4A+94u?= =?us-ascii?Q?8w+tFozX/XsjcQ4gTMyLVDyT/jCE82uqPVjGnmITb0Shl+NvJrxnJglFmUIz?= =?us-ascii?Q?UhrW6Eyy04cSpINO7lUXhQKIUTRPJ3ZHS+ug7v39fjmXvZWJULcQauH3W551?= =?us-ascii?Q?GLwZJNMuoQ8sc5Q5eiSvA/eliIXlY/kXudftsAL8T3PyR+++uKeJyAB96Lbi?= =?us-ascii?Q?T3k1qlP52+CEWiyxOwvZNgsCMHd+l6OVq/B9SZz9klnCoSzsNVZRxhHPvYc7?= =?us-ascii?Q?9YBs3xsfJjKeTfBvtRRwILTMhz9t78RM3Aka2eslhra62W9/2pR+mp+SvVcx?= =?us-ascii?Q?y9RtiY13jd097ze1CG+crwxwvCf+0fc7rDZX5WjrWdbZaqQokuaU1Eayjd41?= =?us-ascii?Q?ddl8I6fpX/Jsy5STOxcAqIwcaKooZPMvVCH4Y4nTbRcqQoSoBRIOtuX8u0Y8?= =?us-ascii?Q?46XjeX8OBPgaznolBItRruMUqoUnwsvCyFHTQ6C80cBsT0waYahtQB1yE03g?= =?us-ascii?Q?=3D=3D?= X-Forefront-PRVS: 0378F1E47A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2310; 23:eMWvFwvB4hyJe1C2YVLiTbTmYCo72rBfcf48wOtLu?= =?us-ascii?Q?qQBDQ6mma5g+HgilrHYQzcHRc2Nmt/auRfXG2ZW7vf2X5E/rRx7pElsz5bD4?= =?us-ascii?Q?ghCdiQhLAxeQqarYx8OwroQdzGiupmkT8NqibMSQyPgmTUWJbsRAqraqAkD5?= =?us-ascii?Q?bAxfdq4ADNDM3YGCNNB4ZS8grvu8Ez5ZBYwfnkL8zatxvETaPCXr4c/8WHD3?= =?us-ascii?Q?vkTWyYevIp6gRt+5rS28nSioBhIOtBKxiy9VihHmnYRVwtk4MaiI2gDsE8Ow?= =?us-ascii?Q?XkzSvIIxIKPtRcIjl/EReMICRVojoE9UP3ukFPbfahErTjm6ot8cIiqSxoHB?= =?us-ascii?Q?hXQKz1ObapQIxEicKileM94OlbH3JhHqu49r3nHr0qNIi5TNxFMBYzvBgV7/?= =?us-ascii?Q?pjMLRjDVjhlw7bNNdyqyv6c8bimtZDp95+IoPYi3Eie0expJ5vb0b3XZp/Qs?= =?us-ascii?Q?bcZ7V1DVoArO4EsbMwSeUfC+dr4+7BbsjwcV3sOLuWFeIPQzQG071V+c8trW?= =?us-ascii?Q?6waaI/2sunvFNE2Y6QzWDbUwQ8CQ/cVavN2Oi60UvSale8bDGa1t7oVs7dxK?= =?us-ascii?Q?rZS/ZQUZmjv5iAwOYCmzxeX1Kuvu0/+w2nreHDy5OaFsn59f5YUVrtZZmeRy?= =?us-ascii?Q?uG+JJmOGiULeYKaXz5iTPFfH3Twn/OxahTM3XxvuwxAntUhwFptIYQ7GOLo8?= =?us-ascii?Q?Hci9d7UPHiL6wyh7/Ha0/pKaLouZKSsRSr60fugXuFLDoV8B8uzS/SF+OKdt?= =?us-ascii?Q?viDBsTwOTgsD0qEPD/2sLzyYEtis+uG3lw7lxrR+5t9yKnAMewR6wiSbGfi8?= =?us-ascii?Q?R0jQMh6rK3UQ3RxAahNBZ/ytqnsl7lHhcDJ8TCEk11KPrXArSPE56wJnKCxU?= =?us-ascii?Q?HlRM6A/YmhKUHYhclM6S/JhaOXUSmEDBHD2HSZw2LMh/ngMnlybiQAImcm7e?= =?us-ascii?Q?j7cHlwLx+HOmrDnCN8Nu25oyFKMj/YFdlgBCeEFvRuGvxS+hWPZLNmpzxS1J?= =?us-ascii?Q?nQiAacZYyAcg9GfKkBiJRfaFa3deZVqKU8KSs/l6mYvF57jFHFon9m30L7B+?= =?us-ascii?Q?OlkEttlPszPn4mJRi7znK492lgNywvdz8wB5jcUrj0PI31qhhOfSxnBKyvph?= =?us-ascii?Q?fNpMQGL3q4fFJ1tHyeqADLH/h6dDXN/SMrHtZBBzlK5IP1lDsIdEUuLHlsjA?= =?us-ascii?Q?lt13WXtniP2kaRXxvNHhbhg7Q35tqJniRKnxaBLR/pS5QNcU1t7z638uzN5s?= =?us-ascii?Q?9NQLbnh6h9Bjdn2p8nl4TBg+7CJQO7IBdvZQ/zSkayn0OgFUeor+lYkGMA6m?= =?us-ascii?Q?66wkGlQZYItCMgD250EZtMevEXt8VT+jfsGVkd0M9ssk0pFnWmI5i3sP4wFv?= =?us-ascii?Q?vsw7mV5Y4Mk6LTpbtdRoXBU4LPmnu3ar19VWuY9Veo2zKkdb36r8fSN1Vh2W?= =?us-ascii?Q?3t/+hukoqWcUl4iJNRUWXsxF/xHjq4BtIDQ5MOZs/B1df7cJrMorK1SImLbs?= =?us-ascii?Q?3NdSDYJTyZa8lBH9iqCoyTIy3h2/ox10dhcV4h16OO7JVckU5ItR6iz?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2310; 6:tV5/gKyAj8H1a35b2tJ7bZYCKBHgfIIYD8qM0vlGai?= =?us-ascii?Q?7JfiVJMlS23Legg+3iuVo5ZrTZ7XLmnP6fNMylzknqZ5FlZVSl37cpfAIjg/?= =?us-ascii?Q?+e1t9KQ7PXVOJkAJQKtI1xJLvrLAjVBBtpYCNSGrXnTyeMXU8s4NqRTPsOJp?= =?us-ascii?Q?Mrrt3Qeyp1AZL9OYGlNd/7d4GtHB4REpRX9eItdCXyhaX+47kyng5P8g5cM9?= =?us-ascii?Q?ChQLrIyZOIb48w3nyq+8siz127lP+6ZmP4QxvbkAEmpY1cvf1NHdmBD8Pqzn?= =?us-ascii?Q?fp4WXpG8WYA6rKSSKSg/HVr3O57le1cs3XHHohLnRETd/AeYlU/RoYPNFoUQ?= =?us-ascii?Q?TwBBH1HOL+oa69CaVTXhrALtePmYC3/2AyH2eFDr4WgcRL5kujRmrfHbV+19?= =?us-ascii?Q?eWD2ARM0vlFMWRcRoA7POkSCMEZ/ZMLN7N4buZM7AnQI1JCjbK2S3ENXmB21?= =?us-ascii?Q?GGBR1nYAQe0rTLn3yROAQo/zm7MrVTD4/rPxRsO3PrKmKd+fVGkrwHF/+Q/c?= =?us-ascii?Q?p/K1K2dJM9BtKi0LlmcJUfhSGcOLUKP5Xkk6UqXZ40rsYU/cwMenkj0tFvpJ?= =?us-ascii?Q?Fh+WG/dj9bD/JC4ig/+VdwoVJqGCFb1h51AG24OUnIM4NQaNv+XXDgH8ISbR?= =?us-ascii?Q?/Mzh2xAjEcLA7dZgaodEvOtVgEwQncJGZS5SN3BvmCqAVH6Dve1x4l7MnqxI?= =?us-ascii?Q?+bVk9X7qCmpK+MvVqMl3Z5mxBoFKhEDaTFgcHUtmVCIVGbEaCrqO6Zkr3J0r?= =?us-ascii?Q?BITXw4uCWjwFXcIuURha3HZTvu9M1KX+e9aRlhbrDjBDh0K/i1irTIsRpQNZ?= =?us-ascii?Q?aLQq2xl9IyLATGCsYR4JDWHHek615lvUnD3P0gqwoUzYfTY6JEg5LhSe73Qm?= =?us-ascii?Q?Q2louJ7VdP3klYoNI0C5IiVDcj0zkrj1Xl9TJNwBP9SLCiEA8qBp5lzOwbCi?= =?us-ascii?Q?SM5qUZkRx1LN8HfeoARX7usHrZ9+4aeCZV1dj/+IBXPc6jv4nS83soSdtIjn?= =?us-ascii?Q?vWjcuFPArunvIMN3uIcaMZ?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2310; 5:JqOXORex040y30aGSS456OJsSHocJT52kuAhxp7LipsI2dwLfL8MMagSkbESat251TyzEw+vTFXsPup/SJe5xMY4/U94kDbYR0rY5/qkWidMb+3ziGn55gnMNgDT7nzRI8q1MXn/fqM/T8Lscbndwk510iukW9Z1Olur7FFZCVoWlOPHDLPsGa7mhL+RQDFvLbjNtF5QftKSvz35fby26vFqmwGnjEfP+j3Uw1BdezO8S1hh89i7j2mQiMJ3U+oOpiOViKV2ONegp1c/3aPETbaBubXOmdiJs4cyyulmz92/uzd/8WeNm8R/xq0TSU89LA8shgFA4v2TXi8VXYy3lXdOfbCcqe30M302S0H5ZYF27mjdVIX7CmetBUkoKhaw79mWbT3CU8VBvr9wd5pZImWFNEE3qS7TSg68Crc7mApJodIj3HsYPzOP5cpZx/3hrqEZHJtAoN1ZhVnl1GLtsjWWuGuF+dEKuUBgbRUO7eBUXjbfBe4X3+MAodjFXdge; 24:5/6q4P/vtHm1TzX1FbFfZ5iEeR1N8Erq5xnCkvReJ9AWDGoX7TtiMd9r4K/FO1JNaV/FcL4z9+l4dvFYzBocWt8zmtC/zeiBj+BR3599mHY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2310; 7:EiyP1Z0NC47jqabKXvE9aEHiLbon4cb1oT1SOR19CWhT+sGFy0sHr21NF8WZCrGv/RgNcnCU7o9HceUV5//kCctWonB1jAgRlRAkwJwf8s+VMeT2m8HXrAtdfTunqnex9FxkKZvS7AxJFeo42ETocxbraS4fnQV+RotfazXEEdl6CzVLIpWf9mFpjcUqM6uwgZPRoJGP4b182MpyRe6iA25gEoJzUk5rN6/uZIlu/JqMFZKEAFmC1AJiAYY7SHKiV56EVmeIjMd9W1GqNxIo+t/C80TLcFGTboEZahbY8hB0FM6LGzi1a19j5R7nOZts5xyI9dFMynHuib8fsn1UJfCOroGN+Phti+nkc3MbPqAEzSjRLzet1YFl+7vQp7AKT37rD+bmfcyma0CScWP5SkqgP0lLjEOLwMfjiRnuMz9rjncObxTzmKmuR9LYiqyWPwqg7+iB5BzPavzj/4pp6xxssp/Rdiy3wV10e70fk0N71eFcKTQyTI0I9JuazxI1dMhOi1zn0STDEniGxYOPnXhKRh6/O8lNDvU4yMKp4Y/r4CbfSULTKyzV59wBDJpOdWPi0vaNJqv+ImQdqDhck83+Lhn/yJRypMWsj8F5wGH32tOSs0BLLGQVucedW+jH95eutxn0qC/wgFsnUgmbGXOdvFBblPQ6zOvs1uLWwgHKcTHJhq38duHUa5BXe1bs8WQqa8F7QwGlLvWJWwZLhYRZaE8+jiCVDhxk6r855g8iS3s2+XAGBYxGc7Za8WPbOn25AhqeR7P3zA2EOSk+dK8X2vrkf45sn7r02DLq0+w= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2017 03:26:06.2089 (UTC) 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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2310 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 03:26:12 -0000 Hi Folks, In the wake of the IETF 99 Curdle meeting, I am in the process of updating the draft-ietf-curdle-ssh-kex-sha2 draft. The following are the summary of changes: - remove use of SHOULD+ and SHOULD- - enumerate all of the Key exchange methods. The table will still have only the non-default "MAY" values, but all entries will exist with a brief indication stating that they MAY be implemented instead of the stronger SHOULD or MUST or SHOULD NOT or MUST NOT. - I am listing diffie-hellman-group1-sha1 as a SHOULD NOT (because it was a MUST preiously), but I am also listing gss-group1-sha1-* as a SHOULD NOT for consistency. Is this okay? Or, should I list the gss group as a MUST NOT? - I am thinking that gss-group14-sha1-* is better as a MAY than a SHOULD. Everything else is MAY, here is the suggested new guidance: Key Exchange Method Name Reference Implement ---------------------------------- ---------- ---------- curve25519-sha256 ssh-curves SHOULD diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT diffie-hellman-group1-sha1 RFC4253 SHOULD NOT diffie-hellman-group14-sha1 RFC4253 SHOULD diffie-hellman-group14-sha256 new-modp MUST diffie-hellman-group16-sha512 new-modp SHOULD ecdh-sha2-nistp256 RFC5656 SHOULD ecdh-sha2-nistp384 RFC5656 SHOULD gss-gex-sha1-* RFC4462 SHOULD NOT gss-group1-sha1-* RFC4462 SHOULD NOT gss-group14-sha256-* gss-keyex SHOULD gss-group16-sha512-* gss-keyex SHOULD gss-nistp256-sha256-* gss-keyex SHOULD gss-nistp384-sha384-* gss-keyex SHOULD gss-curve25519-sha256-* gss-keyex SHOULD rsa1024-sha1 RFC4432 MUST NOT I also have a new piece of text that tries to describe the section of SHA256 vs SHA384 vs SHA512. However, I am not sure it is reasonable. I provide it here for your comments: Selecting an appropriate hashing algorithm As may be seen from the above, the Key Exchange Methods area all using either SHA256 or SHA512 with the exception of the ecdh-sha2-nistp384 which uses SHA384. The cited CNSA Suite specifies the use of SHA384 and says that SHA256 is no longer good enough for TOP SECRET. Nothing is said about the use of SHA512. It may be that the internal state of 1024 bits in both SHA384 and SHA512 makes the SHA384 more secure because it does not leak an additional 128 bits of state. Of course, use of SHA384 also reduces the security strength to 192 bits instead of being 256 bits or more. This seems to contradict the desire to double the symmetric key strength in order to try to be safe from Post Quantum Computing (PQC) attacks given a session key derived from the key exchange will be limited to the security strength of the hash being used. The move away from SHA256 to SHA512 for the newer key exchange methods is more to try to slow Grover's algorithm (a PQC attack) slightly. It is also the case that SHA2-512 may, in many modern CPUs, be implemented more efficiently using 64-bit arithmetic than SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs SHA512 is more about reducing the number of code point alternatives to negotiate. There seemed to be consensus in favor of SHA2-512 over SHA2-384 for key exchanges. Before I publish -09, it would be nice to see if this list is reasonable or not for other folks on the list. Interesting note: I did not find a gss-gex-sha2-* defined in RFC4462. It is also not found in the I-D.ietf-curdle-gss-keyex-sha2 draft. Thank you, -- Mark PS: For completness, here is the list of all of the Key Exchanges methods in my current copy of the draft. 3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4 3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4 3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4 3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 4 3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4 3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 5 3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5 3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 5 3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 5 3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 6 3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 6 3.12. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 6 3.13. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 6 3.14. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . . . 6 3.15. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 6 3.16. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 7 3.17. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 7 3.18. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 7 3.19. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 7 3.20. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 7 3.21. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 8 3.22. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 8 3.23. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . . . 8 3.24. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . . . 8 3.25. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . . . 8 3.26. gss-curve25519-sha256-* . . . . . . . . . . . . . . . . . 8 3.27. gss-curve448-sha512-* . . . . . . . . . . . . . . . . . . 8 3.28. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 8 3.29. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 9 From nobody Mon Jul 24 07:26:27 2017 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 1C936131D35 for ; Mon, 24 Jul 2017 07:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 k0kNJXQUoBPQ for ; Mon, 24 Jul 2017 07:26:23 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 5FD15131D32 for ; Mon, 24 Jul 2017 07:26:23 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id h189so24401272ywf.2 for ; Mon, 24 Jul 2017 07:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:from:subject:to:message-id:date:user-agent:mime-version; bh=eLhRYd7/1F75a6oc34JLSpif8D4+ZT4bJECcwLHaDgk=; b=tprBTwyLH+pl6WujE9rFfnqy6wGP/eO4i1Btoo5+eB9lrVIK9RBL59yJ7gfMTMs5oy RNizCdjIXX2lwkZH940x+wkZGya2DiHUEz2ODsSsFIXDzrQTbRC8Itq7NdG1qZCnDu5+ Rk6j7/6yMobjkj3O1kcJ09W6gywNjcSbpavk0LTV5L7XUi2kFTEJfT4Tx+yX4l/+NMLe kJ6IZttp8q2mner5noM5RB65mJpwo7aWrVWIW9oR7EVuVSoE5iXp2KKDnPlN0zUfpFJW swqQQrIonPKTCmeODk4kmIx5dq8GVJgm0uKwhHITN6WSG+9CPbHYQN76buRlYRa/sBdU TN2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:subject:to:message-id:date :user-agent:mime-version; bh=eLhRYd7/1F75a6oc34JLSpif8D4+ZT4bJECcwLHaDgk=; b=Asqqbh2EYQvGzY9gDBnfuUqfNwsgXGt6XtTCOoTEV+DQXZOu25hgY2s2bl6X+veiF/ 9Budwyt8tm/KidqY6jgD4Sfd1wAWcu4MQJq2L2xUDEzviyxdlQaFoaM/YCeJeXsI0bVg qQ3xD/tspyYz9DiAYeql7QMJif3e7pGfdR52A4HuvaIFrJGgEzj8+ulzqp/zi17LCudH 6Hb5OK+gzJLosXXU3lLrq6G3VsQ4T5OmPR3rAVSUgcVgC71MAa+GxinaAs+C/0YiWevs DCGtG/DoqhQgbJmFq++gHreTD9IHI7KcAl+we8R/spcYM/UpPiBFh5/YmyIl9iy0HmE2 /log== X-Gm-Message-State: AIVw111DpqyrprTM750kD+CJiUHmrev0y5++sZUlsJcrRp+p5jF37/wL FHnjm4CcJqZDqOh0hKiG0g== X-Received: by 10.13.232.151 with SMTP id r145mr13284830ywe.460.1500906382430; Mon, 24 Jul 2017 07:26:22 -0700 (PDT) Received: from [10.6.23.170] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id y66sm4135496ywy.28.2017.07.24.07.26.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 07:26:16 -0700 (PDT) Sender: Matthew Miller From: "Matthew A. Miller" To: curdle@ietf.org Message-ID: Date: Mon, 24 Jul 2017 08:26:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aXNKCiSJmPA0qL8vtpFPIjmfWjKtMDV6W" Archived-At: Subject: [Curdle] Regarding X25519 in JOSE ... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:26:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aXNKCiSJmPA0qL8vtpFPIjmfWjKtMDV6W Content-Type: multipart/mixed; boundary="FKPNgd7AB0qTekDBwsD74TqDqDMFNjVUw"; protected-headers="v1" From: "Matthew A. Miller" To: curdle@ietf.org Message-ID: Subject: Regarding X25519 in JOSE ... --FKPNgd7AB0qTekDBwsD74TqDqDMFNjVUw Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello all, It was asked if any work more work is needed to add X25519 (and X448) to JOSE. I believe [RFC8037] covers that, so I don't think any more work is necessary right now. Thanks, --=20 - m&m Matthew A. Miller [RFC8037] CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) < https://tools.ietf.org/html/rfc8037 > --FKPNgd7AB0qTekDBwsD74TqDqDMFNjVUw-- --aXNKCiSJmPA0qL8vtpFPIjmfWjKtMDV6W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZdgOGAAoJEOz0ck4QngW7z2gIAJfaOxPecy8Lj4hs7yaSbZt7 oMbbfOWcn/hu44HgT3qqwihvFLYtOuam+2cmFzdBHDkj+aiZFiplfh/6shHjPprs DNRe8Zxz46DcK0dTgEd1bohm7WGpsgUVhQT9VK/9R5fcvILVpCYe19oY3QdIbEWh QDO+xlgmDerBwwyuJtvGLviLlTkmapklw8AmhASU0xDdWKdwL3R3cFBwkCByv3RA Viv8uqUbgIoB9MSLIr+Wr2FZ3v0bXRln0wr2ypDsV6C3GY0emAdXVS/liDXTVndj 9zT1tZ8fSF2w31dYSTupEaAL5owjpDVwyEPQQLYQNAJ7iuflbTQybqNhFeZIx1Q= =u6TJ -----END PGP SIGNATURE----- --aXNKCiSJmPA0qL8vtpFPIjmfWjKtMDV6W-- From nobody Mon Jul 24 07:39:00 2017 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 1F5F1131D6F for ; Mon, 24 Jul 2017 07:38:59 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wDtPkCGk_Y3T for ; Mon, 24 Jul 2017 07:38:57 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 3E620131D33 for ; Mon, 24 Jul 2017 07:38:57 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id c24so14086232wra.2 for ; Mon, 24 Jul 2017 07:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=3O6aEwVL7Ui0RFPq0i3zzjfrIA1VNLM9aK2HPTMvwPA=; b=jtMyJk+EYwhk9tWOTRL++/m0WyAwbM8IGwO8kvWvEzt47CnQ73UzGbMdDl6karSYt1 1XtxZ9Cs22OzkIDBIxwEI4iPFBFDSghHLDFewDM19fUmsYZG5LMNr2ltPYxu5rkRDXdF NhzFOo5gK2fwq3a2DXK/QBaKeAAfNo8g51ibpBe9Bi8+XKOMa16hV8THxljy9fpY50zx Ib7pCROKq6L8lAlE4LmC/sJbPd7heKhN8ExqyT2EGtLDXRIU/JK3T3Qj/sK5LH7PwyrJ r3l0rwRVxeEYzGfx4NApj6Cya/9edhF5eJzWcxGUyPBygbzh/bjXgZsMBdTzOkNfBiiq aa5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3O6aEwVL7Ui0RFPq0i3zzjfrIA1VNLM9aK2HPTMvwPA=; b=UuO4/BTRVGQitumkbvXZb7kdNPeXb78ppBtI+EJLJhQWFaSLwjgh5RQb2J+K/t32Ae u7kpkIlQlatSHt8/5nqxKJYaGDVovo7/+/kFR2viDAfbGc/Cb/m20NE/h9wmTINZCFk5 gA2BWi2vxcIHe5fNWv5zu0Wdabu1bZRUc2drC1sjPMa4rOa4TtR1SCevyKTiQAhepWxE XE9AIgWT4HPH0yUoWY1AvbKISYzG41R3zluJXYxKxoTzrw21ZonGIkUlTh2QEsdbrCr7 gkFoX9Hn65Y+znN5WpEMm17zB91kXL94WkGFOSXisiYBuBke9Q8oVf26b2n3pgYnq884 wemA== X-Gm-Message-State: AIVw112ri2yRpZlj3amUIRRB7fYXUGaDQkOwaO6wmrGjR0y5FHzsQP0a RPzTpJem4Y6eZGJU X-Received: by 10.223.139.3 with SMTP id n3mr12512480wra.249.1500907135249; Mon, 24 Jul 2017 07:38:55 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id w19sm4001874wrb.49.2017.07.24.07.38.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 07:38:54 -0700 (PDT) To: "Matthew A. Miller" , curdle@ietf.org References: From: Anders Rundgren Message-ID: <1365eab6-f45a-c5e9-99bc-194b5019814e@gmail.com> Date: Mon, 24 Jul 2017 16:38:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Curdle] Regarding X25519 in JOSE ... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:38:59 -0000 On 2017-07-24 16:26, Matthew A. Miller wrote: > Hello all, > > It was asked if any work more work is needed to add X25519 (and X448) to > JOSE. I believe [RFC8037] covers that, so I don't think any more work > is necessary right now. Would it be possible (and not too controversial) describing why RFC8037 didn't overload the JWK "EC" specification? The reason for asking is because the Java camp intends reusing the EC classes making "OKP" a JOSE-only concept. Personally, I believe OKP is just fine (=clean) and should be adopted not only by Java, but by PKCS #11 and .NET as well. Anders > > > Thanks, > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > From nobody Mon Jul 24 09:26:33 2017 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 618C6131E97 for ; Mon, 24 Jul 2017 09:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable 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 3vaym-golPn4 for ; Mon, 24 Jul 2017 09:26:24 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C380D131E9D for ; Mon, 24 Jul 2017 09:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0FBDF30056B for ; Mon, 24 Jul 2017 12:26:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id He5FMXpMvRfk for ; Mon, 24 Jul 2017 12:26:21 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2A802300288; Mon, 24 Jul 2017 12:26:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com> Date: Mon, 24 Jul 2017 12:26:20 -0400 Cc: IETF SecDir , IESG , curdle Content-Transfer-Encoding: quoted-printable Message-Id: References: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com> To: zhangdacheng X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Secdir review of draft-ietf-curdle-cms-eddsa-signatures-06 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 16:26:26 -0000 Dacheng: Thanks for taking the time to review the document. > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This document specifies the conventions for using Edwards-curve = Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the = Cryptographic Message Syntax (CMS). I think this document can be = published after some tiny updates. >=20 > The comments are listed as follows: >=20 > 1. In security considerations, the first and the second paragraphs are = about how implementations protect the private keys and how they = guarantee the quality of random numbers. Normally, this such = considerations are out of scope of protocol specifications. But I am ok = if the authors would like to keep them.=20 These are implementation considerations that impact security. I think = they should stay in the document. > 2. In the 4th paragraph of security considerations, ' the same private = key SHOULD NOT be used with more than one EdDSA set of parameters.' -> ' = the same private key MUST NOT be used with more than one EdDSA set of = parameters.' Since we already know that the same private key used for = multiple algorithms will cause potential risks, we should use a stronger = word here. I do not think that there is a problem with using the same private key = with PureEdDSA and HashEdDSA. The prudent advice is to avoid mixing the = same private key with different parameter, thus the SHOULD NOT. I point = out that RFC 8032 goes even further: ... Thus, one can use the same key pair for Ed25519, Ed25519ctx, and Ed25519ph and correspondingly with Ed448 and Ed448ph. > 3. In the 5th paragraph of security considerations, ' the same hash = function should be used for all operations.' ->' the same hash function = SHOULD be used for all operations.' Yes, I agree. > 4. In the 1st paragraph, 'When signing with Ed25519, the = digestAlgorithm SHOULD include id-sha512' ->' When signing with Ed25519, = the digestAlgorithm MUST include id-sha512'. 'When signing with Ed448, = the digestAlgorithm SHOULD include id-shake256-len' -> 'When signing = with Ed448, the digestAlgorithm MUST include id-shake256-len'. I assume you are talking about Section 3.1 here. These should not be = changed to MUST. CMS does not require these to be filled in, but = stream-oriented processing works better if they are filled in. Thus, = the SHOULD statement. Russ From nobody Mon Jul 24 10:05:03 2017 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 8A52C12EC2B for ; Mon, 24 Jul 2017 10:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 JPF_3jWnyOUs for ; Mon, 24 Jul 2017 10:05:00 -0700 (PDT) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 78A3412ECB7 for ; Mon, 24 Jul 2017 10:05:00 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id l82so1905209ywc.2 for ; Mon, 24 Jul 2017 10:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=cbYWdTHhGX/zzsRLlBWUeUA+O3mmMI6lgcblOSzckJA=; b=oEbT0YKu2VhT6XXQL5ACEA39nGW36CylGmDgV1L6h3RxtNLpjcx+TeeTB4FckPzu/D XGKb+mCVcLaFo26jNSt4NqRcqH8v/ZOaTNrFzgwW19hEMuux5xgAbaYhVeJD5KoCfeho Ab14ntX9jJFSw9JLqE1419LxHFIoo75w+9Fk6UsGiSrcsQeZ+cnCKQTzXaSlg8RtW7Vl 4rM+NMsDQ5m0vZ6UBxh6qc5H8aMeSuHq8ZA4gF9fUacRPyYXEyxjLiphJzKnIF6pYhDb svaaqJVZCN36H3RFCaKAKUHcOVGCy19X9Ee+AIu/z64JvvaCLcq4g1qzqeTGLlHXPBTy KSGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=cbYWdTHhGX/zzsRLlBWUeUA+O3mmMI6lgcblOSzckJA=; b=WTPk7Gmqdg92zZVIhPYorpOjFFA8o2MdHQVakKDEebxR4Mel/8vhydjTC2cU32cpPh DP2j1Kke/0tk0M099qq3yYMdUKuUM4gZro+Gakjq5kSAch/5+ga56n8mTo7yfDgh0n/r o8BPt+YYGOGQVImGXm1lRBkbhDtfKsJkuGajpPW5VFBdoG8gq52R+BcOrHJN18k5QVsH xKgrXRXi+U70spuvwHXMreH+KU8kvFlWIyk19GtS6tfs0ZZ1vxsEvUI88BYoxXVdSaaa r2xsjc+mt3rISo+4iy3jJeO7LJ0/cSOteHzUVgGiWqacTc9c32vg36guHrkeVl8MrlDB FscA== X-Gm-Message-State: AIVw1114CejnXdjemoP1fqdbmsfWsYQxWVr97QeGyrrI9dxvR+qQpjlR +j2gJcadtdbhybfj70fGlw== X-Received: by 10.37.204.199 with SMTP id l190mr2618950ybf.275.1500915899484; Mon, 24 Jul 2017 10:04:59 -0700 (PDT) Received: from [10.6.23.170] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id f62sm3227026ywd.51.2017.07.24.10.04.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 10:04:58 -0700 (PDT) Sender: Matthew Miller To: Anders Rundgren , curdle@ietf.org References: <1365eab6-f45a-c5e9-99bc-194b5019814e@gmail.com> From: "Matthew A. Miller" Message-ID: Date: Mon, 24 Jul 2017 11:04:57 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 In-Reply-To: <1365eab6-f45a-c5e9-99bc-194b5019814e@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FLFMPtNWFluqs3mtdWdcqQoUlNpbSdQ3A" Archived-At: Subject: Re: [Curdle] Regarding X25519 in JOSE ... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 17:05:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FLFMPtNWFluqs3mtdWdcqQoUlNpbSdQ3A Content-Type: multipart/mixed; boundary="E5a2MfO4q9PdOkbvt4AwUkgwoJX3R8GtT"; protected-headers="v1" From: "Matthew A. Miller" To: Anders Rundgren , curdle@ietf.org Message-ID: Subject: Re: [Curdle] Regarding X25519 in JOSE ... References: <1365eab6-f45a-c5e9-99bc-194b5019814e@gmail.com> In-Reply-To: <1365eab6-f45a-c5e9-99bc-194b5019814e@gmail.com> --E5a2MfO4q9PdOkbvt4AwUkgwoJX3R8GtT Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 17/07/24 16:38, Anders Rundgren wrote: > On 2017-07-24 16:26, Matthew A. Miller wrote: >> Hello all, >> >> It was asked if any work more work is needed to add X25519 (and X448) = to >> JOSE.=C2=A0 I believe [RFC8037] covers that, so I don't think any more= work >> is necessary right now. >=20 > Would it be possible (and not too controversial) describing why > RFC8037 didn't overload the JWK "EC" specification?=C2=A0 The reason > for asking is because the Java camp intends reusing the EC classes > making "OKP" a JOSE-only concept.=C2=A0 Personally, I believe OKP is ju= st > fine (=3Dclean) and should be adopted not only by Java, but by PKCS #11= > and .NET as well. >=20 [ Please let's not re-litigate this decision ... ] The JOSE WG did discuss this[1] (albeit prior to its adoption as a WG item). The rough consensus was to use a different "kty" to avoid various incompatibilities (particularly with regards to the JWK thumbprint definition, although others did come up). - m&m Matthew A. Miller [1] https://mailarchive.ietf.org/arch/msg/jose/8-Mo069HvB9_WlT9M2GrgNYHvG= 0 --E5a2MfO4q9PdOkbvt4AwUkgwoJX3R8GtT-- --FLFMPtNWFluqs3mtdWdcqQoUlNpbSdQ3A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZdii5AAoJEOz0ck4QngW7TC8IAJZhaJbCilCCaTxKJ2AIFhTa 66f0DzW993EIL2eHJzRocjMDbwvnCqbnueLWNpi74J/0SMI0y4V9gnmzSyQBt/D+ XMzcQ0GgQ9q5uVbPmH6f7StHMs7zsTOi371bgXjAqcWGg4pxeSCeWpmYocK2A4nu yRJdnZYpTwOytNrCm+Sg7CzspJUT4MLzv1Jvs/qgKRwNALvbY4EcUoYi7Hrl0c+i 4DjXJgyjTKAgsDtbXk58K0CPmnri1A2c1mECQI/tJrGKZf2czXOBFOSN+QhiNqpM 5WP7C6Mf1sPFOo+Z68e7fi51ez6AqOvDV2BMcJdgVu45pAHFEfpjq4occNVUIWE= =NRZS -----END PGP SIGNATURE----- --FLFMPtNWFluqs3mtdWdcqQoUlNpbSdQ3A-- From nobody Mon Jul 24 12:54:09 2017 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 A6FE0131EEC for ; Mon, 24 Jul 2017 12:54:02 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 H_0JmafCnWvX for ; Mon, 24 Jul 2017 12:54:00 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 624041317C1 for ; Mon, 24 Jul 2017 12:54:00 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id v105so80164720wrb.0 for ; Mon, 24 Jul 2017 12:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XlUwrUeKafbMMEKwzkXZyQbkjFUDd4KL0/+dUY2l1Ro=; b=muXQTqVgmqew9VMKnm/sFrythGRcuOSS8F0zpIinpf6ZWwcENdpbSDhwAE9peymmW1 D49A0sVvQfyI8vMTEC545qbJ/4kYOaY5lFmrIACsSiD6hzfifNknU+ArcBZuS++GXWwM W2pk9hqJZoL1HkTT3q0h2yoTRUo7Itk95Knk684H2gQ1J7Rsz4lv6gc+Ce/K80hlgH0I wEro6jG7nhr8V/fmR9qH7XSSlLtBnzQLWQKT1CfQcHQrDSGHJMB1qjwpKeVkEjU310Pq 7+vbu9//zn1SK06pc9oENI9zBD7Zn+NLNRcmFDxScPzdllwJ/9ZqHZ4mcWL0R5Wv782F otmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XlUwrUeKafbMMEKwzkXZyQbkjFUDd4KL0/+dUY2l1Ro=; b=G+WBzvu0nbKUhwUTrRkniKdIERzen4g04pyMy3oZibdSiC/Tc/V9JD2AMM453NoFzh 6be/OgzvDwghVKjq/6jYec1pse8dnAAkDIYVI5pZefM1YlvxgXjIgfPEyExzo0hDJJpi Rp0wMRhhQbzd7RqZ0XcmY7GqDBq4mdniHxpY/zrtESy6LkKSWiyj1KQlRepSrid6JHOR 79hEjJwQaMJ91Eifl7ePziEU5lR0ZOohZft42haPEWBDfIy+0FZXNROtJaQ+OLw2WmEB CsSVeW7zcSNj47/HXV5qtdoSfl5ElWoZ8aulU8MNbB40zoxSv4zI2ktDXO2zZjEylQpD xoYg== X-Gm-Message-State: AIVw111hNr0sU9qPetg/0tV8gQRZd1KXiGgnFi88Y85Z6ItIo/KGZd7I RjxNu1cXwfOSi5tr X-Received: by 10.223.131.135 with SMTP id 7mr11283227wre.161.1500926038464; Mon, 24 Jul 2017 12:53:58 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id g66sm8010755wmc.6.2017.07.24.12.53.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 12:53:57 -0700 (PDT) To: "Matthew A. Miller" , curdle@ietf.org References: <1365eab6-f45a-c5e9-99bc-194b5019814e@gmail.com> From: Anders Rundgren Message-ID: <608db31f-b7c0-e383-9a9c-b8d97ea30301@gmail.com> Date: Mon, 24 Jul 2017 21:53:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Curdle] Regarding X25519 in JOSE ... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 19:54:03 -0000 On 2017-07-24 19:04, Matthew A. Miller wrote: > > On 17/07/24 16:38, Anders Rundgren wrote: >> On 2017-07-24 16:26, Matthew A. Miller wrote: >>> Hello all, >>> >>> It was asked if any work more work is needed to add X25519 (and X448) to >>> JOSE. I believe [RFC8037] covers that, so I don't think any more work >>> is necessary right now. >> >> Would it be possible (and not too controversial) describing why >> RFC8037 didn't overload the JWK "EC" specification? The reason >> for asking is because the Java camp intends reusing the EC classes >> making "OKP" a JOSE-only concept. Personally, I believe OKP is just >> fine (=clean) and should be adopted not only by Java, but by PKCS #11 >> and .NET as well. >> > > [ Please let's not re-litigate this decision ... ] > > The JOSE WG did discuss this[1] (albeit prior to its adoption as a WG > item). The rough consensus was to use a different "kty" to avoid > various incompatibilities (particularly with regards to the JWK > thumbprint definition, although others did come up). I see. For me this extract from RFC 8037 Do not assume that there is an underlying elliptic curve, despite the existence of the "crv" and "x" parameters. (For instance, this key type could be extended to represent Diffie-Hellman (DH) algorithms based on hyperelliptic surfaces.) was the primary reason why creating a new key type seemed natural, although I (not being a cryptographer) do not actually know what a hyperelliptic surface is :-) https://github.com/cyberphone/java-cfrg-spec Anders > > > - m&m > > Matthew A. Miller > > [1] https://mailarchive.ietf.org/arch/msg/jose/8-Mo069HvB9_WlT9M2GrgNYHvG0 > > From nobody Mon Jul 24 13:58:04 2017 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 05FFD131F20 for ; Mon, 24 Jul 2017 13:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EP3vmf-eZSv7 for ; Mon, 24 Jul 2017 13:58:01 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2747A129AF9 for ; Mon, 24 Jul 2017 13:58:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7725030056B for ; Mon, 24 Jul 2017 16:58:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YqYCNdfELxDn for ; Mon, 24 Jul 2017 16:57:58 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A719F300288; Mon, 24 Jul 2017 16:57:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <150084248880.31306.450946335865671294@ietfa.amsl.com> Date: Mon, 24 Jul 2017 16:57:58 -0400 Cc: IETF Gen-ART , curdle , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <88C7C6F9-FBD3-402A-B174-02C44D9D0092@vigilsec.com> References: <150084248880.31306.450946335865671294@ietfa.amsl.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-cms-eddsa-signatures-06 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 20:58:03 -0000 Jouni: Thanks for the review. > Reviewer: Jouni Korhonen > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-curdle-cms-eddsa-signatures-?? > Reviewer: Jouni Korhonen > Review Date: 2017-07-23 > IETF LC End Date: 2017-07-25 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready to ship. Good that Proto Write-up took care of = explaining > downrefs. >=20 > Major issues: None. >=20 > Minor issues: None. >=20 > Nits/editorial comments: I just have one question whether the use of = RFC2119 > language in Section 5 Security Considerations is intentional? I mean = here that > sometimes e.g. "must" is in lower case and sometimes other keywords = are in > upper case e.g. "SHOULD NOT". Looking through the paragraphs in Section 5... Paragraph 1: The use of "must" and "may" are intentional. These are = needed for security, but they do not impact interoperability. Paragraph 2: The use of "may" is intentional. It is a statement about = what an attacker may do; it has no impact on interoperability. Paragraph 4: It uses "SHOULD NOT" Paragraph 5: In my edit buffer, I have changed "should" to "SHOULD". Russ From nobody Mon Jul 24 14:02:47 2017 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 61F18131F20; Mon, 24 Jul 2017 14:02:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: curdle@ietf.org, ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150093015937.32021.12465797358778837950@ietfa.amsl.com> Date: Mon, 24 Jul 2017 14:02:39 -0700 Archived-At: Subject: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 21:02:39 -0000 Reviewer: Matthew Miller Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-curdle-ssh-ext-info-10 Reviewer: Matthew Miller Review Date: 2017-07-24 IETF LC End Date: 2017-07-30 IESG Telechat date: N/A Summary: This document is ready with an issue. I found this document very coherent and easy to follow. Major issues: Minor issues: My only issue borders on nit, but sided with nit as I can see it potentially causing confusion for an implementer in the future. Section 2.5. "Interpretation of Extension Names and Values" explicitly states in the second paragraph a condition where the relative order of extension-names in an EXT_INFO message is irrelevant. However, the rest of the section seems to imply to me that relative order is not important; so to explicitly call out a scenario seems to imply that relative order *is* relevant/important, sometimes. If relative order is expected to be important most of the time, I think it helpful to explicitly state that and give a rationale for it. Nits/editorial comments: * RFC 5226 is referenced by this document, but is obsoleted by RFC 8126. From nobody Mon Jul 24 17:31:03 2017 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 B73AC1270AC for ; Mon, 24 Jul 2017 17:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vXwH2ZpiIwTq for ; Mon, 24 Jul 2017 17:30:59 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 5AA0912706D for ; Mon, 24 Jul 2017 17:30:59 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id p2so34685265lfg.0 for ; Mon, 24 Jul 2017 17:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EZZJFsFV4jHqHBQ6GKcPUapC42EjnzewqVvJkaVNzBg=; b=H0ET4FulMMg3VS8ZAbw6s1s8Y27iUuo8K2vg7yXa/KsUY1C/FLNN1u7TIx/hd6Uv+W qs3mCvUOXo8vNbO6fyxGeTWztfYAI3QoEqw3+SxzOgLA8gKter0O7qD5w65p2ETP/06p S5GShCQzWrPnE+gXa7092Krs/yZZkGSfyB2ktRMv2J4Tk4ebnDeFC3rTIEpS81IMjTy4 lIGjqpABSHwWjv+Amu5siM+HMkBJBR2QvJuN4jT79BKi6LfYGiWRHmwfpgNjebdln7LA 9AbPnuFTht0XICIA9cWzPkJhrzmJttvIGzps8cqOoxvD73lp9dOgK7T2z0tOUa32BzPP zunA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EZZJFsFV4jHqHBQ6GKcPUapC42EjnzewqVvJkaVNzBg=; b=cp2FR0s5g5+zN01AieIOpHz7TOyN0jQxzRyr3pr7ux88/YPP4nGFwe/2Orb/BlH17x KHL0CFUX05gFO5yF5wzn2ORP/hMuuog27L5UGFu8lD0bKG9OMY9qpiTmJZ71wwTMfzhe cg4rPWS8V5gpu3KH352ZC+mNpEbPEPfmPOqa+SwSmw2J4fTRw3GhUVBDUVK3lh8PE97o UqsWJd9AhLtS4fkRBnSs5Uv7LpOcInq/c69FZdZPFjSgoooebsuAs19JNBt01NRZxB5H +e4j/6C9Mqa4QUlPKuDe1J3cxkTFLqPnjHsMNEf/FiN0+TbGbpqXvbb34m1STz8n5JBq UHSw== X-Gm-Message-State: AIVw1100kyARVYCBfash6YQDGsoo9K/6+wGXDNRVwsY3YCrUkQT93oL2 43CIlqU0xeePNofUyoFw9L3eJtp9TQ== X-Received: by 10.25.206.16 with SMTP id e16mr2839980lfg.30.1500942657498; Mon, 24 Jul 2017 17:30:57 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.142.199 with HTTP; Mon, 24 Jul 2017 17:30:56 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 24 Jul 2017 20:30:56 -0400 X-Google-Sender-Auth: Vq-8-ropyvMBHOLP5yaHppl5BmI Message-ID: To: "Matthew A. Miller" Cc: Curdle Content-Type: multipart/alternative; boundary="001a11412b52edb61c05551971ec" Archived-At: Subject: Re: [Curdle] Regarding X25519 in JOSE ... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 00:31:02 -0000 --001a11412b52edb61c05551971ec Content-Type: text/plain; charset="UTF-8" How about Ed25519 and Ed448? Did those get done as well? On Mon, Jul 24, 2017 at 10:26 AM, Matthew A. Miller < linuxwolf+ietf@outer-planes.net> wrote: > Hello all, > > It was asked if any work more work is needed to add X25519 (and X448) to > JOSE. I believe [RFC8037] covers that, so I don't think any more work > is necessary right now. > > > Thanks, > > -- > - m&m > > Matthew A. Miller > > [RFC8037] CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in > JSON Object Signing and Encryption (JOSE) < > https://tools.ietf.org/html/rfc8037 > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a11412b52edb61c05551971ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How= about Ed25519 and Ed448? Did those get done as well?

On Mon, Jul 24, 2017 at 10:26 AM,= Matthew A. Miller <linuxwolf+ietf@outer-planes.net><= /span> wrote:
Hello all,

It was asked if any work more work is needed to add X25519 (and X448) to JOSE.=C2=A0 I believe [RFC8037] covers that, so I don't think any more = work
is necessary right now.


Thanks,

--
- m&m

Matthew A. Miller

[RFC8037] CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in
JSON Object Signing and Encryption (JOSE) <
https://tools.ietf.org/html/rfc8037 >


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a11412b52edb61c05551971ec-- From nobody Mon Jul 24 20:59:35 2017 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 1FEE6126E3A for ; Mon, 24 Jul 2017 20:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 6Q4HVT0kEQpT for ; Mon, 24 Jul 2017 20:59:31 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20508126B7F for ; Mon, 24 Jul 2017 20:59:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1500955149; h=from:subject:to:date:message-id; bh=MThXoc9RDMXpaHHeFlP8z7b39u7Ijs5RJxZiUOt3S6E=; b=CqlG+BSCQmuJvN1gG7bYJwbOlOHFP4Lc3B/EBDuo0ve7mUAA06oCOjlI3PyNN3M8WFO1vgYKUoy aEei0KG3/WrPaeqmf/Ne9ZYzY7ZzSeNbGojYb0XPNZckaiYpXC+IPYFH+m5+1Dvc/IYj1Z+6aQrgb 5AOy44BVnBG/0Bi0G4FvheQv7u3kX9dJWs1EJsX5VvHN1Do+RpoMfwXo2xw4IpBUnYryFrwlwGIJi LYqs7pUcQl/N6zaJ5lul6MvStixigWfuRGFhkEQvR3yTl+uxhbAxGgQOwWYKUroNBbo1bqscuKwd2 iDVC4Gjpi5vxYwS0c/onuYQG14h5wrqaUvAA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 20:59:08 -0700 Received: from Hebrews (104.129.192.109) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 20:59:06 -0700 From: Jim Schaad To: 'Anders Rundgren' , "'Matthew A. Miller'" , References: <1365eab6-f45a-c5e9-99bc-194b5019814e@gmail.com> In-Reply-To: <1365eab6-f45a-c5e9-99bc-194b5019814e@gmail.com> Date: Tue, 25 Jul 2017 05:59:27 +0200 Message-ID: <008601d304fa$6b3e5aa0$41bb0fe0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFXtNyfHgq3or7cQqEwjQLL8dgFLAHIMF3Bo0xJJxA= X-Originating-IP: [104.129.192.109] Archived-At: Subject: Re: [Curdle] Regarding X25519 in JOSE ... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 03:59:33 -0000 I hope they do not do this. The encoding format for the Edwards curves and for the other EC curves is not the same in any way shape or form. They are different not only for JOSE but also for ASN.1. Reusing the same classes would be a mistake. -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Anders Rundgren Sent: Monday, July 24, 2017 4:39 PM To: Matthew A. Miller ; curdle@ietf.org Subject: Re: [Curdle] Regarding X25519 in JOSE ... On 2017-07-24 16:26, Matthew A. Miller wrote: > Hello all, > > It was asked if any work more work is needed to add X25519 (and X448) > to JOSE. I believe [RFC8037] covers that, so I don't think any more > work is necessary right now. Would it be possible (and not too controversial) describing why RFC8037 didn't overload the JWK "EC" specification? The reason for asking is because the Java camp intends reusing the EC classes making "OKP" a JOSE-only concept. Personally, I believe OKP is just fine (=clean) and should be adopted not only by Java, but by PKCS #11 and .NET as well. Anders > > > Thanks, > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jul 24 21:02:09 2017 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 CDEBA129432 for ; Mon, 24 Jul 2017 21:02:07 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 8bW7MQ7_rm6I for ; Mon, 24 Jul 2017 21:02:05 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8ADA126B7F for ; Mon, 24 Jul 2017 21:02:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01D3050B.897C4C00" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1500955302; h=from:subject:to:date:message-id; bh=2+wbf9iTXhWVhy6ypDVsZPVZlfwETDks5ccRTwbsA84=; b=KV+IGb3nTAZ5/PlM3HD+zOZbQCNLMSc97W/ML4k27C9HFU1pgUWaMbI8+A4yCXyQ7Rt2+af5SOk Ku89IfwnZWWFN15GeYPbJt4JPPn/bC++zE6s5hsT++JJlTrAFejO1BMmlBlALoIMfRmGrGYDrP8K6 C/s/p3XSBDJXms8J469TsCkTQ//oJMKS50m6o6QZjDsFFEBqa5QbVFDQkQ1pkECQnX0dD0NHxpkoa gZwHMZgdhb2aw33yKwBYR8nKM0GBEd+AwR1nCqCX/+pPU5K3x4UY64wbg5BUpHGx4SKkEI+obMmxX cFMkgXkK9FFy0IeOsfGD0bUjQu8X5/jeionw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 21:01:41 -0700 Received: from Hebrews (104.129.192.109) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 21:01:39 -0700 From: Jim Schaad To: 'Phillip Hallam-Baker' , "'Matthew A. Miller'" CC: 'Curdle' References: In-Reply-To: Date: Tue, 25 Jul 2017 06:02:00 +0200 Message-ID: <008701d304fa$c5f306d0$51d91470$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFXtNyfHgq3or7cQqEwjQLL8dgFLAGHiom2o05O4GA= X-Originating-IP: [104.129.192.109] Archived-At: Subject: Re: [Curdle] Regarding X25519 in JOSE ... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 04:02:08 -0000 ------=_NextPart_000_0088_01D3050B.897C4C00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, the document covers all four algorithms, although it only does pure = signatures not hash signatures =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker Sent: Tuesday, July 25, 2017 2:31 AM To: Matthew A. Miller Cc: Curdle Subject: Re: [Curdle] Regarding X25519 in JOSE ... =20 How about Ed25519 and Ed448? Did those get done as well? =20 On Mon, Jul 24, 2017 at 10:26 AM, Matthew A. Miller = > wrote: Hello all, It was asked if any work more work is needed to add X25519 (and X448) to JOSE. I believe [RFC8037] covers that, so I don't think any more work is necessary right now. Thanks, -- - m&m Matthew A. Miller [RFC8037] CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) < https://tools.ietf.org/html/rfc8037 > _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 ------=_NextPart_000_0088_01D3050B.897C4C00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Yes, the = document covers all four algorithms, although it only does pure = signatures not hash signatures

 

Jim

 

 

From: = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker
Sent: Tuesday, July 25, 2017 2:31 = AM
To: Matthew A. Miller = <linuxwolf+ietf@outer-planes.net>
Cc: Curdle = <curdle@ietf.org>
Subject: Re: [Curdle] Regarding X25519 = in JOSE ...

 

How about Ed25519 and = Ed448? Did those get done as well?

 

On Mon, = Jul 24, 2017 at 10:26 AM, Matthew A. Miller <linuxwolf+ietf@outer-planes.net> = wrote:

Hello all,

It was asked if any = work more work is needed to add X25519 (and X448) to
JOSE.  I = believe [RFC8037] covers that, so I don't think any more work
is = necessary right now.


Thanks,

--
- m&m

Matthew A. = Miller

[RFC8037] CFRG Elliptic Curve = Diffie-Hellman (ECDH) and Signatures in
JSON Object Signing and Encryption (JOSE) = <
https://tools.ietf.org/html/rfc8037 = >


___________________________________________= ____
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

 

------=_NextPart_000_0088_01D3050B.897C4C00-- From nobody Tue Jul 25 10:59:19 2017 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 E00DF131E90; Tue, 25 Jul 2017 10:59:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick To: Cc: curdle@ietf.org, ietf@ietf.org, draft-ietf-curdle-ssh-dh-group-exchange.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150100555089.26234.7716617823296361972@ietfa.amsl.com> Date: Tue, 25 Jul 2017 10:59:10 -0700 Archived-At: Subject: [Curdle] Genart last call review of draft-ietf-curdle-ssh-dh-group-exchange-05 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 17:59:11 -0000 Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-curdle-ssh-dh-group-exchange-05 Reviewer: Pete Resnick Review Date: 2017-07-25 IETF LC End Date: 2017-07-30 IESG Telechat date: Not scheduled for a telechat Summary: Ready. No concerns. Major issues: None. Minor issues: None. Nits/editorial comments: I am not convinced the pre-5378 boilerplate is necessary. You refer to, but have not incorporated, material from 4419. From nobody Tue Jul 25 15:24:50 2017 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 CF28F131F8A; Tue, 25 Jul 2017 15:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 z6m7J84vvHSM; Tue, 25 Jul 2017 15:24:29 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 F28FD131F90; Tue, 25 Jul 2017 15:24:25 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id i6so43306459ywb.1; Tue, 25 Jul 2017 15:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w+g6RDD4CGjnId1yU8EOpEQzAP+YoQg0nJSXL562mb4=; b=kquKt1vZHK4F2C7I8zEzEy9RZ1PtBpzHZv3mF0G72/K4mF4+IxIfsr1QQgRq8Ovo1z TCycigms3ED8InQQYMEQigxAOpaU8mBbomCixfzl3msECnpVFG04jbbOwKMF+mSFMsYg 0WQ0rvJKHiD2FpLL4O8DRZ/uAjsS0DCjPAjcX/Fpfks5iEoCedRQ/x3IP2H3GHpddYcI DCMwudlTxa7mG9ydYxvsYVidrFhkwZsR6M8x1bWin5Uo+caJNCM+kXoRJ4qPJ0sXdAEc eTKlo0tWWS2ctRmx5RIKv3llH6gdErLDw6bn9URDVhKDHsNeFwlEhTYCG713U0a4zM42 6rZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w+g6RDD4CGjnId1yU8EOpEQzAP+YoQg0nJSXL562mb4=; b=uA1GZ+ZnuvD8sHvl3yoInq5cYVEK9sF96s2lRHeu0fS83Ki9MTp4UANZ5fUoEbIeFF grogtlTuyEDghjSz+MRRmqxVrfZJ2WJozrj32Ws0lgAF4aIY7L7EbpsUnHTRiCBeXrJx 63Zo9MnWauuh2Z4k4pGZYmuid+Fl0tvazeANUrUsHpHz299EJndhHWIh8s7sDT5gqfuq QS4xxZ43J4xZwBngrrCHeRb+DaH7W6eFW3rW8Hlfxiz6QkvtRBwzz7itRB/3zmf/Mp95 StoUYivieHPoKcgiWE9aQAKa78YsG/vXgnnrA+8PVibp6FBKSj4O994YVcgKIir1jAVn aPFA== X-Gm-Message-State: AIVw111qr865dLvgZuDYQcd8+Q2AGRIB6WzlCmCMSQWhyAURneIRlnGQ fWyAoWf3rlgCX29ItUfAiT8mybuOmQ== X-Received: by 10.37.126.193 with SMTP id z184mr14746551ybc.20.1501021465200; Tue, 25 Jul 2017 15:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.42.200 with HTTP; Tue, 25 Jul 2017 15:24:24 -0700 (PDT) In-Reply-To: <150093015937.32021.12465797358778837950@ietfa.amsl.com> References: <150093015937.32021.12465797358778837950@ietfa.amsl.com> From: denis bider Date: Tue, 25 Jul 2017 16:24:24 -0600 Message-ID: To: Matthew Miller Cc: gen-art@ietf.org, curdle , ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org Content-Type: multipart/alternative; boundary="001a114bb09a3bd60d05552bcbd9" Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:24:32 -0000 --001a114bb09a3bd60d05552bcbd9 Content-Type: text/plain; charset="UTF-8" Good catch. I believe this refers to the following paragraph: "If an extension requires both the client and the server to include it in order for the extension to take effect, the relative position of the extension-name in each EXT_INFO message is irrelevant." I have drafted the following new wording: "Unless a particular extension's specification indicates differently; then, if an extension requires both the client and the server to include it in order for the extension to take effect; implementers MUST use a default assumption that the relative position of the extension-name in each EXT_INFO message is irrelevant with respect to whether the extension takes effect." The purpose of this wording is to: - Provide a sensible default, which is that in the absence of specific knowledge, order of extension names does not matter. - Allow for deviations in special cases where there is specific knowledge. For example, extension "foo-linux" could be specified, but after some years of use, it's observed that it works well for its main purpose, but is not ideal for a server on Windows. Therefore, extension "foo-windows" is specified, which works well when the server is Windows, but not as well when it's Linux. In this case, an implementation that supports "foo-linux" only would be ignorant of anything else, and would use the default rule (order of extension names does not matter). However, an implementation that supports "foo-windows" could implement only that, or both "foo-linux" and "foo-windows". The specification for "foo-windows" could indicate that when both are supported, the first one listed by the server (or in other cases, by the client) is used. Allowing for such an extension-defined special case would allow a Linux server to advertise extensions [... "foo-linux", ..., "foo-windows", ...], preferring "foo-linux", but supporting the less appropriate "foo-windows" mechanism as well. Whereas, a Windows server could advertise [... "foo-windows", ..., "foo-linux", ...], preferring "foo-windows", but supporting the less appropriate "foo-linux" mechanism as well. Does this work? If there are no objections, I'll upload a -11 draft version with this new wording. On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller < linuxwolf+ietf@outer-planes.net> wrote: > Reviewer: Matthew Miller > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-curdle-ssh-ext-info-10 > Reviewer: Matthew Miller > Review Date: 2017-07-24 > IETF LC End Date: 2017-07-30 > IESG Telechat date: N/A > > Summary: > > This document is ready with an issue. > > I found this document very coherent and easy to follow. > > Major issues: > > Minor issues: > > My only issue borders on nit, but sided with nit as I can see it > potentially causing confusion for an implementer in the future. > > Section 2.5. "Interpretation of Extension Names and Values" explicitly > states in the second paragraph a condition where the relative order of > extension-names in an EXT_INFO message is irrelevant. However, the rest > of the section seems to imply to me that relative order is not important; > so to explicitly call out a scenario seems to imply that relative order > *is* relevant/important, sometimes. If relative order is expected to be > important most of the time, I think it helpful to explicitly state that > and give a rationale for it. > > Nits/editorial comments: > > * RFC 5226 is referenced by this document, but is obsoleted by RFC 8126. > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a114bb09a3bd60d05552bcbd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good catch. I believe this refers to the following paragra= ph:

"If an extension requires both the client = and the server to include it in order for the extension to take effect, the= relative position of the extension-name in each EXT_INFO message is irrele= vant."

I have drafted the following new= wording:

"Unless a particular extension'= s specification indicates differently; then, if an extension requires both = the client and the server to include it in order for the extension to take = effect; implementers MUST use a default assumption that the relative positi= on of the extension-name in each EXT_INFO message is irrelevant with respec= t to whether the extension takes effect."

The= purpose of this wording is to:

- Provide a sensib= le default, which is that in the absence of specific knowledge, order of ex= tension names does not matter.

- Allow for deviati= ons in special cases where there is specific knowledge.

For example, extension "foo-linux" could be specified, but = after some years of use, it's observed that it works well for its main = purpose, but is not ideal for a server on Windows. Therefore, extension &qu= ot;foo-windows" is specified, which works well when the server is Wind= ows, but not as well when it's Linux.

In this = case, an implementation that supports "foo-linux" only would be i= gnorant of anything else, and would use the default rule (order of extensio= n names does not matter). However, an implementation that supports "fo= o-windows" could implement only that, or both "foo-linux" an= d "foo-windows". The specification for "foo-windows" co= uld indicate that when both are supported, the first one listed by the serv= er (or in other cases, by the client) is used.

All= owing for such an extension-defined special case would allow a Linux server= to advertise extensions [... "foo-linux", ..., "foo-windows= ", ...], preferring "foo-linux", but supporting the less app= ropriate "foo-windows" mechanism as well. Whereas, a Windows serv= er could advertise [... "foo-windows", ..., "foo-linux"= , ...], preferring "foo-windows", but supporting the less appropr= iate "foo-linux" mechanism as well.

Does= this work?

If there are no objections, I'll u= pload a -11 draft version with this new wording.

<= br>

On= Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller <linuxwolf+iet= f@outer-planes.net> wrote:
= Reviewer: Matthew Miller
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.

Document: draft-ietf-curdle-ssh-ext-info-10
Reviewer: Matthew Miller
Review Date: 2017-07-24
IETF LC End Date: 2017-07-30
IESG Telechat date: N/A

Summary:

This document is ready with an issue.

I found this document very coherent and easy to follow.

Major issues:

Minor issues:

My only issue borders on nit, but sided with nit as I can see it
potentially causing confusion for an implementer in the future.

Section 2.5. "Interpretation of Extension Names and Values" expli= citly
states in the second paragraph a condition where the relative order of
extension-names in an EXT_INFO message is irrelevant.=C2=A0 However, the re= st
of the section seems to imply to me that relative order is not important; so to explicitly call out a scenario seems to imply that relative order
*is* relevant/important, sometimes.=C2=A0 If relative order is expected to = be
important most of the time, I think it helpful to explicitly state that
and give a rationale for it.

Nits/editorial comments:

* RFC 5226 is referenced by this document, but is obsoleted by RFC 8126.

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a114bb09a3bd60d05552bcbd9-- From nobody Wed Jul 26 12:28:27 2017 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 367EB12EC13 for ; Wed, 26 Jul 2017 12:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 6gb7Vd7FkBwi for ; Wed, 26 Jul 2017 12:28:16 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 9604513167B for ; Wed, 26 Jul 2017 12:28:15 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h199so72288907ith.1 for ; Wed, 26 Jul 2017 12:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Y67tEcVfovZOllt8gfOO4/0HMNygfcK22XRnyViv8js=; b=sl66Uk9k1vcPN8ih5xP+TdKHHYJQsu29nxRrvBUQb3JUMUCYvW6Vmsc2GL+Y9rh4KL xb+nYNZPqr87zXKUhWT6V0HMmOhjREF1R4gkR8yJqSVxWdwZwCtDfSeyXk3uX5JTm/ui 7WJCcHIPWmufkNP7sgaK4X6BJKHeovebfEk4R42exK8PajfWahd/oCFBo5+a1rgxiy89 zQZVlkpij+59nDoYmg+Z5LQtLjfrX3d4XMnhk+K9g3utyQo7En++o0ubfE1D4o6/Nwv1 P+m2D12Aw0h8svQodlAhpYsjH0SoIYxhrCS19KhWzDT27ynas1VlO+nUvu71FRoAt0Bt /DDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=Y67tEcVfovZOllt8gfOO4/0HMNygfcK22XRnyViv8js=; b=mMuhUVP6SbdnmmUfNq4uZdYoZYrmsM6rYj4qnoRUQM8QFBPmf1SHxPLPYVWg9lKFpo RTOg/PZLelROmJnHfREonipSPNaZSqY2D/hUaBjsUzQd2oJa9OcKtt6VWSZoBGgNfjcp ydleYGnVbNzOAGrBoycqEEQnl0OLTV+VVMKkE0DNsQ6ykUcD24k0Ir2D/gRPrf4dN37n amKfs0SKsHWS/ZxLXeaQNjackf3341yGASbN+AFnOdO8VDDA9MRXDFqfNn9i6QF5770Y QY/IElKy2P2U8J2FtegvFYWz3iAPnc7HePR7W+5zkWtSOd88BTGxlqDh9iiUOH3G6Le+ ftFw== X-Gm-Message-State: AIVw112cWQK2xPQ2frK6Ys2c1HPz9xPCercB0sw2uSXQuIUWDG7YqKMP FCpblNmqlyHjMnWp X-Received: by 10.36.196.67 with SMTP id v64mr2232518itf.89.1501097294870; Wed, 26 Jul 2017 12:28:14 -0700 (PDT) Received: from [192.168.29.239] (c-73-217-32-196.hsd1.co.comcast.net. [73.217.32.196]) by smtp.gmail.com with ESMTPSA id 202sm327960itx.24.2017.07.26.12.28.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 12:28:14 -0700 (PDT) Sender: Matthew Miller To: denis bider Cc: gen-art@ietf.org, curdle , ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org References: <150093015937.32021.12465797358778837950@ietfa.amsl.com> From: "Matthew A. Miller" Message-ID: <1eef6165-9b5b-c354-dffe-5df1e98098fa@outer-planes.net> Date: Wed, 26 Jul 2017 13:28:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8Gn9vxRJp6ejRsiLo3n6QEq1slDGSLWpi" Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 19:28:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8Gn9vxRJp6ejRsiLo3n6QEq1slDGSLWpi Content-Type: multipart/mixed; boundary="T8urOObO966rGt9CNOsknGPRejclqAA4F"; protected-headers="v1" From: "Matthew A. Miller" To: denis bider Cc: gen-art@ietf.org, curdle , ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org Message-ID: <1eef6165-9b5b-c354-dffe-5df1e98098fa@outer-planes.net> Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10 References: <150093015937.32021.12465797358778837950@ietfa.amsl.com> In-Reply-To: --T8urOObO966rGt9CNOsknGPRejclqAA4F Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thanks very much for the response, Denis. I think I understand the intent here, but I'm not sure this new text is enough to mitigate some future conflict. I'm also concerned that it completely ignores the one-party extensions (e.g., an extension included in the EXT_INFO by only the client or the server, but not both), and what the impact is holistically. Looking at the one-party extensions defined herein, I can't see how their order matters; but does that mean the order will never matter? In writing this reply, I wondered if it's better for the order to always be irrelevant; an implementation might be allowed to hint its preferred order in the EXT_INFO, but implementations are still free to do whatever makes sense to them within the bounds of the relevant extension definitions. If an extension ought to take precedence over another, make it clear in its specification that it SHOULD (or MUST) be dealt with before (or after) others. Does that make sense? - m&m Matthew A. Miller On 17/07/25 16:24, denis bider wrote: > Good catch. I believe this refers to the following paragraph: >=20 > "If an extension requires both the client and the server to include it > in order for the extension to take effect, the relative position of the= > extension-name in each EXT_INFO message is irrelevant." >=20 > I have drafted the following new wording: >=20 > "Unless a particular extension's specification indicates differently; > then, if an extension requires both the client and the server to includ= e > it in order for the extension to take effect; implementers MUST use a > default assumption that the relative position of the extension-name in > each EXT_INFO message is irrelevant with respect to whether the > extension takes effect." >=20 > The purpose of this wording is to: >=20 > - Provide a sensible default, which is that in the absence of specific > knowledge, order of extension names does not matter. >=20 > - Allow for deviations in special cases where there is specific knowled= ge. >=20 > For example, extension "foo-linux" could be specified, but after some > years of use, it's observed that it works well for its main purpose, bu= t > is not ideal for a server on Windows. Therefore, extension "foo-windows= " > is specified, which works well when the server is Windows, but not as > well when it's Linux. >=20 > In this case, an implementation that supports "foo-linux" only would be= > ignorant of anything else, and would use the default rule (order of > extension names does not matter). However, an implementation that > supports "foo-windows" could implement only that, or both "foo-linux" > and "foo-windows". The specification for "foo-windows" could indicate > that when both are supported, the first one listed by the server (or in= > other cases, by the client) is used. >=20 > Allowing for such an extension-defined special case would allow a Linux= > server to advertise extensions [... "foo-linux", ..., "foo-windows", > ...], preferring "foo-linux", but supporting the less appropriate > "foo-windows" mechanism as well. Whereas, a Windows server could > advertise [... "foo-windows", ..., "foo-linux", ...], preferring > "foo-windows", but supporting the less appropriate "foo-linux" mechanis= m > as well. >=20 > Does this work? >=20 > If there are no objections, I'll upload a -11 draft version with this > new wording. >=20 >=20 >=20 > On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller > > wrote: >=20 > Reviewer: Matthew Miller > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area= > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair.=C2=A0 Please treat these comments j= ust > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > >. >=20 > Document: draft-ietf-curdle-ssh-ext-info-10 > Reviewer: Matthew Miller > Review Date: 2017-07-24 > IETF LC End Date: 2017-07-30 > IESG Telechat date: N/A >=20 > Summary: >=20 > This document is ready with an issue. >=20 > I found this document very coherent and easy to follow. >=20 > Major issues: >=20 > Minor issues: >=20 > My only issue borders on nit, but sided with nit as I can see it > potentially causing confusion for an implementer in the future. >=20 > Section 2.5. "Interpretation of Extension Names and Values" explici= tly > states in the second paragraph a condition where the relative order= of > extension-names in an EXT_INFO message is irrelevant.=C2=A0 However= , the rest > of the section seems to imply to me that relative order is not > important; > so to explicitly call out a scenario seems to imply that relative o= rder > *is* relevant/important, sometimes.=C2=A0 If relative order is expe= cted to be > important most of the time, I think it helpful to explicitly state = that > and give a rationale for it. >=20 > Nits/editorial comments: >=20 > * RFC 5226 is referenced by this document, but is obsoleted by RFC = 8126. >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > >=20 >=20 --T8urOObO966rGt9CNOsknGPRejclqAA4F-- --8Gn9vxRJp6ejRsiLo3n6QEq1slDGSLWpi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZeO1NAAoJEOz0ck4QngW7+XwH/RQTYuE2WjpH9eALQH3ZTa4s qJpjNYwl+HaNyd1MWySuYDGOLQzWModVTAsOKhSC1uCMhhyIz508XzdwaoVaEOg/ 67dMv1NwzPeU6ggvuww4iyFSl7PKu9jhkBzD5Xd3LMWNtKQvL36HAyDVOC3omu55 6xBt/B30OCXdmIDQG8N/orcexlhDk8In60C07HD9psNY81IFIDrZPLYx5+grZSbX rWRXc38CVFQz42rOjWccFUeMq7tbEmQkfbrnkq02cc0JUWhRDXzXNhJu0L+aF4ll 8c1kiG641VyCFNmFgac4ZOV4iG9YMNuttQxkzQ7kjp2YTEY2Q7QF4hvZu7TkI2g= =7D6i -----END PGP SIGNATURE----- --8Gn9vxRJp6ejRsiLo3n6QEq1slDGSLWpi-- From nobody Wed Jul 26 20:09:24 2017 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 286F3124BE8; Wed, 26 Jul 2017 20:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LHPVzlwvB3KU; Wed, 26 Jul 2017 20:09:21 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 D88B112711E; Wed, 26 Jul 2017 20:09:20 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l82so40769043ywc.2; Wed, 26 Jul 2017 20:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i4nqD/Hf0VXTis24YtlGqh9ZwQrKatGgfP76M7+ubo8=; b=OFc8Gr3QMEh1O7S1U9YvTFLrGNmDS7Cn1npOEEd+cULR+oljssLULCsrHibb7+G4Bv YxSyTlf1PICfwDdGvQwOJ9SlYCaq6/caVbnCPVsstVEq0q+Ks923D/a9UO89hDl1vHp8 7CN0F/bGfJvYZPBSoF3LkEZTklotGbkiqxOK90u2XFoZegIWWJi2BMdkfoNHa2YlT2Tp Ifp39PMxweT9zeIomP6zLGk9g5yp+joW/QChQno67MJxBaJvjHqkEObesMKGltWBzc30 6dtonJ6ibOx5CwPzx7lUcdVxFKVi74gPe76OlwvIVilY4PKr1s1Wf9aKv30RVlWcAffl jX4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i4nqD/Hf0VXTis24YtlGqh9ZwQrKatGgfP76M7+ubo8=; b=Fmyv8HQsZtFxKsstghdhIuYjKGeDaqbhhM3YFz0N7EH4N3Y//Nm+fMXya7Zn0Bovw/ aVPSLZdnEWpzxtJkO0kypIdyrC1j/cUVnKqWs/+qk7FRY0nlHhxoLR1OiFCeyJUGYF1m MbR7WUvmHpP1btznAZ1zkrufuwggmgW3W3gl+K1prKg9xXWinp+AFi9rE/H5Czr6Rvv6 DGjiUGK4vZgYkTfjvpijPouBnTdB4KmbXRy3Xq08wL4X2wOPSjrn1wLAWWrGd0GYsJID mFi6L7weQseHPvG9NTMSCeDlOxFDX9obl3qmyzbTAdxYA3UuqMwAG0mnJnOraGiFUCBw Dq8Q== X-Gm-Message-State: AIVw1121EUqVwGIjnTJ56dr+Em1RSlT/vXklngzLZFCT9PiepaMeawXf Ps4KGKoDKYjI5MG9dT8ye7p5erYpQA== X-Received: by 10.37.0.195 with SMTP id 186mr2578406yba.46.1501124960090; Wed, 26 Jul 2017 20:09:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.42.200 with HTTP; Wed, 26 Jul 2017 20:09:19 -0700 (PDT) In-Reply-To: <1eef6165-9b5b-c354-dffe-5df1e98098fa@outer-planes.net> References: <150093015937.32021.12465797358778837950@ietfa.amsl.com> <1eef6165-9b5b-c354-dffe-5df1e98098fa@outer-planes.net> From: denis bider Date: Wed, 26 Jul 2017 21:09:19 -0600 Message-ID: To: "Matthew A. Miller" Cc: gen-art@ietf.org, curdle , ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org Content-Type: multipart/alternative; boundary="001a113cf650028e01055543e495" Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 03:09:23 -0000 --001a113cf650028e01055543e495 Content-Type: text/plain; charset="UTF-8" Hello Matthew, I'm not sure if I know how to address this better than with the language so far proposed. Perhaps one choice would be to simply remove this paragraph. However, the reason it was added was because an earlier reviewer (I'm not sure of the details at this time) raised the question about whether extension negotiation works like it does for algorithm lists, such as in e.g. SSH_MSG_KEXINIT. In that case, multiple algorithms are enumerated by both sides, and only one is chosen that (1) is enumerated by both sides, and (2) is the first of those to be enumerated by the client. The main purpose of this paragraph has been to clarify that extension negotiation does not work that way in EXT_INFO. What language would you propose? Is there some simple language that would do? How about this? "An extension may dictate, where it is specified, that in order to take effect, both parties must include it in its EXT_INFO; or it may be sufficient that only one party does; or more complex rules may be specified." On Wed, Jul 26, 2017 at 1:28 PM, Matthew A. Miller < linuxwolf+ietf@outer-planes.net> wrote: > Thanks very much for the response, Denis. > > I think I understand the intent here, but I'm not sure this new text is > enough to mitigate some future conflict. I'm also concerned that it > completely ignores the one-party extensions (e.g., an extension included > in the EXT_INFO by only the client or the server, but not both), and > what the impact is holistically. Looking at the one-party extensions > defined herein, I can't see how their order matters; but does that mean > the order will never matter? > > In writing this reply, I wondered if it's better for the order to always > be irrelevant; an implementation might be allowed to hint its preferred > order in the EXT_INFO, but implementations are still free to do whatever > makes sense to them within the bounds of the relevant extension > definitions. If an extension ought to take precedence over another, > make it clear in its specification that it SHOULD (or MUST) be dealt > with before (or after) others. > > Does that make sense? > > > - m&m > > Matthew A. Miller > > On 17/07/25 16:24, denis bider wrote: > > Good catch. I believe this refers to the following paragraph: > > > > "If an extension requires both the client and the server to include it > > in order for the extension to take effect, the relative position of the > > extension-name in each EXT_INFO message is irrelevant." > > > > I have drafted the following new wording: > > > > "Unless a particular extension's specification indicates differently; > > then, if an extension requires both the client and the server to include > > it in order for the extension to take effect; implementers MUST use a > > default assumption that the relative position of the extension-name in > > each EXT_INFO message is irrelevant with respect to whether the > > extension takes effect." > > > > The purpose of this wording is to: > > > > - Provide a sensible default, which is that in the absence of specific > > knowledge, order of extension names does not matter. > > > > - Allow for deviations in special cases where there is specific > knowledge. > > > > For example, extension "foo-linux" could be specified, but after some > > years of use, it's observed that it works well for its main purpose, but > > is not ideal for a server on Windows. Therefore, extension "foo-windows" > > is specified, which works well when the server is Windows, but not as > > well when it's Linux. > > > > In this case, an implementation that supports "foo-linux" only would be > > ignorant of anything else, and would use the default rule (order of > > extension names does not matter). However, an implementation that > > supports "foo-windows" could implement only that, or both "foo-linux" > > and "foo-windows". The specification for "foo-windows" could indicate > > that when both are supported, the first one listed by the server (or in > > other cases, by the client) is used. > > > > Allowing for such an extension-defined special case would allow a Linux > > server to advertise extensions [... "foo-linux", ..., "foo-windows", > > ...], preferring "foo-linux", but supporting the less appropriate > > "foo-windows" mechanism as well. Whereas, a Windows server could > > advertise [... "foo-windows", ..., "foo-linux", ...], preferring > > "foo-windows", but supporting the less appropriate "foo-linux" mechanism > > as well. > > > > Does this work? > > > > If there are no objections, I'll upload a -11 draft version with this > > new wording. > > > > > > > > On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller > > > > wrote: > > > > Reviewer: Matthew Miller > > Review result: Ready with Issues > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > > >. > > > > Document: draft-ietf-curdle-ssh-ext-info-10 > > Reviewer: Matthew Miller > > Review Date: 2017-07-24 > > IETF LC End Date: 2017-07-30 > > IESG Telechat date: N/A > > > > Summary: > > > > This document is ready with an issue. > > > > I found this document very coherent and easy to follow. > > > > Major issues: > > > > Minor issues: > > > > My only issue borders on nit, but sided with nit as I can see it > > potentially causing confusion for an implementer in the future. > > > > Section 2.5. "Interpretation of Extension Names and Values" > explicitly > > states in the second paragraph a condition where the relative order > of > > extension-names in an EXT_INFO message is irrelevant. However, the > rest > > of the section seems to imply to me that relative order is not > > important; > > so to explicitly call out a scenario seems to imply that relative > order > > *is* relevant/important, sometimes. If relative order is expected > to be > > important most of the time, I think it helpful to explicitly state > that > > and give a rationale for it. > > > > Nits/editorial comments: > > > > * RFC 5226 is referenced by this document, but is obsoleted by RFC > 8126. > > > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > > > > > > > --001a113cf650028e01055543e495 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Matthew,

I'm not sure if I kn= ow how to address this better than with the language so far proposed.
=

Perhaps one choice would be to simply remove this parag= raph. However, the reason it was added was because an earlier reviewer (I&#= 39;m not sure of the details at this time) raised the question about whethe= r extension negotiation works like it does for algorithm lists, such as in = e.g. SSH_MSG_KEXINIT. In that case, multiple algorithms are enumerated by b= oth sides, and only one is chosen that (1) is enumerated by both sides, and= (2) is the first of those to be enumerated by the client. The main purpose= of this paragraph has been to clarify that extension negotiation does not = work that way in EXT_INFO.

What language would you= propose? Is there some simple language that would do? How about this?

"An extension may dictate, where it is specified,= that in order to take effect, both parties must include it in its EXT_INFO= ; or it may be sufficient that only one party does; or more complex rules m= ay be specified."


On Wed, Jul 26, 2017 at 1:28 PM, Matthew A.= Miller <linuxwolf+ietf@outer-planes.net> wrot= e:
Thanks very much for the response, Den= is.

I think I understand the intent here, but I'm not sure this new text is=
enough to mitigate some future conflict.=C2=A0 I'm also concerned that = it
completely ignores the one-party extensions (e.g., an extension included in the EXT_INFO by only the client or the server, but not both), and
what the impact is holistically.=C2=A0 Looking at the one-party extensions<= br> defined herein, I can't see how their order matters; but does that mean=
the order will never matter?

In writing this reply, I wondered if it's better for the order to alway= s
be irrelevant; an implementation might be allowed to hint its preferred
order in the EXT_INFO, but implementations are still free to do whatever makes sense to them within the bounds of the relevant extension
definitions.=C2=A0 If an extension ought to take precedence over another, make it clear in its specification that it SHOULD (or MUST) be dealt
with before (or after) others.

Does that make sense?


- m&m

Matthew A. Miller

On 17/07/25 16:24, denis bider wrote:
> Good catch. I believe this refers to the following paragraph:
>
> "If an extension requires both the client and the server to inclu= de it
> in order for the extension to take effect, the relative position of th= e
> extension-name in each EXT_INFO message is irrelevant."
>
> I have drafted the following new wording:
>
> "Unless a particular extension's specification indicates diff= erently;
> then, if an extension requires both the client and the server to inclu= de
> it in order for the extension to take effect; implementers MUST use a<= br> > default assumption that the relative position of the extension-name in=
> each EXT_INFO message is irrelevant with respect to whether the
> extension takes effect."
>
> The purpose of this wording is to:
>
> - Provide a sensible default, which is that in the absence of specific=
> knowledge, order of extension names does not matter.
>
> - Allow for deviations in special cases where there is specific knowle= dge.
>
> For example, extension "foo-linux" could be specified, but a= fter some
> years of use, it's observed that it works well for its main purpos= e, but
> is not ideal for a server on Windows. Therefore, extension "foo-w= indows"
> is specified, which works well when the server is Windows, but not as<= br> > well when it's Linux.
>
> In this case, an implementation that supports "foo-linux" on= ly would be
> ignorant of anything else, and would use the default rule (order of > extension names does not matter). However, an implementation that
> supports "foo-windows" could implement only that, or both &q= uot;foo-linux"
> and "foo-windows". The specification for "foo-windows&q= uot; could indicate
> that when both are supported, the first one listed by the server (or i= n
> other cases, by the client) is used.
>
> Allowing for such an extension-defined special case would allow a Linu= x
> server to advertise extensions [... "foo-linux", ..., "= foo-windows",
> ...], preferring "foo-linux", but supporting the less approp= riate
> "foo-windows" mechanism as well. Whereas, a Windows server c= ould
> advertise [... "foo-windows", ..., "foo-linux", ..= .], preferring
> "foo-windows", but supporting the less appropriate "foo= -linux" mechanism
> as well.
>
> Does this work?
>
> If there are no objections, I'll upload a -11 draft version with t= his
> new wording.
>
>
>
> On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller
> <linuxwolf+iet= f@outer-planes.net
> <mailto:linuxwolf+ietf@outer-planes.net>&g= t; wrote:
>
>=C2=A0 =C2=A0 =C2=A0Reviewer: Matthew Miller
>=C2=A0 =C2=A0 =C2=A0Review result: Ready with Issues
>
>=C2=A0 =C2=A0 =C2=A0I am the assigned Gen-ART reviewer for this draft. = The General Area
>=C2=A0 =C2=A0 =C2=A0Review Team (Gen-ART) reviews all IETF documents be= ing processed
>=C2=A0 =C2=A0 =C2=A0by the IESG for the IETF Chair.=C2=A0 Please treat = these comments just
>=C2=A0 =C2=A0 =C2=A0like any other last call comments.
>
>=C2=A0 =C2=A0 =C2=A0For more information, please see the FAQ at
>
>=C2=A0 =C2=A0 =C2=A0<https://trac.ietf.org/trac/= gen/wiki/GenArtfaq
>=C2=A0 =C2=A0 =C2=A0<https://trac.ietf.org/trac/= gen/wiki/GenArtfaq>>.
>
>=C2=A0 =C2=A0 =C2=A0Document: draft-ietf-curdle-ssh-ext-info-10 >=C2=A0 =C2=A0 =C2=A0Reviewer: Matthew Miller
>=C2=A0 =C2=A0 =C2=A0Review Date: 2017-07-24
>=C2=A0 =C2=A0 =C2=A0IETF LC End Date: 2017-07-30
>=C2=A0 =C2=A0 =C2=A0IESG Telechat date: N/A
>
>=C2=A0 =C2=A0 =C2=A0Summary:
>
>=C2=A0 =C2=A0 =C2=A0This document is ready with an issue.
>
>=C2=A0 =C2=A0 =C2=A0I found this document very coherent and easy to fol= low.
>
>=C2=A0 =C2=A0 =C2=A0Major issues:
>
>=C2=A0 =C2=A0 =C2=A0Minor issues:
>
>=C2=A0 =C2=A0 =C2=A0My only issue borders on nit, but sided with nit as= I can see it
>=C2=A0 =C2=A0 =C2=A0potentially causing confusion for an implementer in= the future.
>
>=C2=A0 =C2=A0 =C2=A0Section 2.5. "Interpretation of Extension Name= s and Values" explicitly
>=C2=A0 =C2=A0 =C2=A0states in the second paragraph a condition where th= e relative order of
>=C2=A0 =C2=A0 =C2=A0extension-names in an EXT_INFO message is irrelevan= t.=C2=A0 However, the rest
>=C2=A0 =C2=A0 =C2=A0of the section seems to imply to me that relative o= rder is not
>=C2=A0 =C2=A0 =C2=A0important;
>=C2=A0 =C2=A0 =C2=A0so to explicitly call out a scenario seems to imply= that relative order
>=C2=A0 =C2=A0 =C2=A0*is* relevant/important, sometimes.=C2=A0 If relati= ve order is expected to be
>=C2=A0 =C2=A0 =C2=A0important most of the time, I think it helpful to e= xplicitly state that
>=C2=A0 =C2=A0 =C2=A0and give a rationale for it.
>
>=C2=A0 =C2=A0 =C2=A0Nits/editorial comments:
>
>=C2=A0 =C2=A0 =C2=A0* RFC 5226 is referenced by this document, but is o= bsoleted by RFC 8126.
>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Curdle mailing list
>=C2=A0 =C2=A0 =C2=A0Curd= le@ietf.org <mailto:Curdle@ietf.o= rg>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/curdle
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/curdle>
>
>


--001a113cf650028e01055543e495-- From nobody Thu Jul 27 02:16:09 2017 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 EF57B13188F; Thu, 27 Jul 2017 02:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 VBJrvdXhwNNp; Thu, 27 Jul 2017 02:15:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1FA127180; Thu, 27 Jul 2017 02:15:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLJ95902; Thu, 27 Jul 2017 09:15:56 +0000 (GMT) Received: from DGGEMI404-HUB.china.huawei.com (10.3.17.142) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 27 Jul 2017 10:15:54 +0100 Received: from DGGEMI501-MBS.china.huawei.com ([169.254.2.52]) by dggemi404-hub.china.huawei.com ([10.3.17.142]) with mapi id 14.03.0301.000; Thu, 27 Jul 2017 17:15:50 +0800 From: zhangdacheng To: Russ Housley CC: IETF SecDir , IESG , curdle Thread-Topic: Secdir review of draft-ietf-curdle-cms-eddsa-signatures-06 Thread-Index: AQHTBJmcnToY9SpHqUWCJHwmpqIR0KJju5nQ Date: Thu, 27 Jul 2017 09:15:49 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C22420160BC01@dggemi501-mbs.china.huawei.com> References: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5979AF4D.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.52, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d0355d5fd6156d16a8383073044d4cb5 Archived-At: Subject: [Curdle] =?gb2312?b?tPC4tDogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRm?= =?gb2312?b?LWN1cmRsZS1jbXMtZWRkc2Etc2lnbmF0dXJlcy0wNg==?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 09:16:01 -0000 SGksIFJ1c3M6DQoNClNlZSBtZSBjb21tZW50cyBiZWxvdyBwbGVhc2UuDQoNCj4gMS4gSW4gc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMsIHRoZSBmaXJzdCBhbmQgdGhlIHNlY29uZCBwYXJhZ3JhcGhz IGFyZSBhYm91dCBob3cgaW1wbGVtZW50YXRpb25zIHByb3RlY3QgdGhlIHByaXZhdGUga2V5cyBh bmQgaG93IHRoZXkgZ3VhcmFudGVlIHRoZSBxdWFsaXR5IG9mIHJhbmRvbSBudW1iZXJzLiBOb3Jt YWxseSwgdGhpcyBzdWNoIGNvbnNpZGVyYXRpb25zIGFyZSBvdXQgb2Ygc2NvcGUgb2YgcHJvdG9j b2wgc3BlY2lmaWNhdGlvbnMuIEJ1dCBJIGFtIG9rIGlmIHRoZSBhdXRob3JzIHdvdWxkIGxpa2Ug dG8ga2VlcCB0aGVtLiANCg0KVGhlc2UgYXJlIGltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRpb25z IHRoYXQgaW1wYWN0IHNlY3VyaXR5LiAgSSB0aGluayB0aGV5IHNob3VsZCBzdGF5IGluIHRoZSBk b2N1bWVudC4NCg0KRGFjaGVuZzogc3VyZS4NCg0KPiAyLiBJbiB0aGUgNHRoIHBhcmFncmFwaCBv ZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgJyB0aGUgc2FtZSBwcml2YXRlIGtleSBTSE9VTEQg Tk9UIGJlIHVzZWQgd2l0aCBtb3JlIHRoYW4gb25lIEVkRFNBIHNldCBvZiBwYXJhbWV0ZXJzLicg LT4gJyB0aGUgc2FtZSBwcml2YXRlIGtleSBNVVNUIE5PVCBiZSB1c2VkIHdpdGggbW9yZSB0aGFu IG9uZSBFZERTQSBzZXQgb2YgcGFyYW1ldGVycy4nIFNpbmNlIHdlIGFscmVhZHkga25vdyB0aGF0 IHRoZSBzYW1lIHByaXZhdGUga2V5IHVzZWQgZm9yIG11bHRpcGxlIGFsZ29yaXRobXMgd2lsbCBj YXVzZSBwb3RlbnRpYWwgcmlza3MsIHdlIHNob3VsZCB1c2UgYSBzdHJvbmdlciB3b3JkIGhlcmUu DQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggdXNpbmcgdGhl IHNhbWUgcHJpdmF0ZSBrZXkgd2l0aCBQdXJlRWREU0EgYW5kIEhhc2hFZERTQS4gIFRoZSBwcnVk ZW50IGFkdmljZSBpcyB0byBhdm9pZCBtaXhpbmcgdGhlIHNhbWUgcHJpdmF0ZSBrZXkgd2l0aCBk aWZmZXJlbnQgcGFyYW1ldGVyLCB0aHVzIHRoZSBTSE9VTEQgTk9ULiAgSSBwb2ludCBvdXQgdGhh dCBSRkMgODAzMiBnb2VzIGV2ZW4gZnVydGhlcjoNCg0KICAgLi4uIFRodXMsIG9uZSBjYW4gdXNl IHRoZSBzYW1lDQogICBrZXkgcGFpciBmb3IgRWQyNTUxOSwgRWQyNTUxOWN0eCwgYW5kIEVkMjU1 MTlwaCBhbmQgY29ycmVzcG9uZGluZ2x5DQogICB3aXRoIEVkNDQ4IGFuZCBFZDQ0OHBoLg0KDQpE YWNoZW5nOiBPaywgSSBzZWUgeW91ciBwb2ludC4gVGhlbiwgSSB0aGluayBpdCB3aWxsIGJlIGdv b2QgdG8gbWFrZSBzb21lIGNsYXJpZmljYXRpb24gaGVyZSBzaW5jZSB0aGUgZmlyc3Qgc2VudGVu Y2Ugb2YgdGhpcyBwYXJhZ3JhcGggc3Ryb25nbHkgYXJndWVzIHRoYXQgJyBVc2luZyB0aGUgc2Ft ZSBwcml2YXRlIGtleSBmb3IgZGlmZmVyZW50IGFsZ29yaXRobXMgaGFzIHRoZSBwb3RlbnRpYWwg b2YgYWxsb3dpbmcgYW4gYXR0YWNrZXIgdG8gZ2V0IGV4dHJhIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBwcml2YXRlIGtleS4nIE1heWJlIHdlIGNhbiBjaGFuZ2UgdGhlIHNlY29uZCBzZW50ZW5jZSB0 byBzb21ldGhpbmcgbGlrZSAnIEZvciB0aGlzIHJlYXNvbiwgdGhlIHNhbWUgcHJpdmF0ZSBrZXkg U0hPVUxEIE5PVCBiZSB1c2VkIHdpdGggbW9yZSB0aGFuIG9uZSBFZERTQSBzZXQgb2YgcGFyYW1l dGVycywgYWx0aG91Z2ggcGVvcGxlIGJlbGlldmUgdGhhdCBubyBzZWN1cml0eSBpc3N1ZSB3aWxs IGJlIGNhdXNlZCB3aGVuIHVzaW5nIHRoZSBzYW1lIHByaXZhdGUga2V5IHdpdGggUHVyZUVkRFNB IGFuZCBIYXNoRWREU0EgW1JGQzgwMzJdLiAnDQoNCj4gMy4gSW4gdGhlIDV0aCBwYXJhZ3JhcGgg b2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsICcgdGhlIHNhbWUgaGFzaCBmdW5jdGlvbiBzaG91 bGQgYmUgdXNlZCBmb3IgYWxsIG9wZXJhdGlvbnMuJyAtPicgdGhlIHNhbWUgaGFzaCBmdW5jdGlv biBTSE9VTEQgYmUgdXNlZCBmb3IgYWxsIG9wZXJhdGlvbnMuJw0KDQpZZXMsIEkgYWdyZWUuDQoN Cj4gNC4gSW4gdGhlIDFzdCBwYXJhZ3JhcGgsICdXaGVuIHNpZ25pbmcgd2l0aCBFZDI1NTE5LCB0 aGUgZGlnZXN0QWxnb3JpdGhtIFNIT1VMRCBpbmNsdWRlIGlkLXNoYTUxMicgLT4nIFdoZW4gc2ln bmluZyB3aXRoIEVkMjU1MTksIHRoZSBkaWdlc3RBbGdvcml0aG0gTVVTVCBpbmNsdWRlIGlkLXNo YTUxMicuICdXaGVuIHNpZ25pbmcgd2l0aCBFZDQ0OCwgdGhlIGRpZ2VzdEFsZ29yaXRobSBTSE9V TEQgaW5jbHVkZSBpZC1zaGFrZTI1Ni1sZW4nIC0+ICdXaGVuIHNpZ25pbmcgd2l0aCBFZDQ0OCwg dGhlIGRpZ2VzdEFsZ29yaXRobSBNVVNUIGluY2x1ZGUgaWQtc2hha2UyNTYtbGVuJy4NCg0KSSBh c3N1bWUgeW91IGFyZSB0YWxraW5nIGFib3V0IFNlY3Rpb24gMy4xIGhlcmUuICBUaGVzZSBzaG91 bGQgbm90IGJlIGNoYW5nZWQgdG8gTVVTVC4gIENNUyBkb2VzIG5vdCByZXF1aXJlIHRoZXNlIHRv IGJlIGZpbGxlZCBpbiwgYnV0IHN0cmVhbS1vcmllbnRlZCBwcm9jZXNzaW5nIHdvcmtzIGJldHRl ciBpZiB0aGV5IGFyZSBmaWxsZWQgaW4uICBUaHVzLCB0aGUgU0hPVUxEIHN0YXRlbWVudC4NCg0K RGFjaGVuZzogTm8gcHJvYmxlbSB3aXRoIHRoYXQuDQoNClJ1c3MNCg0K From nobody Thu Jul 27 04:58:52 2017 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 4B4ED132125 for ; Thu, 27 Jul 2017 04:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 06_AV7eG01Gx for ; Thu, 27 Jul 2017 04:58:49 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 DF45F131BBE for ; Thu, 27 Jul 2017 04:58:48 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id m86so72109159lfi.4 for ; Thu, 27 Jul 2017 04:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7+m1HyUnN03F/hZJpPfqO4wh5U41PHBKTg4etk/23ac=; b=bOfVITJRpgZhpQhJqw//UIIDlwTZOZ6rDtkeAZu6aXp/uL42zhI345QrIz7f7clVzm fxfqEsMG9XUigxb8Mchu+wG1T6APOsFsZDlUdl2KQ4PIw2UkEO0LarhzB2KMGvqkd3CX TvyJInVZpCqs/GdZyzjA1aRRiWvhUkOa0FmT8+CkxgV0Os2ZBMh4wUoJqL4JJdRDlCaD 95IOKgDk0Km20uVaXVpPjUQ7UsItgC/kvKbuQM+GWjrfwJIVmpRAsVAN+5kjTjcPYYCw SPyQhp+XE8DeATw0lJr+rxjsx/lA7/2fd3SBXlaiLkPKaWNBgzD19yES3ZRyXo/WkGPL fglw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7+m1HyUnN03F/hZJpPfqO4wh5U41PHBKTg4etk/23ac=; b=fhsgE5q8ZwPq4ASYUVQMqA9UN1cICO19sSzPSXMG1TfbdRk/wePJwF7tXkJ6kZAEjo uy5K7WNvBrDazujv6VSb1O0MqKBNAX85EvdoZT98pduA4/vZjC5EEji2zHmrdJ97PaEC eNGlwQA9LCqOE9SPgHZeaL5mtAYliyCgtSwbSt21yQJHHVBHFPUNtADdL7ul2YuKNfCU 1yPYc81AeT8zL5UYpiz3MgypBf3Ct0bWKgUrHGoq2q25glW0lYsax0ozMYtmorIBl/7W VYFeYIgYmmNJN7bljXRfXdvihHefNk/AxdEWtrmp9VlBEUMCjAbM0HVN4iov9jCGrl9+ uhag== X-Gm-Message-State: AIVw110itmvEQ+Im4Gmx3cUkliKdoGmfjcC0DpFT/EDZkpDiKKnvzrKT tvoJxhJz8H6Ynu3Ws2hWnUJAWYJ3IQ== X-Received: by 10.46.84.91 with SMTP id y27mr1694214ljd.190.1501156727162; Thu, 27 Jul 2017 04:58:47 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.142.199 with HTTP; Thu, 27 Jul 2017 04:58:46 -0700 (PDT) In-Reply-To: <008701d304fa$c5f306d0$51d91470$@augustcellars.com> References: <008701d304fa$c5f306d0$51d91470$@augustcellars.com> From: Phillip Hallam-Baker Date: Thu, 27 Jul 2017 07:58:46 -0400 X-Google-Sender-Auth: YTxI4RSfjcZV2xMOfDlB5pVbF5Q Message-ID: To: Jim Schaad Cc: "Matthew A. Miller" , Curdle Content-Type: multipart/alternative; boundary="f403045fbad2798d7805554b49ca" Archived-At: Subject: Re: [Curdle] Regarding X25519 in JOSE ... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 11:58:51 -0000 --f403045fbad2798d7805554b49ca Content-Type: text/plain; charset="UTF-8" Hash signatures are probably not needed since JOSE already has a hash mechanism. OK so looks like my action item from Prague is already done! On Tue, Jul 25, 2017 at 12:02 AM, Jim Schaad wrote: > Yes, the document covers all four algorithms, although it only does pure > signatures not hash signatures > > > > Jim > > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Phillip > Hallam-Baker > *Sent:* Tuesday, July 25, 2017 2:31 AM > *To:* Matthew A. Miller > *Cc:* Curdle > *Subject:* Re: [Curdle] Regarding X25519 in JOSE ... > > > > How about Ed25519 and Ed448? Did those get done as well? > > > > On Mon, Jul 24, 2017 at 10:26 AM, Matthew A. Miller < > linuxwolf+ietf@outer-planes.net> wrote: > > Hello all, > > It was asked if any work more work is needed to add X25519 (and X448) to > JOSE. I believe [RFC8037] covers that, so I don't think any more work > is necessary right now. > > > Thanks, > > -- > - m&m > > Matthew A. Miller > > [RFC8037] CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in > JSON Object Signing and Encryption (JOSE) < > https://tools.ietf.org/html/rfc8037 > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > --f403045fbad2798d7805554b49ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Has= h signatures are probably not needed since JOSE already has a hash mechanis= m.=C2=A0

OK so looks like= my action item from Prague is already done!

On Tue, Jul 25, 2017 at 12:02 AM, Jim Scha= ad <ietf@augustcellars.com> wrote:

Yes, the do= cument covers all four algorithms, although it only does pure signatures no= t hash signatures

=C2=A0<= /u>

Jim

<= u>=C2=A0

=C2=A0

From: Curdle [mailto:curdle-bounces@ietf.org] On Beh= alf Of Phillip Hallam-Baker
Sent: Tuesday, July 25, 2017 2:31= AM
To: Matthew A. Miller <linuxwolf+ietf@outer-p= lanes.net>
Cc: Curdle <curdle@ietf.org>Subject: Re: [Curdle] Regarding X25519 in JOSE ...

=C2=A0

How about Ed25519 and Ed448= ? Did those get done as well?

=C2=A0

On Mon, Jul 24, 2017 at 10:26 AM, Matthew A. Miller <linuxwolf+= ietf@outer-planes.net> wrote:

Hello all,

It was asked if any work more work is need= ed to add X25519 (and X448) to
JOSE.=C2=A0 I believe [RFC8037] covers th= at, so I don't think any more work
is necessary right now.

Thanks,

--
- = m&m

Matthew A= . Miller

[RFC8037= ] CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in
JSON Object Signing and Encryption= (JOSE) <
https://tools.ie= tf.org/html/rfc8037 >


________________= _______________________________
Curdle mailing list
Curdle@ietf.org
https://www= .ietf.org/mailman/listinfo/curdle

=C2=A0

=

--f403045fbad2798d7805554b49ca-- From nobody Thu Jul 27 10:13:46 2017 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 EA9F0131CFD for ; Thu, 27 Jul 2017 10:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3slWJJAC3twO for ; Thu, 27 Jul 2017 10:13:43 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC460131CEE for ; Thu, 27 Jul 2017 10:13:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3582630056B for ; Thu, 27 Jul 2017 13:13:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DszAn6fHtV_B for ; Thu, 27 Jul 2017 13:13:40 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CDED5300429; Thu, 27 Jul 2017 13:13:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <879E76B64CF340468BF5E4DE504C22420160BC01@dggemi501-mbs.china.huawei.com> Date: Thu, 27 Jul 2017 13:13:40 -0400 Cc: curdle , IESG , IETF SecDir Content-Transfer-Encoding: quoted-printable Message-Id: References: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com> <879E76B64CF340468BF5E4DE504C22420160BC01@dggemi501-mbs.china.huawei.com> To: zhangdacheng X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] =?utf-8?b?562U5aSNOiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWll?= =?utf-8?q?tf-curdle-cms-eddsa-signatures-06?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 17:13:45 -0000 Dacheng: Trimming the parts where we have reached agreement... >> 2. In the 4th paragraph of security considerations, ' the same = private key SHOULD NOT be used with more than one EdDSA set of = parameters.' -> ' the same private key MUST NOT be used with more than = one EdDSA set of parameters.' Since we already know that the same = private key used for multiple algorithms will cause potential risks, we = should use a stronger word here. >=20 > I do not think that there is a problem with using the same private key = with PureEdDSA and HashEdDSA. The prudent advice is to avoid mixing the = same private key with different parameter, thus the SHOULD NOT. I point = out that RFC 8032 goes even further: >=20 > ... Thus, one can use the same > key pair for Ed25519, Ed25519ctx, and Ed25519ph and correspondingly > with Ed448 and Ed448ph. >=20 > Dacheng: Ok, I see your point. Then, I think it will be good to make = some clarification here since the first sentence of this paragraph = strongly argues that ' Using the same private key for different = algorithms has the potential of allowing an attacker to get extra = information about the private key.' Maybe we can change the second = sentence to something like ' For this reason, the same private key = SHOULD NOT be used with more than one EdDSA set of parameters, although = people believe that no security issue will be caused when using the same = private key with PureEdDSA and HashEdDSA [RFC8032]. ' How about: Using the same private key with different algorithms has the potential to leak extra information about the private key to an attacker. For this reason, the same private key SHOULD NOT be used with more than one set of EdDSA parameters, although people believe that there are no security concerns when using the same private key with PureEdDSA and HashEdDSA [EDDSA]. Russ From nobody Thu Jul 27 23:49:48 2017 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 2071D132024; Thu, 27 Jul 2017 23:49:40 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150122458010.25311.255754597244038042@ietfa.amsl.com> Date: Thu, 27 Jul 2017 23:49:40 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-11.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 06:49: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 : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-11.txt Pages : 11 Date : 2017-07-27 Abstract: This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-11 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-11 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 Thu Jul 27 23:53:02 2017 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 E88B61296C9; Thu, 27 Jul 2017 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zqFUWeUwk-2e; Thu, 27 Jul 2017 23:52:58 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 4651B126DCA; Thu, 27 Jul 2017 23:52:58 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l82so60641831ywc.2; Thu, 27 Jul 2017 23:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UNpe3sfb4eHaFiGzO/beeSLE5H0XMVlRgkU4j5UDMDQ=; b=Jpxp19cW3Wa+/92dqagKAzRQO2ybpV7KyQk3DuonqUwPkxObRM7Am5Mo8iFX9WAj+l hQhc5m6lthyl2l8RVuwXvNV/6r5IR+5QcTVWPpHg7brRjNf0FVby6KRzBG4zvpBop0Nz GomVITUTzrgzSX+N4u0KDsruH7IH5M2OV1/qQZUIUAExpWnObuA1t0zj+1PWTlwkH8d/ Zf88Pfg/GD6pinz8M6AH81nutEAe/6QkJ3klcLB0Ot2iLBFJ+GjugZHZ6qr4vBOw2JiT cCYAxNgbh7uFASoWKKMCsi1HtrGwd1NjRv7RFfI43ssrSA9KAQRoStEWhY5sLylcanvt 7Ieg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UNpe3sfb4eHaFiGzO/beeSLE5H0XMVlRgkU4j5UDMDQ=; b=isFQJgyEjs+/8PBrll/z0xgrWkmV0CNCLwX2LBZsIINWdP6FPyzxkQy1PbeN9FUyTL T8KvKlXdQuYN17gj2vIgzhUNrR04GFz32OTSYlR7Tl7jmtEgcyPgi1sxKFmf+4Zr6LgA knQ8OaOpEGmSyOeOuJ01Qpl/Xx2ivDq4lNJZ7BkZt1KCzOdD9tt3gfWOoPqAELLQAR5c 8OlkGKr0uUSx4VgRe4GJTNpsZn4ecQf+yYkJRwbeU5sVNeesFEuUVWK4m4FcUDmDrm7s nOy7pcf18TpRvukKkTq0tVL5s7hPlK9CbEZBc/eYoLYdA2FpaJyxU8DTuB7qr62PEbhv kjnQ== X-Gm-Message-State: AIVw113sNMel8bI1Z9to6cDIrvC5EQ0moD/z/c4vXm10dML+G4BGFPDJ c2sRa2uLeyesSEmANgPyJgfq1k4JWZXs X-Received: by 10.129.154.16 with SMTP id r16mr5487871ywg.282.1501224777586; Thu, 27 Jul 2017 23:52:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.42.200 with HTTP; Thu, 27 Jul 2017 23:52:57 -0700 (PDT) In-Reply-To: References: <150093015937.32021.12465797358778837950@ietfa.amsl.com> <1eef6165-9b5b-c354-dffe-5df1e98098fa@outer-planes.net> From: denis bider Date: Fri, 28 Jul 2017 00:52:57 -0600 Message-ID: To: "Matthew A. Miller" Cc: gen-art@ietf.org, curdle , ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b8698989d6605555b21e8" Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 06:53:01 -0000 --94eb2c0b8698989d6605555b21e8 Content-Type: text/plain; charset="UTF-8" OK, I have uploaded version -11 with language as follows: "An extension MAY dictate, where it is specified, that in order to take effect, both parties must include it in their EXT_INFO; or it MAY be sufficient that only one party includes it; or other rules MAY be specified. The relative order in which extensions appear in an EXT_INFO message MUST be ignored by default; but an extension MAY specify that the order matters for that extension, in a specific way." This seems clearer to me than it was in -10. If you still see room for improvement, let me know! On Wed, Jul 26, 2017 at 9:09 PM, denis bider wrote: > Hello Matthew, > > I'm not sure if I know how to address this better than with the language > so far proposed. > > Perhaps one choice would be to simply remove this paragraph. However, the > reason it was added was because an earlier reviewer (I'm not sure of the > details at this time) raised the question about whether extension > negotiation works like it does for algorithm lists, such as in e.g. > SSH_MSG_KEXINIT. In that case, multiple algorithms are enumerated by both > sides, and only one is chosen that (1) is enumerated by both sides, and (2) > is the first of those to be enumerated by the client. The main purpose of > this paragraph has been to clarify that extension negotiation does not work > that way in EXT_INFO. > > What language would you propose? Is there some simple language that would > do? How about this? > > "An extension may dictate, where it is specified, that in order to take > effect, both parties must include it in its EXT_INFO; or it may be > sufficient that only one party does; or more complex rules may be > specified." > > > On Wed, Jul 26, 2017 at 1:28 PM, Matthew A. Miller < > linuxwolf+ietf@outer-planes.net> wrote: > >> Thanks very much for the response, Denis. >> >> I think I understand the intent here, but I'm not sure this new text is >> enough to mitigate some future conflict. I'm also concerned that it >> completely ignores the one-party extensions (e.g., an extension included >> in the EXT_INFO by only the client or the server, but not both), and >> what the impact is holistically. Looking at the one-party extensions >> defined herein, I can't see how their order matters; but does that mean >> the order will never matter? >> >> In writing this reply, I wondered if it's better for the order to always >> be irrelevant; an implementation might be allowed to hint its preferred >> order in the EXT_INFO, but implementations are still free to do whatever >> makes sense to them within the bounds of the relevant extension >> definitions. If an extension ought to take precedence over another, >> make it clear in its specification that it SHOULD (or MUST) be dealt >> with before (or after) others. >> >> Does that make sense? >> >> >> - m&m >> >> Matthew A. Miller >> >> On 17/07/25 16:24, denis bider wrote: >> > Good catch. I believe this refers to the following paragraph: >> > >> > "If an extension requires both the client and the server to include it >> > in order for the extension to take effect, the relative position of the >> > extension-name in each EXT_INFO message is irrelevant." >> > >> > I have drafted the following new wording: >> > >> > "Unless a particular extension's specification indicates differently; >> > then, if an extension requires both the client and the server to include >> > it in order for the extension to take effect; implementers MUST use a >> > default assumption that the relative position of the extension-name in >> > each EXT_INFO message is irrelevant with respect to whether the >> > extension takes effect." >> > >> > The purpose of this wording is to: >> > >> > - Provide a sensible default, which is that in the absence of specific >> > knowledge, order of extension names does not matter. >> > >> > - Allow for deviations in special cases where there is specific >> knowledge. >> > >> > For example, extension "foo-linux" could be specified, but after some >> > years of use, it's observed that it works well for its main purpose, but >> > is not ideal for a server on Windows. Therefore, extension "foo-windows" >> > is specified, which works well when the server is Windows, but not as >> > well when it's Linux. >> > >> > In this case, an implementation that supports "foo-linux" only would be >> > ignorant of anything else, and would use the default rule (order of >> > extension names does not matter). However, an implementation that >> > supports "foo-windows" could implement only that, or both "foo-linux" >> > and "foo-windows". The specification for "foo-windows" could indicate >> > that when both are supported, the first one listed by the server (or in >> > other cases, by the client) is used. >> > >> > Allowing for such an extension-defined special case would allow a Linux >> > server to advertise extensions [... "foo-linux", ..., "foo-windows", >> > ...], preferring "foo-linux", but supporting the less appropriate >> > "foo-windows" mechanism as well. Whereas, a Windows server could >> > advertise [... "foo-windows", ..., "foo-linux", ...], preferring >> > "foo-windows", but supporting the less appropriate "foo-linux" mechanism >> > as well. >> > >> > Does this work? >> > >> > If there are no objections, I'll upload a -11 draft version with this >> > new wording. >> > >> > >> > >> > On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller >> > > > > wrote: >> > >> > Reviewer: Matthew Miller >> > Review result: Ready with Issues >> > >> > I am the assigned Gen-ART reviewer for this draft. The General Area >> > Review Team (Gen-ART) reviews all IETF documents being processed >> > by the IESG for the IETF Chair. Please treat these comments just >> > like any other last call comments. >> > >> > For more information, please see the FAQ at >> > >> > > > >. >> > >> > Document: draft-ietf-curdle-ssh-ext-info-10 >> > Reviewer: Matthew Miller >> > Review Date: 2017-07-24 >> > IETF LC End Date: 2017-07-30 >> > IESG Telechat date: N/A >> > >> > Summary: >> > >> > This document is ready with an issue. >> > >> > I found this document very coherent and easy to follow. >> > >> > Major issues: >> > >> > Minor issues: >> > >> > My only issue borders on nit, but sided with nit as I can see it >> > potentially causing confusion for an implementer in the future. >> > >> > Section 2.5. "Interpretation of Extension Names and Values" >> explicitly >> > states in the second paragraph a condition where the relative order >> of >> > extension-names in an EXT_INFO message is irrelevant. However, the >> rest >> > of the section seems to imply to me that relative order is not >> > important; >> > so to explicitly call out a scenario seems to imply that relative >> order >> > *is* relevant/important, sometimes. If relative order is expected >> to be >> > important most of the time, I think it helpful to explicitly state >> that >> > and give a rationale for it. >> > >> > Nits/editorial comments: >> > >> > * RFC 5226 is referenced by this document, but is obsoleted by RFC >> 8126. >> > >> > >> > _______________________________________________ >> > Curdle mailing list >> > Curdle@ietf.org >> > https://www.ietf.org/mailman/listinfo/curdle >> > >> > >> > >> >> > --94eb2c0b8698989d6605555b21e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I have uploaded version -11 with language as follows:<= div>
"An extension MAY dictate, where it is specified, t= hat in order to take effect, both parties must include it in their EXT_INFO= ; or it MAY be sufficient that only one party includes it; or other rules M= AY be specified. The relative order in which extensions appear in an EXT_IN= FO message MUST be ignored by default; but an extension MAY specify that th= e order matters for that extension, in a specific way."

=
This seems clearer to me than it was in -10. If you still see ro= om for improvement, let me know!


On Wed, Jul 26, 2017 at 9:09 PM, = denis bider <denisbider.ietf@gmail.com> wrote:
Hello Matthew,

=
I'm not sure if I know how to address this better than with the la= nguage so far proposed.

Perhaps one choice would b= e to simply remove this paragraph. However, the reason it was added was bec= ause an earlier reviewer (I'm not sure of the details at this time) rai= sed the question about whether extension negotiation works like it does for= algorithm lists, such as in e.g. SSH_MSG_KEXINIT. In that case, multiple a= lgorithms are enumerated by both sides, and only one is chosen that (1) is = enumerated by both sides, and (2) is the first of those to be enumerated by= the client. The main purpose of this paragraph has been to clarify that ex= tension negotiation does not work that way in EXT_INFO.

What language would you propose? Is there some simple language that w= ould do? How about this?

"An extension may di= ctate, where it is specified, that in order to take effect, both parties mu= st include it in its EXT_INFO; or it may be sufficient that only one party = does; or more complex rules may be specified."


<= div class=3D"gmail_quote">On Wed, Jul 26, 2017 at 1:28 PM, Matthew A. Mille= r <linuxwolf+ietf@outer-planes.net> wrote= :
Thanks very much for the response, Deni= s.

I think I understand the intent here, but I'm not sure this new text is=
enough to mitigate some future conflict.=C2=A0 I'm also concerned that = it
completely ignores the one-party extensions (e.g., an extension included in the EXT_INFO by only the client or the server, but not both), and
what the impact is holistically.=C2=A0 Looking at the one-party extensions<= br> defined herein, I can't see how their order matters; but does that mean=
the order will never matter?

In writing this reply, I wondered if it's better for the order to alway= s
be irrelevant; an implementation might be allowed to hint its preferred
order in the EXT_INFO, but implementations are still free to do whatever makes sense to them within the bounds of the relevant extension
definitions.=C2=A0 If an extension ought to take precedence over another, make it clear in its specification that it SHOULD (or MUST) be dealt
with before (or after) others.

Does that make sense?


- m&m

Matthew A. Miller

On 17/07/25 16:24, denis bider wrote:
> Good catch. I believe this refers to the following paragraph:
>
> "If an extension requires both the client and the server to inclu= de it
> in order for the extension to take effect, the relative position of th= e
> extension-name in each EXT_INFO message is irrelevant."
>
> I have drafted the following new wording:
>
> "Unless a particular extension's specification indicates diff= erently;
> then, if an extension requires both the client and the server to inclu= de
> it in order for the extension to take effect; implementers MUST use a<= br> > default assumption that the relative position of the extension-name in=
> each EXT_INFO message is irrelevant with respect to whether the
> extension takes effect."
>
> The purpose of this wording is to:
>
> - Provide a sensible default, which is that in the absence of specific=
> knowledge, order of extension names does not matter.
>
> - Allow for deviations in special cases where there is specific knowle= dge.
>
> For example, extension "foo-linux" could be specified, but a= fter some
> years of use, it's observed that it works well for its main purpos= e, but
> is not ideal for a server on Windows. Therefore, extension "foo-w= indows"
> is specified, which works well when the server is Windows, but not as<= br> > well when it's Linux.
>
> In this case, an implementation that supports "foo-linux" on= ly would be
> ignorant of anything else, and would use the default rule (order of > extension names does not matter). However, an implementation that
> supports "foo-windows" could implement only that, or both &q= uot;foo-linux"
> and "foo-windows". The specification for "foo-windows&q= uot; could indicate
> that when both are supported, the first one listed by the server (or i= n
> other cases, by the client) is used.
>
> Allowing for such an extension-defined special case would allow a Linu= x
> server to advertise extensions [... "foo-linux", ..., "= foo-windows",
> ...], preferring "foo-linux", but supporting the less approp= riate
> "foo-windows" mechanism as well. Whereas, a Windows server c= ould
> advertise [... "foo-windows", ..., "foo-linux", ..= .], preferring
> "foo-windows", but supporting the less appropriate "foo= -linux" mechanism
> as well.
>
> Does this work?
>
> If there are no objections, I'll upload a -11 draft version with t= his
> new wording.
>
>
>
> On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller
> <linuxwolf+ietf@outer-planes.net
> <mailto:linuxwo= lf+ietf@outer-planes.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Reviewer: Matthew Miller
>=C2=A0 =C2=A0 =C2=A0Review result: Ready with Issues
>
>=C2=A0 =C2=A0 =C2=A0I am the assigned Gen-ART reviewer for this draft. = The General Area
>=C2=A0 =C2=A0 =C2=A0Review Team (Gen-ART) reviews all IETF documents be= ing processed
>=C2=A0 =C2=A0 =C2=A0by the IESG for the IETF Chair.=C2=A0 Please treat = these comments just
>=C2=A0 =C2=A0 =C2=A0like any other last call comments.
>
>=C2=A0 =C2=A0 =C2=A0For more information, please see the FAQ at
>
>=C2=A0 =C2=A0 =C2=A0<https://trac.ietf.org/trac/= gen/wiki/GenArtfaq
>=C2=A0 =C2=A0 =C2=A0<https://trac.ietf.org/trac/= gen/wiki/GenArtfaq>>.
>
>=C2=A0 =C2=A0 =C2=A0Document: draft-ietf-curdle-ssh-ext-info-10 >=C2=A0 =C2=A0 =C2=A0Reviewer: Matthew Miller
>=C2=A0 =C2=A0 =C2=A0Review Date: 2017-07-24
>=C2=A0 =C2=A0 =C2=A0IETF LC End Date: 2017-07-30
>=C2=A0 =C2=A0 =C2=A0IESG Telechat date: N/A
>
>=C2=A0 =C2=A0 =C2=A0Summary:
>
>=C2=A0 =C2=A0 =C2=A0This document is ready with an issue.
>
>=C2=A0 =C2=A0 =C2=A0I found this document very coherent and easy to fol= low.
>
>=C2=A0 =C2=A0 =C2=A0Major issues:
>
>=C2=A0 =C2=A0 =C2=A0Minor issues:
>
>=C2=A0 =C2=A0 =C2=A0My only issue borders on nit, but sided with nit as= I can see it
>=C2=A0 =C2=A0 =C2=A0potentially causing confusion for an implementer in= the future.
>
>=C2=A0 =C2=A0 =C2=A0Section 2.5. "Interpretation of Extension Name= s and Values" explicitly
>=C2=A0 =C2=A0 =C2=A0states in the second paragraph a condition where th= e relative order of
>=C2=A0 =C2=A0 =C2=A0extension-names in an EXT_INFO message is irrelevan= t.=C2=A0 However, the rest
>=C2=A0 =C2=A0 =C2=A0of the section seems to imply to me that relative o= rder is not
>=C2=A0 =C2=A0 =C2=A0important;
>=C2=A0 =C2=A0 =C2=A0so to explicitly call out a scenario seems to imply= that relative order
>=C2=A0 =C2=A0 =C2=A0*is* relevant/important, sometimes.=C2=A0 If relati= ve order is expected to be
>=C2=A0 =C2=A0 =C2=A0important most of the time, I think it helpful to e= xplicitly state that
>=C2=A0 =C2=A0 =C2=A0and give a rationale for it.
>
>=C2=A0 =C2=A0 =C2=A0Nits/editorial comments:
>
>=C2=A0 =C2=A0 =C2=A0* RFC 5226 is referenced by this document, but is o= bsoleted by RFC 8126.
>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Curdle mailing list
>=C2=A0 =C2=A0 =C2=A0Curdle@ietf.org <mailto:Curdle@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/curdle
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/ma= ilman/listinfo/curdle>
>
>



--94eb2c0b8698989d6605555b21e8-- From nobody Fri Jul 28 02:18:37 2017 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 1F814126E64; Fri, 28 Jul 2017 02:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 ga2dx80OXdT9; Fri, 28 Jul 2017 02:18:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C42D127136; Fri, 28 Jul 2017 02:18:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLL65322; Fri, 28 Jul 2017 09:18:30 +0000 (GMT) Received: from DGGEMI404-HUB.china.huawei.com (10.3.17.142) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Jul 2017 10:18:28 +0100 Received: from DGGEMI501-MBS.china.huawei.com ([169.254.2.52]) by dggemi404-hub.china.huawei.com ([10.3.17.142]) with mapi id 14.03.0301.000; Fri, 28 Jul 2017 17:18:20 +0800 From: zhangdacheng To: Russ Housley CC: curdle , IESG , IETF SecDir Thread-Topic: =?gb2312?B?W0N1cmRsZV0gtPC4tDogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWN1?= =?gb2312?Q?rdle-cms-eddsa-signatures-06?= Thread-Index: AQHTBJmcnToY9SpHqUWCJHwmpqIR0KJju5nQgAOseQCAAZNBcA== Date: Fri, 28 Jul 2017 09:18:19 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C22420160BF93@dggemi501-mbs.china.huawei.com> References: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com> <879E76B64CF340468BF5E4DE504C22420160BC01@dggemi501-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.597B0166.0120, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.52, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8f00d14e0d2cc21ec37eee1e0b30efff Archived-At: Subject: [Curdle] =?gb2312?b?tPC4tDogILTwuLQ6IFNlY2RpciByZXZpZXcgb2YgZHJh?= =?gb2312?b?ZnQtaWV0Zi1jdXJkbGUtY21zLWVkZHNhLXNpZ25hdHVyZXMtMDY=?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 09:18:35 -0000 R3JlYXQhDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBSdXNzIEhvdXNsZXkgW21haWx0 bzpob3VzbGV5QHZpZ2lsc2VjLmNvbV0gDQq3osvNyrG85DogMjAxN8TqN9TCMjjI1SAxOjE0DQrK 1bz+yMs6IHpoYW5nZGFjaGVuZyA8ZGFjaGVuZy56aGFuZ0BodWF3ZWkuY29tPg0Ks63LzTogY3Vy ZGxlIDxjdXJkbGVAaWV0Zi5vcmc+OyBJRVNHIDxpZXNnQGlldGYub3JnPjsgSUVURiBTZWNEaXIg PHNlY2RpckBpZXRmLm9yZz4NCtb3zOI6IFJlOiBbQ3VyZGxlXSC08Li0OiBTZWNkaXIgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtY3VyZGxlLWNtcy1lZGRzYS1zaWduYXR1cmVzLTA2DQoNCkRhY2hlbmc6 DQoNClRyaW1taW5nIHRoZSBwYXJ0cyB3aGVyZSB3ZSBoYXZlIHJlYWNoZWQgYWdyZWVtZW50Li4u DQoNCj4+IDIuIEluIHRoZSA0dGggcGFyYWdyYXBoIG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z LCAnIHRoZSBzYW1lIHByaXZhdGUga2V5IFNIT1VMRCBOT1QgYmUgdXNlZCB3aXRoIG1vcmUgdGhh biBvbmUgRWREU0Egc2V0IG9mIHBhcmFtZXRlcnMuJyAtPiAnIHRoZSBzYW1lIHByaXZhdGUga2V5 IE1VU1QgTk9UIGJlIHVzZWQgd2l0aCBtb3JlIHRoYW4gb25lIEVkRFNBIHNldCBvZiBwYXJhbWV0 ZXJzLicgU2luY2Ugd2UgYWxyZWFkeSBrbm93IHRoYXQgdGhlIHNhbWUgcHJpdmF0ZSBrZXkgdXNl ZCBmb3IgbXVsdGlwbGUgYWxnb3JpdGhtcyB3aWxsIGNhdXNlIHBvdGVudGlhbCByaXNrcywgd2Ug c2hvdWxkIHVzZSBhIHN0cm9uZ2VyIHdvcmQgaGVyZS4NCj4gDQo+IEkgZG8gbm90IHRoaW5rIHRo YXQgdGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggdXNpbmcgdGhlIHNhbWUgcHJpdmF0ZSBrZXkgd2l0 aCBQdXJlRWREU0EgYW5kIEhhc2hFZERTQS4gIFRoZSBwcnVkZW50IGFkdmljZSBpcyB0byBhdm9p ZCBtaXhpbmcgdGhlIHNhbWUgcHJpdmF0ZSBrZXkgd2l0aCBkaWZmZXJlbnQgcGFyYW1ldGVyLCB0 aHVzIHRoZSBTSE9VTEQgTk9ULiAgSSBwb2ludCBvdXQgdGhhdCBSRkMgODAzMiBnb2VzIGV2ZW4g ZnVydGhlcjoNCj4gDQo+ICAgLi4uIFRodXMsIG9uZSBjYW4gdXNlIHRoZSBzYW1lDQo+ICAga2V5 IHBhaXIgZm9yIEVkMjU1MTksIEVkMjU1MTljdHgsIGFuZCBFZDI1NTE5cGggYW5kIGNvcnJlc3Bv bmRpbmdseQ0KPiAgIHdpdGggRWQ0NDggYW5kIEVkNDQ4cGguDQo+IA0KPiBEYWNoZW5nOiBPaywg SSBzZWUgeW91ciBwb2ludC4gVGhlbiwgSSB0aGluayBpdCB3aWxsIGJlIGdvb2QgdG8gbWFrZSBz b21lIGNsYXJpZmljYXRpb24gaGVyZSBzaW5jZSB0aGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhpcyBw YXJhZ3JhcGggc3Ryb25nbHkgYXJndWVzIHRoYXQgJyBVc2luZyB0aGUgc2FtZSBwcml2YXRlIGtl eSBmb3IgZGlmZmVyZW50IGFsZ29yaXRobXMgaGFzIHRoZSBwb3RlbnRpYWwgb2YgYWxsb3dpbmcg YW4gYXR0YWNrZXIgdG8gZ2V0IGV4dHJhIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwcml2YXRlIGtl eS4nIE1heWJlIHdlIGNhbiBjaGFuZ2UgdGhlIHNlY29uZCBzZW50ZW5jZSB0byBzb21ldGhpbmcg bGlrZSAnIEZvciB0aGlzIHJlYXNvbiwgdGhlIHNhbWUgcHJpdmF0ZSBrZXkgU0hPVUxEIE5PVCBi ZSB1c2VkIHdpdGggbW9yZSB0aGFuIG9uZSBFZERTQSBzZXQgb2YgcGFyYW1ldGVycywgYWx0aG91 Z2ggcGVvcGxlIGJlbGlldmUgdGhhdCBubyBzZWN1cml0eSBpc3N1ZSB3aWxsIGJlIGNhdXNlZCB3 aGVuIHVzaW5nIHRoZSBzYW1lIHByaXZhdGUga2V5IHdpdGggUHVyZUVkRFNBIGFuZCBIYXNoRWRE U0EgW1JGQzgwMzJdLiAnDQoNCkhvdyBhYm91dDoNCg0KVXNpbmcgdGhlIHNhbWUgcHJpdmF0ZSBr ZXkgd2l0aCBkaWZmZXJlbnQgYWxnb3JpdGhtcyBoYXMgdGhlIHBvdGVudGlhbCB0byBsZWFrIGV4 dHJhIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwcml2YXRlIGtleSB0byBhbiBhdHRhY2tlci4gIEZv ciB0aGlzIHJlYXNvbiwgdGhlIHNhbWUgcHJpdmF0ZSBrZXkgU0hPVUxEIE5PVCBiZSB1c2VkIHdp dGggbW9yZSB0aGFuIG9uZSBzZXQgb2YgRWREU0EgcGFyYW1ldGVycywgYWx0aG91Z2ggcGVvcGxl IGJlbGlldmUgdGhhdCB0aGVyZSBhcmUgbm8gc2VjdXJpdHkgY29uY2VybnMgd2hlbiB1c2luZyB0 aGUgc2FtZSBwcml2YXRlIGtleSB3aXRoIFB1cmVFZERTQSBhbmQgSGFzaEVkRFNBIFtFRERTQV0u DQoNClJ1c3MNCg0K From nobody Fri Jul 28 09:05:19 2017 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 A24F2131CE7 for ; Fri, 28 Jul 2017 09:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 sLHyK7kuy9YN for ; Fri, 28 Jul 2017 09:05:09 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 BDCA4131FE4 for ; Fri, 28 Jul 2017 09:05:08 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id u207so64838346ywc.3 for ; Fri, 28 Jul 2017 09:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=/XT1NiuGZE2tfih6Fzg8BsQWYlWwA+rjHRnSy5L+KmY=; b=t3goYSFtkeGOfTnKr+lXWVjZM00ph+Pbr8eR96u4Xf7M+HpNC0clGnZzCuVah/2tPO bjkcWsGnlDczun4J4OoRTZx2dslWltJVa6zcHIauuv6sUIBPCHp30G8GkPkPl7vP56Bm uVOOBnsDv7qTeX9u7xXWf4kTh4apu0nPeM80rrsZHnNtqEydtdYHc1FSuJ8niEZeEacO A/6wlrysr0zDMpmUngweBmqlwTg8zKak56LAsW6GRbbIexihg5CGKEvhLKcqihZm5JbM 0Joy8CCBsNlFPttmVuIwKCcA0A26Wm+UnONOZeQNzSczQFEyucbHdo00p05pbAgT9cbQ xH7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=/XT1NiuGZE2tfih6Fzg8BsQWYlWwA+rjHRnSy5L+KmY=; b=d6B2TucYu5Gr0U62lbS7B/7kT7ja6qRc3XVyHHRItU6qPNmW79LDYHWcEqIAHyFvbd uO1uNOq9YCWZxTwV4p6kum6Wgd2lpnZdqJGvvSBNJRwkzZL+ZIgHau7UAYLXeIRlLFZS vQu99vhLAXcqWmyTyfN+HqQqr5RoBoJ0+9d5cVrJoY0Wuya70Tfhwodrvpf7hZb9SVw+ Yy1Qsv9LrYMvmpStPMXN2qzkoyeUNZf1uorPRYS7pJB0zsmctBzY/4nG2Bb7A36YHBhc wwRbcJn/duc4UOUuUWuEFK1LdPxIYEQSRYfJJ4iuXawrWLsZMgYmr3USVZFZI6R1fznq HyrQ== X-Gm-Message-State: AIVw113CBrQq3/UigGLQsaqBCn1hJybNDgsw5tJHxfPETN5aK2B/Zs6g A6DG+a5z7ys6DHSu X-Received: by 10.129.108.17 with SMTP id h17mr7040897ywc.447.1501257907696; Fri, 28 Jul 2017 09:05:07 -0700 (PDT) Received: from [10.6.23.170] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id u196sm3337355ywf.64.2017.07.28.09.05.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 09:05:07 -0700 (PDT) Sender: Matthew Miller To: denis bider Cc: gen-art@ietf.org, curdle , ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org References: <150093015937.32021.12465797358778837950@ietfa.amsl.com> <1eef6165-9b5b-c354-dffe-5df1e98098fa@outer-planes.net> From: "Matthew A. Miller" Message-ID: <0406a3c8-0400-b0b5-2b09-93bb5078cb0a@outer-planes.net> Date: Fri, 28 Jul 2017 10:05:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aJCcI3oc7MIhLwqvcFkJjimEiMODAcsw1" Archived-At: Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:05:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aJCcI3oc7MIhLwqvcFkJjimEiMODAcsw1 Content-Type: multipart/mixed; boundary="P46VhQpSaqIMfmUxSVWPmgGMJph8nW77i"; protected-headers="v1" From: "Matthew A. Miller" To: denis bider Cc: gen-art@ietf.org, curdle , ietf@ietf.org, draft-ietf-curdle-ssh-ext-info.all@ietf.org Message-ID: <0406a3c8-0400-b0b5-2b09-93bb5078cb0a@outer-planes.net> Subject: Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10 References: <150093015937.32021.12465797358778837950@ietfa.amsl.com> <1eef6165-9b5b-c354-dffe-5df1e98098fa@outer-planes.net> In-Reply-To: --P46VhQpSaqIMfmUxSVWPmgGMJph8nW77i Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello Denis, I had other things I needed to attend to, and could not respond until now. I think this new text is much improved, thank you. I find the guidance for an extension's specification to be more vague than I like, but I'm maybe that's effectively addressed with the IANA extension table's registration requirements. Thanks again, - m&m Matthew A. Miller On 17/07/28 00:52, denis bider wrote: > OK, I have uploaded version -11 with language as follows: >=20 > "An extension MAY dictate, where it is specified, that in order to take= > effect, both parties must include it in their EXT_INFO; or it MAY be > sufficient that only one party includes it; or other rules MAY be > specified. The relative order in which extensions appear in an EXT_INFO= > message MUST be ignored by default; but an extension MAY specify that > the order matters for that extension, in a specific way." >=20 > This seems clearer to me than it was in -10. If you still see room for > improvement, let me know! >=20 >=20 > On Wed, Jul 26, 2017 at 9:09 PM, denis bider > wrote: >=20 > Hello Matthew, >=20 > I'm not sure if I know how to address this better than with the > language so far proposed. >=20 > Perhaps one choice would be to simply remove this paragraph. > However, the reason it was added was because an earlier reviewer > (I'm not sure of the details at this time) raised the question abou= t > whether extension negotiation works like it does for algorithm > lists, such as in e.g. SSH_MSG_KEXINIT. In that case, multiple > algorithms are enumerated by both sides, and only one is chosen tha= t > (1) is enumerated by both sides, and (2) is the first of those to b= e > enumerated by the client. The main purpose of this paragraph has > been to clarify that extension negotiation does not work that way i= n > EXT_INFO. >=20 > What language would you propose? Is there some simple language that= > would do? How about this? >=20 > "An extension may dictate, where it is specified, that in order to > take effect, both parties must include it in its EXT_INFO; or it ma= y > be sufficient that only one party does; or more complex rules may b= e > specified." >=20 >=20 > On Wed, Jul 26, 2017 at 1:28 PM, Matthew A. Miller > > wrote: >=20 > Thanks very much for the response, Denis. >=20 > I think I understand the intent here, but I'm not sure this new= > text is > enough to mitigate some future conflict.=C2=A0 I'm also concern= ed that it > completely ignores the one-party extensions (e.g., an extension= > included > in the EXT_INFO by only the client or the server, but not both)= , and > what the impact is holistically.=C2=A0 Looking at the one-party= > extensions > defined herein, I can't see how their order matters; but does > that mean > the order will never matter? >=20 > In writing this reply, I wondered if it's better for the order > to always > be irrelevant; an implementation might be allowed to hint its > preferred > order in the EXT_INFO, but implementations are still free to do= > whatever > makes sense to them within the bounds of the relevant extension= > definitions.=C2=A0 If an extension ought to take precedence ove= r another, > make it clear in its specification that it SHOULD (or MUST) be = dealt > with before (or after) others. >=20 > Does that make sense? >=20 >=20 > - m&m >=20 > Matthew A. Miller >=20 > On 17/07/25 16:24, denis bider wrote: > > Good catch. I believe this refers to the following paragraph:= > > > > "If an extension requires both the client and the server to > include it > > in order for the extension to take effect, the relative > position of the > > extension-name in each EXT_INFO message is irrelevant." > > > > I have drafted the following new wording: > > > > "Unless a particular extension's specification indicates > differently; > > then, if an extension requires both the client and the server= > to include > > it in order for the extension to take effect; implementers > MUST use a > > default assumption that the relative position of the > extension-name in > > each EXT_INFO message is irrelevant with respect to whether t= he > > extension takes effect." > > > > The purpose of this wording is to: > > > > - Provide a sensible default, which is that in the absence of= > specific > > knowledge, order of extension names does not matter. > > > > - Allow for deviations in special cases where there is > specific knowledge. > > > > For example, extension "foo-linux" could be specified, but > after some > > years of use, it's observed that it works well for its main > purpose, but > > is not ideal for a server on Windows. Therefore, extension > "foo-windows" > > is specified, which works well when the server is Windows, bu= t > not as > > well when it's Linux. > > > > In this case, an implementation that supports "foo-linux" onl= y > would be > > ignorant of anything else, and would use the default rule > (order of > > extension names does not matter). However, an implementation = that > > supports "foo-windows" could implement only that, or both > "foo-linux" > > and "foo-windows". The specification for "foo-windows" could > indicate > > that when both are supported, the first one listed by the > server (or in > > other cases, by the client) is used. > > > > Allowing for such an extension-defined special case would > allow a Linux > > server to advertise extensions [... "foo-linux", ..., > "foo-windows", > > ...], preferring "foo-linux", but supporting the less appropr= iate > > "foo-windows" mechanism as well. Whereas, a Windows server co= uld > > advertise [... "foo-windows", ..., "foo-linux", ...], preferr= ing > > "foo-windows", but supporting the less appropriate "foo-linux= " > mechanism > > as well. > > > > Does this work? > > > > If there are no objections, I'll upload a -11 draft version > with this > > new wording. > > > > > > > > On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller > > > > >> wrote: > > > >=C2=A0 =C2=A0 =C2=A0Reviewer: Matthew Miller > >=C2=A0 =C2=A0 =C2=A0Review result: Ready with Issues > > > >=C2=A0 =C2=A0 =C2=A0I am the assigned Gen-ART reviewer for thi= s draft. The > General Area > >=C2=A0 =C2=A0 =C2=A0Review Team (Gen-ART) reviews all IETF doc= uments being > processed > >=C2=A0 =C2=A0 =C2=A0by the IESG for the IETF Chair.=C2=A0 Plea= se treat these > comments just > >=C2=A0 =C2=A0 =C2=A0like any other last call comments. > > > >=C2=A0 =C2=A0 =C2=A0For more information, please see the FAQ a= t > > > >=C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 >>. > > > >=C2=A0 =C2=A0 =C2=A0Document: draft-ietf-curdle-ssh-ext-info-1= 0 > >=C2=A0 =C2=A0 =C2=A0Reviewer: Matthew Miller > >=C2=A0 =C2=A0 =C2=A0Review Date: 2017-07-24 > >=C2=A0 =C2=A0 =C2=A0IETF LC End Date: 2017-07-30 > >=C2=A0 =C2=A0 =C2=A0IESG Telechat date: N/A > > > >=C2=A0 =C2=A0 =C2=A0Summary: > > > >=C2=A0 =C2=A0 =C2=A0This document is ready with an issue. > > > >=C2=A0 =C2=A0 =C2=A0I found this document very coherent and ea= sy to follow. > > > >=C2=A0 =C2=A0 =C2=A0Major issues: > > > >=C2=A0 =C2=A0 =C2=A0Minor issues: > > > >=C2=A0 =C2=A0 =C2=A0My only issue borders on nit, but sided wi= th nit as I can > see it > >=C2=A0 =C2=A0 =C2=A0potentially causing confusion for an imple= menter in the > future. > > > >=C2=A0 =C2=A0 =C2=A0Section 2.5. "Interpretation of Extension = Names and > Values" explicitly > >=C2=A0 =C2=A0 =C2=A0states in the second paragraph a condition= where the > relative order of > >=C2=A0 =C2=A0 =C2=A0extension-names in an EXT_INFO message is = irrelevant.=C2=A0 > However, the rest > >=C2=A0 =C2=A0 =C2=A0of the section seems to imply to me that r= elative order is not > >=C2=A0 =C2=A0 =C2=A0important; > >=C2=A0 =C2=A0 =C2=A0so to explicitly call out a scenario seems= to imply that > relative order > >=C2=A0 =C2=A0 =C2=A0*is* relevant/important, sometimes.=C2=A0 = If relative order is > expected to be > >=C2=A0 =C2=A0 =C2=A0important most of the time, I think it hel= pful to > explicitly state that > >=C2=A0 =C2=A0 =C2=A0and give a rationale for it. > > > >=C2=A0 =C2=A0 =C2=A0Nits/editorial comments: > > > >=C2=A0 =C2=A0 =C2=A0* RFC 5226 is referenced by this document,= but is > obsoleted by RFC 8126. > > > > > >=C2=A0 =C2=A0 =C2=A0__________________________________________= _____ > >=C2=A0 =C2=A0 =C2=A0Curdle mailing list > >=C2=A0 =C2=A0 =C2=A0Curdle@ietf.org > > > >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/curd= le > > >=C2=A0 =C2=A0 =C2=A0 > > > > > >=20 >=20 >=20 --P46VhQpSaqIMfmUxSVWPmgGMJph8nW77i-- --aJCcI3oc7MIhLwqvcFkJjimEiMODAcsw1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZe2CxAAoJEOz0ck4QngW7efcH/iSZgOSSttcv2DsWZA2dXoU9 n1uhdbWGogTaIu5CMMscw1fvHLuCJid5WrZExJSddQJGI1tgYE9ieOWMzVfavLGp v809lNyCTZKQklLcJDWQLM4VTLi18g8D2RDzb8QXd4/ViAml0HGMzaCaLoMpr1Vr lP5RtFezOKR/M4zR86TwQkGOa921dH0pInQfp5evRbN/FOoYwWA2UZDKnJk+sYaa uPcXLwg+9c60vmd8nTI5lM/w0WtjgSGiyfdx4h1sQN43zO/SCEOycYGb3PfX7rSP tms+eRO6eMRwqieKs8y49jVfcQKWih1KcJVKSG9RQSObuYUyvMPtFMdykH5c00Q= =Yk5d -----END PGP SIGNATURE----- --aJCcI3oc7MIhLwqvcFkJjimEiMODAcsw1-- From nobody Sun Jul 30 07:38:05 2017 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 0258B131C2B; Sun, 30 Jul 2017 07:37:56 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150142547596.17769.2342902440380875523@ietfa.amsl.com> Date: Sun, 30 Jul 2017 07:37:56 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-sha2-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 30 Jul 2017 14:37:56 -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 : Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) Author : Mark D. Baushke Filename : draft-ietf-curdle-ssh-kex-sha2-09.txt Pages : 15 Date : 2017-07-30 Abstract: This document is intended to update the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. This document updates RFC 4250. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-09 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-kex-sha2-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-kex-sha2-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 30 09:08:08 2017 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 BE793129417 for ; Sun, 30 Jul 2017 09:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 ufH3tIjWCBll for ; Sun, 30 Jul 2017 09:08:04 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0100.outbound.protection.outlook.com [104.47.34.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34D812940A for ; Sun, 30 Jul 2017 09:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NFG76UU5JoqDQkEQAxUmMprYXFTMmEE3S56xgxxbWsg=; b=HpaW4w5mQLaQd4eZ+fQ+NHKEGcVOBKEg4LSsZBESPexaN+Su1k1wSht/hHxXIQZT3CMxGURwg0t04bRqnfZrdO8tZQ0R7OGZ4fmhwT3tIhJjtUajYrJfB+yf19RDslVlZbo63iXaVL8FLm2EJI0TIZl7+0eP49aJSYAC8oLEuc0= Received: from BY1PR0501CA0017.namprd05.prod.outlook.com (10.162.139.27) by CO2PR05MB699.namprd05.prod.outlook.com (10.141.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Sun, 30 Jul 2017 16:08:03 +0000 Received: from BY2NAM05FT057.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::207) by BY1PR0501CA0017.outlook.office365.com (2a01:111:e400:4821::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10 via Frontend Transport; Sun, 30 Jul 2017 16:08:03 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT057.mail.protection.outlook.com (10.152.100.194) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1304.16 via Frontend Transport; Sun, 30 Jul 2017 16:08:02 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 30 Jul 2017 09:07:54 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v6UG7sUS000501; Sun, 30 Jul 2017 09:07:54 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 7A81511446; Sun, 30 Jul 2017 09:07:53 -0700 (PDT) To: CC: Eric Rescorla In-Reply-To: <150142547596.17769.2342902440380875523@ietfa.amsl.com> References: <150142547596.17769.2342902440380875523@ietfa.amsl.com> Comments: In-reply-to: message dated "Sun, 30 Jul 2017 07:37:56 -0700." From: "Mark D. Baushke" Date: Sun, 30 Jul 2017 09:07:53 -0700 Message-ID: <50122.1501430873@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain 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)(6009001)(39450400003)(39400400002)(39410400002)(39860400002)(39850400002)(39840400002)(2980300002)(199003)(189002)(626005)(69596002)(68736007)(6392003)(110136004)(38730400002)(7696004)(189998001)(53936002)(6306002)(55016002)(97876018)(4743002)(229853002)(97736004)(50466002)(48376002)(5660300001)(54356999)(7126002)(2810700001)(50986999)(105596002)(966005)(106466001)(356003)(76506005)(4326008)(230783001)(8936002)(117636001)(5003940100001)(8676002)(81156014)(478600001)(76176999)(86362001)(6916009)(2906002)(47776003)(6266002)(7846003)(6246003)(2351001)(2950100002)(305945005)(53416004)(81166006)(77096006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB699; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT057; 1:4XY/PWtNp9IIwsC1feJqF87kJC806PnpLPOKd2KfJSUew37B/sjEHWRuO82887N/YJOxSeexrYVmgM+plnwc5z0/UOYFwRVEVxdN2aXsziWyEmHkEByjLXxt6szIo0TRE3kocdIADNQXCogD3LzKICiyQZpbwtCZElDSHNLKwTc6kH5sQw/XmKkrJ0bVwkBFT5JQMV5p9Kw7f792yMqg/kN/93NK3g5ykyR+xTdhKdW2ku8K8vnRb85wkBUzkjX2+v7RhCZ2bzzEZa9NmtdzbxkLtnQ44XC5OX7o7nDMgFmABP6Y8Nq6erPwx4DwSEfBC9qCd0IcEtw1rrLdMQeU5jmTcg2vKNTgJEbkH3VGRrmmKg/AmUyYLJ5qtiRSIFd0cUPj3lnL2HsTjwVH+WGfMUYMVd7Bjr3a/aWrB/oFan8fPmc9l36PeTmHnyKprZmMSZFvLE4pPnjdcnJnJWCH9cMarTVmvuQW2SSQZ3fGLJZ81JdadJaW9OncfO/K1K6mueWL5Pr1NICXlTDiibBCRQPGQs2scRxbvZSxY1sMVhu/lqpo+GIoBYqe36aXVocSt05WQYO477x1yjtm8DhiBzijcrQFECzSO79KP7Ogtk3eDYFkLKg+bcQ3cT0ik3rm+DdP3nt4jXVlB6Oy1qtTTfsBKl3vg5BXQNa8WjZIK3rlJpoJx5G+i4jfLUwSQWJjhgn0SRQip8nu/72h9m24PQyqMKpRyQhhwOtNF3sotNhdaL9wSAvr2DT3+I+53UZBabdpeZIFLH6VCOUIhl3JqBruEDgbewxzG9u3hreWnbaSZhbYqcvHZOkhazkY55jXqoLztgdcRDnA0elABiTKHQ== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 443a5be0-9165-4caa-ca44-08d4d7652815 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB699; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB699; 3:X64RtFHcLJj6S8cbcq6367oQg4biCmkWZWo+Ms+LsHCBUkFtB/V35pbuwzRRO6cMr9vpj0iNutvrGtY05GTNG23lnkwkWHY8Q3y4vKgLFRndUlenFTqjTm5VMuUc9K9rutb2BkWjPiGrRj6OuQuWszKT70+v4RU0ZnkA0W2y2AJXFtN9LXIWbrhFVUioP+pBbrbjo1DQxqn3KAFwSSa3UBALMC4rfYnKIp5G5kHoRzRo96D2kU48d9+5DiJAZrhbHH9iy9V7iCbCcMU1WRY02Dy0WeqcSRMfInR9UTS26bIEHRIvYVJDIyOjoAJpuvhKHv3QxjvaLe10oV8xZzjGoBprnNy4BI8LiPmru/95Yxxd2jdTvZW2WpMHHWvDYE/ecmbQ//eAzLd239btNgoRDEYqQGMrS81CNCEzYTbQkpZkyGmeRRMtalDPEq/N/l6K99G1Sg4/yJJmpC3yWssccf6LKPY+G0Ut47WYcHk2uct+i97JQnTnYqKitiXH8/xiPMR/ZuIaMcz5Mb8febB5EmD6UtAS99Fd//eEi1D0BeW8YhMwVnMTlcpun3ZanZbjUHGw+91JaZCus4Y1zBV8/M23bbo4DwAfTTNuR4Sc944G+05N+kPiaW4XVm3cjfYCDDLzbds6J14iYKsdZtNpNMgCvT0oH3ZfBPsv/412PglwnpWyxq2NH4DpHCHmPLbxwOqPz5UIvFViHbwRbkB9xLACypi4PvqPaaLW/nfFrwMk8f1JIWX1rtH9g6zpf3ryvMy3wni8/5hhPpCHQh2hGOhsyuJge492LurPCTb6kaiEaiuGKU1i8Zh4ZE+N54eHD+rRyWwMiQH43Z0rGT6dJCLJvrR/fqUhGvdxdCQTKiUb5rL3MwtdjkRXerF7wpoIUUYIJhpq0ZxcR5X71jLKGOObMFygXmTbwniA6ZbUDLa9WpobTQ6AiuxgUVHZqWVL X-MS-TrafficTypeDiagnostic: CO2PR05MB699: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB699; 25:NJYjBCeFgrhwH68MtrVvxZVwh0jSlQz/dyQqlRv5XxdkLhce0K1/dfN6VsGVtlL8jM9TW7EyGNOp2BBHC31zJq/Ojgc69q7mW2AkRctKg07oi9QANEl9naBSk/dpLUUgwsRRnqvilNJ1Wgexu3sUfqOjVoFyr8fiQ0LHXF/iAC3RZfxaavFVR2oeIO+T+bRYuhJIOd0lTKKCZHfOZEhjiiZ4UMk+pCBeKOAwEXI+iw2yCMNU29/SC0KiD/KIn9neHzQAgBoKFYKITCvXT6WfrBXwbn2eetI+IHujqqM1+HNnojWPqLSBiKzK//OHpYsqLyfXEb0lw+LRclSellDSOfjcKu/bT4sVVaOgl3yHoCL1TJP9LcVLotqpYskkDqDEkQT7WycJc8IzTS8Yrt5MVeh8qS87PrwOCTA6EjFrrsjGEKGh56KEmHFwgwi70iAXNsj5Wbvb23F9yboPwz36eonK82jqMRyVbwd4NN1upRpoq/7n4pJhWR5C5vnugXdzc0U9pp83rau3VxMLPOUbd5N1EFlW6XdYEArh80X6M+CbyvJSIYpn2hhJxT6vR7L/RkvMX3pmoZyPZ4rFAA5Z2MKmobbPf/UbaNXRSiqA3KJfLO7n5tRqI5eTUFGf+XsTVywh8ABLUpj/tu9CKoSyJx+YZhl9u+BE3ZWpRqTKbl/rUPV4JjqbaK0oF3BU5pHGQyVhifb3AeMaGdwMiylu8nat9HPP8m+vkKW5kuKb9N07016z+ye4L0Eemg8meM533lQ8KuTBLcwXIqcgxfcK3jHXtt9a352ZzrlEDNhT0fjs1RpXR8QYrxMMQYdI9XGcJMRq+b02zB8i/T1/3Ybf20vYR6a+Nr+nY01XfDxjOynmYkipuWIMUoIP4fsts3m6IR5OYMwtwGRkq8QS3rTQJZNQHTOpSnveeoR3KPfKnjQ= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB699; 31:05oj/aUXdfsKwlLmtFgZncEB/g6csrmn77wDyTcF3mCWpXk0fpaocK2xV6KJEx4a1vXRfGR9LEJtggHGFp3zViLCx/mch31jcdhi9nfbIJ5mwOI+iqH6TuK82XWqyuOnA5s8QhcxeMUXZ5O76cF1qf3D3QQWcHdCJJuvnrdVzaOqAQxuNCk9zMDr+NFsnqM4Ps31f+W+nEza/zMTdHYElldEi/8z0W7zrSo0J80JNKLHGK8a8kuIR7EX4J4XQPa02wZUrRKEM+sRWdAl1eXBKVyT07fohNyv8GDKcXDOsDyKAs1OxsMdECrjU90U/CfjkRws+yliPKiFSG7fLIKQIfIadN/W5/oWIXFitcDdQ0LDqKVw9w3pSs1nCLJdtuC8o9xDau2J2Dza+hAYCuWWGXC0COTIOsuLX+TAWRmTvxGUB3JDlTjCDoD7OqlzlnZECKuJlw2pn9qjk2b0vGZ0HS8g5hoHCvIzKPBriFCya1D5jMKtJanqlEVUzuTU3amgTW1/fA62o1zbcXDVlvEAcW5KQcLxaVTRF+vBj70fSQwBdqAW806i6ayANGC4O2but4ZIxKfUyzPra6QsViimzCGdqzfCRsj6V/tPqzLR07uXhctFUq4EXKhdz8eooWmNRX8O3/PhEH+fgz2Rp708jzw3f1IaNuO4mZaUxBJ2xO5gTY+DE7m/an/zUT4843+j3BU+rXX+C8Dp18HePsH9CA== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB699; 20:KeYCESItEe/NqNC61IIi9Czy4EwxUXL2SUF37AsV7NwTrf26aP9R58ommVq/Tf/8VzEg2/2c8eOdMUT7KZ43+HUyTrwC/KV2psxzLt2Nod7NxbkwyNgV/4Xdn/qK9c8s/vM+2b44YJgg9Q2ubEFBoiimuTi6k2jeTl9VPqyCcK0zZIcmMGubVc/qRzQuQDR/SffWE1+98Ag+8PPQjfRDa/7AJnRnkGdeERf4ZgyEHpfAuw/S8+3e88vK/NLOOoOZbf5KjsKZWvbYR+cQQByZrfb4STPZNAn/n1SkuZmjbcXmbwfu9O+2K2IiwNstVeYuHhAJ0lL9oEdm33gOVtsHOErIgGGa2TNVHy9pXfyvcJ84FgUeMDXT0TxXS/+WoKa/omkStis24pNw5Rl0xwukcjwhOalbwMRRJgNfsNkEyvhWwvJhJC0PbSij7yRwK5b7wO5bYyajS8g8LnX+mkHgmb+Hkw2rRXq/kLMvarEIP2SMCTrHlyILf+/o7Ruz0Ohk X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13016025)(5005006)(8121501046)(13018025)(93006095)(93003095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB699; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB699; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB699; 4:NfQSDPKK3mNuk9PZKpP8JJNzn1MGU0i4AdIpmBH8fqZ?= =?us-ascii?Q?/2wP6LbK5cY6k9eD/jssW4BxRRgxx9MrnXG1KCZ7z+79x2C+21IISBeUUQeD?= =?us-ascii?Q?8Ln7n4vJw6BA2Vw9rQfNRLBHCUIDGoY9D+euQ2ja3tA6aOs2Yq41k/n87lf6?= =?us-ascii?Q?+lhXVLwjIYJfFxy3OtBJ5s6kPPsL+1qzTBptFrFvqNCWyb8REeIMetRggcI2?= =?us-ascii?Q?LOY6c1Vq5LC3vYEKZsFPbtpKXRNDLhOg8hKjrtAaKxOM60YwUR4lPCUOW0Lt?= =?us-ascii?Q?DL9Fn3AiyXSxLa5bMV0nTKoZVCTlsbS7ikcZA4Wf+owIfsv/aDofeMM+Q/W8?= =?us-ascii?Q?XJa2NnXQoFLSPcKI2h8Vxx/zBWIV9fgn3S603Nyt975Czm1ExrmryYIaOtDm?= =?us-ascii?Q?eCDlEM7UebvPFI2ng1vl7imubHMuRNftGnK4XMtaQ5QlXJDOR3eK+RzrRZPT?= =?us-ascii?Q?UJQ5DhIlWY9Jh1KweHeJ1t4r/QpP7uVaRVljmQQFSuvV1zWxPlkxRQLkn+yZ?= =?us-ascii?Q?r4ZbhdlFAQ3o6DTMsXGmI75OxrBwVg4yN80kWTIWnibS08i5OaazC3BIJfsf?= =?us-ascii?Q?h2+38cwQb3Sw82GVpjUhtUj5LqLUAPsBT1Z5M20ltbRr9K+69aeSjM2i2n7J?= =?us-ascii?Q?QUOgBvoy5EYWuk97VZi1ysFPCOAJ2/zx+nffb8czuO/PZeck8WuyABNG9eDZ?= =?us-ascii?Q?w9rzcNxsE0MfTU3d224FRHbnBJkKK6eKroR8ByoSYBTBSIUWvBFXjta5oi8b?= =?us-ascii?Q?HB3BEPj9KPFejIqqh2TLCsAm49Jdrifi2P2lyzjhF5f4YkoeoJkVyIA1Lu2t?= =?us-ascii?Q?7aEKNstlb0z9UtgCqYQxi5YTJn8mW7Kow3Qp4XvDD9ExswPM1MTTtbFMRnWE?= =?us-ascii?Q?EpDAL+m29NqfrGNLX3f1QHy8TzvbA6zVJhEPZKW9eud8foy+oy8TFbDFNPSr?= =?us-ascii?Q?FaW5uSMldXMNT3QQbNSLNW34EGwZKHjolSS4vOmXLbHHwj3fUN6cdJvxl6YJ?= =?us-ascii?Q?K0tg4FQUjIpTK5pHHPNUygB9Haw1ijwl+OjdYLcDuL0euoUcR1RiO3MRgyPM?= =?us-ascii?Q?xpFtfA7O5Q/6dbv9cBkt8iePrhimno8awSjDyEubMJ6n2arYu4JjYXc4G16A?= =?us-ascii?Q?nbMPM2996QnSy8QiqXnBURJkMXwIC72D5PQmAJnKGGaJv28tJfKyRMIJj1Yo?= =?us-ascii?Q?1T6QT4VYWexZ1OT6McUP5QkKz7Lq3fDj5LicZx/PsHcyHOErEO6m19I8BT61?= =?us-ascii?Q?eaQJ1PgEO7PvKkso=3D?= X-Forefront-PRVS: 0384275935 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB699; 23:l66Y9FBfofHt43hRk6dKeh3X56VHU70OEXX/EETJ0U?= =?us-ascii?Q?tWgEPS5jRcaFHKmXEL1O5ke8fbaYdyIRaJV6LihXO70GH4z3sSEaZkKUring?= =?us-ascii?Q?yds72i77nYUnvQITXxMiedMSlW3BHuEeUUzs/31Y/4/Aq4kCe0UyU06zQVsn?= =?us-ascii?Q?LkkYX/EZ8OKWp2fVuk+4R0NLOxberapDHaai7EDuVeBBcJJeSBOip1Popghu?= =?us-ascii?Q?OnU+D7+tHefMi3ubfXrmiFx+Ux/3IQHhxZcA4CAgWUqFxucl0cR1tdVLpX1d?= =?us-ascii?Q?N3MvlQnEHRL5ZFCy0Byql2aggCZs6VIHaQoEltjEfUDTIEY1qlwoTgPVmwNE?= =?us-ascii?Q?XED2ulXnXbmM6a1hOLH+0HlQdz1K3K7VFNI/30haNk+7gfOivoJep0K72Qvz?= =?us-ascii?Q?zpaT/SEdA/8OY4o9TheWh6N2JZBp48d1NS0ZUq0SJ8gZTTem2XnFNHUu30Zg?= =?us-ascii?Q?qhh8M6U15pg0n4gp/EblXyaPxObKzNeDdzJZKeL4Bqq1N9FUfTUN9K53QVDE?= =?us-ascii?Q?VmpDQgq3h1ZYUZ4RdtR1Ve9hk6bTknS7MqLiIgC6F/cSVIwoITAiaYTeXDVC?= =?us-ascii?Q?yqizayk2vHBmrRij6pNzUqnj3o3Euy8Bwh3z3w0gUM0d+dIhxVnpY+Qb+G8R?= =?us-ascii?Q?t/3SbSC/dissa2jSxtZLSgbsmIMkX3qGPV+mwGI4nZtZygUBxescETVAqlKF?= =?us-ascii?Q?ZKwNei8yrwE4s4RnyXmP4nIEAEKeDRjb5UNT12GcoFxg1yYe2Ys1c79lB/Zu?= =?us-ascii?Q?+/Y4aqtASlv1q7kJgtkPPzHiE2w2Cjq1152yQe5Zjlm5CvSo6o1MoXCgqLFW?= =?us-ascii?Q?y3n2KxCItxv7ZtnhWkN/YKFRAXQlFpSV2MSRgilVsvtKva2W6W7zDGcunfdF?= =?us-ascii?Q?Dmcp7wC1sx84XTIk5Id+LF3TQC5Ykl753wLefHyrFbAEMBtc6pl6WVadSfmo?= =?us-ascii?Q?myiRohJm7qHQ/peZ8dJOoyYFvtBDgStQb4Trlv8hgRg4Bu7ssr5bKL7psDmk?= =?us-ascii?Q?LsGP5GK1oyu7OrC9lnEkBoU+QSTVXaAqXHTjP8vnDTcZJt5ycoieH7HwoYNU?= =?us-ascii?Q?KHb3uMgcccO1SC9ZqncBfIR+L9Tl3psnKpy/QY+wsF8v5AgtBfbnz0MIURKK?= =?us-ascii?Q?J0ePqUNwtr/EHP7Z9SbDtSKH1/XkVD0B28sfW6Q4d2JmS2ZajhnpYZ6mnNYz?= =?us-ascii?Q?ZYGxC7uOmHP43Hr04cbuSG077gS96o8iERAQPMVBFw7DHR76hYRsIHHEjaAt?= =?us-ascii?Q?AHH0SVSNyrGk2czlwvzk9wlEhD0rt4JePcwQZ5bum2cV9MCSUWZg0qz7YChC?= =?us-ascii?Q?358f+spnkoxA0aqF9tTvGTyF+3fvzAzKeAH69gh23p0DWpWO6pP0jFnWsB8r?= =?us-ascii?Q?tZ6XNufMjk1vF4hAP8SKWvhUeI/Yj1dvE2u21Ws7SpJz423tVWvMHsSLzits?= =?us-ascii?Q?guCjREBQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB699; 6:zZzhcPFJFKO/6vpgz7NA8jn2Q+0q8HYAVupLrWg0CO1?= =?us-ascii?Q?G5+o+Jmk3Bp9jjO0Gd564NG5jeg+TKJLkd6f/LFUH6Ogx8gWoF2OVnjw4SR3?= =?us-ascii?Q?ECWnaU+AMLlPN5bvvQp1kPk23lseZwgOawLcaBCYWP4CXNc6lB8yyXX9B/IW?= =?us-ascii?Q?R7vbW6aCk1sSDLV2bNskM1OJwPpgwYkPwhqChB+AyS0dWjnIWkWBhAGqm7CE?= =?us-ascii?Q?P+q7oR7+fKt7tP5beazmV2EXfgoaWtGTsxWk559N3YM9E8eOcOlPt1zKnjoZ?= =?us-ascii?Q?x0kD2yTPdIIzocxhydRj575mlMkr5TgHgPuDB+T2dM90vtXPNYGj8sMzgW5v?= =?us-ascii?Q?olEoLIqjLH+9EYS3exBZ7pU5qax3hIILSafYzT4JjFJrC0j6E81nHr9jMd7y?= =?us-ascii?Q?E6IlMZg/gCVzGTmuAQiABxe7qvRnieqjJixC7LR+5wK44ryjFUCmt+URUQEy?= =?us-ascii?Q?znBYQJOCOXE8zwZLJ3NcUMr3s9Nf2qX7+3OqIBX1a67BJmV+1J3PSdTNrKpp?= =?us-ascii?Q?0tvY1xx3d02p32I5JPlpuYG+ahqXazBexpDWWxspcOKYm4g+0hMlao3671U7?= =?us-ascii?Q?8wXoeMIG641C4RrwWrNxbifnGgR4h06Rmfqs+1uk+DmrXVeh42UT/mqcSss3?= =?us-ascii?Q?B+YQfejUREWkNXBGptGye+tLkzJ2A79b+JLX7D1zV9eGTSMP+6MVODWl1dFM?= =?us-ascii?Q?dSLbqTQtlIBr3RrG4bcZ/jNKrMFFfHfogglOkXszniCOK+p7+Iz62+LnY0ig?= =?us-ascii?Q?AXILXNwj3k2uYQrIkCf/J9rUNByB+AzMMKDH28k3BKTrLemYULnRDe2YFxLy?= =?us-ascii?Q?Vfq3ZRH5EO7dL2MC0EYFuVrakv0Yndb+t+jUgBJH5rvv4GcP4/z9wbhR6dqT?= =?us-ascii?Q?DrKE1pzEdvnMX1hj2vb6hdHTojibthpHJlULdBbu3Ph6CU00HLWympz3VrO/?= =?us-ascii?Q?79Px3Bj0DOpuPFJKsVOoCGRZv02dg0/OugQVWjIOiUAyNEUJ48oAyVW105U5?= =?us-ascii?Q?4WmvkAGj5mfZnPrt8mBhE?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB699; 5:QqWdK6ZjrAP6usIwvt7WJyN1HUN0Yqs2Vk4X5ttKQrMpUuDoL6VhCmpZxVPaOvTGCdI0tVFMkWNT0C2RaTLv7axJc1ZNQ3xBreVWi6YXk8NbdS0Zg4zY3ME4e5g5NWiC9ZEt/BZIYaVgkWkUp1Pti92wUoQRe8oaqRhWrF3y1Bn4aqenAOmsBPxXTH2ir16ipPqa8qr2q7ImmAYvQVI3600cUgtw6M9EuA0uKq/D22f8G2bZkV0lipUZj4BxyXJhk6PbkdvkurQ2QGramKtBOqi/yz0zwO7LK/5b+mrbsIgPaRyOPnuArDo9bTLIRlWlmL3qfIfk9VPK5QAMVGvNnNU+bJiVrgv1yZyig2ZUkevCf+k05rj0YOULysvtcIKSkkNccmjCIH4IbSYNBgOA8TFWWvANCvIuo/RLc43Y/LKve+HUu1ldBhYu0HS+LR5z9pIDsFUTcmSfHu0WQdn+saf5ylPQwPV3dyZClMULGytZZRW+6zRIuvbhATBbu5pq; 24:7uFhziC8+Tptia21KtIPJcnVriLVn1Q6Uv0Cu62crUIbC5csnQCGLMdJaBLctVR5Twp4FShJD/p/RYRm2GehDEDDRFn944o+y9BYJio7iRw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB699; 7:OIrmtfYSr7KoAjTj1pj6QBMyjaFVGIH/6bAFxOVcLhvBGISavHa1xqvjUkQbcWzIlOSCGc1DSrR812A7k7sbs19AuG+bRDpkuyUoZz/Jl3F9bV7zLcYWELqmaVJsFP6o7em8G2Dn2moQ1PseqtTJdWLFC6t7yAilNKNIv61daYHx/1aGrNoYFibOAEK1BCBqxuyNTTkQOipcJMTCEho2qHF0Wlzlo/nE6JMp1lm3XbQ6z99q8gtCTyMK+9lET68xsLs5sQXWiJRz+YEqnGpQ8C8FAfCaMEzLS/tXYaFL7bvRlEZSnht/mv8qpOD7e2QbW4rYmOncj36nBlIk0hLLe93ucas68XFeyMBZ4spWFE5Re0j2jxoYqu+sfJu0fqGDf/4FS6emsmsZzpTzt2I46qB3Pn9qdAfagnUwzmpV3OcYLwbSUCF/zJ2Yl01L2WH8PP/WTNqzRJ7CR3qgwVBLNHtQ2NgjrCmWxdOEK4F//XxvXQ+lzhSXsxvMkgzED0kYdoC+7LDG0DO1QrOAeJOJogPH66liodOKHUdd+UNaVc4eSneQvxVFq+pG1TMLCbGyVSlC3y3INE71nX71lfjVSI8wP1lhxWaOX9dWGRcLFvlJ0TSbnbVV7P38df6rA66FhrskY6BA/jdGEg7AaLFUNvjOxKNTMXKUu3DXoDkvy1NakWAvFUO9FRGjTFMOwiZOC9dHUN0yxdn8PeuSlShDZO1nsbVghtaqDglVyi/lPOCKqIKtcoMqglIspXABLj5NAb4HyOOhK2I6E+vO8JYgR562SL2IccZzvzK3i5ROOCM= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2017 16:08:02.9955 (UTC) 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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB699 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-sha2-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 30 Jul 2017 16:08:07 -0000 Hi, > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-09 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-kex-sha2-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-kex-sha2-09 I have tried to incorporate the feedback provided at IETF 99 into this draft. Hearing no feedback on my suggested changes, I have published a new revision. Please let me know if there are any additional changes needed. Thank you, -- Mark From nobody Sun Jul 30 10:49:04 2017 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 C8541131C90; Sun, 30 Jul 2017 10:49:02 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150143694277.17769.2974901089450125620@ietfa.amsl.com> Date: Sun, 30 Jul 2017 10:49:02 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-04.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 30 Jul 2017 17:49:03 -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 : Deprecate 3DES and RC4 in Kerberos Authors : Benjamin Kaduk Michiko Short Filename : draft-ietf-curdle-des-des-des-die-die-die-04.txt Pages : 9 Date : 2017-07-30 Abstract: The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. Accordingly, RFC 4757 is moved to Obsolete status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-04 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 Sun Jul 30 10:50:05 2017 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 027CA131C9C for ; Sun, 30 Jul 2017 10:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 otQzrebx-ijO for ; Sun, 30 Jul 2017 10:50:03 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 1E33F131C97 for ; Sun, 30 Jul 2017 10:50:03 -0700 (PDT) X-AuditID: 1209190e-369ff70000001a39-d6-597e1c491ab9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id C4.F6.06713.94C1E795; Sun, 30 Jul 2017 13:50:02 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v6UHo0hh014497 for ; Sun, 30 Jul 2017 13:50:01 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6UHnvjg027466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 30 Jul 2017 13:49:59 -0400 Date: Sun, 30 Jul 2017 12:49:57 -0500 From: Benjamin Kaduk To: curdle@ietf.org Message-ID: <20170730174957.GN58771@kduck.kaduk.org> References: <150143694277.17769.2974901089450125620@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150143694277.17769.2974901089450125620@ietfa.amsl.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUixG6nouslUxdpcNDPYuvCWcwOjB5Llvxk CmCM4rJJSc3JLEst0rdL4Mo41zOPvWACf8WmvWwNjB+4uxg5OSQETCQOb+5n6mLk4hASWMwk 8XrRS2YI5zijxJpDkxghnNdMEjc2vAQq4+BgEVCV2LG4HqSbTUBFoqH7MjNIWERAWKJngSRI WFggROL1ye8sIDYv0IJNL1ezgdhCAs4Sq380sUHEBSVOznwCVsMsoCVx4x/EdGYBaYnl/zhA wpwCLhJzXs0CKxEVUJaYt28V2wRG/llIumch6Z6F0L2AkXkVo2xKbpVubmJmTnFqsm5xcmJe XmqRrrFebmaJXmpK6SZGUMhxSvLtYJzU4H2IUYCDUYmHV+JYTaQQa2JZcWXuIUZJDiYlUd51 3LWRQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4hb4B5XhTEiurUovyYVLSHCxK4rziGo0RQgLp iSWp2ampBalFMFkZDg4lCd6JUnWRQoJFqempFWmZOSUIaSYOTpDhPEDD/0sC1fAWFyTmFmem Q+RPMSpKifPygDQLgCQySvPgekEpQSJ7f80rRnGgV4R5H4BU8QDTCVz3K6DBTECDJUtBri4u SURISTUw+lYzl/Wuf+4RKyaSHCo3U2Relr/EY89Yw6PC04Iubvd2P/xzQ7uScVbvQUuNXVsK bjgImRb8jItKM637Oue9/gfbmS4H1NPn670rP1ttnPuB8QGTp/2fUykfo98r9hitKDzvKCrO 4XJV+/FczmDVuTmzl82UULsRtn/aH+btqd8z9J7+4TmrxFKckWioxVxUnAgA/6GtZeQCAAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-04.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 30 Jul 2017 17:50:05 -0000 This is just to fix a typo and a couple of nits from Ekr's AD review. -Ben On Sun, Jul 30, 2017 at 10:49:02AM -0700, internet-drafts@ietf.org wrote: > > 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 : Deprecate 3DES and RC4 in Kerberos > Authors : Benjamin Kaduk > Michiko Short > Filename : draft-ietf-curdle-des-des-des-die-die-die-04.txt > Pages : 9 > Date : 2017-07-30 > > Abstract: > The 3DES and RC4 encryption types are steadily weakening in > cryptographic strength, and the deprecation process should be begun > for their use in Kerberos. Accordingly, RFC 4757 is moved to > Obsolete status, as none of the encryption types it specifies should > be used, and RFC 3961 is updated to note the deprecation of the > triple-DES encryption types. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-04 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-04 > > > 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/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Jul 30 22:00:03 2017 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 87B3B131748; Sun, 30 Jul 2017 21:59:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Orit Levin To: Cc: draft-ietf-curdle-ssh-modp-dh-sha2.all@ietf.org, curdle@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150147719452.17668.11130233205318099796@ietfa.amsl.com> Date: Sun, 30 Jul 2017 21:59:54 -0700 Archived-At: Subject: [Curdle] Genart last call review of draft-ietf-curdle-ssh-modp-dh-sha2-07 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 04:59:55 -0000 Reviewer: Orit Levin Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-curdle-ssh-modp-dh-sha2-?? Reviewer: Orit Levin Review Date: 2017-07-30 IETF LC End Date: 2017-07-30 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready. No issue observed. Major issues: Minor issues: Nits/editorial comments: From nobody Mon Jul 31 08:12:16 2017 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 B0B801324BE for ; Mon, 31 Jul 2017 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 XtOhijquaDd4 for ; Mon, 31 Jul 2017 08:12:13 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 714121324C0 for ; Mon, 31 Jul 2017 08:12:04 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6VF4cxA015959 for ; Mon, 31 Jul 2017 16:12:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=6XWCwcYAHBp0pStowsZpitZFi4TLpoYMR+/yj83rpRw=; b=Ux6Tn46jVME37xUFkCDykCrrETB1/gLtowxeRtz6Qap1Mia/d5ERKtAIP3fxoqLFOJvx UGx3QGp96uq0d+og75gWKNooxQGfnezCwFmo9bleg2wMie28vNrpot4uOcKdmn5G9qhl I4H7al28JyZAZ2QJzqW4mfjHjhoP+43dQwW68jKVvLyxQYRS1ckm+f9JaycDiMtG5z+5 X5av3IM63qqzoxQgDkEI5ZsEOqtK4rvWlJPH08vATvkucT8AhDOnfQGWCGiyA9HYpP/A M/r7IMP3j39P9oGkLJ5FqC0nCB+aiLJC7u17CN9NYfwr+NK97zBX00xw0CdiYtNgV5HR iw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2c0hwe9nfs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 31 Jul 2017 16:12:02 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6VFBKuZ002218 for ; Mon, 31 Jul 2017 11:12:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c0npupyc6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 31 Jul 2017 11:12:00 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 31 Jul 2017 11:12:00 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 31 Jul 2017 11:11:59 -0400 From: "Salz, Rich" To: "Salz, Rich" , "curdle@ietf.org" Thread-Topic: Minutes Thread-Index: AQHS/uQSxcnlLN8uzk+HqwdTzOQMZKJYkO8QgBWP6iA= Date: Mon, 31 Jul 2017 15:11:59 +0000 Message-ID: References: <6cf2b3b564504e4a85edde6ccdd10326@usma1ex-dag1mb3.msg.corp.akamai.com> In-Reply-To: <6cf2b3b564504e4a85edde6ccdd10326@usma1ex-dag1mb3.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.207] Content-Type: multipart/alternative; boundary="_000_d6aa4f221146460f9cc4bac631582998usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310258 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310255 Archived-At: Subject: Re: [Curdle] Minutes X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 15:12:15 -0000 --_000_d6aa4f221146460f9cc4bac631582998usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGhpbOKAmXMgbWludXRlcyBoYXZlIGJlZW4gdXBsb2FkZWQuICBUaGFua3MgYWdhaW4hDQoNCg0K LS0NClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNT TCBEZXYgVGVhbQ0KSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KDQpG cm9tOiBTYWx6LCBSaWNoIFttYWlsdG86cnNhbHpAYWthbWFpLmNvbV0NClNlbnQ6IE1vbmRheSwg SnVseSAxNywgMjAxNyA1OjU2IFBNDQpUbzogY3VyZGxlQGlldGYub3JnDQpTdWJqZWN0OiBbQ3Vy ZGxlXSBGVzogTWludXRlcw0KDQpEcmFmdCBtaW51dGVzIGZyb20gUGhpbC4gIFBsZWFzZSBwb3N0 IGFueSBjb3JyZWN0aW9ucyBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgd2Vlay4gIFRoYW5rIHlvdS4N Cg== --_000_d6aa4f221146460f9cc4bac631582998usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5QaGls 4oCZcyBtaW51dGVzIGhhdmUgYmVlbiB1cGxvYWRlZC4mbmJzcDsgVGhhbmtzIGFnYWluITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tLSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW5pb3IgQXJjaGl0 ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBTYWx6LCBSaWNo IFttYWlsdG86cnNhbHpAYWthbWFpLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1 bHkgMTcsIDIwMTcgNTo1NiBQTTxicj4NCjxiPlRvOjwvYj4gY3VyZGxlQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFtDdXJkbGVdIEZXOiBNaW51dGVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EcmFmdCBtaW51dGVz IGZyb20gUGhpbC4mbmJzcDsgUGxlYXNlIHBvc3QgYW55IGNvcnJlY3Rpb25zIGJlZm9yZSB0aGUg ZW5kIG9mIHRoZSB3ZWVrLiZuYnNwOyBUaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_d6aa4f221146460f9cc4bac631582998usma1exdag1mb1msgcorpak_--