From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 16:50:06 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14904 for ; Thu, 3 Jun 2004 16:50:05 -0400 (EDT) Received: (qmail 20423 invoked by uid 605); 3 Jun 2004 20:50:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20025 invoked from network); 3 Jun 2004 20:49:59 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 3 Jun 2004 20:49:59 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09306; Thu, 3 Jun 2004 15:59:14 -0400 (EDT) Message-Id: <200406031959.PAA09306@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-19.txt Date: Thu, 03 Jun 2004 15:59:14 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : T. Ylonen, C. Lonvick Filename : draft-ietf-secsh-connect-19.txt Pages : 22 Date : 2004-6-3 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-19.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-connect-19.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-connect-19.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-3154419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-3154419.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 16:50:18 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14954 for ; Thu, 3 Jun 2004 16:50:17 -0400 (EDT) Received: (qmail 20061 invoked by uid 605); 3 Jun 2004 20:50:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19996 invoked from network); 3 Jun 2004 20:49:56 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 3 Jun 2004 20:49:56 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09348; Thu, 3 Jun 2004 15:59:39 -0400 (EDT) Message-Id: <200406031959.PAA09348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-06.txt Date: Thu, 03 Jun 2004 15:59:39 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : S. Lehtinen, C. Lonvick Filename : draft-ietf-secsh-assignednumbers-06.txt Pages : 12 Date : 2004-6-3 This document defines the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for initialization of the IANA databases referenced in those documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-assignednumbers-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-assignednumbers-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-3154441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-3154441.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 16:50:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14996 for ; Thu, 3 Jun 2004 16:50:28 -0400 (EDT) Received: (qmail 20069 invoked by uid 605); 3 Jun 2004 20:50:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20011 invoked from network); 3 Jun 2004 20:49:58 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 3 Jun 2004 20:49:57 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09173; Thu, 3 Jun 2004 15:58:32 -0400 (EDT) Message-Id: <200406031958.PAA09173@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-21.txt Date: Thu, 03 Jun 2004 15:58:32 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : T. Ylonen, C. Lonvick Filename : draft-ietf-secsh-userauth-21.txt Pages : 16 Date : 2004-6-3 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-userauth-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-3154413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-3154413.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 16:50:46 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15035 for ; Thu, 3 Jun 2004 16:50:46 -0400 (EDT) Received: (qmail 20637 invoked by uid 605); 3 Jun 2004 20:50:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20085 invoked from network); 3 Jun 2004 20:50:00 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 3 Jun 2004 20:50:00 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09364; Thu, 3 Jun 2004 15:59:47 -0400 (EDT) Message-Id: <200406031959.PAA09364@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-18.txt Date: Thu, 03 Jun 2004 15:59:47 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen, C. Lonvick Filename : draft-ietf-secsh-transport-18.txt Pages : 29 Date : 2004-6-3 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-18.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-18.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-3154449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-3154449.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 16:51:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15126 for ; Thu, 3 Jun 2004 16:51:07 -0400 (EDT) Received: (qmail 20674 invoked by uid 605); 3 Jun 2004 20:50:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20068 invoked from network); 3 Jun 2004 20:50:00 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 3 Jun 2004 20:50:00 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09313; Thu, 3 Jun 2004 15:59:26 -0400 (EDT) Message-Id: <200406031959.PAA09313@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-16.txt Date: Thu, 03 Jun 2004 15:59:26 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : T. Ylonen, C. Lonvick Filename : draft-ietf-secsh-architecture-16.txt Pages : 29 Date : 2004-6-3 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-architecture-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-architecture-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-3154430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-3154430.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 18:01:25 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23403 for ; Thu, 3 Jun 2004 18:01:24 -0400 (EDT) Received: (qmail 25604 invoked by uid 605); 3 Jun 2004 22:01:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25575 invoked from network); 3 Jun 2004 22:01:19 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 3 Jun 2004 22:01:19 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i53LnHAl019716; Thu, 3 Jun 2004 14:49:18 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jun 2004 14:49:17 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E70B092651@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Thu, 3 Jun 2004 14:49:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-connect-19.txt Scanning time = 06/03/2004 14:49:16 Engine/Pattern = 7.000-1004/1.899.00 Action taken on message: The attachment draft-ietf-secsh-connect-19.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 18:01:36 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23455 for ; Thu, 3 Jun 2004 18:01:36 -0400 (EDT) Received: (qmail 25652 invoked by uid 605); 3 Jun 2004 22:01:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25602 invoked from network); 3 Jun 2004 22:01:20 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 3 Jun 2004 22:01:20 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i53Lu9Al019985; Thu, 3 Jun 2004 14:56:09 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jun 2004 14:56:09 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E70B092654@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Thu, 3 Jun 2004 14:56:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-transport-18.txt Scanning time = 06/03/2004 14:56:06 Engine/Pattern = 7.000-1004/1.899.00 Action taken on message: The attachment draft-ietf-secsh-transport-18.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 18:01:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23502 for ; Thu, 3 Jun 2004 18:01:46 -0400 (EDT) Received: (qmail 25704 invoked by uid 605); 3 Jun 2004 22:01:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25584 invoked from network); 3 Jun 2004 22:01:20 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 3 Jun 2004 22:01:19 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i53LkvAl019625; Thu, 3 Jun 2004 14:46:58 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jun 2004 14:46:57 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E70B092650@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Thu, 3 Jun 2004 14:46:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-userauth-21.txt Scanning time = 06/03/2004 14:46:49 Engine/Pattern = 7.000-1004/1.899.00 Action taken on message: The attachment draft-ietf-secsh-userauth-21.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 18:02:02 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23547 for ; Thu, 3 Jun 2004 18:02:02 -0400 (EDT) Received: (qmail 25748 invoked by uid 605); 3 Jun 2004 22:01:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25646 invoked from network); 3 Jun 2004 22:01:21 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 3 Jun 2004 22:01:21 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i53LsSAl019929; Thu, 3 Jun 2004 14:54:28 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jun 2004 14:54:28 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E70B092653@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Thu, 3 Jun 2004 14:54:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-assignednumbers-06.txt Scanning time = 06/03/2004 14:54:25 Engine/Pattern = 7.000-1004/1.899.00 Action taken on message: The attachment draft-ietf-secsh-assignednumbers-06.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 18:02:26 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23603 for ; Thu, 3 Jun 2004 18:02:26 -0400 (EDT) Received: (qmail 25919 invoked by uid 605); 3 Jun 2004 22:01:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25623 invoked from network); 3 Jun 2004 22:01:21 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 3 Jun 2004 22:01:21 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i53LpwAl019834; Thu, 3 Jun 2004 14:51:58 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jun 2004 14:51:57 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E70B092652@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Thu, 3 Jun 2004 14:51:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-architecture-16.txt Scanning time = 06/03/2004 14:51:54 Engine/Pattern = 7.000-1004/1.899.00 Action taken on message: The attachment draft-ietf-secsh-architecture-16.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 3 18:18:30 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27030 for ; Thu, 3 Jun 2004 18:18:30 -0400 (EDT) Received: (qmail 12983 invoked by uid 605); 3 Jun 2004 22:18:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12963 invoked from network); 3 Jun 2004 22:18:30 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 3 Jun 2004 22:18:30 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 03 Jun 2004 14:49:47 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i53Lnals014531 for ; Thu, 3 Jun 2004 14:49:36 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA02343 for ; Thu, 3 Jun 2004 14:49:36 -0700 (PDT) Date: Thu, 3 Jun 2004 14:49:36 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-userauth-21.txt In-Reply-To: <200406031958.PAA09173@ietf.org> Message-ID: References: <200406031958.PAA09173@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I submitted the IDs again and it looks like I got things right this time. :-) I have the IDs, xml's, and htmlwdiffs here: http://www.employees.org/~lonvick/secsh-wg/ The first set of htmlwdiffs are here: http://www.employees.org/~lonvick/secsh-wg/may19/ Some of those IDs didn't get posted but the htmlwdiffs have a bunch -o- notes included; mostly IESG suggestions for improvements. The new set of updates are here: http://www.employees.org/~lonvick/secsh-wg/june02/ I'm not really bothering to keep the Assigned Numbers updated yet as the references in that refer to sections within the other core IDs that are changing right now. Mostly, I've updated the references and changed some of the language in some places to appease the IESG members. There are other things that need to be changed from other IESG comments but I would appreciate comments on the changes I've made so far. I want to thank the people who sent me emails volunteering to host these "diff" files. It appears that employees.org is not going away right now. :-) If it starts looking bad again, I'll be in touch. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 4 18:59:38 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25895 for ; Fri, 4 Jun 2004 18:59:37 -0400 (EDT) Received: (qmail 25199 invoked by uid 605); 4 Jun 2004 22:59:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25190 invoked from network); 4 Jun 2004 22:59:36 -0000 Received: from sf.firstpr.com.au (69.59.149.144) by mail.netbsd.org with SMTP; 4 Jun 2004 22:59:36 -0000 Received: from shitei.mindrot.org (shitei.mindrot.org [203.217.30.81]) by sf.firstpr.com.au (Postfix) with ESMTP id 5DAA012AD5A for ; Fri, 4 Jun 2004 15:40:25 -0700 (PDT) Received: by shitei.mindrot.org (Postfix, from userid 1000) id 3B4A827C187; Sat, 5 Jun 2004 08:40:14 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by shitei.mindrot.org (Postfix) with ESMTP id 39E1127D819 for ; Sat, 5 Jun 2004 08:40:14 +1000 (EST) Message-ID: <40BFD735.6000303@mindrot.org> Date: Fri, 04 Jun 2004 11:58:13 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt References: <200406031959.PAA09364@ietf.org> In-Reply-To: <200406031959.PAA09364@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit 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 Secure Shell Working Group of the IETF. > > Title : SSH Transport Layer Protocol > Author(s) : T. Ylonen, C. Lonvick > Filename : draft-ietf-secsh-transport-18.txt > Pages : 29 > Date : 2004-6-3 The new text in Section 4.2 includes: > Since the protocol being defined in this set of documents is version > 2.0, the 'protoversion' MUST be "2.0". Which renders several deployed implementations non-compliant and is contradictory with section 5.1: > Server implementations MAY support a configurable "compatibility" > flag that enables compatibility with old versions. When this flag is > on, the server SHOULD identify its protocol version as "1.99". > Clients using protocol 2.0 MUST be able to identify this as identical > to "2.0". In this mode the server SHOULD NOT send the carriage > return character (ASCII 13) after the version identification string. I suggest that the old text be restored or the validity of offering a protocol version of 1.99 be mentioned in section 4.2. I don't understand why new changes are being made to the drafts again - I was under the impression that they were just about ready for publication. Can someone more familiar with the process please explain what stands in the way of this happening? -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 4 19:40:09 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27536 for ; Fri, 4 Jun 2004 19:40:09 -0400 (EDT) Received: (qmail 2361 invoked by uid 605); 4 Jun 2004 23:40:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2344 invoked from network); 4 Jun 2004 23:40:04 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 4 Jun 2004 23:40:03 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i54NdvcP023726; Fri, 4 Jun 2004 17:39:57 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i54Nduii013597; Fri, 4 Jun 2004 19:39:56 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i54NdunH007425; Fri, 4 Jun 2004 19:39:56 -0400 (EDT) Message-Id: <200406042339.i54NdunH007425@thunk.east.sun.com> From: Bill Sommerfeld To: Damien Miller cc: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt In-Reply-To: Your message of "Fri, 04 Jun 2004 11:58:13 +1000." <40BFD735.6000303@mindrot.org> Reply-to: sommerfeld@east.sun.com Date: Fri, 04 Jun 2004 19:39:56 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I don't understand why new changes are being made to the drafts again > - I was under the impression that they were just about ready for > publication. Can someone more familiar with the process please explain > what stands in the way of this happening? The documents are currently under review by the IESG. Any changes at this point should be primarily driven by comments from the IESG, which can be found in the IETF draft tracker at: https://datatracker.ietf.org/public/pidtracker.cgi Enter "secsh" in the WG acronym field) and hit "SEARCH". Then pick a document, click on DETAIL to see its history. In the Detail Info section, click on "IESG evaluation record" to see IESG comments. > The new text in Section 4.2 includes: > > > Since the protocol being defined in this set of documents is version > > 2.0, the 'protoversion' MUST be "2.0". > > Which renders several deployed implementations non-compliant and > is contradictory with section 5.1: > > > Server implementations MAY support a configurable "compatibility" > > flag that enables compatibility with old versions. When this flag is > > on, the server SHOULD identify its protocol version as "1.99". > > Clients using protocol 2.0 MUST be able to identify this as identical > > to "2.0". In this mode the server SHOULD NOT send the carriage > > return character (ASCII 13) after the version identification string. > > I suggest that the old text be restored or the validity of offering > a protocol version of 1.99 be mentioned in section 4.2. > Chris: can you clarify the intent of this change? It appears to be part of an attempt to respond to the following IESG comments: 2. Section 3.3. This is clearly here to allow servers to interoperate with SSH version 1. However, there is no specification for SSHv1. The WG decided to not document SSHv1, even as an informational RFC. There are many SSHv1 implementations, and at least one very large vendor has no intention of moving to SSHv2. A reference to some kind of SSHv1 specification is needed to provide context. and 4. Page 6, first paragraph. The SHOULD NOT conflicts with the MUST at the bottom of page 4. Suggestion: change the MUST at the bottom of page 4 to SHOULD. (these may be a bit tricky to follow as sections were renumbered in -17) As Damien says, this is creating an internal inconsistancy within the document. I suggest changing the "MUST" to something along the lines of: the 'protoversion' SHOULD be "2.0" unless the compatibility flag described in section 5.1 is enabled. Regarding a stable reference, For those interested, the SSH 1.x protocol. The only known documentation of the 1.x protocol is contained in README files that are shipped along with the source code. In section 5.0, I think we can generate a formal reference along the lines of "The file named RFC within ftp://.../ssh-1.2.x.tar.gz" given a suitably stable URL.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 4 21:11:00 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01260 for ; Fri, 4 Jun 2004 21:10:59 -0400 (EDT) Received: (qmail 14322 invoked by uid 605); 5 Jun 2004 01:10:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14294 invoked from network); 5 Jun 2004 01:10:55 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 5 Jun 2004 01:10:55 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Jun 2004 17:41:54 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i550g4Xl019625; Fri, 4 Jun 2004 17:42:04 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA27491; Fri, 4 Jun 2004 17:42:03 -0700 (PDT) Date: Fri, 4 Jun 2004 17:42:03 -0700 (PDT) From: Chris Lonvick To: Bill Sommerfeld cc: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt In-Reply-To: <200406042339.i54NdunH007425@thunk.east.sun.com> Message-ID: References: <200406042339.i54NdunH007425@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Fri, 4 Jun 2004, Bill Sommerfeld wrote: > > I don't understand why new changes are being made to the drafts again > > - I was under the impression that they were just about ready for > > publication. Can someone more familiar with the process please explain > > what stands in the way of this happening? > > The documents are currently under review by the IESG. > > Any changes at this point should be primarily driven by comments from > the IESG, which can be found in the IETF draft tracker at: > > https://datatracker.ietf.org/public/pidtracker.cgi > > Enter "secsh" in the WG acronym field) and hit "SEARCH". > > Then pick a document, click on DETAIL to see its history. > > In the Detail Info section, click on "IESG evaluation record" to see > IESG comments. > > > The new text in Section 4.2 includes: > > > > > Since the protocol being defined in this set of documents is version > > > 2.0, the 'protoversion' MUST be "2.0". > > > > Which renders several deployed implementations non-compliant and > > is contradictory with section 5.1: > > > > > Server implementations MAY support a configurable "compatibility" > > > flag that enables compatibility with old versions. When this flag is > > > on, the server SHOULD identify its protocol version as "1.99". > > > Clients using protocol 2.0 MUST be able to identify this as identical > > > to "2.0". In this mode the server SHOULD NOT send the carriage > > > return character (ASCII 13) after the version identification string. > > > > I suggest that the old text be restored or the validity of offering > > a protocol version of 1.99 be mentioned in section 4.2. > > > Chris: can you clarify the intent of this change? It appears to be > part of an attempt to respond to the following IESG comments: > > 2. Section 3.3. This is clearly here to allow servers to interoperate with > SSH version 1. However, there is no specification for SSHv1. The WG decided > to not document SSHv1, even as an informational RFC. There are many SSHv1 > implementations, and at least one very large vendor has no intention of > moving to SSHv2. A reference to some kind of SSHv1 specification is needed > to provide context. > > and > > 4. Page 6, first paragraph. The SHOULD NOT conflicts with the MUST at the > bottom of page 4. Suggestion: change the MUST at the bottom of page 4 to > SHOULD. > > (these may be a bit tricky to follow as sections were renumbered in > -17) That's correct. I've also placed it here: http://www.employees.org/~lonvick/secsh-wg/may19/transport-16-18.html > > As Damien says, this is creating an internal inconsistancy within the document. Doh! That wasn't my intent. I was hoping to say that you MUST have "2.0" for _this_ protocol but you MAY have "1.99" for backwards compatibility. > > I suggest changing the "MUST" to something along the lines of: > > the 'protoversion' SHOULD be "2.0" unless the > compatibility flag described in section 5.1 is enabled. I'll work on that. > > Regarding a stable reference, > > For those interested, the SSH 1.x protocol. The only known > documentation of the 1.x protocol is contained in README files that > are shipped along with the source code. > > In section 5.0, I think we can generate a formal reference along the > lines of "The file named RFC within ftp://.../ssh-1.2.x.tar.gz" > given a suitably stable URL.. I'll get that into the Informational References section. All: I really do need feedback on any changes that are made. These changes need to appease the IESG reviewers _AND_ they need to be technically correct. The goal of the IESG in this is to ensure that we produce a quality document that is very clear even to someone reading it for the first time without any background in the subject. This is really required for a Standards Track RFC. They, and ourselves, would also like to get this done fairly quickly as they are creating a backlog - not only for our documents but also for things relying upon SSH such as the NetConf WG documents. Keep those cards 'n letters comin' in. :-) Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 01:58:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10870 for ; Mon, 7 Jun 2004 01:58:12 -0400 (EDT) Received: (qmail 13212 invoked by uid 605); 7 Jun 2004 05:58:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13196 invoked from network); 7 Jun 2004 05:58:08 -0000 Received: from 213-240-201-51.ddns.cablebg.net (HELO master.workstation.localhost) (213.240.201.51) by mail.netbsd.org with SMTP; 7 Jun 2004 05:58:07 -0000 Received: from roumenpetrov.info (localhost [127.0.0.1]) by master.workstation.localhost (8.12.4/8.12.4) with ESMTP id i575XB2G002770 for ; Mon, 7 Jun 2004 08:33:11 +0300 Message-ID: <40C3FE17.3020804@roumenpetrov.info> Date: Mon, 07 Jun 2004 08:33:11 +0300 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: bg, ru, de, en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: last ID-ACTION: drafts... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit - draft-ietf-secsh-architecture-16.txt / Section "Abstract" : "The SSH consists of three major components: The Transport Layer Protocol..." Now last two components ("User Authentication Protocol" and "Connection Protocol") disappear ! Could please check. - draft-ietf-secsh-transport-18.txt In reference "[RFC2459] ... Internet X.509 Public Key Infrastructure Certificate and CRL Profile..." is obsolete. What about to be replaced with "[RFC3280] ..." ? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 09:31:48 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14479 for ; Mon, 7 Jun 2004 09:31:48 -0400 (EDT) Received: (qmail 19297 invoked by uid 605); 7 Jun 2004 13:31:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19288 invoked from network); 7 Jun 2004 13:31:46 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 7 Jun 2004 13:31:46 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2004 06:31:01 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i57DVhXl017799; Mon, 7 Jun 2004 06:31:43 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA11689; Mon, 7 Jun 2004 06:31:43 -0700 (PDT) Date: Mon, 7 Jun 2004 06:31:43 -0700 (PDT) From: Chris Lonvick To: Roumen Petrov cc: ietf-ssh@NetBSD.org Subject: Re: last ID-ACTION: drafts... In-Reply-To: <40C3FE17.3020804@roumenpetrov.info> Message-ID: References: <40C3FE17.3020804@roumenpetrov.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Mon, 7 Jun 2004, Roumen Petrov wrote: > - draft-ietf-secsh-architecture-16.txt / Section "Abstract" : "The SSH > consists of three major components: The Transport Layer Protocol..." > Now last two components ("User Authentication Protocol" and "Connection > Protocol") disappear ! > Could please check. Yikes. I'll restore that. Sorry. > > - draft-ietf-secsh-transport-18.txt > In reference "[RFC2459] ... Internet X.509 Public Key Infrastructure > Certificate and CRL Profile..." is obsolete. > What about to be replaced with "[RFC3280] ..." ? Good catch. I'll update that. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 09:57:09 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16116 for ; Mon, 7 Jun 2004 09:57:08 -0400 (EDT) Received: (qmail 12149 invoked by uid 605); 7 Jun 2004 13:57:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12130 invoked from network); 7 Jun 2004 13:57:03 -0000 Received: from psg.com (147.28.0.62) by mail.netbsd.org with SMTP; 7 Jun 2004 13:57:03 -0000 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BXKNs-000A3P-4l for ietf-ssh@NetBSD.org; Mon, 07 Jun 2004 13:41:52 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+secsh@rt.psg.com RT-Ticket: psg.com #440 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+secsh@rt.psg.com CC: ietf-ssh@NetBSD.org RT-Originator: clonvick@cisco.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #440] IANA - Architecture - Registries In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) MIME-Version: 1.0 Date: Mon, 07 Jun 2004 13:41:52 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Change in Section 8 (IANA Considerations) of version 16 to state that the only _true_ set of instructions to IANA is in AssignedNumbers. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 09:57:15 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16136 for ; Mon, 7 Jun 2004 09:57:15 -0400 (EDT) Received: (qmail 12153 invoked by uid 605); 7 Jun 2004 13:57:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12137 invoked from network); 7 Jun 2004 13:57:04 -0000 Received: from psg.com (147.28.0.62) by mail.netbsd.org with SMTP; 7 Jun 2004 13:57:04 -0000 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BXKNr-000A3H-Ma for ietf-ssh@NetBSD.org; Mon, 07 Jun 2004 13:41:51 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+secsh@rt.psg.com RT-Ticket: psg.com #440 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+secsh@rt.psg.com CC: ietf-ssh@NetBSD.org RT-Originator: clonvick@cisco.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #440] IANA - Architecture - Registries In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) MIME-Version: 1.0 Date: Mon, 07 Jun 2004 13:41:51 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Change in Section 8 (IANA Considerations) of version 16 to state that the only _true_ set of instructions to IANA is in AssignedNumbers. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 09:57:23 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16176 for ; Mon, 7 Jun 2004 09:57:22 -0400 (EDT) Received: (qmail 12159 invoked by uid 605); 7 Jun 2004 13:57:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12114 invoked from network); 7 Jun 2004 13:57:03 -0000 Received: from psg.com (147.28.0.62) by mail.netbsd.org with SMTP; 7 Jun 2004 13:57:03 -0000 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BXKRo-000AdJ-6p for ietf-ssh@NetBSD.org; Mon, 07 Jun 2004 13:45:56 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+secsh@rt.psg.com RT-Ticket: psg.com #441 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+secsh@rt.psg.com CC: ietf-ssh@NetBSD.org RT-Originator: clonvick@cisco.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #441] IESG - Architecture - atsign - additional IESG Response In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) MIME-Version: 1.0 Date: Mon, 07 Jun 2004 13:45:56 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list >I don't understand the comment. >Names of the form "user@host" are used in a number of places (email, login >names in ftp://user@host/ URLs, NAIs for roaming, IM identifiers and more). > >I *think* the purpose of the paragraph > > Names with the at-sign ('@') in them are allocated by the owner of > DNS name after the at-sign (hierarchical allocation in [RFC- > 2343]), otherwise the same restrictions as above. > >is to give local extensibility to protocol parameter identifiers; there >are a number of variants that are commonly suggested for this, and DNS >based naming is one of them. (It's not a particularly good one, though - >DNS names change hands too often to be considered "completely stable", and >we do tend to want stability in parameter naming..... it also gives all >the problems of "X-" headers in enabling wide deployment of >non-interoperable extensions; if this isn't currently in use, and we need >to push back on the document for other reasons, it might be worth asking >the authors whether losing this would cause them heartburn. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 09:57:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16207 for ; Mon, 7 Jun 2004 09:57:33 -0400 (EDT) Received: (qmail 12296 invoked by uid 605); 7 Jun 2004 13:57:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12123 invoked from network); 7 Jun 2004 13:57:03 -0000 Received: from psg.com (147.28.0.62) by mail.netbsd.org with SMTP; 7 Jun 2004 13:57:03 -0000 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BXKRn-000AdE-PM for ietf-ssh@NetBSD.org; Mon, 07 Jun 2004 13:45:55 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+secsh@rt.psg.com RT-Ticket: psg.com #441 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+secsh@rt.psg.com CC: ietf-ssh@NetBSD.org RT-Originator: clonvick@cisco.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #441] IESG - Architecture - atsign - additional IESG Response In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) MIME-Version: 1.0 Date: Mon, 07 Jun 2004 13:45:55 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list >I don't understand the comment. >Names of the form "user@host" are used in a number of places (email, login >names in ftp://user@host/ URLs, NAIs for roaming, IM identifiers and more). > >I *think* the purpose of the paragraph > > Names with the at-sign ('@') in them are allocated by the owner of > DNS name after the at-sign (hierarchical allocation in [RFC- > 2343]), otherwise the same restrictions as above. > >is to give local extensibility to protocol parameter identifiers; there >are a number of variants that are commonly suggested for this, and DNS >based naming is one of them. (It's not a particularly good one, though - >DNS names change hands too often to be considered "completely stable", and >we do tend to want stability in parameter naming..... it also gives all >the problems of "X-" headers in enabling wide deployment of >non-interoperable extensions; if this isn't currently in use, and we need >to push back on the document for other reasons, it might be worth asking >the authors whether losing this would cause them heartburn. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 10:12:30 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17582 for ; Mon, 7 Jun 2004 10:12:29 -0400 (EDT) Received: (qmail 27681 invoked by uid 605); 7 Jun 2004 14:12:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27668 invoked from network); 7 Jun 2004 14:12:27 -0000 Received: from psg.com (147.28.0.62) by mail.netbsd.org with SMTP; 7 Jun 2004 14:12:27 -0000 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BXKrS-000FOr-N5 for ietf-ssh@NetBSD.org; Mon, 07 Jun 2004 14:12:26 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+secsh@rt.psg.com RT-Ticket: psg.com #450 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+secsh@rt.psg.com CC: ietf-ssh@NetBSD.org RT-Originator: clonvick@cisco.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #450] IESG - Connect - example In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) MIME-Version: 1.0 Date: Mon, 07 Jun 2004 14:12:26 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Also in Section 7.1 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 10:12:39 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17614 for ; Mon, 7 Jun 2004 10:12:38 -0400 (EDT) Received: (qmail 27701 invoked by uid 605); 7 Jun 2004 14:12:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27678 invoked from network); 7 Jun 2004 14:12:28 -0000 Received: from psg.com (147.28.0.62) by mail.netbsd.org with SMTP; 7 Jun 2004 14:12:27 -0000 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1BXKrT-000FOw-6i for ietf-ssh@NetBSD.org; Mon, 07 Jun 2004 14:12:27 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+secsh@rt.psg.com RT-Ticket: psg.com #450 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+secsh@rt.psg.com CC: ietf-ssh@NetBSD.org RT-Originator: clonvick@cisco.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #450] IESG - Connect - example In-Reply-To: Managed-BY: RT 3.0.9 (http://www.bestpractical.com/rt/) MIME-Version: 1.0 Date: Mon, 07 Jun 2004 14:12:27 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Also in Section 7.1 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 7 10:39:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20826 for ; Mon, 7 Jun 2004 10:39:36 -0400 (EDT) Received: (qmail 23935 invoked by uid 605); 7 Jun 2004 14:39:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23921 invoked from network); 7 Jun 2004 14:39:34 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 7 Jun 2004 14:39:34 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2004 07:39:53 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i57EdWMp021831 for ; Mon, 7 Jun 2004 07:39:32 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA01752 for ; Mon, 7 Jun 2004 07:39:32 -0700 (PDT) Date: Mon, 7 Jun 2004 07:39:32 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Issue Tracker In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I've started using the Issue Tracker at https://rt.psg.com/ . Most of the IESG and IANA comments were resolved by Darren so I can open the ticket with a description, and close it right away. Unresolved issues will stick around until I get it right in the documents. Anyone can use it to insert comments and suggestions for resolutions. Please see the instructions here: http://rt.psg.com/ Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 8 05:42:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14840 for ; Tue, 8 Jun 2004 05:42:28 -0400 (EDT) Received: (qmail 17546 invoked by uid 605); 8 Jun 2004 09:42:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17509 invoked from network); 8 Jun 2004 09:42:25 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 8 Jun 2004 09:42:25 -0000 Received: by shitei.mindrot.org (Postfix, from userid 1000) id 1545227C187; Tue, 8 Jun 2004 19:10:38 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by shitei.mindrot.org (Postfix) with ESMTP id 0F63D27D819 for ; Tue, 8 Jun 2004 19:10:38 +1000 (EST) Message-ID: <40C55C1F.6080502@mindrot.org> Date: Tue, 08 Jun 2004 16:26:39 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: rt+secsh@rt.psg.com Cc: ietf-ssh@NetBSD.org, openssh@openssh.com Subject: Re: [psg.com #441] IESG - Architecture - atsign - additional IESG Response References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit rt+secsh@rt.psg.com wrote: >>I don't understand the comment. >>Names of the form "user@host" are used in a number of places (email, login >>names in ftp://user@host/ URLs, NAIs for roaming, IM identifiers and more). >> >>I *think* the purpose of the paragraph >> >> Names with the at-sign ('@') in them are allocated by the owner of >> DNS name after the at-sign (hierarchical allocation in [RFC- >> 2343]), otherwise the same restrictions as above. >> >>is to give local extensibility to protocol parameter identifiers; there >>are a number of variants that are commonly suggested for this, and DNS >>based naming is one of them. (It's not a particularly good one, though - >>DNS names change hands too often to be considered "completely stable", and >>we do tend to want stability in parameter naming..... it also gives all >>the problems of "X-" headers in enabling wide deployment of >>non-interoperable extensions; if this isn't currently in use, and we need >>to push back on the document for other reasons, it might be worth asking >>the authors whether losing this would cause them heartburn. OpenSSH uses this feature now and I plan to use it in the future for new extentions (ciphers and auth methods). Banning this will render widely deployed software non-compliant. The use of user@domain in the secsh protocol is completely orthogonal to its use in URIs or email. These names are used as internal protocol identifiers, not in addressing. IMO this is much more elegant a namespace than X-whatever. The "stability" issue seems irrelevant too - there are no catastrophic consequences if the domain name goes away. Remember that these are, by definition, vendor or site-local extensions. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 8 10:37:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00354 for ; Tue, 8 Jun 2004 10:37:26 -0400 (EDT) Received: (qmail 4061 invoked by uid 605); 8 Jun 2004 14:37:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3947 invoked from network); 8 Jun 2004 14:37:01 -0000 Received: from fw.hel.fi.ssh.com (195.20.116.97) by mail.netbsd.org with SMTP; 8 Jun 2004 14:37:01 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id i58E4mQs025989 for ; Tue, 8 Jun 2004 17:04:48 +0300 (EEST) Received: (qmail 4619 invoked from network); 8 Jun 2004 14:04:48 -0000 Received: from unknown (HELO ?127.0.0.1?) ([10.1.0.55]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 8 Jun 2004 14:04:48 -0000 Message-ID: <40C5C7C1.60409@ssh.com> Date: Tue, 08 Jun 2004 17:05:53 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Miller CC: rt+secsh@rt.psg.com, ietf-ssh@NetBSD.org, openssh@openssh.com Subject: Re: [psg.com #441] IESG - Architecture - atsign - additional IESG Response References: <40C55C1F.6080502@mindrot.org> In-Reply-To: <40C55C1F.6080502@mindrot.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Damien Miller wrote: > OpenSSH uses this feature now and I plan to use it in the future > for new extentions (ciphers and auth methods). Banning this will render > widely deployed software non-compliant. > > The use of user@domain in the secsh protocol is completely orthogonal to > its use in URIs or email. These names are used as internal protocol > identifiers, not in addressing. IMO this is much more elegant a > namespace than X-whatever. > > The "stability" issue seems irrelevant too - there are no catastrophic > consequences if the domain name goes away. Remember that these are, > by definition, vendor or site-local extensions. I agree. Above is also fully applicable to Tectia SSH products of SSH Communications Security Corp. -- Timo J. Rinne Fredrikinkatu 42 +358 20 500 7000 T Director, New Product Technologies FIN-00100 Helsinki +358 20 500 7051 F SSH Communications Security Corp. Finland http://www.ssh.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 8 11:21:22 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01916 for ; Tue, 8 Jun 2004 11:21:22 -0400 (EDT) Received: (qmail 15311 invoked by uid 605); 8 Jun 2004 15:21:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15302 invoked from network); 8 Jun 2004 15:21:20 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 8 Jun 2004 15:21:20 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i58FLJcH019987; Tue, 8 Jun 2004 08:21:19 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i58FLJcc014956; Tue, 8 Jun 2004 11:21:19 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i58FLJ2O000464; Tue, 8 Jun 2004 11:21:19 -0400 (EDT) Message-Id: <200406081521.i58FLJ2O000464@thunk.east.sun.com> From: Bill Sommerfeld To: rt+secsh@rt.psg.com, ietf-ssh@NetBSD.org Subject: Re: [psg.com #441] IESG - Architecture - atsign - additional IESG Response In-Reply-To: Your message of "Tue, 08 Jun 2004 17:05:53 +0300." <40C5C7C1.60409@ssh.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 08 Jun 2004 11:21:19 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list [Cc's trimmed.] For the WG (background): Increased scrutiny of vendor/implementation-specific extension mechanisms (such as the user@domain syntax used by ssh) by the IESG appears to be fallout from problems experienced with RADIUS, where vendor extensions have caused interoperability and security problems. See: http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt For the document editor: the original issue appears to have resulted with a confusion between the use of the id@domain syntax; while the syntax of these names resembles that of RFC822 email addresses, they are most definitely not email addresses. I suggest inserting a clarification to that effect in the section. For any IESG members listening: I believe this WG can demonstrate a track record for responsible use of this feature by the implementor community. In particular, under the taxonomy described in the above draft, usage is either "minor extensibility", or does not create a radius-like security issue as the id@domain options are used in a context which doesn't allow for "noncritical" options to be ignored. Most commonly, they're used to select amongst several ways of doing something in a negotiation; failure to understand an option means that an alternative option acceptable to both peers may be accepted; if no alternatives are available, this would likely be due to security policy -- the peers will simply fail to talk. It is extraordinarily unlikely that the use of id@domain identifiers will result in the peers misunderstanding each other; I'd say that the risk of such problems is dwarfed by the risk to interoperability from out-and-out implementation errors. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 8 12:18:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06024 for ; Tue, 8 Jun 2004 12:18:32 -0400 (EDT) Received: (qmail 7675 invoked by uid 605); 8 Jun 2004 16:18:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7663 invoked from network); 8 Jun 2004 16:18:31 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 8 Jun 2004 16:18:31 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i58GIPcH024013; Tue, 8 Jun 2004 09:18:25 -0700 (PDT) Received: from soe-austin.central.sun.com (soe-austin.Central.Sun.COM [10.1.194.2]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i58GIO4F016803; Tue, 8 Jun 2004 10:18:25 -0600 (MDT) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i58GIOP6003928; Tue, 8 Jun 2004 11:18:24 -0500 (CDT) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i58GILg1003912; Tue, 8 Jun 2004 11:18:21 -0500 (CDT) Date: Tue, 8 Jun 2004 11:18:21 -0500 From: Nicolas Williams To: Damien Miller Cc: rt+secsh@rt.psg.com, ietf-ssh@NetBSD.org, openssh@openssh.com Subject: Re: [psg.com #441] IESG - Architecture - atsign - additional IESG Response Message-ID: <20040608161818.GA1104@soe-austin.central.sun.com> Mail-Followup-To: Nicolas Williams , Damien Miller , rt+secsh@rt.psg.com, ietf-ssh@NetBSD.org, openssh@openssh.com References: <40C55C1F.6080502@mindrot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C55C1F.6080502@mindrot.org> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jun 08, 2004 at 04:26:39PM +1000, Damien Miller wrote: > rt+secsh@rt.psg.com wrote: > > >>I don't understand the comment. > >>Names of the form "user@host" are used in a number of places (email, login > >>names in ftp://user@host/ URLs, NAIs for roaming, IM identifiers and more). > >> > >>I *think* the purpose of the paragraph > >> > >> Names with the at-sign ('@') in them are allocated by the owner of > >> DNS name after the at-sign (hierarchical allocation in [RFC- > >> 2343]), otherwise the same restrictions as above. > >> > >>is to give local extensibility to protocol parameter identifiers; there > >>are a number of variants that are commonly suggested for this, and DNS > >>based naming is one of them. (It's not a particularly good one, though - > >>DNS names change hands too often to be considered "completely stable", and > >>we do tend to want stability in parameter naming..... it also gives all > >>the problems of "X-" headers in enabling wide deployment of > >>non-interoperable extensions; if this isn't currently in use, and we need > >>to push back on the document for other reasons, it might be worth asking > >>the authors whether losing this would cause them heartburn. > > OpenSSH uses this feature now and I plan to use it in the future > for new extentions (ciphers and auth methods). Banning this will render > widely deployed software non-compliant. > > The use of user@domain in the secsh protocol is completely orthogonal to > its use in URIs or email. These names are used as internal protocol > identifiers, not in addressing. IMO this is much more elegant a > namespace than X-whatever. > > The "stability" issue seems irrelevant too - there are no catastrophic > consequences if the domain name goes away. Remember that these are, > by definition, vendor or site-local extensions. I agree. The '@' sign here is used to reserve part of the namespace of named SSHv2 protocol elements for private allocation (the extensions that this enables are typically not proprietary, though they may be). More importantly, these names are not visible to users and so users won't try to interpret them -- these names are internal to SSHv2. This feature has been used in production deployments for several extensions to SSHv2, so it cannot be removed, even if the removal made sense -- which it does not. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 8 19:55:44 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10969 for ; Tue, 8 Jun 2004 19:55:43 -0400 (EDT) Received: (qmail 6068 invoked by uid 605); 8 Jun 2004 23:55:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6048 invoked from network); 8 Jun 2004 23:55:40 -0000 Received: from brmea-mail-4.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 8 Jun 2004 23:55:40 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i58NrwMf009581 for ; Tue, 8 Jun 2004 17:53:59 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i58Ntdcc019870 for ; Tue, 8 Jun 2004 19:55:39 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i58NtdLH011918 for ; Tue, 8 Jun 2004 19:55:39 -0400 (EDT) Message-Id: <200406082355.i58NtdLH011918@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: IETF document publication process tweaks. Reply-to: sommerfeld@east.sun.com Date: Tue, 08 Jun 2004 19:55:39 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list For those of you who don't subscribe to IETF-announce, you should be aware that the IESG has once again revised the procedures for Internet-Draft submission. - The old ID-Nits list is now the "ID Checklist", http://www.ietf.org/ID-Checklist.html - There is also now a script available which provides an "internet draft lint" tool, which checks for conformance with many of the mechanical aspects of these new checklists. See: http://ietf.levkowetz.com/tools/idnits/ - In addition, with the publication of RFC 3667 and RFC 3668, which supersede RFC2026, there now also newly rototilled draft template boilerplate/copyright/IPR notice/etc.; A new version of the xml2rfc toolkit is available at http://xml.resource.org/ which includes the new boilerplate. While use of xml2rfc is not required, it is strongly encouraged.. As working group chair, I'm responsible for checking all drafts against the checklist. Help save you and me time by checking them first before sending them in.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 10 22:14:56 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12432 for ; Thu, 10 Jun 2004 22:14:56 -0400 (EDT) Received: (qmail 10933 invoked by uid 605); 11 Jun 2004 02:14:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10923 invoked from network); 11 Jun 2004 02:14:47 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 11 Jun 2004 02:14:47 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i5B2Ek0R012633 for ; Thu, 10 Jun 2004 19:14:46 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5B2Ekcc021713 for ; Thu, 10 Jun 2004 22:14:46 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5B2Ec7O006766 for ; Thu, 10 Jun 2004 22:14:46 -0400 (EDT) Message-Id: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Reply-to: clonvick@cisco.com Date: Thu, 10 Jun 2004 22:14:38 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message got caught in a filter at netbsd due to a false positive keyword hit. sorry for the delay in forwarding this.. Date: Wed, 9 Jun 2004 09:57:30 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org cc: rt+secsh@rt.psg.com Subject: Re: [psg.com #460] IESG - Transport - Oakley In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Folks, This is the issue we were discussing a few weeks ago about the Oakley groups. The recommendation at the time was to - reference the proper RFC for Oakley Group 2 - delete the actual value of the prime from the document - state that other works will be forthcoming for better Groups. I made an effort to capture it this way: 8.1 diffie-hellman-group1-sha1 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit MODP Group). At the time of this writing, this method MUST be supported for interoperability as all of the known implementations support it. The Working Group RECOMMENDS that implementations also support the Oakley Group 14 [RFC3526] (2048bit MODP Group) method. However, at the time of this writing, those methods have not been defined. It is expected that this Working Group will produce a document that defines this method for use in this protocol, so readers should look carefully at documents produced by this Working Group to see if other methods are required. You can see the difference (htmlwdiff) from the prior version here: http://www.employees.org/~lonvick/secsh-wg/june02/transport-17-18.html Can I get some feedback on this? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 11 06:04:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09649 for ; Fri, 11 Jun 2004 06:04:00 -0400 (EDT) Received: (qmail 29348 invoked by uid 605); 11 Jun 2004 10:03:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29330 invoked from network); 11 Jun 2004 10:03:57 -0000 Received: from mail-in-06.arcor-online.net (151.189.21.46) by mail.netbsd.org with SMTP; 11 Jun 2004 10:03:57 -0000 Received: from localhost.arcor.net (dsl-213-023-020-006.arcor-ip.net [213.23.20.6]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id A17B1F6B00; Fri, 11 Jun 2004 09:51:29 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 23C64F1B6; Fri, 11 Jun 2004 09:51:23 +0200 (CEST) Date: Fri, 11 Jun 2004 09:51:22 +0200 From: Markus Friedl To: clonvick@cisco.com Cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <20040611075122.GD29105@folly> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list again, why change a deployed protcol? > However, at the time of this writing, those methods have not been > defined. i think it vague comments like this should not be in the document. just state that further groups might be defined in additional documents. On Thu, Jun 10, 2004 at 10:14:38PM -0400, Bill Sommerfeld wrote: > 8.1 diffie-hellman-group1-sha1 > > The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key > exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit > MODP Group). At the time of this writing, this method MUST be > supported for interoperability as all of the known implementations > support it. The Working Group RECOMMENDS that implementations also > support the Oakley Group 14 [RFC3526] (2048bit MODP Group) method. > However, at the time of this writing, those methods have not been > defined. It is expected that this Working Group will produce a > document that defines this method for use in this protocol, so > readers should look carefully at documents produced by this Working > Group to see if other methods are required. > > > You can see the difference (htmlwdiff) from the prior version here: > http://www.employees.org/~lonvick/secsh-wg/june02/transport-17-18.html > > Can I get some feedback on this? > > Thanks, > Chris > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 11 08:34:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18685 for ; Fri, 11 Jun 2004 08:34:28 -0400 (EDT) Received: (qmail 9583 invoked by uid 605); 11 Jun 2004 12:34:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9573 invoked from network); 11 Jun 2004 12:34:26 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 11 Jun 2004 12:34:26 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 11 Jun 2004 05:35:55 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5BCYNdJ025879; Fri, 11 Jun 2004 05:34:23 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA03459; Fri, 11 Jun 2004 05:34:23 -0700 (PDT) Date: Fri, 11 Jun 2004 05:34:23 -0700 (PDT) From: Chris Lonvick To: Markus Friedl cc: ietf-ssh@NetBSD.org, rt+secsh@rt.psg.com Subject: Re: [psg.com #460] IESG - Transport - Oakley In-Reply-To: <20040611075122.GD29105@folly> Message-ID: References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Markus, On Fri, 11 Jun 2004, Markus Friedl wrote: > again, why change a deployed protcol? What I'm trying to do is to get the wording right in these documents so that 1) the documents reflect the deployed protocol and, 2) they address the nits posted by the IESG. As we saw in the discussion about the "@", the IESG may be incorrect in their views. In that case, we should make the document more clear to minimize any confusion. In this case, I don't see that I'm making any changes to the protocol. If I inadvertently do, please point it out and I'll adjust it back. > > > However, at the time of this writing, those methods have not been > > defined. > > i think it vague comments like this should not be > in the document. just state that further groups > might be defined in additional documents. OK. > > On Thu, Jun 10, 2004 at 10:14:38PM -0400, Bill Sommerfeld wrote: > > 8.1 diffie-hellman-group1-sha1 > > > > The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key > > exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit > > MODP Group). At the time of this writing, this method MUST be > > supported for interoperability as all of the known implementations > > support it. The Working Group RECOMMENDS that implementations also > > support the Oakley Group 14 [RFC3526] (2048bit MODP Group) method. > > However, at the time of this writing, those methods have not been > > defined. It is expected that this Working Group will produce a > > document that defines this method for use in this protocol, so > > readers should look carefully at documents produced by this Working > > Group to see if other methods are required. > > > > > > You can see the difference (htmlwdiff) from the prior version here: > > http://www.employees.org/~lonvick/secsh-wg/june02/transport-17-18.html > > New proposal: The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit MODP Group). At the time of this writing, this method MUST be supported for interoperability as all of the known implementations support it. The Working Group RECOMMENDS that implementations also support the Oakley Group 14 [RFC3526] (2048bit MODP Group) method which is not defined in this document. Other groups may be defined in additional documents. Please comment on this. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 11 12:34:16 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15874 for ; Fri, 11 Jun 2004 12:34:16 -0400 (EDT) Received: (qmail 11591 invoked by uid 605); 11 Jun 2004 16:33:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11522 invoked from network); 11 Jun 2004 16:33:57 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 11 Jun 2004 16:33:57 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa08431; 11 Jun 2004 10:32 EDT Date: Fri, 11 Jun 2004 10:32:36 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <249420000.1086964356@minbar.fac.cs.cmu.edu> In-Reply-To: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > 8.1 diffie-hellman-group1-sha1 > > The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key > exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit > MODP Group). At the time of this writing, this method MUST be > supported for interoperability as all of the known implementations > support it. The Working Group RECOMMENDS that implementations also > support the Oakley Group 14 [RFC3526] (2048bit MODP Group) method. > However, at the time of this writing, those methods have not been > defined. It is expected that this Working Group will produce a > document that defines this method for use in this protocol, so > readers should look carefully at documents produced by this Working > Group to see if other methods are required. Don't say "At the time of this writing, this method MUST be supported...". The use of MUST indicates something that implementors are _required_ to do in order to be compliant with the spec. Either something is a requirement or it isn't; don't hedge. In this case, diffie-hellman-group1-sha1 is REQUIRED, not just "at the time of this writing" but for any implementation that ever wants to claim compliance with this spec. Don't say "The Working Group RECOMMENDS..." something that then isn't specified. RECOMMENDED is also requirements language; it means "do this unless you have a good reason not to". It's inappropriate to use it to describe something we don't specify. It would be reasonable to RECOMMEND or (IMHO) even REQUIRE support for dh-gex; I think this issue has come up before. It might be reasonable for the dh-gex document to RECOMMEND or REQUIRE support for a particular group, though I don't believe that's necessary. RFC's are mostly timeless documents, and should avoid talking about the current state of things, which is likely to have changed by the time the reader sees the document. For example, by the time this document is published as an RFC, dh-gex will probably be done and approved (looking at the I-D tracker, it looks like it only needs a corrected copyright). Finally, section 8.1 is about defining the KEX method identified by the protocol constant "diffie-hellman-group1-sha1". It should not define other methods, or include text or requirements that are not actually part of the definition of that method. Let's limit section 8.1 to something like: The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit MODP Group). This method is REQUIRED. The the security considerations section of the architecture document can talk about the issue and recommend support of dh-gex as a solution. For that matter, we can list dh-gex as RECOMMENDED in section 6.5 (did the WG ever come to concensus on whether we should do this?), though it will mean a normative reference to that document. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 11 13:41:44 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20413 for ; Fri, 11 Jun 2004 13:41:43 -0400 (EDT) Received: (qmail 20854 invoked by uid 605); 11 Jun 2004 17:41:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20840 invoked from network); 11 Jun 2004 17:41:41 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 11 Jun 2004 17:41:41 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5BHfaJ6013827; Fri, 11 Jun 2004 10:41:36 -0700 (PDT) Received: from soe-austin.central.sun.com (soe-austin.Central.Sun.COM [10.1.194.2]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5BHfZ4F002487; Fri, 11 Jun 2004 11:41:36 -0600 (MDT) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5BHfZ93594005; Fri, 11 Jun 2004 12:41:35 -0500 (CDT) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5BHfYne594004; Fri, 11 Jun 2004 12:41:34 -0500 (CDT) Date: Fri, 11 Jun 2004 12:41:34 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt Message-ID: <20040611174131.GA593949@soe-austin.central.sun.com> References: <40BFD735.6000303@mindrot.org> <200406042339.i54NdunH007425@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406042339.i54NdunH007425@thunk.east.sun.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Jun 04, 2004 at 07:39:56PM -0400, Bill Sommerfeld wrote: > > I don't understand why new changes are being made to the drafts again > > - I was under the impression that they were just about ready for > > publication. Can someone more familiar with the process please explain > > what stands in the way of this happening? > > The documents are currently under review by the IESG. > > Any changes at this point should be primarily driven by comments from > the IESG, which can be found in the IETF draft tracker at: > > https://datatracker.ietf.org/public/pidtracker.cgi > > Enter "secsh" in the WG acronym field) and hit "SEARCH". > > Then pick a document, click on DETAIL to see its history. > > In the Detail Info section, click on "IESG evaluation record" to see > IESG comments. Bill, I found not much in the eval record for the transport draft, and only a little more for the architecture and other core drafts. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 11 13:54:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21274 for ; Fri, 11 Jun 2004 13:54:11 -0400 (EDT) Received: (qmail 7443 invoked by uid 605); 11 Jun 2004 17:54:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7431 invoked from network); 11 Jun 2004 17:54:09 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 11 Jun 2004 17:54:09 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5BHs4il011487; Fri, 11 Jun 2004 11:54:04 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5BHrjcE015145; Fri, 11 Jun 2004 11:53:45 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5BHpE1a746567; Fri, 11 Jun 2004 12:51:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5BHpE2Z746566; Fri, 11 Jun 2004 12:51:14 -0500 (CDT) Date: Fri, 11 Jun 2004 12:51:14 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt Message-ID: <20040611175114.GH262657@binky.central.sun.com> References: <40BFD735.6000303@mindrot.org> <200406042339.i54NdunH007425@thunk.east.sun.com> <20040611174131.GA593949@soe-austin.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040611174131.GA593949@soe-austin.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Jun 11, 2004 at 12:41:33PM -0500, Nicolas Williams wrote: > Bill, I found not much in the eval record for the transport draft, and > only a little more for the architecture and other core drafts. Never mind. I've found it off the architecture draft, which does have an eval record. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 11 14:01:23 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21857 for ; Fri, 11 Jun 2004 14:01:22 -0400 (EDT) Received: (qmail 13830 invoked by uid 605); 11 Jun 2004 18:01:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13819 invoked from network); 11 Jun 2004 18:01:20 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 11 Jun 2004 18:01:20 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5BI0nil015720; Fri, 11 Jun 2004 12:00:49 -0600 (MDT) Received: from soe-austin.central.sun.com (soe-austin.Central.Sun.COM [10.1.194.2]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5BI0m4F011135; Fri, 11 Jun 2004 12:00:48 -0600 (MDT) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5BI0j0G594019; Fri, 11 Jun 2004 13:00:45 -0500 (CDT) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5BI0iGT594018; Fri, 11 Jun 2004 13:00:44 -0500 (CDT) Date: Fri, 11 Jun 2004 13:00:44 -0500 From: Nicolas Williams To: Chris Lonvick Cc: Markus Friedl , ietf-ssh@NetBSD.org, rt+secsh@rt.psg.com Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <20040611180044.GB593949@soe-austin.central.sun.com> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Jun 11, 2004 at 05:34:23AM -0700, Chris Lonvick wrote: > Hi Markus, > > On Fri, 11 Jun 2004, Markus Friedl wrote: > > > again, why change a deployed protcol? > > What I'm trying to do is to get the wording right in these documents so > that > 1) the documents reflect the deployed protocol and, > 2) they address the nits posted by the IESG. > > As we saw in the discussion about the "@", the IESG may be incorrect in > their views. In that case, we should make the document more clear to > minimize any confusion. In this case, I don't see that I'm making any > changes to the protocol. If I inadvertently do, please point it out and > I'll adjust it back. The IESG comment on this is: " 13. Section 6.1. There is only one Oakley group defined, and it has an equivalent strength of 80-bit symmetric encryption. There should be additional Oakley groups that offer strength commensurate with the other recommendations in the document. The document should explicitly reference RFC 3526, and make use of group 14 (2048 bits). " To me this means that the IESG is unhappy with diffie-hellman-group1-sha1. But diffie-hellman-group1-sha1 is really a MUST for interop for historical reasons. I think it should remain a MUST, or, if downgraded to SHOULD, an interop note should be added to the spec. As for larger groups, we have three choices: - specify diffie-hellman-group14-sha1 and make it MANDATORY to implement - make diffie-hellman-group-exchange-sha1 MANDATORY to implement - both of the above [...] > New proposal: > > The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key > exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit > MODP Group). At the time of this writing, this method MUST be > supported for interoperability as all of the known implementations > support it. The Working Group RECOMMENDS that implementations also > support the Oakley Group 14 [RFC3526] (2048bit MODP Group) method > which is not defined in this document. Other groups may be defined > in additional documents. > > Please comment on this. How can the WG RECOMMEND that something be implemented which isn't specified?? RFC3526 does not, after all, specify an SSHv2 key exchange protocol for the various groups it describes. I seriously doubt that this is what the IESG had in mind. And you also wrote: > This is the issue we were discussing a few weeks ago about the Oakley > groups. The recommendation at the time was to > - reference the proper RFC for Oakley Group 2 > - delete the actual value of the prime from the document > - state that other works will be forthcoming for better Groups. "state that other works will be forthcoming" does not amount to "[the WG] RECOMMENDS that implementations also support the Oakley Group 14..." See above. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 11 15:05:18 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25022 for ; Fri, 11 Jun 2004 15:05:18 -0400 (EDT) Received: (qmail 19180 invoked by uid 605); 11 Jun 2004 19:05:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19158 invoked from network); 11 Jun 2004 19:05:13 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 11 Jun 2004 19:05:13 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA09490; Fri, 11 Jun 2004 15:05:12 -0400 (EDT) From: der Mouse Message-Id: <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Fri, 11 Jun 2004 14:43:16 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley In-Reply-To: <20040611180044.GB593949@soe-austin.central.sun.com> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > As for larger groups, we have three choices: > - specify diffie-hellman-group14-sha1 and make it MANDATORY to implement > - make diffie-hellman-group-exchange-sha1 MANDATORY to implement > - both of the above As an implementor, I would argue for the first of these. Getting diffie-hellman-group-exchange-sha1 right is a good deal more complicated than simply using another fixed group. Of course, as a security geek, I argue for the second, or perhaps the third, since g-ex-sha1 is stronger than g14-sha1 just on general principles (because the putative attacker knows less a priori) - at least if the size parameters are suitable. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jun 12 14:40:40 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16419 for ; Sat, 12 Jun 2004 14:40:39 -0400 (EDT) Received: (qmail 3075 invoked by uid 605); 12 Jun 2004 18:40:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3063 invoked from network); 12 Jun 2004 18:40:37 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Jun 2004 18:40:37 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id B97D1F643A; Sat, 12 Jun 2004 20:15:29 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id CF080F935F; Sat, 12 Jun 2004 20:15:17 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5CIFHGU014748; Sat, 12 Jun 2004 20:15:17 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5CIFGS2014745; Sat, 12 Jun 2004 20:15:16 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 12 Jun 2004 20:15:16 +0200 In-Reply-To: <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > > As for larger groups, we have three choices: > > > - specify diffie-hellman-group14-sha1 and make it MANDATORY to implement > > - make diffie-hellman-group-exchange-sha1 MANDATORY to implement > > - both of the above > > As an implementor, I would argue for the first of these. Getting > diffie-hellman-group-exchange-sha1 right is a good deal more > complicated than simply using another fixed group. I also argue this way. If we need to change anything at all at this stage (and it seems the IESG has a valid concern), then I think we should do it the simple way and get it over with. Mandating one more fix group, diffie-hellman-group14-sha1, is a simple change to the spec, and a 20-line change to update an implementation. Is it still appropriate to use sha1 (rather than sha256) with group 14? Staying with sha1 has the advantage that it reduces the number of cryptographic algorithms that must be included in a minimalistic implementation of the protocol. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jun 13 08:58:13 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08949 for ; Sun, 13 Jun 2004 08:58:13 -0400 (EDT) Received: (qmail 20845 invoked by uid 605); 13 Jun 2004 12:58:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20830 invoked from network); 13 Jun 2004 12:58:07 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 13 Jun 2004 12:58:06 -0000 Received: from mindrot.org (unknown [172.29.84.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shitei.mindrot.org (Postfix) with ESMTP id 9AE2627C187; Sun, 13 Jun 2004 22:57:47 +1000 (EST) Message-ID: <40CC4E5D.9080508@mindrot.org> Date: Sun, 13 Jun 2004 22:53:49 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040312) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > I also argue this way. If we need to change anything at all at this > stage (and it seems the IESG has a valid concern), then I think we > should do it the simple way and get it over with. > > Mandating one more fix group, diffie-hellman-group14-sha1, is a simple > change to the spec, and a 20-line change to update an implementation. Agreed, so long as the diffie-hellman-group1-sha1 remains a MUST. I'd like to see DH-GEX recommended, but I think that can be done in the DH-GEX draft itself when it is advanced. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jun 13 15:29:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29811 for ; Sun, 13 Jun 2004 15:29:11 -0400 (EDT) Received: (qmail 29655 invoked by uid 605); 13 Jun 2004 19:29:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29565 invoked from network); 13 Jun 2004 19:29:09 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 13 Jun 2004 19:29:09 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa24746; 13 Jun 2004 15:28 EDT Date: Sun, 13 Jun 2004 15:28:14 -0400 From: Jeffrey Hutzelman To: Damien Miller , =?ISO-8859-1?Q?Niels_M=F6ller?= cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <539620000.1087154894@minbar.fac.cs.cmu.edu> In-Reply-To: <40CC4E5D.9080508@mindrot.org> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Sunday, June 13, 2004 22:53:49 +1000 Damien Miller =20 wrote: > Niels M=F6ller wrote: >> I also argue this way. If we need to change anything at all at this >> stage (and it seems the IESG has a valid concern), then I think we >> should do it the simple way and get it over with. >> >> Mandating one more fix group, diffie-hellman-group14-sha1, is a simple >> change to the spec, and a 20-line change to update an implementation. > > Agreed, so long as the diffie-hellman-group1-sha1 remains a MUST. Yes, there is a strong interoperability argument for keeping=20 diffie-hellman-group1-sha1. Not only is there a very large installed base, = but there are many distinct implementations. Expecting every implementor=20 to support the new group and every user to deploy a new version overnight=20 would be unreasonable. > I'd like to see DH-GEX recommended, Me too. > but I think that can be done in the > DH-GEX draft itself when it is advanced. Yeah, but it would be better to do it in the core specification, where the=20 recommendation will have more visibility. IIRC all DH-GEX needs is some=20 cleanup wrt copyright issues (and, by now, new boilerplate). If that can=20 happen soon it doesn't seem like it would be unreasonable to have a=20 normative reference to it. > Is it still appropriate to use sha1 (rather than sha256) with group > 14? Staying with sha1 has the advantage that it reduces the number of > cryptographic algorithms that must be included in a minimalistic > implementation of the protocol. I don't know, but it certainly would be desirable to stick with sha1. For=20 one thing, it means the new method can be specified in one sentence, and as = you note, implemented very nearly as easily. It might be desirable to RECOMMEND or even REQUIRE that=20 diffie-hellman-group14-sha1 be listed _before_ diffie-hellman-group1-sha1,=20 so that its use is preferred when both sides support it. And of course, I=20 imagine that implementors will provide policy options to turn off support=20 for either group. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 03:51:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11995 for ; Mon, 14 Jun 2004 03:51:36 -0400 (EDT) Received: (qmail 24310 invoked by uid 605); 14 Jun 2004 07:51:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24287 invoked from network); 14 Jun 2004 07:51:28 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Jun 2004 07:51:27 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 48184E022B; Mon, 14 Jun 2004 09:51:26 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 80E78E0591; Mon, 14 Jun 2004 09:51:15 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5E7pEGU027814; Mon, 14 Jun 2004 09:51:14 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5E7pDJS027810; Mon, 14 Jun 2004 09:51:13 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 14 Jun 2004 09:51:12 +0200 In-Reply-To: <539620000.1087154894@minbar.fac.cs.cmu.edu> Message-ID: Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > It might be desirable to RECOMMEND or even REQUIRE that > diffie-hellman-group14-sha1 be listed _before_ > diffie-hellman-group1-sha1, so that its use is preferred when both > sides support it. I don't think such a recommendation or requirement is appropriate at all; algorithm selection is an implementation/local configuration issue. Saying that both groups MUST be supported is clear enough, I'd expect that all implementations except possibly very constrained ones will prefer group14 over group1, as soon as it's implemented and tested. As I understand it, the goal of this wg since the beginning has been that the specified algorithms, and in particular, all RECOMMENDED or REQUIRED algorithms, should be *good enough* from a security perspective. So that users can choose freely between algorithms for whatever reasons they have, without compromising security by mistake. A user should not be able to break security by using ordinary algorithm selection options[2], and then the default algorithm preferences in implementations shouldn't matter either. No matter what the specification and implementations do, there will always be some link that is weakest (and that could well be something out of scope of the protocol spec, like the backup routines for the seedfile of the randomness generator, whatever). Our job is to ensure that the weakest link is reasonably strong, not to spell out the relative strength of each link. Now I'm afraid I'm not up to date on the state of art in computing discrete logarithms. If it's the case that group1 really is considered insecure, then the spec should grandfather[1] its use (in much the same way as we would discourage plain DES, if it had ever appeared as a MUST in te specification), but as far as I'm aware, that's not the case. Bottom line: Just specify diffie-hellman-group14-sha1. Regards, /Niels -- [1] Thanks to our chair Bill who explained the meaning of this very useful verb a while ago. [2] And letting users prefer "none" at all in an implementation degrades the user interface. I should probably stop supporting it, or at least rename the command line option from -c none to --I-dont-want-any-security-and-I-know-what-I-am-doing. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 05:31:55 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16503 for ; Mon, 14 Jun 2004 05:31:54 -0400 (EDT) Received: (qmail 16021 invoked by uid 605); 14 Jun 2004 09:31:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16011 invoked from network); 14 Jun 2004 09:31:50 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 14 Jun 2004 09:31:49 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 17FD2433DA; Mon, 14 Jun 2004 11:14:40 +0200 (CEST) Message-ID: <40CD6CD8.9040003@siliconcircus.com> Date: Mon, 14 Jun 2004 11:16:08 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: Jeffrey Hutzelman , Damien Miller , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Jeffrey Hutzelman writes: > > >>It might be desirable to RECOMMEND or even REQUIRE that >>diffie-hellman-group14-sha1 be listed _before_ >>diffie-hellman-group1-sha1, so that its use is preferred when both >>sides support it. > > > I don't think such a recommendation or requirement is appropriate at > all; algorithm selection is an implementation/local configuration > issue. Saying that both groups MUST be supported is clear enough, I'd > expect that all implementations except possibly very constrained ones > will prefer group14 over group1, as soon as it's implemented and > tested. Nonetheless, providing a hint to possibly-ill-informed implementors about what should come first by default wouldn't be a bad thing? I agree that it certainly shouldn't be REQUIRED, but RECOMMENDing that the default configuration prefers group14 would hardly be a bad thing? Few admins I know would trust themselves to play with the ordering of algorithm selection, making the implementor's default choice a very relevant issue. Helping the implementors to get this right doesn't really have many disadvantages? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 07:22:41 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22190 for ; Mon, 14 Jun 2004 07:22:40 -0400 (EDT) Received: (qmail 16381 invoked by uid 605); 14 Jun 2004 11:22:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16366 invoked from network); 14 Jun 2004 11:22:33 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Jun 2004 11:22:32 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 8FDE1112A57; Mon, 14 Jun 2004 13:22:31 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 80B14C9DC0; Mon, 14 Jun 2004 13:22:20 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5EBMKGU000812; Mon, 14 Jun 2004 13:22:20 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5EBMIje000809; Mon, 14 Jun 2004 13:22:18 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jon Bright Cc: Jeffrey Hutzelman , Damien Miller , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <40CD6CD8.9040003@siliconcircus.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 14 Jun 2004 13:22:18 +0200 In-Reply-To: <40CD6CD8.9040003@siliconcircus.com> Message-ID: Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jon Bright writes: > Nonetheless, providing a hint to possibly-ill-informed implementors > about what should come first by default wouldn't be a bad thing? Adding such a recommendation would not be the end of the world as we know it, but it would be a useless bloat of the spec, imho. The protocol specification should explain the details needed for implementing the protocol, it's not the place for random advice on how to best use and implement the protocol. For example we don't include a long discussion on the pros and cons of aes vs des3, and I think it's good that we don't do that. I think it should be fairly obvious that group14 is harder to crack than group1, and that using group14 will consume more cpu cycles. If there's anybody who doesn't agree it's obvious, and who is willing to write a *concise* and correct piece of text that says that group14 is believed to be more secure than group1, then I won't strongly oppose that such text is added to the spec. But I still think it's unnecessary, and I certainly don't want to have to wait for such text to materialize. Defining the group and referring to RFC 3526 should be enough (it's a little unfortunate that RFC 3526 doesn't include group two for comparison). BTW, about naming. The proposed naming is a little confusing: SSH name "Well known" name diffie-hellman-group1-sha1 Well known group 2 (RFC 2412) ^ ^ diffie-hellman-group14-sha1 Well known group 14 (RFC 3516) ^^ ^^ On one hand, it would be a little more consistent to use "diffie-hellman-group2-sha1" for oakley group 14 (meaning simply the second fixed group defined for the ssh protocol). On the other hand, it would be nice to be able to generalize diffie-hellman-groupXX-sha1 Well known group XX (RFC 3516) but then diffie-hellman-group1-sha1 would be a kind-of ugly exception. I don't feel very strongly about this, though. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 11:22:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09245 for ; Mon, 14 Jun 2004 11:22:28 -0400 (EDT) Received: (qmail 6867 invoked by uid 605); 14 Jun 2004 15:21:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6825 invoked from network); 14 Jun 2004 15:21:24 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 14 Jun 2004 15:21:24 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa27546; 14 Jun 2004 11:21 EDT Date: Mon, 14 Jun 2004 11:21:05 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Jon Bright cc: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <725220000.1087226465@minbar.fac.cs.cmu.edu> In-Reply-To: References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <40CD6CD8.9040003@siliconcircus.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Monday, June 14, 2004 13:22:18 +0200 Niels M=F6ller = =20 wrote: > Jon Bright writes: > >> Nonetheless, providing a hint to possibly-ill-informed implementors >> about what should come first by default wouldn't be a bad thing? > > Adding such a recommendation would not be the end of the world as we > know it, but it would be a useless bloat of the spec, imho. The > protocol specification should explain the details needed for > implementing the protocol, it's not the place for random advice on how > to best use and implement the protocol. Actually, the protocol specification is a perfectly reasonable place for=20 advice to implementors. > I think it should be fairly obvious that group14 is harder to crack > than group1, and that using group14 will consume more cpu cycles. Well, that's the expectation I would have. But I don't agree it will be=20 obvious to everyone. In any case, I don't have any particular attachment to adding such a=20 recommendation; I just tossed it out there as an idea. > BTW, about naming. The proposed naming is a little confusing: > > SSH name "Well known" name > > diffie-hellman-group1-sha1 Well known group 2 (RFC 2412) > ^ ^ > diffie-hellman-group14-sha1 Well known group 14 (RFC 3516) Yup. I blame the people who named diffie-hellman-group1-sha1. > On the other hand, > it would be nice to be able to generalize > > diffie-hellman-groupXX-sha1 Well known group XX (RFC 3516) I was assuming it was pretty much agreed that this would be the appropriate = solution. It does mean there's no name for the method which uses group 1,=20 but somehow I suspect we don't care very much... Oh, and for those reading who are confused... - Groups 1-4 are defined in RFC2409 (IKE) and RFC2412 (Oakley). Groups 1 and 2 are MODP groups of size 768 and 1024 bits, and are defined identically in both places. Groups 3 and 4 are EC2N groups; they are _not_ defined identically in both places -- one of the two documents is in error, but I'm not awake enough to tell which. - Groups 5 and 14-18 are defined in RFC3526 (not RFC2516). They are MODP groups of increasing size, from 1536 to 8192 bits. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 11:34:50 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10371 for ; Mon, 14 Jun 2004 11:34:50 -0400 (EDT) Received: (qmail 19189 invoked by uid 605); 14 Jun 2004 15:34:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19180 invoked from network); 14 Jun 2004 15:34:49 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Jun 2004 15:34:49 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 7020E113BF0; Mon, 14 Jun 2004 17:34:48 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 25C84113F3B; Mon, 14 Jun 2004 17:34:37 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5EFYaGU003867; Mon, 14 Jun 2004 17:34:36 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5EFYZYd003864; Mon, 14 Jun 2004 17:34:35 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Jon Bright , Damien Miller , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <40CD6CD8.9040003@siliconcircus.com> <725220000.1087226465@minbar.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 14 Jun 2004 17:34:34 +0200 In-Reply-To: <725220000.1087226465@minbar.fac.cs.cmu.edu> Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > > On the other hand, > > it would be nice to be able to generalize > > > > diffie-hellman-groupXX-sha1 Well known group XX (RFC 3516) > > I was assuming it was pretty much agreed that this would be the > appropriate solution. It does mean there's no name for the method > which uses group 1, but somehow I suspect we don't care very much... Agreed, it's reasonable to not care about the 768-bit "well known group 1". It just wasn't clear to me before that the numbering in "diffie-hellman-group1-sha1" does *not* match the numbering elsewhere (RFC 2412). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 12:35:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13551 for ; Mon, 14 Jun 2004 12:35:00 -0400 (EDT) Received: (qmail 12356 invoked by uid 605); 14 Jun 2004 16:35:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12342 invoked from network); 14 Jun 2004 16:34:59 -0000 Received: from brmea-mail-4.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 14 Jun 2004 16:34:59 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5EGX453017982; Mon, 14 Jun 2004 10:33:04 -0600 (MDT) Received: from soe-austin.central.sun.com (soe-austin.Central.Sun.COM [10.1.194.2]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5EGYo4F017964; Mon, 14 Jun 2004 10:34:50 -0600 (MDT) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5EGYnu9353228; Mon, 14 Jun 2004 11:34:49 -0500 (CDT) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5EGYkm4353155; Mon, 14 Jun 2004 11:34:46 -0500 (CDT) Date: Mon, 14 Jun 2004 11:34:46 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Damien Miller , Niels =?unknown-8bit?Q?M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <20040614163443.GA352198@soe-austin.central.sun.com> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539620000.1087154894@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sun, Jun 13, 2004 at 03:28:14PM -0400, Jeffrey Hutzelman wrote: > On Sunday, June 13, 2004 22:53:49 +1000 Damien Miller > wrote: > >Is it still appropriate to use sha1 (rather than sha256) with group > >14? Staying with sha1 has the advantage that it reduces the number of > >cryptographic algorithms that must be included in a minimalistic > >implementation of the protocol. > > I don't know, but it certainly would be desirable to stick with sha1. For > one thing, it means the new method can be specified in one sentence, and as > you note, implemented very nearly as easily. DH-GEX uses SHA-1, so if SHA-1 is not appropriate for DH group 14 then it doesn't seem appropriate for DH-GEX either... > It might be desirable to RECOMMEND or even REQUIRE that > diffie-hellman-group14-sha1 be listed _before_ diffie-hellman-group1-sha1, > so that its use is preferred when both sides support it. And of course, I > imagine that implementors will provide policy options to turn off support > for either group. Why not generalize diffie-hellman-group- and recommend group 14 w/ SHA-1? Then when adding new ciphers we can ensure that eash new cipher has a recommended group (and recommended group size for DH-GEX). And then recommend that peers advertise first groups of the recommended size for the cipher with the largest key size. I don't mean to replace DH-GEX by this suggestion, just a quick and easy way to satisfy the IESG's concerns without requiring much effort on the part of any implementors, particularly ones that don't implement DH-GEX. One result of using standardized DH groups is a higher degree of confidence, for clients, in the quality of selected groups over groups offered by servers in DH-GEX. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 18:01:43 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05943 for ; Mon, 14 Jun 2004 18:01:43 -0400 (EDT) Received: (qmail 18751 invoked by uid 605); 14 Jun 2004 22:01:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18742 invoked from network); 14 Jun 2004 22:01:42 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 14 Jun 2004 22:01:42 -0000 Received: from mindrot.org (unknown [172.29.84.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shitei.mindrot.org (Postfix) with ESMTP id 2DCCF27C187; Tue, 15 Jun 2004 08:01:20 +1000 (EST) Message-ID: <40CE1F3A.8050601@mindrot.org> Date: Tue, 15 Jun 2004 07:57:14 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040312) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Cc: Jeffrey Hutzelman , =?ISO-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> In-Reply-To: <20040614163443.GA352198@soe-austin.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >>I don't know, but it certainly would be desirable to stick with sha1. For >>one thing, it means the new method can be specified in one sentence, and as >>you note, implemented very nearly as easily. > > DH-GEX uses SHA-1, so if SHA-1 is not appropriate for DH group 14 then > it doesn't seem appropriate for DH-GEX either... If the issue is that sha1 only returns 160 bits, insufficient to fully populate the keys for aes192-cbc and aes256-cbc then I don't believe that this is a practical prolem (maybe in ~70 years) and certainly not one to delay publication over. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 18:18:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07824 for ; Mon, 14 Jun 2004 18:18:32 -0400 (EDT) Received: (qmail 3272 invoked by uid 605); 14 Jun 2004 22:18:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3263 invoked from network); 14 Jun 2004 22:18:31 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 14 Jun 2004 22:18:31 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5EMINil021828; Mon, 14 Jun 2004 16:18:23 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5EMI7cE007150; Mon, 14 Jun 2004 16:18:08 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5EMFDWw778308; Mon, 14 Jun 2004 17:15:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5EMFBS7778307; Mon, 14 Jun 2004 17:15:11 -0500 (CDT) Date: Mon, 14 Jun 2004 17:15:11 -0500 From: Nicolas Williams To: Damien Miller Cc: Jeffrey Hutzelman , Niels =?unknown-8bit?Q?M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <20040614221511.GQ748675@binky.central.sun.com> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CE1F3A.8050601@mindrot.org> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jun 15, 2004 at 07:57:14AM +1000, Damien Miller wrote: > Nicolas Williams wrote: > >>I don't know, but it certainly would be desirable to stick with sha1. For > >>one thing, it means the new method can be specified in one sentence, and as > >>you note, implemented very nearly as easily. > > > > DH-GEX uses SHA-1, so if SHA-1 is not appropriate for DH group 14 then > > it doesn't seem appropriate for DH-GEX either... > > If the issue is that sha1 only returns 160 bits, insufficient to fully > populate the keys for aes192-cbc and aes256-cbc then I don't believe > that this is a practical prolem (maybe in ~70 years) and certainly not > one to delay publication over. I don't think it's a practical problem now, no. But parametrizing the SSHv2 DH kex (diffie-hellman-group-) shouldn't hold up publication as long as we quickly reach consensus on the meaning of and . I'm not opposed to limitting to SHA-1 to begin with. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 18:34:44 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08580 for ; Mon, 14 Jun 2004 18:34:43 -0400 (EDT) Received: (qmail 18744 invoked by uid 605); 14 Jun 2004 22:34:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18735 invoked from network); 14 Jun 2004 22:34:42 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 14 Jun 2004 22:34:42 -0000 Received: from mindrot.org (unknown [172.29.84.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shitei.mindrot.org (Postfix) with ESMTP id 2163C27C187; Tue, 15 Jun 2004 08:34:21 +1000 (EST) Message-ID: <40CE2800.5020902@mindrot.org> Date: Tue, 15 Jun 2004 08:34:40 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040312) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Cc: Jeffrey Hutzelman , =?ISO-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> In-Reply-To: <20040614221511.GQ748675@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > I don't think it's a practical problem now, no. > > But parametrizing the SSHv2 DH kex (diffie-hellman-group-) > shouldn't hold up publication as long as we quickly reach consensus > on the meaning of and . Throughout the protocol, all of these fields are names, not parameters. Parametising one but not all may give implemntors the idea that they have the ability to pick and choose (e.g. cipher key lengths). I think we should specify diffie-hellman-group1-sha1 (MUST), diffie-hellman-group14-sha1 (RECOMMENDED or MUST), perhaps recommend DH-GEX (ideally *in* the DH-GEX document when it is advanced) and leave it at that. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 18:46:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09853 for ; Mon, 14 Jun 2004 18:46:28 -0400 (EDT) Received: (qmail 27863 invoked by uid 605); 14 Jun 2004 22:46:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27853 invoked from network); 14 Jun 2004 22:46:28 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 14 Jun 2004 22:46:28 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5EMkLJ6012785; Mon, 14 Jun 2004 15:46:21 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5EMk6cE016416; Mon, 14 Jun 2004 16:46:06 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5EMhDc0778319; Mon, 14 Jun 2004 17:43:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5EMhDms778318; Mon, 14 Jun 2004 17:43:13 -0500 (CDT) Date: Mon, 14 Jun 2004 17:43:13 -0500 From: Nicolas Williams To: Damien Miller Cc: Jeffrey Hutzelman , Niels =?unknown-8bit?Q?M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <20040614224313.GR748675@binky.central.sun.com> References: <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CE2800.5020902@mindrot.org> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jun 15, 2004 at 08:34:40AM +1000, Damien Miller wrote: > Nicolas Williams wrote: > > I don't think it's a practical problem now, no. > > > > But parametrizing the SSHv2 DH kex (diffie-hellman-group-) > > shouldn't hold up publication as long as we quickly reach consensus > > on the meaning of and . > > Throughout the protocol, all of these fields are names, not parameters. > Parametising one but not all may give implemntors the idea that they > have the ability to pick and choose (e.g. cipher key lengths). They are names, but there's no reason that we can't parametrize names for the simple DH kex. I see no reason why we couldn't let implementors pick and choose as long as there are required ones for interop. > I think we should specify diffie-hellman-group1-sha1 (MUST), > diffie-hellman-group14-sha1 (RECOMMENDED or MUST), perhaps recommend > DH-GEX (ideally *in* the DH-GEX document when it is advanced) and leave > it at that. I don't oppose this. I do prefer that we parametrize the DH kex in addition, but that is not essential. Whatever else we do though, let's make sure that the DH group namespace is consistent going forward; we can use "group14" or "group2" now, but then after that we should follow the whichever convention in adding new groups. And I do prefer "group14" over "group2" because that places the DH group namespace control in one place. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 18:51:41 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10126 for ; Mon, 14 Jun 2004 18:51:41 -0400 (EDT) Received: (qmail 2985 invoked by uid 605); 14 Jun 2004 22:51:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2966 invoked from network); 14 Jun 2004 22:51:39 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 14 Jun 2004 22:51:39 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa29363; 14 Jun 2004 18:50 EDT Date: Mon, 14 Jun 2004 18:50:49 -0400 From: Jeffrey Hutzelman To: Damien Miller , Nicolas Williams cc: =?ISO-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <799020000.1087253449@minbar.fac.cs.cmu.edu> In-Reply-To: <40CE2800.5020902@mindrot.org> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, June 15, 2004 08:34:40 +1000 Damien Miller wrote: > Nicolas Williams wrote: >> I don't think it's a practical problem now, no. >> >> But parametrizing the SSHv2 DH kex (diffie-hellman-group-) >> shouldn't hold up publication as long as we quickly reach consensus >> on the meaning of and . > > Throughout the protocol, all of these fields are names, not parameters. > Parametising one but not all may give implemntors the idea that they > have the ability to pick and choose (e.g. cipher key lengths). > > I think we should specify diffie-hellman-group1-sha1 (MUST), > diffie-hellman-group14-sha1 (RECOMMENDED or MUST), perhaps recommend > DH-GEX (ideally *in* the DH-GEX document when it is advanced) and leave > it at that. I still believe that recommending DH-GEX in the core document is better than doing so only in the DH-GEX document. People can claim to implement ssh without having ever _read_ the DH-GEX document. Other than that, I'm inclined to agree. We should adopt the groupNN convention informally, but making it a formal parameter seems to invite implementors to interpret other names the same way. At this point I don't think we have any disagreement that - we should specify diffie-hellman-group14-sha1 - it should be at least RECOMMENDED (I prefer REQUIRED; who objects?) - we should not specify other hashes at this time From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 19:58:45 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14143 for ; Mon, 14 Jun 2004 19:58:45 -0400 (EDT) Received: (qmail 24021 invoked by uid 605); 14 Jun 2004 23:58:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24008 invoked from network); 14 Jun 2004 23:58:39 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 14 Jun 2004 23:58:39 -0000 Received: by shitei.mindrot.org (Postfix, from userid 1000) id C742D27C187; Tue, 15 Jun 2004 09:58:17 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by shitei.mindrot.org (Postfix) with ESMTP id BDC5827D804 for ; Tue, 15 Jun 2004 09:58:17 +1000 (EST) Message-ID: <40CE34E7.7040303@mindrot.org> Date: Tue, 15 Jun 2004 09:29:43 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Nicolas Williams , =?ISO-8859-1?Q?Niels_M?= =?ISO-8859-1?Q?=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <799020000.1087253449@minbar.fac.cs.cmu.edu> In-Reply-To: <799020000.1087253449@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > I still believe that recommending DH-GEX in the core document is better > than doing so only in the DH-GEX document. People can claim to implement > ssh without having ever _read_ the DH-GEX document. Well, DH-GEX seems to need a little more work than the core docs and it has not received as much scrutiny. If mentioning a document that will not likely be published until well after the core docs is deemed acceptable, then we don't oppose it. > Other than that, I'm inclined to agree. We should adopt the groupNN > convention informally, but making it a formal parameter seems to invite > implementors to interpret other names the same way. > > At this point I don't think we have any disagreement that > - we should specify diffie-hellman-group14-sha1 > - it should be at least RECOMMENDED (I prefer REQUIRED; who objects?) > - we should not specify other hashes at this time Agree. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 20:24:49 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15234 for ; Mon, 14 Jun 2004 20:24:49 -0400 (EDT) Received: (qmail 16073 invoked by uid 605); 15 Jun 2004 00:24:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16063 invoked from network); 15 Jun 2004 00:24:47 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Jun 2004 00:24:47 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa29514; 14 Jun 2004 20:24 EDT Date: Mon, 14 Jun 2004 20:24:32 -0400 From: Jeffrey Hutzelman To: Damien Miller cc: Nicolas Williams , =?ISO-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <814300000.1087259072@minbar.fac.cs.cmu.edu> In-Reply-To: <40CE34E7.7040303@mindrot.org> References: <200406110214.i5B2Ec7O006766@thunk.east.sun.com> <20040611075122.GD29105@folly> <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <799020000.1087253449@minbar.fac.cs.cmu.edu> <40CE34E7.7040303@mindrot.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, June 15, 2004 09:29:43 +1000 Damien Miller wrote: > Jeffrey Hutzelman wrote: > >> I still believe that recommending DH-GEX in the core document is better >> than doing so only in the DH-GEX document. People can claim to >> implement ssh without having ever _read_ the DH-GEX document. > > Well, DH-GEX seems to need a little more work than the core docs and it > has not received as much scrutiny. If mentioning a document that will > not likely be published until well after the core docs is deemed > acceptable, then we don't oppose it. According to the ID-tracker, this document went through IESG-wide last call back in January, and there are very few comments on record, all procedural. It sure looks to me like it needs little more than for the editor to submit a new document which addresses the remaining issues. Can someone who knows please explain whether this is correct, and if not, what is the real status of this document? If we want to put a normative reference to DH-GEX into the core document, we can do so. It will hold up publication until DH-GEX is published, but only at the last minute (like, RFC-Editor will sit on the completed document until the references can all be resolved). I don't consider that to be a big deal, especially since I think the actual delay will be zero. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 21:27:34 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18943 for ; Mon, 14 Jun 2004 21:27:33 -0400 (EDT) Received: (qmail 7757 invoked by uid 605); 15 Jun 2004 01:27:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7724 invoked from network); 15 Jun 2004 01:27:31 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 15 Jun 2004 01:27:30 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA14477; Mon, 14 Jun 2004 21:27:29 -0400 (EDT) From: der Mouse Message-Id: <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Mon, 14 Jun 2004 21:18:55 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley In-Reply-To: <20040614224313.GR748675@binky.central.sun.com> References: <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> But parametrizing the SSHv2 DH kex (diffie-hellman-group-) >>> shouldn't hold up publication as long as we quickly reach consensus >>> on the meaning of and . >> Throughout the protocol, all of these fields are names, not >> parameters. Parametising one but not all may give implemntors the >> idea that they have the ability to pick and choose (e.g. cipher key >> lengths). > They are names, but there's no reason that we can't parametrize names > for the simple DH kex. I see no reason why we couldn't let > implementors pick and choose as long as there are required ones for > interop. By parameterizing, here, are we talking about something like diffie-hellman-groupN-HASH is a valid method name for any N for which $REFERENCE defines a group, and any HASH for which . or are we talking about diffie-hellman-groupN-HASH is a method name; the first protocol packet contains the group number and the hash name ... or are we talking about standardizing group14-sha1 and group1-sha1 and, in our own minds, reserving the rest of the diffie-hellman-group%d-%s namespace for future specification along similar lines? My own impression has been that we've been doing the last of these, but now I'm not sure. For what it's worth, I agree with >> I think we should specify diffie-hellman-group1-sha1 (MUST), >> diffie-hellman-group14-sha1 (RECOMMENDED or MUST), perhaps recommend >> DH-GEX (ideally *in* the DH-GEX document when it is advanced) and >> leave it at that. As for... > we can use "group14" or "group2" now, but then after that we should > follow the whichever convention in adding new groups. ...for what it's worth, I prefer group14, with the group1/group2 confusion grandfathered. (If it were entirely up to me, I'd define group2 as the official name for the old one, with group1 as a deprecated equivalent for the sake of interoperability.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 21:28:13 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18972 for ; Mon, 14 Jun 2004 21:28:12 -0400 (EDT) Received: (qmail 8376 invoked by uid 605); 15 Jun 2004 01:28:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8367 invoked from network); 15 Jun 2004 01:28:11 -0000 Received: from citi.umich.edu (141.211.133.111) by mail.netbsd.org with SMTP; 15 Jun 2004 01:28:11 -0000 Received: by citi.umich.edu (Postfix, from userid 104123) id 675802080A; Mon, 14 Jun 2004 21:28:10 -0400 (EDT) Date: Mon, 14 Jun 2004 21:28:10 -0400 From: Niels Provos To: Jeffrey Hutzelman Cc: Damien Miller , Nicolas Williams , Niels =?iso-8859-1?Q?M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <20040615012810.GB915@citi.citi.umich.edu> Mail-Followup-To: Jeffrey Hutzelman , Damien Miller , Nicolas Williams , Niels =?iso-8859-1?Q?M=F6ller?= , ietf-ssh@NetBSD.org References: <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <799020000.1087253449@minbar.fac.cs.cmu.edu> <40CE34E7.7040303@mindrot.org> <814300000.1087259072@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814300000.1087259072@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jun 14, 2004 at 08:24:32PM -0400, Jeffrey Hutzelman wrote: > According to the ID-tracker, this document went through IESG-wide last call > back in January, and there are very few comments on record, all procedural. > It sure looks to me like it needs little more than for the editor to submit > a new document which addresses the remaining issues. Can someone who knows > please explain whether this is correct, and if not, what is the real status > of this document? It's on my TODO list. I will have a new draft sometime this week. Niels. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 14 22:12:24 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21795 for ; Mon, 14 Jun 2004 22:12:24 -0400 (EDT) Received: (qmail 14461 invoked by uid 605); 15 Jun 2004 02:12:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14431 invoked from network); 15 Jun 2004 02:12:19 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 15 Jun 2004 02:12:19 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5F2CHJ6019947; Mon, 14 Jun 2004 19:12:18 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5F2CHcc019110; Mon, 14 Jun 2004 22:12:17 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5F2CHaX013185; Mon, 14 Jun 2004 22:12:17 -0400 (EDT) Message-Id: <200406150212.i5F2CHaX013185@thunk.east.sun.com> From: Bill Sommerfeld To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley In-Reply-To: Your message of "Mon, 14 Jun 2004 21:18:55 EDT." <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> Reply-to: sommerfeld@east.sun.com Date: Mon, 14 Jun 2004 22:12:17 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > By parameterizing, here, are we talking about something like > > diffie-hellman-groupN-HASH is a valid method name for any N for > which $REFERENCE defines a group, and any HASH for which > . some seem to be implying this. > or are we talking about > > diffie-hellman-groupN-HASH is a method name; the first protocol > packet contains the group number and the hash name ... I haven't seen any indication that anyone was seriously suggesting this; moreover, I believe this breaks group negotiation unless all parties agree in advance to support all groups (which sort of defeats the purpose) since you can't add parameters to the offered group.. > or are we talking about standardizing group14-sha1 and group1-sha1 and, > in our own minds, reserving the rest of the diffie-hellman-group%d-%s > namespace for future specification along similar lines? > > My own impression has been that we've been doing the last of these, but > now I'm not sure. I believe consensus is congealing around this option. Anyone who believes otherwise should speak up ASAP. > > we can use "group14" or "group2" now, but then after that we should > > follow the whichever convention in adding new groups. > > ...for what it's worth, I prefer group14, with the group1/group2 > confusion grandfathered. (If it were entirely up to me, I'd define > group2 as the official name for the old one, with group1 as a > deprecated equivalent for the sake of interoperability.) I'm speculating that the ssh group 1 == ike group 2 confusion arose from a desire to have a distinct group number space for the two protocols. If you're going to use the same groups at each bit size, that makes no sense to me. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 11:50:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28478 for ; Tue, 15 Jun 2004 11:50:07 -0400 (EDT) Received: (qmail 25413 invoked by uid 605); 15 Jun 2004 15:50:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25403 invoked from network); 15 Jun 2004 15:50:05 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Jun 2004 15:50:05 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30726; 15 Jun 2004 11:49 EDT Date: Tue, 15 Jun 2004 11:49:42 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <999270000.1087314582@minbar.fac.cs.cmu.edu> In-Reply-To: <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> References: <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, June 14, 2004 21:18:55 -0400 der Mouse wrote: >>>> But parametrizing the SSHv2 DH kex (diffie-hellman-group-) >>>> shouldn't hold up publication as long as we quickly reach consensus >>>> on the meaning of and . >>> Throughout the protocol, all of these fields are names, not >>> parameters. Parametising one but not all may give implemntors the >>> idea that they have the ability to pick and choose (e.g. cipher key >>> lengths). >> They are names, but there's no reason that we can't parametrize names >> for the simple DH kex. I see no reason why we couldn't let >> implementors pick and choose as long as there are required ones for >> interop. > > By parameterizing, here, are we talking about something like > > diffie-hellman-groupN-HASH is a valid method name for any N for > which $REFERENCE defines a group, and any HASH for which > . Yes, that's what Nico meant when he proposed parameterizing these kex method names, at least for the case where HASH is 'sha1'. The advantage is that if we do this, we then have a well-defined kex method for any of the standard Oakley MODP groups, including any defined in the future, without having to define them separately in each document. This is analogous to the approach we take with the GSSAPI key exchanges, where there is automatically a well-defined SSH key exchange for any GSSAPI mechanism that meets certain requirements. I think it was understood that the HASH namespace would really just be cases defined by this WG, but that any suitable value of N would be usable without a new specification. > or are we talking about > > diffie-hellman-groupN-HASH is a method name; the first protocol > packet contains the group number and the hash name ... No, we're certainly not doing this. Or rather, we are; the method name in question is diffie-hellman-group-exchange-sha1, and it is defined in draft-ietf-secsh-dh-group-exchange-04.txt. But it is not the subject of this discussion. Note that we're mostly talking about group selection here. I don't think anyone is seriously considering another hash, and it's not at all clear that there's a convenient namespace to draw hash names from as there is for groups. Of course, for any specific hash we want to use it is easy to write a document that says "diffie-hellman-group1-FOO specifies Diffie-Hellman key exchange as described in [ssh-transport] Section 8 with [... description of the FOO hash ...] as the hash and Oakley Group 2 [RFC2409] (1024bit MODP Group).". If we make "groupN" a parameter, the text changes somewhat: "For any N>2, if RFC2412 or its successors define Oakley group N as a MODP group, then diffie-hellman-groupN-FOO specifies Diffie-Hellman key exchange as described in [ssh-transport] Section 8 with [... description of the FOO hash ...] as the hash and the specified group." And of course, it is easy to write similar text for DH-GEX. > or are we talking about standardizing group14-sha1 and group1-sha1 and, > in our own minds, reserving the rest of the diffie-hellman-group%d-%s > namespace for future specification along similar lines? We've pretty much agreed we're going to do at least this much. The question is whether we will formalize the groupN syntax, such that other groups can be used without explicit specification. > ...for what it's worth, I prefer group14, with the group1/group2 > confusion grandfathered. (If it were entirely up to me, I'd define > group2 as the official name for the old one, with group1 as a > deprecated equivalent for the sake of interoperability.) Actually, I don't think anyone's spoken up who _doesn't_ prefer the "group14" nomenclature. But I don't think we should assign an alternate name to diffie-hellman-group1-sha1 -- I can see no benefit to having multiple names for the same thing. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 11:54:17 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28748 for ; Tue, 15 Jun 2004 11:54:17 -0400 (EDT) Received: (qmail 952 invoked by uid 605); 15 Jun 2004 15:53:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 939 invoked from network); 15 Jun 2004 15:53:56 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 15 Jun 2004 15:53:56 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2004 08:56:10 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5FFrstV012668 for ; Tue, 15 Jun 2004 08:53:55 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA24428 for ; Tue, 15 Jun 2004 08:53:54 -0700 (PDT) Date: Tue, 15 Jun 2004 08:53:54 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, From all of the notes on this subject, it looks like we may have some consensus on how to address this issue. Many thanks to everyone who partifipated in this discussion; it helps to move us forward. I believe that this is going to require edits to 4 places in the documents. [TRANSPORT] - revise section 8.1 (formerly titled "diffie-hellman-group1-sha1") 8.1 Required Key Exchange Methods Two methods for key exchange are defined in this document. The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit MODP Group). This method MUST be supported for interoperability as all of the known implementations currently support it. The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit MODP Group), and it MUST also be supported. [NUMBERS] - Add a line in the current Section 4.3 4.3 Key Exchange Method Names The Key Exchange Method Name describes a key-exchange method for the protocol [SSH-TRANS]. The names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignment of new key-exchange method names must be accompanied by a reference to a standards-track or Informational RFC which describes this method. Method name Reference ------------ --------- diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1] diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.1] [ARCHITECTURE] (2 changes needed) (1) Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically names diffie-hellman-group1-sha1. This can be changed to "the key exchange methods described in Section 8.1 in [TRANS]". (2) A new section 9.2.8 will be needed to discuss the ordering of key exchange method proposals. Currently, [TRANS] Section 7.1 states: ------------------- kex_algorithms Key exchange algorithms were defined above. The first algorithm MUST be the preferred (and guessed) algorithm. If both sides make the same guess, that algorithm MUST be used. Otherwise, the following algorithm MUST be used to choose a key exchange method: iterate over client's kex algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: + the server also supports the algorithm, + if the algorithm requires an encryption-capable host key, there is an encryption-capable algorithm on the server's server_host_key_algorithms that is also supported by the client, and + if the algorithm requires a signature-capable host key, there is a signature-capable algorithm on the server's server_host_key_algorithms that is also supported by the client. + If no algorithm satisfying all these conditions can be found, the connection fails, and both sides MUST disconnect. ------------------- The proposed new section in [ARCH] will say: As stated in Section 7.1 of [TRANS], each device will send a list of methods for key exchange. The preferred method will be the first in the list. The preferred method SHOULD be the cryptographically strongest method, and the method most likely to satisfy the conditions stated in that section. Of the two methods defined in Section 8.1 of [TRANS], diffie-hellman-group14-sha1 MUST be listed before diffie-hellman-group1-sha1 in the kex list. Implementors are encouraged to review current literature to decide upon the order of any other locally defined kex methods listed in the kex proposal. These edits do _not_ address the following items: - Parameterizing the kex namespace. - Using SSH"group1" when we mean IKE"group2". From what I understand, making changes to this would have interoperability ramifications to the deployed products. - Referencing DH-GEX. If there is strong consensus from the WG that any of these issues really needs to be addressed, I will work on them. Can I get some feedback on these proposed changes and the items I'm not addressing? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 12:05:07 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29301 for ; Tue, 15 Jun 2004 12:05:06 -0400 (EDT) Received: (qmail 10854 invoked by uid 605); 15 Jun 2004 16:05:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10842 invoked from network); 15 Jun 2004 16:05:04 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 15 Jun 2004 16:05:04 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id EA8C911677A; Tue, 15 Jun 2004 18:05:02 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 3AAA311683B; Tue, 15 Jun 2004 18:04:52 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5FG4qGU028336; Tue, 15 Jun 2004 18:04:52 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5FG4oBW028330; Tue, 15 Jun 2004 18:04:50 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> <999270000.1087314582@minbar.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 15 Jun 2004 18:04:50 +0200 In-Reply-To: <999270000.1087314582@minbar.fac.cs.cmu.edu> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > If we make "groupN" a parameter, the text changes somewhat: > "For any N>2, if RFC2412 or its successors define Oakley group N as a > MODP group, then diffie-hellman-groupN-FOO specifies Diffie-Hellman As far as I'm aware, the requirement above that a group is of the "modp" kind is unnecessary. Not that I'm planning to implementing any more fancy groups (like EC, discussed some weeks ago) anytime soon, but SSH diffie-hellman exchange should work fine with any group where the DH-problem is hard. For groups where it's not obvious how to represent an element as a single bignum, the mapping from group elements to byte strings would also have to be specified somewhere, of course. Anyway, I think this parameterization thing is unnecessarily complicated. We need one more fix group, let's just do that. If we find that we need another fix group in the future (e.g. if dh-group-exchange for some reason isn't universally accepted as the way to go, or if we want ec-groups, or whatever), then it's simple to choose another fix group and a suitable name for it when the need arises. > Actually, I don't think anyone's spoken up who _doesn't_ prefer the > "group14" nomenclature. But I don't think we should assign an > alternate name to diffie-hellman-group1-sha1 -- I can see no benefit > to having multiple names for the same thing. Agree totally. Keep it simple. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 12:19:04 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29927 for ; Tue, 15 Jun 2004 12:19:03 -0400 (EDT) Received: (qmail 25437 invoked by uid 605); 15 Jun 2004 16:19:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25418 invoked from network); 15 Jun 2004 16:19:00 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Jun 2004 16:19:00 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30753; 15 Jun 2004 12:17 EDT Date: Tue, 15 Jun 2004 12:17:33 -0400 From: Jeffrey Hutzelman To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <1011330000.1087316253@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, June 15, 2004 08:53:54 -0700 Chris Lonvick wrote: > Hi Folks, > > From all of the notes on this subject, it looks like we may have some > consensus on how to address this issue. Many thanks to everyone who > partifipated in this discussion; it helps to move us forward. I believe > that this is going to require edits to 4 places in the documents. > > > [TRANSPORT] - revise section 8.1 (formerly titled > "diffie-hellman-group1-sha1") > > 8.1 Required Key Exchange Methods > > Two methods for key exchange are defined in this document. > > The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key > exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit > MODP Group). This method MUST be supported for interoperability as all > of the known implementations currently support it. > > The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key > exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit > MODP Group), and it MUST also be supported. I don't like the section name. Structurally, this section isn't about defining required methods; it's about defining some specific methods that build on the functional description in the section before. IMHO this would work better with separate sections 8.1 and 8.2, defining diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1, resepectively. In any case, the new method needs to be listed in section 6.5, "Key Exchange Methods". > [NUMBERS] - Add a line in the current Section 4.3 Fine. > [ARCHITECTURE] (2 changes needed) > > (1) > Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically names > diffie-hellman-group1-sha1. This can be changed to "the key exchange > methods described in Section 8.1 in [TRANS]". Make it section 8. Really, the statement applies to anything built on that general description, including new methods that may be defined in the future with different groups or hashes. > (2) > A new section 9.2.8 will be needed to discuss the ordering of key exchange > method proposals. Currently, [TRANS] Section 7.1 states: > ------------------- > kex_algorithms > Key exchange algorithms were defined above. The first > algorithm MUST be the preferred (and guessed) algorithm. If > both sides make the same guess, that algorithm MUST be used. > Otherwise, the following algorithm MUST be used to choose a key > exchange method: iterate over client's kex algorithms, one at a > time. Choose the first algorithm that satisfies the following > conditions: > + the server also supports the algorithm, > + if the algorithm requires an encryption-capable host key, > there is an encryption-capable algorithm on the server's > server_host_key_algorithms that is also supported by the > client, and > + if the algorithm requires a signature-capable host key, > there is a signature-capable algorithm on the server's > server_host_key_algorithms that is also supported by the > client. > + If no algorithm satisfying all these conditions can be > found, the connection fails, and both sides MUST disconnect. > ------------------- > The proposed new section in [ARCH] will say: > > As stated in Section 7.1 of [TRANS], each device will send a list of > methods for key exchange. The preferred method will be the first in > the list. The preferred method SHOULD be the cryptographically > strongest method, and the method most likely to satisfy the conditions > stated in that section. The conditions are all about negotiating a method which both sides support. The only way to choose an order such that the preferred method is "likely to satisfy" these conditions is to choose one that you think the peer supports, and for which there is a suitable host key algorithm that you think the peer supports. That would imply either waiting for the other side's KEXINIT message (both sides can't do this, and neither should), or making guesses based on the version string. I propose dropping everything after the last comma. > Of the two methods defined in Section 8.1 of > [TRANS], diffie-hellman-group14-sha1 MUST be listed before > diffie-hellman-group1-sha1 in the kex list. I don't think we have concensus for this requirement. > - Parameterizing the kex namespace. I don't feel real strongly about this one way or the other. I don't think we have agreement to do it yet, and I'm not sure how important it is. > - Using SSH"group1" when we mean IKE"group2". From what I understand, > making changes to this would have interoperability ramifications to the > deployed products. Yeah; it would suck. > - Referencing DH-GEX. I don't think this needs to be much more than a line in section 6.5 of the transport draft listing diffie-hellman-group-exchange-sha1 as a RECOMMENDED method, plus a mention somewhere in section 9.2 of the architecture draft. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 12:21:35 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00093 for ; Tue, 15 Jun 2004 12:21:35 -0400 (EDT) Received: (qmail 28002 invoked by uid 605); 15 Jun 2004 16:21:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27993 invoked from network); 15 Jun 2004 16:21:34 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 15 Jun 2004 16:21:34 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5FGLXil019013; Tue, 15 Jun 2004 10:21:33 -0600 (MDT) Received: from soe-austin.central.sun.com (soe-austin.Central.Sun.COM [10.1.194.2]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5FGLXcE025752; Tue, 15 Jun 2004 10:21:33 -0600 (MDT) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5FGLWom994142; Tue, 15 Jun 2004 11:21:32 -0500 (CDT) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5FGLVH0994141; Tue, 15 Jun 2004 11:21:31 -0500 (CDT) Date: Tue, 15 Jun 2004 11:21:31 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <20040615162128.GA991408@soe-austin.central.sun.com> References: <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jun 14, 2004 at 09:18:55PM -0400, der Mouse wrote: > >>> But parametrizing the SSHv2 DH kex (diffie-hellman-group-) > >>> shouldn't hold up publication as long as we quickly reach consensus > >>> on the meaning of and . > >> Throughout the protocol, all of these fields are names, not > >> parameters. Parametising one but not all may give implemntors the > >> idea that they have the ability to pick and choose (e.g. cipher key > >> lengths). > > They are names, but there's no reason that we can't parametrize names > > for the simple DH kex. I see no reason why we couldn't let > > implementors pick and choose as long as there are required ones for > > interop. > > By parameterizing, here, are we talking about something like > > diffie-hellman-groupN-HASH is a valid method name for any N for > which $REFERENCE defines a group, and any HASH for which > . Though I have no fundamental objections to this, it does seem to go too far. > or are we talking about > > diffie-hellman-groupN-HASH is a method name; the first protocol > packet contains the group number and the hash name ... No. > or are we talking about standardizing group14-sha1 and group1-sha1 and, > in our own minds, reserving the rest of the diffie-hellman-group%d-%s > namespace for future specification along similar lines? Yes, but, I'd like the namespace reservation to be a bit more than just "in our minds" -- though we can't bind subsequent changes to SSHv2 to a group naming policy, we can certainly recommend one in the spec. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 12:34:15 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00843 for ; Tue, 15 Jun 2004 12:34:15 -0400 (EDT) Received: (qmail 10299 invoked by uid 605); 15 Jun 2004 16:34:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10254 invoked from network); 15 Jun 2004 16:34:04 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Jun 2004 16:34:04 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30765; 15 Jun 2004 12:33 EDT Date: Tue, 15 Jun 2004 12:33:44 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <1015860000.1087317224@minbar.fac.cs.cmu.edu> In-Reply-To: References: <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> <999270000.1087314582@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Tuesday, June 15, 2004 18:04:50 +0200 Niels M=F6ller=20 wrote: > Jeffrey Hutzelman writes: > >> If we make "groupN" a parameter, the text changes somewhat: >> "For any N>2, if RFC2412 or its successors define Oakley group N as a >> MODP group, then diffie-hellman-groupN-FOO specifies Diffie-Hellman > > As far as I'm aware, the requirement above that a group is of the > "modp" kind is unnecessary. Not that I'm planning to implementing any > more fancy groups (like EC, discussed some weeks ago) anytime soon, > but SSH diffie-hellman exchange should work fine with any group where > the DH-problem is hard. For groups where it's not obvious how to > represent an element as a single bignum, the mapping from group > elements to byte strings would also have to be specified somewhere, of > course. Sure; there's certainly no reason other groups wouldn't work. But as you=20 note, the wire representation of group elements would have to be defined=20 for those groups where they're not single integers, including EC groups.=20 In addition, the method description in section 8 embeds the MODP group=20 operation; for this method to be well-defined with other groups, the=20 description would have to be generalized. Really, I don't expect there will be any new ECP or EC2N Oakley groups.=20 But the existing groups 3 and 4 are both EC2N groups, and I didn't want to=20 give anyone ideas about trying to use these groups when the protocol is not = well-defined for them. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 12:41:39 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01254 for ; Tue, 15 Jun 2004 12:41:39 -0400 (EDT) Received: (qmail 19388 invoked by uid 605); 15 Jun 2004 16:41:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19372 invoked from network); 15 Jun 2004 16:41:37 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Jun 2004 16:41:37 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30774; 15 Jun 2004 12:41 EDT Date: Tue, 15 Jun 2004 12:41:06 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <1016940000.1087317666@minbar.fac.cs.cmu.edu> In-Reply-To: <20040615162128.GA991408@soe-austin.central.sun.com> References: <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> <20040615162128.GA991408@soe-austin.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, June 15, 2004 11:21:31 -0500 Nicolas Williams wrote: > Yes, but, I'd like the namespace reservation to be a bit more than just > "in our minds" -- though we can't bind subsequent changes to SSHv2 to > a group naming policy, we can certainly recommend one in the spec. [TRANSPORT] 8.1 diffie-hellman-group1-sha1 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit MODP Group). This method MUST be supported for interoperability as all of the known implementations currently support it. Note that, for historical reasons, this method is named using the phrase "group1" even though it specifies the use of Oakley Group 2. 8.2 diffie-hellman-group14-sha1 The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit MODP Group), and it MUST also be supported. [NUMBERS] 4.3 Key Exchange Method Names ... Note that, for historical reasons, the name "diffie-hellman-group1-sha1" is used for a key exchange method using Oakley Group 2. This is considered an aberration and should not be repeated. Any future specifications of Diffie Hellman key exchange using Oakley groups defined in [RFC2412] or its successors should be named using the group numbers assigned by IANA, and names of the form "diffie-hellman-groupN-sha1" should be reserved for this purpose. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 13:15:46 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03278 for ; Tue, 15 Jun 2004 13:15:46 -0400 (EDT) Received: (qmail 21450 invoked by uid 605); 15 Jun 2004 17:14:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21429 invoked from network); 15 Jun 2004 17:14:42 -0000 Received: from brmea-mail-4.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 15 Jun 2004 17:14:42 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5FHCs53002393; Tue, 15 Jun 2004 11:12:54 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5FHEPcE020163; Tue, 15 Jun 2004 11:14:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5FHBlLo782640; Tue, 15 Jun 2004 12:12:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5FHBkL2782639; Tue, 15 Jun 2004 12:11:46 -0500 (CDT) Date: Tue, 15 Jun 2004 12:11:46 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <20040615171146.GE748675@binky.central.sun.com> References: <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> <20040615162128.GA991408@soe-austin.central.sun.com> <1016940000.1087317666@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1016940000.1087317666@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jun 15, 2004 at 12:41:06PM -0400, Jeffrey Hutzelman wrote: > wrote: > >Yes, but, I'd like the namespace reservation to be a bit more than just > >"in our minds" -- though we can't bind subsequent changes to SSHv2 to > >a group naming policy, we can certainly recommend one in the spec. > > [TRANSPORT] > > 8.1 diffie-hellman-group1-sha1 > The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key > exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit > MODP Group). This method MUST be supported for interoperability as all > of the known implementations currently support it. Note that, for > historical reasons, this method is named using the phrase "group1" > even though it specifies the use of Oakley Group 2. > > 8.2 diffie-hellman-group14-sha1 > > The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key > exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit > MODP Group), and it MUST also be supported. > > > [NUMBERS] > > 4.3 Key Exchange Method Names > > ... > > Note that, for historical reasons, the name "diffie-hellman-group1-sha1" > is used for a key exchange method using Oakley Group 2. This is > considered an aberration and should not be repeated. Any future > specifications of Diffie Hellman key exchange using Oakley groups > defined in [RFC2412] or its successors should be named using the > group numbers assigned by IANA, and names of the form > "diffie-hellman-groupN-sha1" should be reserved for this purpose. No mention of HASH functions other than SHA-1? Should there be an IANA registry for SSHv2 kex names? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 13:23:05 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03611 for ; Tue, 15 Jun 2004 13:23:04 -0400 (EDT) Received: (qmail 1937 invoked by uid 605); 15 Jun 2004 17:22:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1926 invoked from network); 15 Jun 2004 17:22:58 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Jun 2004 17:22:58 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30836; 15 Jun 2004 13:22 EDT Date: Tue, 15 Jun 2004 13:22:35 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <1027270000.1087320155@minbar.fac.cs.cmu.edu> In-Reply-To: <20040615171146.GE748675@binky.central.sun.com> References: <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> <20040615162128.GA991408@soe-austin.central.sun.com> <1016940000.1087317666@minbar.fac.cs.cmu.edu> <20040615171146.GE748675@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, June 15, 2004 12:11:46 -0500 Nicolas Williams wrote: > No mention of HASH functions other than SHA-1? Eh; I was going to write that text and decided not to. > Should there be an IANA > registry for SSHv2 kex names? Indeed there should. It is defined in section 4.3 of draft-ietf-secsh-assignednumbers-06.txt, which is the section I was proposing to append text to. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 13:54:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05152 for ; Tue, 15 Jun 2004 13:54:46 -0400 (EDT) Received: (qmail 689 invoked by uid 605); 15 Jun 2004 17:54:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 668 invoked from network); 15 Jun 2004 17:54:40 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 15 Jun 2004 17:54:40 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id DFEA1D8B2B; Tue, 15 Jun 2004 19:54:38 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id BC454E0C6B; Tue, 15 Jun 2004 19:54:26 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5FHsQGU029758; Tue, 15 Jun 2004 19:54:26 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5FHsOSk029755; Tue, 15 Jun 2004 19:54:24 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 15 Jun 2004 19:54:23 +0200 In-Reply-To: Message-ID: Lines: 101 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > [TRANSPORT] - revise section 8.1 (formerly titled > "diffie-hellman-group1-sha1") Looks ok. > [NUMBERS] - Add a line in the current Section 4.3 > The Key Exchange Method Name describes a key-exchange method for the > protocol [SSH-TRANS]. The names MUST be printable US-ASCII strings, > and MUST NOT contain the characters at-sign ('@'), comma (','), or > whitespace or control characters (ASCII codes 32 or less). Names are > case-sensitive, and MUST NOT be longer than 64 characters. This is the same for all algorithm names. It would make sense to describe this name syntax in *one* place, and not repeat it several times in the document. Besides from that nit, it looks ok to me. > [ARCHITECTURE] (2 changes needed) > > (1) > Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically names > diffie-hellman-group1-sha1. This can be changed to "the key exchange > methods described in Section 8.1 in [TRANS]". Or just make it clear that diffie-hellman-group1-sha1 is an *example* of a specified key exchange method that have PFS-properties. > A new section 9.2.8 will be needed to discuss the ordering of key exchange > method proposals. Currently, [TRANS] Section 7.1 states: I don't think this is needed at all. To me, the rules are the same as for all the other algorithm lists: Each client lists the algorithms it is willing to use, in the client's preferred order. The client's preferences can be based on perceived relative strength, or on cpu cost, or on explicit user configuration. It's totally up to the client to decide. The key exchange method is no different, in this respect, than the host key algorithm list, encryption algorithm list and mac algorithm list. > As stated in Section 7.1 of [TRANS], each device will send a list of > methods for key exchange. The preferred method will be the first in > the list. The preferred method SHOULD be the cryptographically > strongest method, and the method most likely to satisfy the conditions > stated in that section. Of the two methods defined in Section 8.1 of > [TRANS], diffie-hellman-group14-sha1 MUST be listed before > diffie-hellman-group1-sha1 in the kex list. Implementors are > encouraged to review current literature to decide upon the order of any > other locally defined kex methods listed in the kex proposal. "You can get this nice car in any color of your choice, as long as your choice is black", or "You must put the algorithm you prefer first, and you MUST prefer the one I say". It makes the word "prefer" meaningless. I *strongly* object to having MUSTs and SHOULDs here. And I'd prefer not having this section at all. If we, now or in the future, really want to deprecate diffie-hellman-group1-sha1, the right way to do that is to *formally* deprecate it, by changing diffie-hellman-group1-sha1 REQUIRED diffie-hellman-group14-sha1 REQUIRED to diffie-hellman-group1-sha1 DEPRECATED diffie-hellman-group14-sha1 REQUIRED in the appropriate document. I don't want any semi-deprecated state that is is buried elsewhere in the text, and in particular, the architecture document is *not* the right place. > - Parameterizing the kex namespace. I see no need to do anything formal about that. > - Using SSH"group1" when we mean IKE"group2". From what I understand, > making changes to this would have interoperability ramifications to the > deployed products. Don't change diffie-hellman-group1-sha1, it's too late. Also, a new alias for the same thing is unnecessary and pointless. > - Referencing DH-GEX. > > If there is strong consensus from the WG that any of these issues really > needs to be addressed, I will work on them. I don't have any strong opinion on that. I don't think it's necessary; the dh-gex spec seems to be the right place for recommending dh-gex. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 14:20:49 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06332 for ; Tue, 15 Jun 2004 14:20:48 -0400 (EDT) Received: (qmail 27260 invoked by uid 605); 15 Jun 2004 18:20:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27240 invoked from network); 15 Jun 2004 18:20:40 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Jun 2004 18:20:40 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30888; 15 Jun 2004 14:19 EDT Date: Tue, 15 Jun 2004 14:19:12 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Chris Lonvick cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley Message-ID: <1039990000.1087323552@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Tuesday, June 15, 2004 19:54:23 +0200 Niels M=F6ller=20 wrote: > Chris Lonvick writes: >> [ARCHITECTURE] (2 changes needed) >> >> (1) >> Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically >> names diffie-hellman-group1-sha1. This can be changed to "the key >> exchange methods described in Section 8.1 in [TRANS]". > > Or just make it clear that diffie-hellman-group1-sha1 is an *example* of > a specified key exchange method that have PFS-properties. > >> A new section 9.2.8 will be needed to discuss the ordering of key >> exchange method proposals. Currently, [TRANS] Section 7.1 states: > > I don't think this is needed at all. To me, the rules are the same as > for all the other algorithm lists: Each client lists the algorithms it > is willing to use, in the client's preferred order. I'm not sure if you're commenting here on the proposed ARCH/9.2.8 text, or=20 on the TRANS/7.1 text which Chris actually quoted at this point. The=20 quoted text was existing text from the transport draft, and is the=20 normative description of the algorithm selection rules for key exchange=20 (which are a bit more complicated than for others). It needn't be=20 duplicated in the architecture document, but I don't think that was being=20 proposed. >> As stated in Section 7.1 of [TRANS], each device will send a list of >> methods for key exchange. The preferred method will be the first in >> the list. The preferred method SHOULD be the cryptographically >> strongest method, and the method most likely to satisfy the = conditions >> stated in that section. Of the two methods defined in Section 8.1 of >> [TRANS], diffie-hellman-group14-sha1 MUST be listed before >> diffie-hellman-group1-sha1 in the kex list. Implementors are >> encouraged to review current literature to decide upon the order of >> any other locally defined kex methods listed in the kex proposal. > > "You can get this nice car in any color of your choice, as long as > your choice is black", or "You must put the algorithm you prefer > first, and you MUST prefer the one I say". It makes the word "prefer" > meaningless. I'm inclined to agree; MUST is too strong. > If we, now or in the future, really want to deprecate > diffie-hellman-group1-sha1, the right way to do that is to *formally* > deprecate it, by changing Careful. REQUIRED means must-implement. DEPRECATED doesn't mean anything, = requirements-wise. We want people to implement group1 but not prefer it.=20 We do not want people not to implement it, at least now. > the text, and in particular, the architecture document is *not* the > right place. The security considerations section is a perfectly reasonable place for=20 advice on algorithm selection, to the extent that we want to give such=20 advice. I'm still inclined to think we should provide some advice like=20 "prefer diffie-hellman-group14-sha1". On further reflection, I think it gets even more fun... For some symmetric ciphers, group1 will be good enough. For others, it will not. What this means is that we should avoid selecting a cipher for which the=20 kex does not provide enough keying material. Or, more likely, we should=20 avoid selecting a kex that does not provide enough keying material for the=20 cipher we're going to use. Unfortunately, that would mean changing the=20 algorithm selection rules, and I think it's too late to do that without a=20 really good reason. As it stands now, we could end up negotiating diffie-hellman-group1-sha1=20 and, say, aes256-cbc, which woule not be very good. So, IMHO there's a good security reason for giving advice about selecting a larger group. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 16:05:31 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13274 for ; Tue, 15 Jun 2004 16:05:31 -0400 (EDT) Received: (qmail 4293 invoked by uid 605); 15 Jun 2004 20:05:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4275 invoked from network); 15 Jun 2004 20:05:27 -0000 Received: from brmea-mail-4.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 15 Jun 2004 20:05:27 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5FK2K53026156; Tue, 15 Jun 2004 14:02:20 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5FK46ii004202; Tue, 15 Jun 2004 16:04:06 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5FK45x7018060; Tue, 15 Jun 2004 16:04:06 -0400 (EDT) Message-Id: <200406152004.i5FK45x7018060@thunk.east.sun.com> From: Bill Sommerfeld To: Jeffrey Hutzelman cc: =?ISO-8859-1?Q?Niels_M=F6ller?= , Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley In-Reply-To: Your message of "Tue, 15 Jun 2004 14:19:12 EDT." <1039990000.1087323552@minbar.fac.cs.cmu.edu> Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jun 2004 16:04:05 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list [wg chair hat off]. We have to cope with a grab bag of algorithms at seemingly random bit-strengths that don't necessarily fit together well if you try to tune one to match the other. I think that's the wrong attitude.. > What this means is that we should avoid selecting a cipher for which the > kex does not provide enough keying material. Reality check: so, if the kex provides N bits, and you have a choice between a cipher with keysize N/2 and keysize 2N, you would prefer the N/2-bit cipher to running a 2N bit cipher with what is effectively a stretched N-bit key? The latter is obviously stronger against brute force attacks. > Or, more likely, we should avoid selecting a kex that does not > provide enough keying material for the cipher we're going to use. > Unfortunately, that would mean changing the algorithm selection > rules, and I think it's too late to do that without a really good > reason. Going outside the scope of the IETF spec and deep into quality-of-implementation space: I'd rather see an application-level requirement for a specific strength-in-bits. If the kex generates enough bits, add it to the acceptable list. Likewise, if the symmetric algorithm is N-bits-strong against all known attacks, add it to the list. Then sort the lists by the performance metric of your choice (throughput, latency, etc.,). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 17:20:46 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17306 for ; Tue, 15 Jun 2004 17:20:45 -0400 (EDT) Received: (qmail 14554 invoked by uid 605); 15 Jun 2004 21:20:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14533 invoked from network); 15 Jun 2004 21:20:43 -0000 Received: from mailhost.wrq.com (HELO ein.wrq.com) (150.215.214.117) by mail.netbsd.org with SMTP; 15 Jun 2004 21:20:43 -0000 Received: from abra.na.wrq.com (wrq.com [150.215.15.20]) by ein.wrq.com (8.12.8/8.12.8) with ESMTP id i5FKvCnM020148; Tue, 15 Jun 2004 13:57:12 -0700 Received: by abra.na.wrq.com with Internet Mail Service (5.5.2657.72) id ; Tue, 15 Jun 2004 13:57:11 -0700 Message-ID: <1A6B6A5A3597C340BB63728001DC78795A72A7@kodos.na.wrq.com> From: Scott Rankin To: "'Chris Lonvick'" , "'ietf-ssh@NetBSD.org'" Cc: "'openssh@roumenpetrov.info'" Subject: RE: I-D ACTION:draft-ietf-secsh-transport-18.txt Date: Tue, 15 Jun 2004 13:57:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list Sorry if this is already known. I couldn't look in the bug tracking system as it required a username and password. Just a couple questions. In section 6.6 Public Key Algorithms. x509v3-sign-rsa and x509v3-sign-dss are listed as "defined" formats. That said, I have been unable to find where these are defined (and there is no citation of this definition in this section). Perhaps this is why RFC2459 (and soon to be RFC3280 per earlier mails) was listed in the References at the end of the document? Is it RFC3280 or RFC3279 which defines x509v3-sign-rsa and x509v3-sign-dss? All the other public key algorithms have at least an additional sentence below the table of formats as well. Maybe that is all the document needs. I have scoured through the mailing list archives and the ietf pkix working group and secsh internet drafts and rfcs and have come up dry. Any thoughts? This sentence, "The key type MUST always be explicitly known (from algorithm negotiation or some other source)" sounds awkward to me. I think it is the combination of MUST and always. It seems redundant. cheers, scott rankin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 17:35:38 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18040 for ; Tue, 15 Jun 2004 17:35:37 -0400 (EDT) Received: (qmail 26307 invoked by uid 605); 15 Jun 2004 21:35:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26285 invoked from network); 15 Jun 2004 21:35:35 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 15 Jun 2004 21:35:34 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id AAF7912BF72; Tue, 15 Jun 2004 23:35:33 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id C346212BFA5; Tue, 15 Jun 2004 23:35:17 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5FLZHGU002706; Tue, 15 Jun 2004 23:35:17 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5FLZGPs002703; Tue, 15 Jun 2004 23:35:16 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <1039990000.1087323552@minbar.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 15 Jun 2004 23:35:16 +0200 In-Reply-To: <1039990000.1087323552@minbar.fac.cs.cmu.edu> Message-ID: Lines: 91 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > > I don't think this is needed at all. To me, the rules are the same as > > for all the other algorithm lists: Each client lists the algorithms it > > is willing to use, in the client's preferred order. > > I'm not sure if you're commenting here on the proposed ARCH/9.2.8 > text, or on the TRANS/7.1 text which Chris actually quoted at this > point. Sorry if I was unclear. I didn't want to comment the old text in section 7.1 of the transport draft, which is about how to select the algorithm to use from the given lists. That's a little too hairy for my taste, but if it works (I don't know, I haven't really tested the "algorithm guessing" part), then we should *not* touch it now. I wanted to comment the new text, which says in which order a client should or must list its algorithms. I.e. the text which restricts the set of allowed input to the algorithm selection procedure. > The security considerations section is a perfectly reasonable place > for advice on algorithm selection, to the extent that we want to give > such advice. This is partly a question of taste. The way I see the architectures document, it should describe the overall structure of the protocol and the components, which roles the various parts play, what security properties the parts are expected to have, data types and background needed in many places, etc. I'd find it easier to accept a general recommendation that if there are no other particular reason to prefer a certain algorithm over the other, clients should list algorithms ordered by strength, strongest first. Such a recommendation applies equally to all of the key exchange, host key, encryption and mac algorithm lists. Comments on particular algorithms seem out of place. If we really need that, the security considerations section of the transport draft seems like more natural place to me. > On further reflection, I think it gets even more fun... > For some symmetric ciphers, group1 will be good enough. > For others, it will not. > What this means is that we should avoid selecting a cipher for which > the kex does not provide enough keying material. I don't buy this reasoning at all. The security requirements are determined by the context in which the connection is made, not by the key size of negotiated ciphers. Say you have estimated that you need "100-bit security" (I'm not going to try to define this rigorously, I hope you understand what I mean). Then you can use a 110-bit key exchange method, and a 256-bit cipher and a 256-bit mac. That's fine. The important thing is that *both* are strong enough. Or you can also use a 200-bit key exchange, a 128-bit cipher and a 160-bit mac. That's fine too. It *doesn't matter* if the weakest link happens to be the key exchange or the cipher, as long as it's strong enough. And it makes no sense to strive towards a system where all links are of equal strength; if some link happens to be much stronger than necessary, what's the problem with that? And I agree with Bill that if we want to replace preferences of the form "I want group14 and aes256" (like in the implementations I'm aware of) with preferences of the form "I want at least 100-bit security", then that's excellent. It can be implemented in servers and clients, and in all cases it affects *which* algorithms are listed, not their order. As long as only algorithms that have adequate security are listed, order doesn't matter. > As it stands now, we could end up negotiating > diffie-hellman-group1-sha1 and, say, aes256-cbc, which woule not be > very good. In this case, depending on the circumstances, either group1 is harder to crack than your enemies can afford, or it isn't. If group1 is strong enough, then (diffie-hellman-group1-sha1 + aes256-cbc) is adequate, and so is (diffie-hellman-group1-sha1 + 3des-cbc). And I'd choose aes256-cbc, since the overall security will be the same, and aes256 likely is significantly faster. And if your enemies do have a discrete log table for group1, or you suspect that they might have, *don't* list that group, in any order, ever. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 15 18:22:45 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22731 for ; Tue, 15 Jun 2004 18:22:44 -0400 (EDT) Received: (qmail 15105 invoked by uid 605); 15 Jun 2004 22:22:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15086 invoked from network); 15 Jun 2004 22:22:43 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 15 Jun 2004 22:22:42 -0000 Received: from mindrot.org (unknown [172.29.84.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shitei.mindrot.org (Postfix) with ESMTP id EB52127C18E for ; Wed, 16 Jun 2004 08:22:18 +1000 (EST) Message-ID: <40CF76A5.9080508@mindrot.org> Date: Wed, 16 Jun 2004 08:22:29 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040312) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <20040611180044.GB593949@soe-austin.central.sun.com> <200406111905.PAA09490@Sparkle.Rodents.Montreal.QC.CA> <40CC4E5D.9080508@mindrot.org> <539620000.1087154894@minbar.fac.cs.cmu.edu> <20040614163443.GA352198@soe-austin.central.sun.com> <40CE1F3A.8050601@mindrot.org> <20040614221511.GQ748675@binky.central.sun.com> <40CE2800.5020902@mindrot.org> <20040614224313.GR748675@binky.central.sun.com> <200406150127.VAA14477@Sparkle.Rodents.Montreal.QC.CA> <999270000.1087314582@minbar.fac.cs.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Anyway, I think this parameterization thing is unnecessarily > complicated. We need one more fix group, let's just do that. If we > find that we need another fix group in the future (e.g. if > dh-group-exchange for some reason isn't universally accepted as the > way to go, or if we want ec-groups, or whatever), then it's simple to > choose another fix group and a suitable name for it when the need > arises. Agree From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 03:01:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13645 for ; Wed, 16 Jun 2004 03:01:07 -0400 (EDT) Received: (qmail 14804 invoked by uid 605); 16 Jun 2004 07:01:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14794 invoked from network); 16 Jun 2004 07:01:04 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 16 Jun 2004 07:01:04 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 3E1F27FD30; Wed, 16 Jun 2004 09:01:03 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 51D497FEF2; Wed, 16 Jun 2004 09:00:48 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5G70lGU009587; Wed, 16 Jun 2004 09:00:48 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5G70kMo009584; Wed, 16 Jun 2004 09:00:46 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Scott Rankin Cc: "'Chris Lonvick'" , "'ietf-ssh@NetBSD.org'" , "'openssh@roumenpetrov.info'" Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt References: <1A6B6A5A3597C340BB63728001DC78795A72A7@kodos.na.wrq.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 16 Jun 2004 09:00:45 +0200 In-Reply-To: <1A6B6A5A3597C340BB63728001DC78795A72A7@kodos.na.wrq.com> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Scott Rankin writes: > x509v3-sign-rsa and x509v3-sign-dss are listed as "defined" formats. That > said, I have been unable to find where these are defined (and there is no > citation of this definition in this section). The last thing this group said on x509, iirc, was that use of x509 needs to be specified in more detail, and that it should be done in a separate document. And that separate document doesn't yet exist. I think someone mentioned that there exists one or two implementations that support x509, so my advice is that you figure out what they do, and try to get it written down. (Personally, I'm not very interested in x509, so I may have missed something). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 09:10:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24143 for ; Wed, 16 Jun 2004 09:10:13 -0400 (EDT) Received: (qmail 21674 invoked by uid 605); 16 Jun 2004 13:10:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21650 invoked from network); 16 Jun 2004 13:10:09 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 16 Jun 2004 13:10:09 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 16 Jun 2004 06:12:33 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5GDA6In014841; Wed, 16 Jun 2004 06:10:06 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA22949; Wed, 16 Jun 2004 06:10:06 -0700 (PDT) Date: Wed, 16 Jun 2004 06:10:06 -0700 (PDT) From: Chris Lonvick To: Scott Rankin cc: "'ietf-ssh@NetBSD.org'" , "'openssh@roumenpetrov.info'" Subject: RE: I-D ACTION:draft-ietf-secsh-transport-18.txt In-Reply-To: <1A6B6A5A3597C340BB63728001DC78795A72A7@kodos.na.wrq.com> Message-ID: References: <1A6B6A5A3597C340BB63728001DC78795A72A7@kodos.na.wrq.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Scott, I've opened Ticket #474: "WG - transport - x509v3-sign-*" from your excellent catch. The responses so far indicate that it's been well discussed before so hopefully we can resolve this one quickly. The instructions for the Issue Tracker are here: http://rt.psg.com/ Access to the Issue Tracker starts here: https://rt.psg.com/ If you're not one of the people who can open/close/modify tickets, then your access is with username = ietf password = ietf Thanks, Chris On Tue, 15 Jun 2004, Scott Rankin wrote: > Sorry if this is already known. I couldn't look in the bug tracking system > as it required a username and password. > > Just a couple questions. > > In section 6.6 Public Key Algorithms. > > x509v3-sign-rsa and x509v3-sign-dss are listed as "defined" formats. That > said, I have been unable to find where these are defined (and there is no > citation of this definition in this section). > > Perhaps this is why RFC2459 (and soon to be RFC3280 per earlier mails) was > listed in the References at the end of the document? > > Is it RFC3280 or RFC3279 which defines x509v3-sign-rsa and x509v3-sign-dss? > > All the other public key algorithms have at least an additional sentence > below the table of formats as well. Maybe that is all the document needs. > > I have scoured through the mailing list archives and the ietf pkix working > group and secsh internet drafts and rfcs and have come up dry. Any thoughts? > > > This sentence, > "The key type MUST always be explicitly known (from algorithm > negotiation or some other source)" sounds awkward to me. I think it is > the combination of MUST and always. It seems redundant. > > > cheers, > scott rankin > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 09:14:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24224 for ; Wed, 16 Jun 2004 09:14:28 -0400 (EDT) Received: (qmail 2473 invoked by uid 605); 16 Jun 2004 12:14:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2460 invoked from network); 16 Jun 2004 12:14:27 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 16 Jun 2004 12:14:27 -0000 Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id B69761CD965; Wed, 16 Jun 2004 23:57:00 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BaZ2j-0003zN-TO; Wed, 16 Jun 2004 23:57:25 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: clonvick@cisco.com, ietf-ssh@NetBSD.org, scottra@wrq.com Subject: RE: I-D ACTION:draft-ietf-secsh-transport-18.txt Cc: openssh@roumenpetrov.info In-Reply-To: <1A6B6A5A3597C340BB63728001DC78795A72A7@kodos.na.wrq.com> Message-Id: Date: Wed, 16 Jun 2004 23:57:25 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Scott Rankin writes: >x509v3-sign-rsa and x509v3-sign-dss are listed as "defined" formats. That >said, I have been unable to find where these are defined (and there is no >citation of this definition in this section). The last time this came up I dug through the entire archives and posted a summary of all the posts I could find on the topic (it'll be in the archives somewhere, grep for my From: address). The conclusion was that no-one could agree on how this should work, and no-one was interested enough to sit down and sort it out. Unfortunately those two ID strings are still present in the spec although they're not useful for anything, I think it'd be best to either remove them entirely (make them accessible via a vendor-specific string if anyone does actually want to use them), or just include a note to say that these values exist for historical purposes but aren't used for anything, sort of like the "entry" keyword in K&R C. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 09:14:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24242 for ; Wed, 16 Jun 2004 09:14:32 -0400 (EDT) Received: (qmail 29347 invoked by uid 605); 16 Jun 2004 09:14:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29326 invoked from network); 16 Jun 2004 09:14:31 -0000 Received: from 213-240-201-51.ddns.cablebg.net (HELO master.workstation.localhost) (213.240.201.51) by mail.netbsd.org with SMTP; 16 Jun 2004 09:14:30 -0000 Received: from roumenpetrov.info (localhost [127.0.0.1]) by master.workstation.localhost (8.12.4/8.12.4) with ESMTP id i5G9E9ZR001106; Wed, 16 Jun 2004 12:14:10 +0300 Message-ID: <40D00F61.3050301@roumenpetrov.info> Date: Wed, 16 Jun 2004 12:14:09 +0300 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: bg, ru, de-de, de, en-us, en MIME-Version: 1.0 To: Scott Rankin CC: "'Chris Lonvick'" , "'ietf-ssh@NetBSD.org'" Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt References: <1A6B6A5A3597C340BB63728001DC78795A72A7@kodos.na.wrq.com> In-Reply-To: <1A6B6A5A3597C340BB63728001DC78795A72A7@kodos.na.wrq.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi Scott, Following lines mysterious disappear after draft-ietf-secsh-transport-12.txt (I guess). ================================================ .... The "x509v3-sign-rsa" method indicates that the certificates, the public key, and the resulting signature are in X.509v3 compatible DER-encoded format. The formats used in X.509v3 is described in [RFC-2459]. This method indicates that the key (or one of the keys in the certificate) is an RSA-key. The "x509v3-sign-dss". As above, but indicates that the key (or one of the keys in the certificate) is a DSS-key. ================================================ Might ssh.com don't like other to implement X.509 certificates support ? To write new draft for 5 lines as some people suggest (see list archive) is waste of time. Note that their secsh implementation don't support X.509 certificates. Scott Rankin wrote: >Sorry if this is already known. I couldn't look in the bug tracking system >as it required a username and password. > >Just a couple questions. > >In section 6.6 Public Key Algorithms. > >x509v3-sign-rsa and x509v3-sign-dss are listed as "defined" formats. That >said, I have been unable to find where these are defined (and there is no >citation of this definition in this section). > >Perhaps this is why RFC2459 (and soon to be RFC3280 per earlier mails) was >listed in the References at the end of the document? > >Is it RFC3280 or RFC3279 which defines x509v3-sign-rsa and x509v3-sign-dss? > >All the other public key algorithms have at least an additional sentence >below the table of formats as well. Maybe that is all the document needs. > >I have scoured through the mailing list archives and the ietf pkix working >group and secsh internet drafts and rfcs and have come up dry. Any thoughts? > > >This sentence, >"The key type MUST always be explicitly known (from algorithm > negotiation or some other source)" sounds awkward to me. I think it is >the combination of MUST and always. It seems redundant. > > >cheers, >scott rankin > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 09:16:35 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24286 for ; Wed, 16 Jun 2004 09:16:35 -0400 (EDT) Received: (qmail 1572 invoked by uid 605); 16 Jun 2004 09:16:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1555 invoked from network); 16 Jun 2004 09:16:33 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 16 Jun 2004 09:16:33 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id C1ECE433DA; Wed, 16 Jun 2004 11:23:08 +0200 (CEST) Message-ID: <40D011B0.6020105@siliconcircus.com> Date: Wed, 16 Jun 2004 11:24:00 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: =?ISO-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley References: <1039990000.1087323552@minbar.fac.cs.cmu.edu> In-Reply-To: <1039990000.1087323552@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, I'd argue for text more like this: ----- As stated in Section 7.1 of [TRANS], each device will send a list of methods for key exchange. The most-preferred method is the first in the list. Implementations are free to determine their default preferences based upon relative cryptographic security, performance or other criteria. If only the two methods defined in Section 8.1 of [TRANS] are are implemented, it is RECOMMENDED that diffie-hellman-group14-sha1 be listed before diffie-hellman-group1-sha1 in the kex list. ---- Where this text belongs is a different question - [ARCH] is probably wrong, in my opinion. This seems more like an issue for the Security Considerations section of [TRANS]. The text above would obviously need reformatting if it were moved there. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 09:35:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24683 for ; Wed, 16 Jun 2004 09:35:14 -0400 (EDT) Received: (qmail 16357 invoked by uid 605); 16 Jun 2004 12:31:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16301 invoked from network); 16 Jun 2004 12:31:08 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 16 Jun 2004 12:31:08 -0000 Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id CA2451CD969; Thu, 17 Jun 2004 00:04:23 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BaZ9t-0003zi-2N; Thu, 17 Jun 2004 00:04:49 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: openssh@roumenpetrov.info, scottra@wrq.com Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt Cc: clonvick@cisco.com, ietf-ssh@NetBSD.org In-Reply-To: <40D00F61.3050301@roumenpetrov.info> Message-Id: Date: Thu, 17 Jun 2004 00:04:49 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Roumen Petrov writes: >The "x509v3-sign-rsa" method indicates that the certificates, the public key, >and the resulting signature are in X.509v3 compatible DER-encoded format. The >formats used in X.509v3 is described in [RFC-2459]. This method indicates that >the key (or one of the keys in the certificate) is an RSA-key. This doesn't actually describe the format - it's about as useful to implementors as the equivalent reference to PGP sigs (that is, not at all). These things really should be removed from the spec rather than being left in an undefined state, or at least marked as reserved for future use. >To write new draft for 5 lines as some people suggest (see list archive) is >waste of time. It's going to take a *lot* more than those 5 lines to define everything, and since no-one seems to be interested in it, reserving it to be defined in a separate document is a good idea. If you really want this so badly, you could always write the RFC yourself :-). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 11:08:48 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04002 for ; Wed, 16 Jun 2004 11:08:47 -0400 (EDT) Received: (qmail 6023 invoked by uid 605); 16 Jun 2004 15:08:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5571 invoked from network); 16 Jun 2004 15:07:48 -0000 Received: from liandra.wv.cs.cmu.edu (HELO liandra.pc.cs.cmu.edu) (128.2.67.162) by mail.netbsd.org with SMTP; 16 Jun 2004 15:07:48 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa17296; 15 Jun 2004 21:57 EDT Date: Tue, 15 Jun 2004 21:57:49 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Bill Sommerfeld cc: =?ISO-8859-1?Q?Niels_M=F6ller?= , Chris Lonvick , Subject: Re: [psg.com #460] IESG - Transport - Oakley In-Reply-To: <200406152004.i5FK45x7018060@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 15 Jun 2004, Bill Sommerfeld wrote: > [wg chair hat off]. > > We have to cope with a grab bag of algorithms at seemingly random > bit-strengths that don't necessarily fit together well if you try to > tune one to match the other. I think that's the wrong attitude.. > > > What this means is that we should avoid selecting a cipher for which the > > kex does not provide enough keying material. > > Reality check: > > so, if the kex provides N bits, and you have a choice between a cipher > with keysize N/2 and keysize 2N, you would prefer the N/2-bit cipher > to running a 2N bit cipher with what is effectively a stretched N-bit > key? > > The latter is obviously stronger against brute force attacks. I'd prefer not to be running in either situation without knowing it. Unfortunately, there are a lot of factors, and it's hard to say what combinations are acceptable, so we don't try. We also don't (can't) prevent implementations from rejecting combinations they decide are unacceptable. It seems clear to me that listing the group14 method before the group1 will result in better security and possibly better interoperability. That doesn't mean we need a REQUIREMENT here, but some advice doesn't seem out of line. > > Or, more likely, we should avoid selecting a kex that does not > > provide enough keying material for the cipher we're going to use. > > Unfortunately, that would mean changing the algorithm selection > > rules, and I think it's too late to do that without a really good > > reason. > > Going outside the scope of the IETF spec and deep into > quality-of-implementation space: > > I'd rather see an application-level requirement for a specific > strength-in-bits. If the kex generates enough bits, add it to the > acceptable list. Likewise, if the symmetric algorithm is > N-bits-strong against all known attacks, add it to the list. > > Then sort the lists by the performance metric of your choice > (throughput, latency, etc.,). Yes, that sounds like a good approach for an implementation to take. Of course, DH-GEX makes this real fun -- you can't know what key size it will produce. In other words, yet another multi-level negotiation issue. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 11:09:11 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04173 for ; Wed, 16 Jun 2004 11:09:11 -0400 (EDT) Received: (qmail 6044 invoked by uid 605); 16 Jun 2004 15:08:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5579 invoked from network); 16 Jun 2004 15:07:49 -0000 Received: from liandra.wv.cs.cmu.edu (HELO liandra.pc.cs.cmu.edu) (128.2.67.162) by mail.netbsd.org with SMTP; 16 Jun 2004 15:07:49 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa17334; 15 Jun 2004 22:05 EDT Date: Tue, 15 Jun 2004 22:05:01 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: =?iso-8859-1?q?Niels_M=F6ller?= cc: Chris Lonvick , Subject: Re: [psg.com #460] IESG - Transport - Oakley In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE On 15 Jun 2004, Niels M=F6ller wrote: > I'd find it easier to accept a general recommendation that if there > are no other particular reason to prefer a certain algorithm over the > other, clients should list algorithms ordered by strength, strongest > first. Such a recommendation applies equally to all of the key exchange, > host key, encryption and mac algorithm lists. Sure, that seems like a resonable recommendation to make. > Comments on particular algorithms seem out of place. If we really need > that, the security considerations section of the transport draft seems > like more natural place to me. The transport draft doesn't really have a security considerations section. All the security considerations are collected in the architecture draft, just as we collected all the IANA considerations in one place. > > On further reflection, I think it gets even more fun... > > For some symmetric ciphers, group1 will be good enough. > > For others, it will not. > > > What this means is that we should avoid selecting a cipher for which > > the kex does not provide enough keying material. > > I don't buy this reasoning at all. The security requirements are > determined by the context in which the connection is made, not by the > key size of negotiated ciphers. Yeah, OK. The approach Bill describes makes a lot more sense. And in any case, it can't be anything other than a means of deciding what methods to offer and in what order, which is entirely a matter of implementation and local policy. > And I agree with Bill that if we want to replace preferences of the > form "I want group14 and aes256" (like in the implementations I'm > aware of) with preferences of the form "I want at least 100-bit > security", then that's excellent. It can be implemented in servers and > clients, and in all cases it affects *which* algorithms are listed, > not their order. As long as only algorithms that have adequate > security are listed, order doesn't matter. Yes. Now that it's been suggested, I'd love to see an implementation or three actually do this. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 12:11:58 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15354 for ; Wed, 16 Jun 2004 12:11:57 -0400 (EDT) Received: (qmail 4784 invoked by uid 605); 16 Jun 2004 16:11:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4775 invoked from network); 16 Jun 2004 16:11:56 -0000 Received: from brmea-mail-4.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 16 Jun 2004 16:11:56 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5GG9I53006684; Wed, 16 Jun 2004 10:09:18 -0600 (MDT) Received: from soe-austin.central.sun.com (soe-austin.Central.Sun.COM [10.1.194.2]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5GGB4cE017921; Wed, 16 Jun 2004 10:11:04 -0600 (MDT) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5GGB4EA708121; Wed, 16 Jun 2004 11:11:04 -0500 (CDT) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5GGB1CC708120; Wed, 16 Jun 2004 11:11:01 -0500 (CDT) Date: Wed, 16 Jun 2004 11:11:00 -0500 From: Nicolas Williams To: Peter Gutmann Cc: openssh@roumenpetrov.info, scottra@wrq.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt Message-ID: <20040616161058.GA707160@soe-austin.central.sun.com> Mail-Followup-To: Nicolas Williams , Peter Gutmann , openssh@roumenpetrov.info, scottra@wrq.com, clonvick@cisco.com, ietf-ssh@NetBSD.org References: <40D00F61.3050301@roumenpetrov.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jun 17, 2004 at 12:04:49AM +1200, Peter Gutmann wrote: > Roumen Petrov writes: > >To write new draft for 5 lines as some people suggest (see list archive) is > >waste of time. > > It's going to take a *lot* more than those 5 lines to define everything, and > since no-one seems to be interested in it, reserving it to be defined in a > separate document is a good idea. If you really want this so badly, you could > always write the RFC yourself :-). Yup. And for merely reserving the names the numbers (IANA) doc seems best: " 4.3 Public Key Algorithm Names Algorithm name Reference --------------- --------- ssh-dss [SSH-TRANS, Section 4.6] ssh-rsa [SSH-TRANS, Section 4.6] x509v3-sign-rsa [SSH-TRANS, Section 4.6] x509v3-sign-dss [SSH-TRANS, Section 4.6] spki-sign-rsa [SSH-TRANS, Section 4.6] spki-sign-dss [SSH-TRANS, Section 4.6] pgp-sign-rsa [SSH-TRANS, Section 4.6] pgp-sign-dss [SSH-TRANS, Section 4.6] " Just replace the reference to the transport I-D section 4.6 with "[TBD]" and remove all references to undefined host key algs from the transport I-D. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 12:30:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17207 for ; Wed, 16 Jun 2004 12:30:46 -0400 (EDT) Received: (qmail 20675 invoked by uid 605); 16 Jun 2004 16:30:46 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20040616163046.20672.qmail@mail.netbsd.org> Received: (qmail 20652 invoked from network); 16 Jun 2004 16:30:45 -0000 Received: from ns1.24host-1.net (HELO windowsIBM) (69.59.152.12) by mail.netbsd.org with SMTP; 16 Jun 2004 16:30:45 -0000 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 16 Jun 2004 09:30:37 -0700 To: ietf-ssh@NetBSD.org From: travis@acne-resource.org X-Mailer: Version 5.0 Subject: Trading links with your site Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hello, I am the volunteer administrator for the Acne Resource Center, an informational resource all about Acne; how it develops and how to cope. I am writing you because we are looking to exchange links with other websites. I propose that we exchange links. If you will link to the Acne Resource Center, located at http://www.acne-resource.org/ then I will place a reciprocal link on our links page. Just let me know where you want your link to appear by getting back to me with where your link is located and where you want yours to appear. Also, if you have a short byline for your site, I would be more than happy to add that as well. A sample byline for the Acne Resource Center would be: Explore the Acne Resource Center for hundreds of articles on acne, including research on acne, an in-depth look at the different kinds of acne and how to cope with the emotional effects of acne. If you have any questions, please do not hesitate to ask. Kind regards, Travis Whitley travis@acne-resource.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 16:00:41 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11935 for ; Wed, 16 Jun 2004 16:00:41 -0400 (EDT) Received: (qmail 2964 invoked by uid 605); 16 Jun 2004 20:00:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2955 invoked from network); 16 Jun 2004 20:00:39 -0000 Received: from mailhost.wrq.com (HELO ein.wrq.com) (150.215.214.117) by mail.netbsd.org with SMTP; 16 Jun 2004 20:00:39 -0000 Received: from abra.na.wrq.com (wrq.com [150.215.15.20]) by ein.wrq.com (8.12.8/8.12.8) with ESMTP id i5GK0cnM028987 for ; Wed, 16 Jun 2004 13:00:38 -0700 Received: by abra.na.wrq.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Jun 2004 13:00:37 -0700 Message-ID: <1A6B6A5A3597C340BB63728001DC78795A72AA@kodos.na.wrq.com> From: Scott Rankin To: "'ietf-ssh@NetBSD.org'" Subject: question related to the DH-GEX draft Date: Wed, 16 Jun 2004 13:00:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list I am trying to figure out what NL is (quoted below)? From Section 5 of [1], "... The hash H is computed as the HASH hash of the concatenation of the following: string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded)" It looks to me like [SSH-TRANS] defines these version strings as, SSH-protoversion-softwareversion SP comments CR LF Perhaps this is just a typo and is supposed to read, ... string V_C, the client's version string (CR and LF excluded) string V_S, the server's version string (CR and LF excluded) cheers, scott rankin [1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-04.tx t [SSH-TRANS] http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-18.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 16:03:24 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12018 for ; Wed, 16 Jun 2004 16:03:23 -0400 (EDT) Received: (qmail 6316 invoked by uid 605); 16 Jun 2004 20:03:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6307 invoked from network); 16 Jun 2004 20:03:22 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 16 Jun 2004 20:03:22 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5GK3LJ6011942; Wed, 16 Jun 2004 13:03:21 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5GK3Lii023485; Wed, 16 Jun 2004 16:03:21 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5GK3L06023944; Wed, 16 Jun 2004 16:03:21 -0400 (EDT) Message-Id: <200406162003.i5GK3L06023944@thunk.east.sun.com> From: Bill Sommerfeld To: Scott Rankin cc: "'ietf-ssh@NetBSD.org'" Subject: Re: question related to the DH-GEX draft In-Reply-To: Your message of "Wed, 16 Jun 2004 13:00:31 PDT." <1A6B6A5A3597C340BB63728001DC78795A72AA@kodos.na.wrq.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jun 2004 16:03:21 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I am trying to figure out what NL is (quoted below)? NL=newline. Alternate name for ASCII LF common to folks from the UNIX/C universe. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 20:34:16 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04142 for ; Wed, 16 Jun 2004 20:34:15 -0400 (EDT) Received: (qmail 6636 invoked by uid 605); 17 Jun 2004 00:34:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6619 invoked from network); 17 Jun 2004 00:34:13 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 Jun 2004 00:34:12 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5H0XwJ6027719; Wed, 16 Jun 2004 17:33:58 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5H0Xvcc029035; Wed, 16 Jun 2004 20:33:57 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5H0Xv5K028124; Wed, 16 Jun 2004 20:33:57 -0400 (EDT) Message-Id: <200406170033.i5H0Xv5K028124@thunk.east.sun.com> From: Bill Sommerfeld To: Nicolas Williams cc: Peter Gutmann , openssh@roumenpetrov.info, scottra@wrq.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt In-Reply-To: Your message of "Wed, 16 Jun 2004 11:11:00 CDT." <20040616161058.GA707160@soe-austin.central.sun.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jun 2004 20:33:57 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Date: Wed, 16 Jun 2004 11:11:00 -0500 > From: Nicolas Williams > To: Peter Gutmann > Cc: openssh@roumenpetrov.info, scottra@wrq.com, clonvick@cisco.com, > ietf-ssh@NetBSD.org > Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt > > On Thu, Jun 17, 2004 at 12:04:49AM +1200, Peter Gutmann wrote: > > Roumen Petrov writes: > > >To write new draft for 5 lines as some people suggest (see list archive) is > > >waste of time. > > > > It's going to take a *lot* more than those 5 lines to define everything, and > > since no-one seems to be interested in it, reserving it to be defined in a > > separate document is a good idea. If you really want this so badly, you could > > always write the RFC yourself :-). Indeed. Several attempts to recruit an author for such a document have failed. Any *new* volunteers? > Yup. And for merely reserving the names the numbers (IANA) doc seems > best: > > " > 4.3 Public Key Algorithm Names > > Algorithm name Reference > --------------- --------- > ssh-dss [SSH-TRANS, Section 4.6] > ssh-rsa [SSH-TRANS, Section 4.6] > x509v3-sign-rsa [SSH-TRANS, Section 4.6] > x509v3-sign-dss [SSH-TRANS, Section 4.6] > spki-sign-rsa [SSH-TRANS, Section 4.6] > spki-sign-dss [SSH-TRANS, Section 4.6] > pgp-sign-rsa [SSH-TRANS, Section 4.6] > pgp-sign-dss [SSH-TRANS, Section 4.6] > " > > Just replace the reference to the transport I-D section 4.6 with > "[TBD]" and remove all references to undefined host key algs from the > transport I-D. This is probably the best bet. .. though I've heard rumors that some folks have indeed implemented this and may be using the code point already, in which case we may need to use a different name for the standard version.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 21:02:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05407 for ; Wed, 16 Jun 2004 21:02:47 -0400 (EDT) Received: (qmail 28772 invoked by uid 605); 17 Jun 2004 01:02:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28758 invoked from network); 17 Jun 2004 01:02:45 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 17 Jun 2004 01:02:44 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5H12Zil011364; Wed, 16 Jun 2004 19:02:35 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5H12KcE029252; Wed, 16 Jun 2004 19:02:20 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5H0wvuC788960; Wed, 16 Jun 2004 19:59:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i5H0wu8Y788959; Wed, 16 Jun 2004 19:58:56 -0500 (CDT) Date: Wed, 16 Jun 2004 19:58:56 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: Peter Gutmann , openssh@roumenpetrov.info, scottra@wrq.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt Message-ID: <20040617005856.GL748675@binky.central.sun.com> Mail-Followup-To: Nicolas Williams , Bill Sommerfeld , Peter Gutmann , openssh@roumenpetrov.info, scottra@wrq.com, clonvick@cisco.com, ietf-ssh@NetBSD.org References: <20040616161058.GA707160@soe-austin.central.sun.com> <200406170033.i5H0Xv5K028124@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406170033.i5H0Xv5K028124@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jun 16, 2004 at 08:33:57PM -0400, Bill Sommerfeld wrote: > > Yup. And for merely reserving the names the numbers (IANA) doc seems > > best: [...] > > Just replace the reference to the transport I-D section 4.6 with > > "[TBD]" and remove all references to undefined host key algs from the > > transport I-D. > > This is probably the best bet. > > .. though I've heard rumors that some folks have indeed implemented > this and may be using the code point already, in which case we may > need to use a different name for the standard version.. Not if the standard matches those implementations, yes otherwise. Either way, not an issue until someone steps up to actually spec the x.509 and/or pgp host key algs. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jun 16 23:34:38 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12206 for ; Wed, 16 Jun 2004 23:34:37 -0400 (EDT) Received: (qmail 7259 invoked by uid 605); 17 Jun 2004 03:34:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7250 invoked from network); 17 Jun 2004 03:34:36 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 17 Jun 2004 03:34:36 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA21235; Wed, 16 Jun 2004 23:34:34 -0400 (EDT) From: der Mouse Message-Id: <200406170334.XAA21235@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Wed, 16 Jun 2004 23:31:12 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: question related to the DH-GEX draft In-Reply-To: <1A6B6A5A3597C340BB63728001DC78795A72AA@kodos.na.wrq.com> References: <1A6B6A5A3597C340BB63728001DC78795A72AA@kodos.na.wrq.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I am trying to figure out what NL is (quoted below)? NL is one of the two names (the other one is LF) for the ASCII character with code 10 (0x0a, etc). That character has two names because it is commonly interpreted in two distinct ways: as ine eed or as ew ine. In this case, they should probably be LF, not NL, since NL is appropriate when that single octet performs a new-line function, whereas here, its pairing with CR implies that it is acting as LF rather than NL. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 17 02:10:51 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27223 for ; Thu, 17 Jun 2004 02:10:50 -0400 (EDT) Received: (qmail 17593 invoked by uid 605); 17 Jun 2004 06:10:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17577 invoked from network); 17 Jun 2004 06:10:46 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 17 Jun 2004 06:10:46 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 8AB421F4481; Thu, 17 Jun 2004 07:47:48 +0200 (MEST) Received: from askja.got.appgate.com (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id E84996C025; Thu, 17 Jun 2004 07:47:48 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by askja.got.appgate.com (Postfix) with ESMTP id B89472F6EC; Thu, 17 Jun 2004 07:44:09 +0200 (MEST) Received: from askja.got.appgate.com ([127.0.0.1]) by localhost (askja.got.appgate.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13948-02-7; Thu, 17 Jun 2004 07:44:08 +0200 (MEST) Received: from localhost (pelee.got.appgate.com [172.23.2.10]) by askja.got.appgate.com (Postfix) with ESMTP id 942EC2F6E8; Thu, 17 Jun 2004 07:44:08 +0200 (MEST) Date: Thu, 17 Jun 2004 07:47:36 +0200 (CEST) From: maf@appgate.com Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt To: sommerfeld@east.sun.com Cc: Nicolas.Williams@sun.com, pgut001@cs.auckland.ac.nz, openssh@roumenpetrov.info, scottra@wrq.com, clonvick@cisco.com, ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20040617054408.942EC2F6E8@askja.got.appgate.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 16 Jun, Bill Sommerfeld wrote: > .. though I've heard rumors that some folks have indeed implemented > this and may be using the code point already, in which case we may > need to use a different name for the standard version.. We at Appgate have implemented x509v3 support for both user authentication and host-keys. But since the definition of x509v3-sign-[rd]sa was lacking we used the vendor extension trick, our algorithms are called x509v3-sign-[rd]sa@appgate.com. In other words there is no need to change names for our sake. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 17 02:27:31 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03688 for ; Thu, 17 Jun 2004 02:27:30 -0400 (EDT) Received: (qmail 29650 invoked by uid 605); 17 Jun 2004 06:27:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29636 invoked from network); 17 Jun 2004 06:27:23 -0000 Received: from 213-240-201-51.ddns.cablebg.net (HELO master.workstation.localhost) (213.240.201.51) by mail.netbsd.org with SMTP; 17 Jun 2004 06:27:22 -0000 Received: from roumenpetrov.info (localhost [127.0.0.1]) by master.workstation.localhost (8.12.4/8.12.4) with ESMTP id i5H6R7aM002312; Thu, 17 Jun 2004 09:27:10 +0300 Message-ID: <40D139BB.607@roumenpetrov.info> Date: Thu, 17 Jun 2004 09:27:07 +0300 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: bg, ru, de, en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-transport-18.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: >Roumen Petrov writes: >[SNIP] > >since no-one seems to be interested in it > > Please check secureshell@securityfocus.com and openssh-unix-dev@mindrot.org lists. Note one of request was openssh to support 'x509v3-sign-*' only ;-) ! >[SNIP] > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 17 08:16:10 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23166 for ; Thu, 17 Jun 2004 08:16:10 -0400 (EDT) Received: (qmail 23960 invoked by uid 605); 17 Jun 2004 12:15:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23868 invoked from network); 17 Jun 2004 12:15:47 -0000 Received: from duendo.net (82.144.15.170) by mail.netbsd.org with SMTP; 17 Jun 2004 12:15:46 -0000 Received: from [192.168.0.25] (account jmf@lannet.es HELO juan.duendo.net) by duendo.net (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 726120 for ietf-ssh@netbsd.org; Thu, 17 Jun 2004 13:15:45 +0200 From: Juan Reply-To: jmf@lannet.es To: ietf-ssh@NetBSD.org Subject: Ocultar carpetas de sistema Date: Thu, 17 Jun 2004 13:15:44 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200406171315.44293.jmf@lannet.es> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Buenos d=EDas, Tengo instalado OpenSSH en un servidor Windows, Tengo a cada usuario asigna= do=20 una carpeta de conexi=F3n, pero si desde el cliente le dan a subir a un niv= el=20 superior, pueden ver todo los directorios de OpenSSh, con sus respectivos=20 archivos, donde se encuentran los usuarios y sus directorios de conexi=F3n. =BFExiste alguna forma de que solo se conecten al directorio que esta=20 espec=EDficado y no a los de los programas?. Un saludo, jmf@lannet.es From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 17 19:00:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24150 for ; Thu, 17 Jun 2004 19:00:26 -0400 (EDT) Received: (qmail 21157 invoked by uid 605); 17 Jun 2004 23:00:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21144 invoked from network); 17 Jun 2004 23:00:26 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 17 Jun 2004 23:00:26 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5HN0Fil005716; Thu, 17 Jun 2004 17:00:15 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5HN0Fcc019373; Thu, 17 Jun 2004 19:00:15 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5HN0E2q007680; Thu, 17 Jun 2004 19:00:14 -0400 (EDT) Message-Id: <200406172300.i5HN0E2q007680@thunk.east.sun.com> From: Bill Sommerfeld To: jmf@lannet.es cc: ietf-ssh@NetBSD.org Subject: Re: Ocultar carpetas de sistema In-Reply-To: Your message of "Thu, 17 Jun 2004 13:15:44 +0200." <200406171315.44293.jmf@lannet.es> Reply-to: sommerfeld@east.sun.com Date: Thu, 17 Jun 2004 19:00:14 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I do not speak or read spanish; I fed your message to babelfish.altavista.com and while its translation is rough, it appears that you want help with OpenSSH on windows. Unfortunately, you've reached the wrong list; this list is for the IETF Secure Shell working group's discussion of the ssh protocol and is not for end-user support. Questions regarding the support of specific ssh implementations are better directed at the vendor/supplier/implementor of the particular implementation of ssh you've installed. I believe the OpenSSH folks run a bunch of lists for support questions and the like; see http://openssh.org/list.html (and I'm sure that one of the openssh developers lurking here will speak up if I got this wrong..). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 21 17:14:43 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00491 for ; Mon, 21 Jun 2004 17:14:43 -0400 (EDT) Received: (qmail 27293 invoked by uid 605); 21 Jun 2004 21:14:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27005 invoked from network); 21 Jun 2004 21:14:27 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by mail.netbsd.org with SMTP; 21 Jun 2004 21:14:27 -0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i5LKfQRs014201 for ; Mon, 21 Jun 2004 13:41:26 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA20288 for ; Mon, 21 Jun 2004 13:41:26 -0700 (PDT) Date: Mon, 21 Jun 2004 13:41:26 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: [psg.com #460] IESG - Transport - Oakley - new proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I've gone through all of the notes on this Issue again and now have 6 changes to make to the documents for this. --------------------- (1) [TRANSPORT] - revise section 6.5 6.5 Key Exchange Methods The key exchange method specifies how one-time session keys are generated for encryption and for authentication, and how the server authentication is done. Two REQUIRED key exchange method has been defined: diffie-hellman-group1-sha1 REQUIRED diffie-hellman-group14-sha1 REQUIRED These methods are described later in this document. Additional methods may be defined as specified in [SSH-NUMBERS]. Note that, for historical reasons, the name "diffie-hellman-group1-sha1" is used for a key exchange method using Oakley Group 2. This is considered an aberration and should not be repeated. Any future specifications of Diffie Hellman key exchange using Oakley groups defined in [RFC2412] or its successors should be named using the group numbers assigned by IANA, and names of the form "diffie-hellman-groupN-sha1" should be reserved for this purpose. --------------------- (2) [TRANSPORT] - revise section 8.1 8.1 diffie-hellman-group1-sha1 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit MODP Group). This method MUST be supported for interoperability as all of the known implementations currently support it. Note that, for historical reasons, this method is named using the phrase "group1" even though it specifies the use of Oakley Group 2. --------------------- (3) [TRANSPORT] - add section 8.2 8.2 diffie-hellman-group14-sha1 The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit MODP Group), and it MUST also be supported. --------------------- (4) [NUMBERS] - Add a line in the current Section 4.3 4.3 Key Exchange Method Names The Key Exchange Method Name describes a key-exchange method for the protocol [SSH-TRANS]. The names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignment of new key-exchange method names must be accompanied by a reference to a standards-track or Informational RFC which describes this method. Method name Reference ------------ --------- diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1] diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2] --------------------- (5) [ARCHITECTURE] modify 9.2.7 (Security Considerations for TRANS) Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically names diffie-hellman-group1-sha1. I'd like to reference both defined key exchange methods in this section. Current extract from 9.2.7 SSH sessions resulting from a key exchange using diffie-hellman-group1-sha1 are secure even if private keying/ authentication material is later revealed, but not if the session keys are revealed. So, given this definition of PFS, SSH does have PFS. Change to: SSH sessions resulting from a key exchange using diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are secure even if private keying/ authentication material is later revealed, but not if the session keys are revealed. So, given this definition of PFS, SSH does have PFS. --------------------- (6) [ARCHITECTURE] new section 9.2.8 (Security Considerations for TRANS) A new section 9.2.8 will be needed to discuss the ordering of key exchange method proposals. Currently, [TRANS] Section 7.1 states: +++ kex_algorithms Key exchange algorithms were defined above. The first algorithm MUST be the preferred (and guessed) algorithm. If both sides make the same guess, that algorithm MUST be used. Otherwise, the following algorithm MUST be used to choose a key exchange method: iterate over client's kex algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: + the server also supports the algorithm, + if the algorithm requires an encryption-capable host key, there is an encryption-capable algorithm on the server's server_host_key_algorithms that is also supported by the client, and + if the algorithm requires a signature-capable host key, there is a signature-capable algorithm on the server's server_host_key_algorithms that is also supported by the client. + If no algorithm satisfying all these conditions can be found, the connection fails, and both sides MUST disconnect. +++ The proposed new section in [ARCH] will say: As stated in Section 7.1 of [TRANS], each device will send a list of preferred methods for key exchange. The most-preferred method is the first in the list. Implementations are free to determine their default preferences based upon relative cryptographic security, performance or other criteria. If only the two methods defined in Section 8 of [TRANS] are are implemented, it is RECOMMENDED that diffie-hellman-group14-sha1 be listed before diffie-hellman-group1-sha1 in the kex list. --------------------- Please send back your comments to this proposal. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 21 18:26:23 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10149 for ; Mon, 21 Jun 2004 18:26:23 -0400 (EDT) Received: (qmail 15177 invoked by uid 605); 21 Jun 2004 22:26:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15168 invoked from network); 21 Jun 2004 22:26:22 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 21 Jun 2004 22:26:22 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa26610; 21 Jun 2004 18:25 EDT Date: Mon, 21 Jun 2004 18:25:24 -0400 From: Jeffrey Hutzelman To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal Message-ID: <821280000.1087856724@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, June 21, 2004 13:41:26 -0700 Chris Lonvick wrote: > (1) > [TRANSPORT] - revise section 6.5 > > Two REQUIRED key exchange method has been defined: "have" Otherwise OK. > (2) > [TRANSPORT] - revise section 8.1 OK. > (3) > [TRANSPORT] - add section 8.2 OK. > (4) > [NUMBERS] - Add a line in the current Section 4.3 OK. > (5) > [ARCHITECTURE] modify 9.2.7 (Security Considerations for TRANS) > Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically > names diffie-hellman-group1-sha1. I'd like to reference both defined > key exchange methods in this section. > > Current extract from 9.2.7 > SSH sessions resulting from a key exchange using > diffie-hellman-group1-sha1 are secure even if private keying/ > authentication material is later revealed, but not if the session > keys are revealed. So, given this definition of PFS, SSH does have > PFS. > Change to: > SSH sessions resulting from a key exchange using > diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 > are secure even if private keying/ > authentication material is later revealed, but not if the session > keys are revealed. So, given this definition of PFS, SSH does have > PFS. I guess this is OK, but I would still rather refer to TRANS section 8 in general, rather than to only the specific methods we happen to define. SSH sessions resulting from a key exchange using the diffie-hellman method described in [TRANS] Section 8 (including diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1) are secure even if private keying/authentication material is later revealed, but not if the session keys are revealed. So, given this definition of PFS, SSH does have PFS. > (6) > [ARCHITECTURE] new section 9.2.8 (Security Considerations for TRANS) > A new section 9.2.8 will be needed to discuss the ordering of key > exchange method proposals. I guess that text looks OK to me. I've sort of become indifferent on this; I won't object strongly if people don't want to add this sort of text. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 22 05:39:59 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22557 for ; Tue, 22 Jun 2004 05:39:58 -0400 (EDT) Received: (qmail 27232 invoked by uid 605); 22 Jun 2004 09:39:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27219 invoked from network); 22 Jun 2004 09:39:57 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 22 Jun 2004 09:39:56 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id F3FE194F4C; Tue, 22 Jun 2004 11:39:20 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id DA46810836C; Tue, 22 Jun 2004 11:39:09 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i5M9d9GU000615; Tue, 22 Jun 2004 11:39:09 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i5M9d8TC000612; Tue, 22 Jun 2004 11:39:08 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 22 Jun 2004 11:39:07 +0200 In-Reply-To: Message-ID: Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > [TRANSPORT] - revise section 6.5 > > 6.5 Key Exchange Methods [...] > repeated. Any future specifications of Diffie Hellman key exchange > using Oakley groups defined in [RFC2412] or its successors should be > named using the group numbers assigned by IANA, and names of the form > "diffie-hellman-groupN-sha1" should be reserved for this purpose. ^^^^^^^^^^^^^^^^^^ I'd say "are reserved for this purpose", if such text can go in this document (rather than the numbers document). No need to be vague about the reservation. > [TRANSPORT] - revise section 8.1 Ok. > [TRANSPORT] - add section 8.2 Ok. > 8.2 diffie-hellman-group14-sha1 Ok. > [NUMBERS] - Add a line in the current Section 4.3 Ok. > [ARCHITECTURE] modify 9.2.7 (Security Considerations for TRANS) > Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically > names diffie-hellman-group1-sha1. I'd like to reference both defined > key exchange methods in this section. Ok. > [ARCHITECTURE] new section 9.2.8 (Security Considerations for TRANS) [...] > The proposed new section in [ARCH] will say: > > As stated in Section 7.1 of [TRANS], each device will send a list of > preferred methods for key exchange. The most-preferred method is the > first in the list. Implementations are free to determine their default > preferences based upon relative cryptographic security, performance > or other criteria. If only the two methods defined in Section 8 of > [TRANS] are are implemented, it is RECOMMENDED that > diffie-hellman-group14-sha1 be listed before > diffie-hellman-group1-sha1 in the kex list. I can accept this writing, but I would still prefer that it either be deleted, or be generalized to something like "if an implementation doesn't have any other reason to preferring one algorithm over the other, it's recommended to sort the algorithms by cryptographic strength, strongest first", which applies to all algorithm lists, not just the key exchange method. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 24 11:16:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20691 for ; Thu, 24 Jun 2004 11:16:31 -0400 (EDT) Received: (qmail 8191 invoked by uid 605); 24 Jun 2004 15:16:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8177 invoked from network); 24 Jun 2004 15:16:25 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 24 Jun 2004 15:16:25 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2004 08:20:04 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5OFGM4N012999 for ; Thu, 24 Jun 2004 08:16:22 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA14297 for ; Thu, 24 Jun 2004 08:16:22 -0700 (PDT) Date: Thu, 24 Jun 2004 08:16:22 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, On Tue, 22 Jun 2004, [iso-8859-1] Niels M=F6ller wrote: > Chris Lonvick writes: > > > The proposed new section in [ARCH] will say: > > > > As stated in Section 7.1 of [TRANS], each device will send a list of > > preferred methods for key exchange. The most-preferred method is th= e > > first in the list. Implementations are free to determine their defa= ult > > preferences based upon relative cryptographic security, performance > > or other criteria. If only the two methods defined in Section 8 of > > [TRANS] are are implemented, it is RECOMMENDED that > > diffie-hellman-group14-sha1 be listed before > > diffie-hellman-group1-sha1 in the kex list. > > I can accept this writing, but I would still prefer that it either be > deleted, or be generalized to something like "if an implementation > doesn't have any other reason to preferring one algorithm over the > other, it's recommended to sort the algorithms by cryptographic > strength, strongest first", which applies to all algorithm lists, not > just the key exchange method. also On Tue, 22 Jun 2004, Jeffrey Hutzelman writes: > I guess that text looks OK to me. I've sort of become indifferent on > this; I won't object strongly if people don't want to add this sort of > text. So, it doesn't look like everyone is ready for a group hug on this one. I'll make this alternate proposal for this section: As stated in Section 7.1 of [TRANS], each device will send a list of preferred methods for key exchange. The most-preferred method is the first in the list. Implementators are free to determine their default preferences. If an implementation doesn't have any other reason to preferring one algorithm over the other, it is RECOMMENDED to sort the algorithms by cryptographic strength, strongest first. Some additional guidance for this is given in BCP 86 [RFC 3766]. ftp://ftp.rfc-editor.org/in-notes/rfc3766.txt I'll also find a spot to globalize that for all proposal lists. I need to get some consensus on this so please vote for one of the following: A - Use this wording in a new section. B - Use the old wording in a new section. C - Delete the proposed new section. D - [write-in your new proposal] The default is "A". If I don't hear from anyone, or if the votes received don't give clear consensus, I'll go with that. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jun 24 18:44:10 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24492 for ; Thu, 24 Jun 2004 18:44:09 -0400 (EDT) Received: (qmail 10866 invoked by uid 605); 24 Jun 2004 22:44:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10856 invoked from network); 24 Jun 2004 22:44:08 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 24 Jun 2004 22:44:07 -0000 Received: from mindrot.org (h209-5-161-221.ipplus.ca [209.5.161.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shitei.mindrot.org (Postfix) with ESMTP id 66BDD27C188; Fri, 25 Jun 2004 08:43:22 +1000 (EST) Message-ID: <40DB58D3.3060504@mindrot.org> Date: Thu, 24 Jun 2004 16:42:27 -0600 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040608) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Chris Lonvick wrote: > Hi, > > On Tue, 22 Jun 2004, [iso-8859-1] Niels M?ller wrote: > > >>Chris Lonvick writes: >> >> >>>The proposed new section in [ARCH] will say: >>> >>> As stated in Section 7.1 of [TRANS], each device will send a list of >>> preferred methods for key exchange. The most-preferred method is the >>> first in the list. Implementations are free to determine their default >>> preferences based upon relative cryptographic security, performance >>> or other criteria. If only the two methods defined in Section 8 of >>> [TRANS] are are implemented, it is RECOMMENDED that >>> diffie-hellman-group14-sha1 be listed before >>> diffie-hellman-group1-sha1 in the kex list. >> >>I can accept this writing, but I would still prefer that it either be >>deleted, or be generalized to something like "if an implementation >>doesn't have any other reason to preferring one algorithm over the >>other, it's recommended to sort the algorithms by cryptographic >>strength, strongest first", which applies to all algorithm lists, not >>just the key exchange method. > > > also > > On Tue, 22 Jun 2004, Jeffrey Hutzelman writes: > > >>I guess that text looks OK to me. I've sort of become indifferent on >>this; I won't object strongly if people don't want to add this sort of >>text. > > > > So, it doesn't look like everyone is ready for a group hug on this one. > I'll make this alternate proposal for this section: > > As stated in Section 7.1 of [TRANS], each device will send a list of > preferred methods for key exchange. The most-preferred method is the > first in the list. Implementators are free to determine their default > preferences. If an implementation doesn't have any other reason to > preferring one algorithm over the other, it is RECOMMENDED to sort the > algorithms by cryptographic strength, strongest first. Some additional > guidance for this is given in BCP 86 [RFC 3766]. > ftp://ftp.rfc-editor.org/in-notes/rfc3766.txt I think this is too wordy. It is axiomatic that implementors can determine their own preferences. Perhaps this: > As stated in Section 7.1 of [TRANS], each device will send a list of > preferred methods for key exchange. The most-preferred method is the > first in the list. It is RECOMMENDED to sort > the algorithms by cryptographic strength, strongest first. Some > additional guidance for this is given in BCP 86 [RFC 3766]. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 25 09:20:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28788 for ; Fri, 25 Jun 2004 09:20:27 -0400 (EDT) Received: (qmail 12765 invoked by uid 605); 25 Jun 2004 13:20:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12756 invoked from network); 25 Jun 2004 13:20:24 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 25 Jun 2004 13:20:24 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2004 05:54:32 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5PCph4N026549 for ; Fri, 25 Jun 2004 05:51:44 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA28849 for ; Fri, 25 Jun 2004 05:51:43 -0700 (PDT) Date: Fri, 25 Jun 2004 05:51:43 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal In-Reply-To: <40DB58D3.3060504@mindrot.org> Message-ID: References: <40DB58D3.3060504@mindrot.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Thu, 24 Jun 2004, Damien Miller wrote: > > > As stated in Section 7.1 of [TRANS], each device will send a list of > > preferred methods for key exchange. The most-preferred method is the > > first in the list. It is RECOMMENDED to sort > > the algorithms by cryptographic strength, strongest first. Some > > additional guidance for this is given in BCP 86 [RFC 3766]. > > I'm OK with this. I have one other vote for "A" but since this has the essential gist of the thought I'll ask if anyone really opposes it. If not, I'll integrate those changes into the docs. Just FYI, I'm going to a part of west Texas next week where the Internet doesn't reach. I believe that there's also some strange localized phenomena in the area which prevents computers from booting. I'll pick things up when I'm back. :-) Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 25 11:12:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08260 for ; Fri, 25 Jun 2004 11:12:29 -0400 (EDT) Received: (qmail 9215 invoked by uid 605); 25 Jun 2004 15:12:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9175 invoked from network); 25 Jun 2004 15:12:22 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 25 Jun 2004 15:12:21 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1Bdqs2-0007QQ-00; Fri, 25 Jun 2004 14:35:58 +0100 Date: Fri, 25 Jun 2004 14:35:57 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Data transfer during key re-exchange Message-ID: <20040625133557.GA28157@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list What happens to "application data" (connection protocol etc) during a key re-exchange is still not specified by the current transport draft (transport-18). This has come up at least three times. The WG decision made by Bill Sommerfeld[1] was that non-rekey-related traffic should be suspended for the duration of the rekey, but this was not implemented in the draft. [1] 19 Oct 2003, thread 'Some questions about "SSH Transport Layer Encryption Modes"', <200310192351.h9JNpxAx004282@thunk.east.sun.com> Therefore, I propose the following change for the transport draft: In section 9 "Key re-exchange", between the last two paragraphs, insert the following paragraph: Once a party has sent a KEXINIT message for key re-exchange, it MUST NOT send any messages other than DISCONNECT, IGNORE, and DEBUG; NEWKEYS; and key exchange method specific messages (message numbers 30 to 49); until it has sent a NEWKEYS message. Note however that after sending a KEXINIT message, each party MUST be prepared to process an arbitrary number of received messages that may be "in flight" before seeing a KEXINIT from the other party. If anyone has objections, this issue should at least go in the issue tracker, so it doesn't get lost again. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jun 25 12:05:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18904 for ; Fri, 25 Jun 2004 12:05:37 -0400 (EDT) Received: (qmail 9634 invoked by uid 605); 25 Jun 2004 16:05:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9625 invoked from network); 25 Jun 2004 16:05:34 -0000 Received: from ashdown-four.mit.edu (HELO liandra.pc.cs.cmu.edu) (18.250.5.4) by mail.netbsd.org with SMTP; 25 Jun 2004 16:05:34 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa05026; 25 Jun 2004 10:04 EDT Date: Fri, 25 Jun 2004 10:04:19 -0400 From: Jeffrey Hutzelman To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal Message-ID: <50690000.1088172259@liandra.pc.cs.cmu.edu> In-Reply-To: References: <40DB58D3.3060504@mindrot.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, June 25, 2004 05:51:43 -0700 Chris Lonvick wrote: >> > As stated in Section 7.1 of [TRANS], each device will send a list of >> > preferred methods for key exchange. The most-preferred method is the >> > first in the list. It is RECOMMENDED to sort >> > the algorithms by cryptographic strength, strongest first. Some >> > additional guidance for this is given in BCP 86 [RFC 3766]. >> >> > > I'm OK with this. I have one other vote for "A" but since this has the > essential gist of the thought I'll ask if anyone really opposes it. If > not, I'll integrate those changes into the docs. Works for me. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jun 28 13:19:39 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17002 for ; Mon, 28 Jun 2004 13:19:36 -0400 (EDT) Received: (qmail 16021 invoked by uid 605); 28 Jun 2004 17:19:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16002 invoked from network); 28 Jun 2004 17:19:29 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 28 Jun 2004 17:19:29 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6182986 for ietf-ssh@netbsd.org; Mon, 28 Jun 2004 10:19:27 -0600 Message-ID: <40E04511.9020304@vandyke.com> Date: Mon, 28 Jun 2004 10:19:29 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040622) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Data transfer during key re-exchange References: <20040625133557.GA28157@chiark.greenend.org.uk> In-Reply-To: <20040625133557.GA28157@chiark.greenend.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jacob Nevins wrote: > What happens to "application data" (connection protocol etc) during a > key re-exchange is still not specified by the current transport draft > (transport-18). > > This has come up at least three times. The WG decision made by Bill > Sommerfeld[1] was that non-rekey-related traffic should be suspended for > the duration of the rekey, but this was not implemented in the draft. > > [1] 19 Oct 2003, thread 'Some questions about "SSH Transport Layer > Encryption Modes"', <200310192351.h9JNpxAx004282@thunk.east.sun.com> > > Therefore, I propose the following change for the transport draft: > > In section 9 "Key re-exchange", between the last two paragraphs, insert > the following paragraph: > > Once a party has sent a KEXINIT message for key re-exchange, it MUST > NOT send any messages other than DISCONNECT, IGNORE, and DEBUG; > NEWKEYS; and key exchange method specific messages (message numbers > 30 to 49); until it has sent a NEWKEYS message. Note however that > after sending a KEXINIT message, each party MUST be prepared to > process an arbitrary number of received messages that may be "in > flight" before seeing a KEXINIT from the other party. > > If anyone has objections, this issue should at least go in the issue > tracker, so it doesn't get lost again. Every time this discussion has come up before I've looked for the language that I knew was there in section 7.1, and then found it in section 7.3 (which really is quite clear, if misplaced) This message [NEWKEYS] is the only valid message after key exchange, in addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages.... Implementations MUST NOT accept any other messages after key exchange before receiving SSH_MSG_NEWKEYS. And in section 9, Re-exchange is processed identically to the initial key exchange, except for the session identifier that will remain unchanged. I've never quite understood the confusion on this issue... however, I don't object to the new text. I do object to it's proposed location though... I think it should go in Section 7.1 and section 7.3 could be condensed a little bit to remove redunancy. If a re-enforcing sentance is needed in section 9 (processed identically including valid packet restrictions) I wouldn't mind that. I would strike the final paragraph of section 9-- it is wrong (key exchanges _does_ affect the protocols because we stop sending their data for the duration) and only introduces confusion about an issue that is pretty well specified otherwise. I guess we could reword it as our re-enforcing sentance: Application data MUST NOT be sent after KEXINIT and prior to the SSH_MSG_NEWKEYS packet; other than this restiction, key exchange does not affect the protocols that lie above the SSH transport layer. - Joseph