From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 12:29:13 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18999 for ; Fri, 1 Apr 2005 12:29:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 96E61534F; Fri, 1 Apr 2005 17:29:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id A104B52F6 for ; Fri, 1 Apr 2005 17:29:04 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7281556; Fri, 01 Apr 2005 10:29:03 -0700 Message-ID: <424D84FA.6080402@vandyke.com> Date: Fri, 01 Apr 2005 10:29:30 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Whalen Cc: ietf-ssh@NetBSD.org Subject: Re: comments on draft-ietf-secsh-filexfer-07.txt References: <3EF96AF20489A34296050FBD5C36ECB905A32E@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB905A32E@beacon.PSC.process.com> 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 Richard Whalen wrote: > 4.1 Is it ok for a client to use 'version-select' after sending '4' > as a requested version number? Should this state a minimum > value of '3'? Yes, it is okay for a client to use 'version-select' as long as the initially negotiated version has the SSH_FXP_EXTENDED, the client can use the 'version-select' I have however, updated the draft to require that the 'version-select' be the first request. This avoids questions about what versionin-flight data from the server is using. I also explicitly allowed a version-downgrade; this might be useful, if, for example, due to bugs, the negotiated version can't be used. In addition, I added a 'vendor-id' extension that can be used similarly to the way the ssh-2.0- ident string is used in the main protocol. Currently, many implemenations are done in seperate processes, which makes it hard for them to use the ssh ident string when trying to detect and work around sftp bugs (like the reversed symlink parameters bug that several vendors, include us here at vandyke, have.) > 4.5 "seperated" should be "separated" (multiple occurrences). Thanks. Done. > In the example of a 'comma-seperated-versions' string the > terminating quote after "3,6,7 is missing. Fixed. > The sentence that follows the example is awkward "Versions defined by are:" > How about "The defined versions are:" Thanks. Fixed. > 6.9 in the discussion of the SPARSE flag, > "Some server may store..." should be "Some servers may store..." Fixed. > 6.10 Can an FSETSTAT operation with the text hint be used > to convert a text file handle to a binary file handle if > the value is set to one of the binary value types or is > the value ignored and this is always a request to convert > a binary file handle to a text file handle? Ugh... what do people think of this. I'm inclined to take this behavior out? Does anyone think it is useful enough to be able to convert handles to make it worth the pain? I'm inclined to make it illegal for both fsetstat and setstat. I've removed it for now (so if you really want it speak _real_ fast since I'm publishing again at the end of the day!) If we decide to put it back in, I think it should do both. And of course a server could refuse to support such a conversion by not including the text-hint flag in it's valid attribute mask. > 7.4 Should there be a way to specify that a created directory > should be case sensitive or case insensitive? If it is not > specified, which is it? The implication based upon 6.9 is > that it should be case sensitive, but what if that is > not the default/possible for the file system? We currently assume that this isn't a settable parameter, and is an attribute of the filesystem. In other words, the reason we have it in the ATTR is because we presume it might change as you cross mount points or drive letters, etc., but that it can't be controlled by either the server or the client. > 7.7 "The SSH_FXP_LINK request creates a symbolic link..." > strike "symbolic" as it can create either a symbolic > or hard link. Thanks. Done. > 7.8.1 "A client that use REALPATH(".", "") and treats..." > should be "A client that uses REALPATH(".", "") and treats..." Fixed. > 9.2 "The total number of unused bytes availabe on the device..." > should be "The total number of unused bytes available on > the device..." Fixed. Thanks for the review. I'll be publishing another version latter today. - Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 15:09:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01675 for ; Fri, 1 Apr 2005 15:09:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AB44651FF; Fri, 1 Apr 2005 20:08:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 996055166 for ; Fri, 1 Apr 2005 20:08:52 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1DHSRn-0007A3-00 for ietf-ssh@netbsd.org; Fri, 01 Apr 2005 21:08:51 +0100 Date: Fri, 1 Apr 2005 21:08:51 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: filexfer: short reads Message-ID: <20050401200851.GA20772@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 (This issue is present in filexfer-07, but not new in this version.) Of SSH_FXP_READ, filexfer-07 states (sec 7.2.1): | For normal disk files, it is normally guaranteed that this will | read the specified number of bytes, or up to end of file. | | If the server specified 'max-read-size' then failure to return | 'length' bytes indicates that EOF or an error occured. The "guarantee" in the first paragraph doesn't seem to be worth anything, given the "for normal disk files" (undefined) and even more vague "normally" hedging. This is an issue particularly when a client attempts to optimise transfers by having multiple requests "in flight" simultaneously, as discussed in sec 10. For instance, if a client issues a series of reads (say) 4k apart, and the server returns short reads (say 512 bytes), the client then has to have a strategy to fill in the resulting gaps, and probably some heuristic to guess the read size for the rest of the file (in the absence of 'max-read-size'). If this guarantee were usable, this fragmentation/reassembly machinery would not be necessary. (We've had a report of this in practice -- an OpenVMS server returning short reads for a ZIP file, apparently due to an implementation detail. My guess would be that there wouldn't be a way for an SFTP client to tell that this is anything other then a "normal disk file".) The "guarantee" should either be made useful, or removed. I suspect that the right answer is to remove it in the absence of 'max-read-size' information (especially as some reassembly capability is already required of optimising clients in order to deal with responses arriving out of order). The language that was added in sec 10 in -06 seems to support this interpretation: | Implemenations MUST also be aware that read requests may not return | all the requested data, even if the data is available. [typo "Implemenations" for "Implementations"] From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 15:16:38 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02998 for ; Fri, 1 Apr 2005 15:16:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7AA4351EB; Fri, 1 Apr 2005 20:16:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 407F15166 for ; Fri, 1 Apr 2005 20:16:30 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7281968 for ietf-ssh@netbsd.org; Fri, 01 Apr 2005 13:16:28 -0700 Message-ID: <424DAC38.8000609@vandyke.com> Date: Fri, 01 Apr 2005 13:16:56 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: filexfer: short reads References: <20050401200851.GA20772@chiark.greenend.org.uk> In-Reply-To: <20050401200851.GA20772@chiark.greenend.org.uk> 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 Jacob Nevins wrote: > (This issue is present in filexfer-07, but not new in this version.) > > Of SSH_FXP_READ, filexfer-07 states (sec 7.2.1): > > | For normal disk files, it is normally guaranteed that this will > | read the specified number of bytes, or up to end of file. > | > | If the server specified 'max-read-size' then failure to return > | 'length' bytes indicates that EOF or an error occured. > > The "guarantee" in the first paragraph doesn't seem to be worth > anything, given the "for normal disk files" (undefined) and even more > vague "normally" hedging. Thanks... I'll remove it. > This is an issue particularly when a client attempts to optimise > transfers by having multiple requests "in flight" simultaneously, as > discussed in sec 10. For instance, if a client issues a series of > reads (say) 4k apart, and the server returns short reads (say 512 > bytes), the client then has to have a strategy to fill in the resulting > gaps, and probably some heuristic to guess the read size for the rest of > the file (in the absence of 'max-read-size'). If this guarantee were > usable, this fragmentation/reassembly machinery would not be necessary. This is exactly the reason I added the max-read-size for. > (We've had a report of this in practice -- an OpenVMS server returning > short reads for a ZIP file, apparently due to an implementation detail. > My guess would be that there wouldn't be a way for an SFTP client to > tell that this is anything other then a "normal disk file".) We also had this from a couple of embedded devices, that never did anything more than 4K. > The "guarantee" should either be made useful, or removed. I suspect > that the right answer is to remove it in the absence of 'max-read-size' > information (especially as some reassembly capability is already > required of optimising clients in order to deal with responses arriving > out of order). The language that was added in sec 10 in -06 seems to > support this interpretation: Yep. > | Implemenations MUST also be aware that read requests may not return > | all the requested data, even if the data is available. > > [typo "Implemenations" for "Implementations"] Fixed. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 15:31:20 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07340 for ; Fri, 1 Apr 2005 15:31:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3939C51BA; Fri, 1 Apr 2005 20:31:17 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 250B25166 for ; Fri, 1 Apr 2005 20:31:15 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa15396; 1 Apr 2005 15:30 EST Date: Fri, 01 Apr 2005 15:30:47 -0500 From: Jeffrey Hutzelman To: Bill Sommerfeld Cc: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gss-keyex and null host keys Message-ID: In-Reply-To: <1112312576.27244.556.camel@thunk> References: <1112312576.27244.556.camel@thunk> Originator-Info: login-token=Mulberry:01EUVSBnutx3pdkMqHRMOCdai3iTGYect+uoBrR8U=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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 Thursday, March 31, 2005 06:42:57 PM -0500 Bill Sommerfeld wrote: > On Thu, 2005-03-31 at 14:51, Jeffrey Hutzelman wrote: > >> I'm adding the following text to the next version of the draft: > >> Therefore, when a new key for an already-known host is received >> via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue >> strong warnings or abort the connection, provided the GSSAPI-based >> key exchange succeeds. > > I think we need to provide additional guidance about hostkey update > acceptance.. I don't think we do. I think that section 4.1 of the architecture document provides all the guidance we need in this area, which is mostly a matter for policy and configuration. Our existing security considerations RECOMMEND that clients issue a warning when the offered host key does not match that cached by the client, on the assumption that such a mismatch is an indication of a MitM attack. But that recommendation is based on the fact that in the base protocol, the host key offered by a server is completely unauthenticated. The purpose of the new text is to point out that host keys offered during GSSAPI-based key exchange are _not_ unauthenticated, and a strong warning is not indicated. It is still up to the implementation and local policy to determine the relative reliability of different sources of keys. BTW, it is worth noting that most implementations do not have any mechanism for recording the source or confidence level of a cached key, nor do we require such a mechanism (or even that clients store keys). -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 15:36:17 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08819 for ; Fri, 1 Apr 2005 15:36:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 078EF520E; Fri, 1 Apr 2005 20:36:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id 96EE35166 for ; Fri, 1 Apr 2005 20:36:13 +0000 (UTC) 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 j31KaCZO017228 for ; Fri, 1 Apr 2005 12:36:13 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j31KaCQp019218; Fri, 1 Apr 2005 15:36:12 -0500 (EST) Subject: core drafts approved by IESG! From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1112387759.9762.4292.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Fri, 01 Apr 2005 15:36:01 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit If you take a look at: http://tools.ietf.org/wg/secsh/ you'll note that the five core drafts have been marked "approved -- announcement to be sent". They were approved during yesterday's IESG meeting. To the best of my knowledge this is not an april fool's prank :-) Thanks to all who have helped make this finally happen. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 16:58:54 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25955 for ; Fri, 1 Apr 2005 16:58:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A35C75229; Fri, 1 Apr 2005 21:58:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id F0778516A for ; Fri, 1 Apr 2005 21:58:39 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7282207; Fri, 01 Apr 2005 14:58:38 -0700 Message-ID: <424DC42A.2050900@vandyke.com> Date: Fri, 01 Apr 2005 14:59:06 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: filexfer-07 References: <200503290936.EAA18173@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200503290936.EAA18173@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: > I just looked over draft-ietf-secsh-filexfer-07.txt and have some > comments. Thanks, I appreciate the review. > Section 3, before the beginning of 3.1, says that "Implementations MUST > ignore excess data after an otherwise valid packet", but it is not > clear exactly what this means: it could be taken to mean that extra > data may appear after a valid [length;type;request-id;data] blob, or > whether it means that extra data may appear after the data within such > a blob. Because of the difficulty of packetizing the octet stream in > the former, I assume it's the latter, but I think the wording could do > with clarification. Thanks. I've changed it to read: Implementations MUST ignore excess data at the end of an otherwise valid packet. Implementation MUST respond to unrecognized packet types with an SSH_FX_OP_UNSUPPORTED error. This will allow the protocol to be extended in a backwards compatible way as needed. Is this better? > In section 3.2, two is hardly "several"; I'd suggest just "This > document defines these data types in addition...". Done. > In section 3.2, in the definition of "extension-pair", should it read > s/consensus/CONSENSUS/ as is done elsewhere RFC2434 language is used? > > In 3.3, RESERVED_FOR_EXTENSIONS is not a packet type value and I would > argue it should not appear in the list of packet type values, at least > not in a way that makes it look like a value. Perhaps instead of > > > In addition, values 210 through 255 are reserved for extensions as > defined in Section {whatever}. Thanks. Done. > Additional packet types should only be defined if the protocol > > Also, the last-quoted line above suffers from the misplaced-only > problem; it should be "...should be defined only if the..." or, in this > particular case, perhaps even "...defined only when the...". Actually, this conflicts with the new 'excess data' wording. I've fixed this to clarify that servers MUST respond with UNSUPPORTED, and that we have to rev the protocol number if the client is to receive new packet types. (Although the client can receive a new packet type in response to a new packet type request.) > Section 4, first paragraph, ast line: "...adhere to particular versino > of..." needs s/to par/to that par/. Fixed. > In 4.1, I'd rather see s/dis-contiguous/discontiguous/. Done. > 4.2, last sentence: s/name/&s/ Done. > 4.3, second paragraph, last sentence: \r\n is C notation; I'd rather > see this read something like "...uses CRLF pairs as the...". Similar > notation exists in the discussion of the "newline" extension. Fixed. > 4.3, third paragraph, reads "Servers for systems blah blah or systems > blah blah, MUST translate...". I'd get rid of the comma, or add > another comma just after the parenthetical note. But I'd prefer to > replace the whole sentence with something like "Servers for systems > using other conventions MUST translate to and from the canonical > form.". (Note I added "and from" as well.) Done. I used your preferred language. > 4.4, second sentence, last paragraph: this needs a comma between > "following extension" and "which all". I reworded it to not be such a complex compound sentance. > 4.4, in the description of max-read-size, has another misplaced "only": > s/only complete/complete only/. The second paragraph of this > description is technically inconsistent; it says that a server MUST do > something, and then describes cases under which it might not. I think > it needs a little rewording. Done. > 5, describing filename-translation-control, perhaps should indicate > which value of do-translate indicates which action. Perhaps "MUST > enable or disable filename translation according as 'do-translate' is > true or false"? Done. > 6 describes a "new compound data type is defined for encoding file > attributes", but does not give it any name. By exclusion and > back-reference, I assume this is the ATTRS that appears in (eg) 7.1.1; > I'd prefer to see the ATTRS name shown here in 6 as well. Done. > 6 describes the *time_nseconds fields as "if flag SUBSECOND_TIMES", but > 6.7 makes it clear they really are "if flags {ACCESS,CREATE,MODIFY}TIME > and SUBSECOND_TIMES". I'd prefer this be stated clearly here, perhaps > by indenting the "if flag" clauses: > > int64 atime if flag ACCESSTIME > uint32 atime_nseconds if flag SUBSECOND_TIMES Done. > 6 inconsistently names attributes with dashes or underscores separating > words (eg, allocation-size, mime-type, but atime_nseconds, > extended_count). I'd prefer to see this uniform (I'd rather see > dashes, but I'd rather see uniform underscores than the mixed mess > that's there). Done. > > 6 describes a createtime field. Based on the close match of the rest > of the attributes, and the lack of a last-change-time field, this > appears to be an example of the common misunderstanding of the ctime > stat() field: it is not a create time, but a last-inode-change-time. > I'm not sure how fixable this is, though I would like to see somewhere > to put the ctime. No, it is definitely createtime (that is why I didn't call it ctime!) Windows (and other non-unix OS's) track create time as well. I have added the following field: 'ctime' contains the last time the file attrbutes were changed. The exact meaning of this field depends on the server. > 6.4 says that "the number of bytes tha tthe file consumes on disk" "is > greater than or equal to [the EOF location]". This appears to mean > that it cannot be used on filesystems supporting holes in files, and > must be artifically increased, or not provided, for files containing > sufficient holes to outweigh any indirect blocks or other overhead. > Since I assume this is supposed to be a palce to report the st_blocks > value, I suspect this is not what's intended. You are correct; I fixed it to explicitly note that it can be smaller than size. > 6.4, second paragraph, I'd prefer s/removed/& (if it was created)/, > since it's possible that preallocation and creation may be an atomic > operation. Done. > 6.4, third paragraph, last sentence: "If the operation succeeds, it > should be the min of the 'size' before the operation and the new > 'allocation-size'.". (1) I'd prefer s/min/&imum/; (2) it's not clear > what the "it" is referring back to. I conjecture it's the 'size' of > the file, since that's the subject of the previous sentence, but it > appears to be referring to "the operation" from the "If" clause. Thanks. Fixed. > It's not clear what to do if the same operation tries to set the size > and the allocation-size to different values. Hmm... Different values is okay: size: 400 bytes allocation-size: 4K Set the EOF to 400 bytes, and pre-allocate to 4K on disk. I've added some text specifying what to do if they conflict. I.e., size: 4K allocation-size: 1K is an error (INVALID_PARAMETER) > 6.5, second paragraph, third line, appears to be missing an open ". Thanks. > 6.5, second paragraph: "...should not place any special meaning with > the attribute value" - I'd s/with/on/. Done. > 6.5, last paragraph: I'd add "for a modification operation" to the end > of the sentence. Done. (I used 'during a modification...') > 6.6, second paragraph: s/posix/POSIX/. Done. > 6.9, describing SSH_FILEXFER_ATTR_FLAGS_SYSTEM: "The file is part of > operating system". There is an article missing here after "of". Fixed. > 6.9, describing SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE: another > mispalced "only". s/can only apply/applies only/ Done. > 6.9, describing SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY: another misplaced > "only". "The file can be opened for writing only in append mode." Hmm... someone requested that this be added for unix; I don't recall who, and it isn't in man stat for my fedora 3 system. I assume it means this, which is the new text: Opening the file without either the SSH_FXF_ACCESS_APPEND_DATA or the SSH_FXF_ACCESS_APPEND_DATA_ATOMIC flag (Section 7.1.1.3) MUST result in an SSH_FX_INVALID_PARAMETER error. > 6.9, describing SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE, first paragraph: > missing comma after "created to this file". Fixed. > 6.10, section heading should be "text-hint", since that's what it's > called above. Thanks. > 6.10 says that "If this flag is present during an fsetstat operation, > the file handle is converted to a text-mode handle, as if it had been > opened with SSH_FXF_ACCESS_TEXT_MODE"; this seems wrong if the value > given is one of the _BINARY values, especially KNOWN_BINARY. I've removed this text and forbidden this flag during either fsetstat or setstat (unless someone screams _right now_!) > 6.11, section heading should be "mime-type". Done. > 6.12, section heading should be "link-count". Done. > There is no description of the untranslated-name field. Good catch. I added it. I also realized I did need the attrib-bits-valid (which I'd put in and taken out between 06 and 07) because otherwise the server could end up twiddling bits inadvertantly when trying to comunicate the TRANSLATION_ERR. > In 6.13, the edict that an implementation "SHOULD ignore" extended data > fields it doesn't understand seems to conflict with the general dictum > that unsupported attributes in a set operation should produce errors. > What's the thinking behind this? It does conflict, doesn't it? I've changed the "supported2" extension to explicitly declare attribute extensions versus 'SSH_FXP_EXTENDED' extensions, and changed it to fail with SSH_FX_UNSUPPORTED > 7.1.1.2, first paragraph, refers to section 5.7, which as far as I can > tell does not exist. This appears to be intended to refer to what is > now 6.8. Furthermore, as far as I can see, nowhere are the actual > semantics of the various access types defined, either for open purposes > or for ACL purposes (though in the latter case there is a reasonably > strong implication that they should be interpreted per NFSv4). Okay, I noted that the meaning of the flags was also in RFC3010, fixed the reference, and emphasised that the meaning for open was also in RFC3010. > 7.1.1.2, second paragraph: s/it's/its/ and s/equivilants/equivalents/. > I'd also s/can not/cannot/, but that's less important. Done. > 7.1.1.2, last paragraph: s/limitted/limited/ (twice). Done. > 7.1.1.3, describing SSH_FXF_TEXT, second paragraph: I'd remove "both > the" and s/function/&s/. Done. > 7.1.1.3, describing SSH_FXF_TEXT, third paragraph: this contains two > "correctly"s, one of which should go. Fixed. > 7.1.1.3, describing SSH_FXF_TEXT, describing "text-seek": does this > really belong here? It seems odd to describe this nested inside this > flag bit description. Good point... I haven't quite figured out where to put it though. > 7.1.1.3, describing SSH_FXF_ACCESS_READ_LOCK: s/gaurantee/guarantee/ > (twice). Also, it's not clear whether "the exclusive reader" means > with respect to other sftp clients or with respect to all other OS > activity; and, an exclusive read lock is a very peculiar thing, and not > at all what a "read lock" normally does. All right; I renamed it to SSH_FXF_ACCESS_EXCLUSIVE_READ, and changed it to say: The server MUST guarantee that no other handle has been opened with ACE4_READ_DATA access, and that no other handle will be opened with ACE4_READ_DATA access until the client closes the handle. (This MUST apply both to other clients and to other processes on the server.) If there is a conflicting lock the server MUST return SSH_FX_LOCK_CONFLICT. If the server cannot make the locking guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. Other handles MAY be opened for ACE4_WRITE_DATA or any other access, as long as it does not include ACE4_READ_DATA. Is this better? > 7.1.1.3, describing SSH_FXF_ACCESS_WRITE_LOCK: s/gaurantee/guarantee/. > Also, it's not clear whether "the exclusive writer" means with respect > to other sftp clients or with respect to all other OS activity. I used the same text as for EXCLUSIVE_READ, modified appropriately. I also changed the name of the to EXCLUSIVE_WRITE. > > 7.1.1.3, describing SSH_FXF_ACCESS_DELETE_LOCK: s/gaurantee/guarantee/. > Also, it's not clear whether the guarantee applies to the file itself > or to the name with which it aws opened. I replaced the text with this: The server MUST guarantee that no other handle has been opened with ACE4_DELETE access, opened with the SSH_FXF_ACCESS_DELETE_ON_CLOSE flag set, and that no other handle will be opened with ACE4_DELETE access or with the SSH_FXF_ACCESS_DELETE_ON_CLOSE flag set, and that the file itself is not deleted in any other way until the client closes the handle. Is this better? > 7.1.1.3 says that "The 'attrs' field is ignored if an exiting file is > opened" - this needs s/exiting/existing/. Done. > 7.1.1.3, "The following table is provided to assist in mapping posix > semantics" - s/posix/POSIX/. Done. > 7.1.3 mentions that a close can fail, but it does not indicate what > happens if so - interpreted under the usual assumption that a failed > operation did not happen, it would appear that there is now a handle > that is still open but which cannot be accessed (since the handle goes > invalid from the client's POV upon sending the request). True. I believe this problem extends to close failure at the OS level to. I don't think there is anything the client or protocol can do about this. I've added the following paragraph: Note that the handle is invalid regardless of the SSH_FXP_STATUS result. There is no way for the client to recover a handle that fails to close. The client MUST release all resources associated with the handle regardless of the status. The server SHOULD take whatever steps it can to recover from a close failure and to ensure that all resources associated with the handle on the server are correctly released. > 7.2.1, last paragraph: I'd refer to see this worded differently. > Perhaps "If the server returned 'max-read-size' in the "supported2" > extension in its version packet (see section 4.4), then failure...". I changed it to: If the server specified a non-zero 'max-read-size' in it's 'supported2' (Section 4.5) extension, then failure to return 'length' bytes indicates that EOF or an error occured. > 7.2.2, describing "handle": s/oridinary/ordinary/ Fixed. > 7.2.3, describing writing beyond EOF, says that it writes "zeroes". It > is not clear whether this is all-bits-0 bytes or the character 0 in > some character set or what; I'd prefer to see this made clearer. Fixed. > 7.5 requires that SSH_FXP_FSTAT return an invalid-handle error for > directory handles. I think this should be fixed. Should FSTAT work on directory handles then? I've changed it to do so, and made it explicit that it does. Should FSETSTAT also work? I've changed it to do so. > 7.6, last paragraph, last sentence: s/client/&s/. Fixed. > 7.7 says that SSH_FXP_LINK creates a symbolic link, but the description > makes it clear that it is also for creating hardlinks as well. Maybe > remove "symbolic" from the description sentence? Done. > 7.7, last paragraph, last sentence: s/server/&s/. Fixed. > 7.8, describing control-byte, third or fourth paragraph: > s/syntaticly/syntactically/. Fixed. > 7.8.1, RFCEDITOR note, first paragraph: s/it's/its/ - I don't know if > these paragraphs are worth fixing; I include this in case they are. Fixed. > 8 describes "error message" and conflates the description of "language > tag" into it. I'd prefer to see "language tag" described on its own, > parallel to the way "error message" and "error/status code" are. Done. > 8, describing SSH_FX_NO_CONNECTION and SSH_FX_CONNECTION_LOST: more > misplaced "only"s. They should be moved to after their "locally"s. Ditched the only's; they confuse me :-) > 8, describing SSH_FX_QUOTA_EXCEEDED: s/users/user's/ Fixed. > 8, describing SSH_FX_UNKNOWN_PRINCIPLE: this needs to be > SSH_FX_UNKNOWN_PRINCIPAL, with s/princple/principal/ in the > description. (Since the wire protocol does not use the names, such a > change would be backward-compatible.) Fixed. > 8, describing SSH_FX_BYTE_RANGE_LOCK_CONFLICT and > SSH_FX_BYTE_RANGE_LOCK_REFUSED, speaks of "byte range" locks. As far > as I can tell, this is the only place in the entire document that such > a thing is mentioned. I have no idea why two error codes were > allocated to refer to conflicts with something that is undefined and > outside the scope of the protocol anyway, but it is not at all clear > what this is all about. Some operating systems support byte range locks. It is possible for an SFTP operation to come into conflict with such a lock even though the SFTP protocol does not support a byte-range lock. If replaced the text with: Some operating systems support locking a range of bytes within a file. On such operating systems, it is possible for a SFTP request to fail due to some other process owning a byte-range lock, even though the SFTP protocol does not support byte-range locks natively. A read or write operation failed because another process's byte-range lock overlaps with the request. SSH_FX_BYTE_RANGE_LOCK_REFUSED isn't strictly necessary, but I don't think it hurts either-- we aren't exactly constrained by a small error space here. I'll ditch it if people really don't want it there. > 8, describing the end-of-file field in an SSH_FXP_DATA response: > s/limitted/limited/. Fixed. > 8, describing SSH_FXP_NAME responses, says that "the remaining fields > repeat 'count' times", but this is true of only the next two fields, > not of the end-of-list optional field, which never repeats. Fixed. > 9, describing "request-specific data": another misplaced "only". It > needs to move to just before the "if". Reworded to use SHOULD NOT instead, which is clearer anyhow. > 9, describing how to allocate packet types for extensions: "in > additional to any other data" - s/additional/addition/. Done. > 9.1.2, describing "block-size": s/ever/&y/. Also, s/entire range/&,/. Done. > 9.1.2, last paragraph (part of the SSH_FXP_EXTENDED_REPLY "hash" > description): s/computer/computed/. Fixed. > 9.2, last paragraph ("bytes-per-allocation-unit" description): > s/block/&s/. Fixed. > 9.3: I'd prefer to see it explicitly stated that the returned pathname > is suitable for use in operations such as realpath. Done. > 10, third paragraph: s/channels/channel's/. Done. > 11, second paragraph, first sentence: swap "only" with "constrained". Done. > 11, seventh paragraph: while the text as it stands is not really > _wrong_, I'd prefer to s/insure/ensure/. Done. > 13, isn't the canonical tardemark sentence shorter now? Yep. The short version is in there too :-) Now fixed. Thanks for the exhaustive review. Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 17:23:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27795 for ; Fri, 1 Apr 2005 17:23:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 768635254; Fri, 1 Apr 2005 22:23:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 154FC5166 for ; Fri, 1 Apr 2005 22:23:27 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7282356 for ietf-ssh@netbsd.org; Fri, 01 Apr 2005 15:23:27 -0700 Message-ID: <424DC9FA.8020900@vandyke.com> Date: Fri, 01 Apr 2005 15:23:54 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-ssh@netbsd.org" Subject: Publishing filexfer again in a couple of hours... 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 If you've got comments, holler now! Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 17:23:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27835 for ; Fri, 1 Apr 2005 17:23:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 47F775267; Fri, 1 Apr 2005 22:23:51 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from beacon.PSC.process.com (unknown [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id 3F18C5166 for ; Fri, 1 Apr 2005 22:23:49 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: filexfer-07 Date: Fri, 1 Apr 2005 17:24:44 -0500 Message-ID: <3EF96AF20489A34296050FBD5C36ECB905A35A@beacon.PSC.process.com> Thread-Topic: filexfer-07 Thread-Index: AcU3BjlTOUXHOxCeRc2Mm6D7gjfW/gAAZWkw From: "Richard Whalen" To: "Joseph Galbraith" , "der Mouse" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On > Behalf Of Joseph Galbraith > Sent: Friday, April 01, 2005 4:59 PM > To: der Mouse > Cc: ietf-ssh@NetBSD.org > Subject: Re: filexfer-07 >=20 > > 7.1.1.3, describing SSH_FXF_ACCESS_READ_LOCK: s/gaurantee/guarantee/ > > (twice). Also, it's not clear whether "the exclusive reader" means > > with respect to other sftp clients or with respect to all other OS > > activity; and, an exclusive read lock is a very peculiar=20 > thing, and not > > at all what a "read lock" normally does. >=20 > All right; I renamed it to SSH_FXF_ACCESS_EXCLUSIVE_READ, > and changed it to say: >=20 > The server MUST guarantee that no other handle has been > opened with ACE4_READ_DATA access, and that no other > handle will be opened with ACE4_READ_DATA access until > the client closes the handle. (This MUST apply both > to other clients and to other processes on the server.) >=20 > If there is a conflicting lock the server MUST return > SSH_FX_LOCK_CONFLICT. If the server cannot make the locking > guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. >=20 > Other handles MAY be opened for ACE4_WRITE_DATA or any other > access, as long as it does not include ACE4_READ_DATA. >=20 > Is this better? >=20 I think that the lock described is still pretty unusual for a file. = When accessing a file the usual methods of locking are: None - I don't care if there is other current access, I'll take my = chances if something modifies it while I'm writing/reading it. Read - I don't want anyone to modify the file (or its attributes) while = I'm reading it. I don't care about other readers. Write - I don't want anyone else to be accessing the file while I access = it for write. I don't want to risk others getting a corrupt file while = I'm changing it. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 17:45:03 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29043 for ; Fri, 1 Apr 2005 17:45:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0D6355256; Fri, 1 Apr 2005 22:44:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id AE1ED5274 for ; Fri, 1 Apr 2005 22:44:55 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7282390; Fri, 01 Apr 2005 15:44:54 -0700 Message-ID: <424DCF01.2060907@vandyke.com> Date: Fri, 01 Apr 2005 15:45:21 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Whalen Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 References: <3EF96AF20489A34296050FBD5C36ECB905A35A@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB905A35A@beacon.PSC.process.com> 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 Richard Whalen wrote: >>-----Original Message----- >>From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On >>Behalf Of Joseph Galbraith >>Sent: Friday, April 01, 2005 4:59 PM >>To: der Mouse >>Cc: ietf-ssh@NetBSD.org >>Subject: Re: filexfer-07 >> >> >>>7.1.1.3, describing SSH_FXF_ACCESS_READ_LOCK: s/gaurantee/guarantee/ >>>(twice). Also, it's not clear whether "the exclusive reader" means >>>with respect to other sftp clients or with respect to all other OS >>>activity; and, an exclusive read lock is a very peculiar >> >>thing, and not >> >>>at all what a "read lock" normally does. >> >>All right; I renamed it to SSH_FXF_ACCESS_EXCLUSIVE_READ, >>and changed it to say: >> >> The server MUST guarantee that no other handle has been >> opened with ACE4_READ_DATA access, and that no other >> handle will be opened with ACE4_READ_DATA access until >> the client closes the handle. (This MUST apply both >> to other clients and to other processes on the server.) >> >> If there is a conflicting lock the server MUST return >> SSH_FX_LOCK_CONFLICT. If the server cannot make the locking >> guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. >> >> Other handles MAY be opened for ACE4_WRITE_DATA or any other >> access, as long as it does not include ACE4_READ_DATA. >> >>Is this better? >> > > > I think that the lock described is still pretty unusual for a file. It reflects the windows file sharing model. In windows, you say I'm willing to let others READ, write or delete (or any combination thereof) this file while I'm accessing it. Hence, EXCLUSIVE_READ is I'm willing to let other WRITE or DELETE this file. > When accessing a file the usual methods of locking are: > > None - I don't care if there is other current access, I'll > take my chances if something modifies it while I'm > writing/reading it. This is no locking bit set. > Read - I don't want anyone to modify the file (or its > attributes) while I'm reading it. I don't care about > other readers. This is EXCLUSIVE_WRITE set (and probably DELETE_LOCK) > Write - I don't want anyone else to be accessing the > file while I access it for write. I don't want to > risk others getting a corrupt file while I'm changing it. This is EXCLUSIVE_WRITE|EXCLUSIVE_READ (and possibly DELETE_LOCK) The only potential problem is that you may not be able to support EXCLUSIVE_READ set by itself-- in which case you'd have to return UNSUPPORTED for that lock request. And unfortunately, that limitation can't be expressed in the "supported2" extension. I'll add a note that clients that use the locking bits might need to watch out for this. (I expect most clients will want the default unix behavior of no bits set.) Do you have any other suggestions of how to accomadate both models? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 18:15:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02168 for ; Fri, 1 Apr 2005 18:15:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 09C0B52A2; Fri, 1 Apr 2005 23:14:54 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 7D33552D1 for ; Fri, 1 Apr 2005 23:14:50 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa15500; 1 Apr 2005 18:14 EST Date: Fri, 01 Apr 2005 18:14:12 -0500 From: Jeffrey Hutzelman To: Richard Whalen , Joseph Galbraith , der Mouse Cc: ietf-ssh@NetBSD.org Subject: RE: filexfer-07 Message-ID: In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB905A35A@beacon.PSC.process.com> References: <3EF96AF20489A34296050FBD5C36ECB905A35A@beacon.PSC.process.com> Originator-Info: login-token=Mulberry:01YDIn48qanFesfZ9kk7BXUvekXg7nZqDNp1VIlrI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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, April 01, 2005 05:24:44 PM -0500 Richard Whalen wrote: >> -----Original Message----- >> From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On >> Behalf Of Joseph Galbraith >> Sent: Friday, April 01, 2005 4:59 PM >> To: der Mouse >> Cc: ietf-ssh@NetBSD.org >> Subject: Re: filexfer-07 >> >> > 7.1.1.3, describing SSH_FXF_ACCESS_READ_LOCK: s/gaurantee/guarantee/ >> > (twice). Also, it's not clear whether "the exclusive reader" means >> > with respect to other sftp clients or with respect to all other OS >> > activity; and, an exclusive read lock is a very peculiar >> thing, and not >> > at all what a "read lock" normally does. >> >> All right; I renamed it to SSH_FXF_ACCESS_EXCLUSIVE_READ, >> and changed it to say: >> >> The server MUST guarantee that no other handle has been >> opened with ACE4_READ_DATA access, and that no other >> handle will be opened with ACE4_READ_DATA access until >> the client closes the handle. (This MUST apply both >> to other clients and to other processes on the server.) >> >> If there is a conflicting lock the server MUST return >> SSH_FX_LOCK_CONFLICT. If the server cannot make the locking >> guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. >> >> Other handles MAY be opened for ACE4_WRITE_DATA or any other >> access, as long as it does not include ACE4_READ_DATA. >> >> Is this better? >> > > I think that the lock described is still pretty unusual for a file. When > accessing a file the usual methods of locking are: > > None - I don't care if there is other current access, I'll take my > chances if something modifies it while I'm writing/reading it. > > Read - I don't want anyone to modify the file (or its attributes) while > I'm reading it. I don't care about other readers. > > Write - I don't want anyone else to be accessing the file while I access > it for write. I don't want to risk others getting a corrupt file while > I'm changing it. I agree, the locking semantics the document describes are pretty bizarre. In general, a read lock excludes writers, while a write lock excludes both readers and other writers. Also, it is worth noting that the current text, especially with the requirement that locks MUST apply to other processes on the server, basically requires the use of operating-system-provided mandatory file locking. This is problematic because on some systems, mandatory locking is rarely used, if it is available at all, and the sftp server may not be in a position to influence whether mandatory locking is used for a particular file. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 1 19:00:55 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05218 for ; Fri, 1 Apr 2005 19:00:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E7D8252C3; Sat, 2 Apr 2005 00:00:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8EA065208 for ; Sat, 2 Apr 2005 00:00:48 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7282556; Fri, 01 Apr 2005 17:00:47 -0700 Message-ID: <424DE0CA.6090106@vandyke.com> Date: Fri, 01 Apr 2005 17:01:14 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Richard Whalen , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 References: <3EF96AF20489A34296050FBD5C36ECB905A35A@beacon.PSC.process.com> In-Reply-To: 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 Jeffrey Hutzelman wrote: > > > On Friday, April 01, 2005 05:24:44 PM -0500 Richard Whalen > wrote: > >>> -----Original Message----- >>> From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On >>> Behalf Of Joseph Galbraith >>> Sent: Friday, April 01, 2005 4:59 PM >>> To: der Mouse >>> Cc: ietf-ssh@NetBSD.org >>> Subject: Re: filexfer-07 >>> >>> > 7.1.1.3, describing SSH_FXF_ACCESS_READ_LOCK: s/gaurantee/guarantee/ >>> > (twice). Also, it's not clear whether "the exclusive reader" means >>> > with respect to other sftp clients or with respect to all other OS >>> > activity; and, an exclusive read lock is a very peculiar >>> thing, and not >>> > at all what a "read lock" normally does. >>> >>> All right; I renamed it to SSH_FXF_ACCESS_EXCLUSIVE_READ, >>> and changed it to say: >>> >>> The server MUST guarantee that no other handle has been >>> opened with ACE4_READ_DATA access, and that no other >>> handle will be opened with ACE4_READ_DATA access until >>> the client closes the handle. (This MUST apply both >>> to other clients and to other processes on the server.) >>> >>> If there is a conflicting lock the server MUST return >>> SSH_FX_LOCK_CONFLICT. If the server cannot make the locking >>> guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. >>> >>> Other handles MAY be opened for ACE4_WRITE_DATA or any other >>> access, as long as it does not include ACE4_READ_DATA. >>> >>> Is this better? >>> >> >> I think that the lock described is still pretty unusual for a file. When >> accessing a file the usual methods of locking are: >> >> None - I don't care if there is other current access, I'll take my >> chances if something modifies it while I'm writing/reading it. >> >> Read - I don't want anyone to modify the file (or its attributes) while >> I'm reading it. I don't care about other readers. >> >> Write - I don't want anyone else to be accessing the file while I access >> it for write. I don't want to risk others getting a corrupt file while >> I'm changing it. > > I agree, the locking semantics the document describes are pretty > bizarre. In general, a read lock excludes writers, while a write lock > excludes both readers and other writers. The locking model you describe is support by the locking semantics in the document, and are probably the most useful. But, where being able to control all 8 locking modes supported by the document is most useful is when SFTP is being used as remote filesystem protocol (of which we have two implementations that I know of-- so this isn't just a theoritical use case.) This allows correct behavior when the client and server support the same lock model, and reasonable fall back behavior (by allowing the client to mask off unsupported bits.) The only thing that concerns me here is the pontential for servers to support EXCLUSE_READ|EXCLUSIVE_WRITE, but not EXCLUSIVE_READ by itself, since that can't be expressed in the supported2 extension. I'm tempted to go to a 3-bit enum instead, and have a locking modes byte in the supported2 extension with one bit set for each mode supported. But I'm not sure it is worth it. What if we were to call them BLOCK_ instead of LOCK_; that might not intefere with pre-existing terminalogy and still expresses the meaning well. (That is block as in prevent, not B-LOCK.) As flags, they'd be: BLOCK_READ BLOCK_WRITE BLOCK_DELETE And as enums, they'd be: BLOCK_NONE BLOCK_READ BLOCK_WRITE BLOCK_READ_WRITE BLOCK_DELETE BLOCK_DELETE_READ BLOCK_DELETE_WRITE BLOCK_DELETE_READ_WRITE and in supported2: byte block-mode If bit 0 is on, block mode 0 (BLOCK_NONE) is supported, if bit 1 is on, block mode 1 (BLOCK_READ) is supported, and so on. > Also, it is worth noting that the current text, especially with the > requirement that locks MUST apply to other processes on the server, Hmmm... I'm not sure how useful such a lock is if it doesn't apply to other process on the server. How do you think such a lock would be useful? > basically requires the use of operating-system-provided mandatory file > locking. This is problematic because on some systems, mandatory locking > is rarely used, if it is available at all, and the sftp server may not > be in a position to influence whether mandatory locking is used for a > particular file. Is there some other locking model you'd like to see? I expect locking for most FTP-style clients to be either unwanted or 'nice to have.' In the unwanted case, they just don't set any lock bits. In the 'nice to have' category, they set them and then mask against the 'supported2' open flags field to turn them off if the server doesn't support them. For example, downloaders will probably want either no locking or EXCLUSIVE_WRITE, meaning don't let anybody else write the file while I download it. (I don't like these names... not sure whether to go back to the LOCK names or if something else is better.) Of course, a downloader that asks for EXCLUSIVE_WRITE won't be able to download an active log file, for example. (So probably, it is either optional or a downloader really wants no locking.) An uploader is different... they might want EXLUSIVE_WRITE|EXCLUSIVE_READ (in other words, don't let anyone else much with it while I upload, and until I'm done, don't let anyone read the partial file either.) But, I suspect that most uploaders will probably not mind if the server doens't honor that request... in which case they just allow the 'supported2' mask to clear the bits. (This is the case today where most unix servers don't do any file locking.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Apr 2 20:28:01 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09206 for ; Sat, 2 Apr 2005 20:28:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0871C5403; Sun, 3 Apr 2005 01:27:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 9B1BB517E for ; Sun, 3 Apr 2005 01:27:52 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id UAA27141; Sat, 2 Apr 2005 20:27:43 -0500 (EST) From: der Mouse Message-Id: <200504030127.UAA27141@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sat, 2 Apr 2005 20:16:10 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: draft-harris-ssh-rsa-kex-01.txt Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I've just been trying to implement draft-harris-ssh-rsa-kex-01.txt. There is a subtle gotcha lurking in that spec that I would like to see clarified. One of the packets is described as byte SSH_MSG_KEXRSA_SECRET string RSAES-OAEP-ENCRYPT(K_T, K) Now, the OAEP encryption is a raw RSA encryption of a number computed in a complicated way that's not relevant here. Thus, it is, fundamentally, a big number, even though 3447 specifies that it's converted to an octet string. Now, RFC3447 *does* specify that conversion. But the encoding of this data blob as a string is deceptively close to the encoding of the big number as an mpint (the major difference is exactly how and when leading zero bits are included). I'd like to see this similarly explicitly acknowledged and clarified. Maybe something like Note that the encoding of the encrypted secret is similar to the "mpint" encoding of the raw RSA encryption result, but differs in its handling of high-order 0 bits. The packet contains the octet sequence as a "string", not the raw RSA output as an "mpint". (Assuming of course that that's what is intended; if not, the wording needs even mroe work.) Thoughts? Comments? /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Apr 2 21:27:30 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12893 for ; Sat, 2 Apr 2005 21:27:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1BE6A5402; Sun, 3 Apr 2005 02:27:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 552A75168 for ; Sun, 3 Apr 2005 02:27:23 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA27779; Sat, 2 Apr 2005 21:27:22 -0500 (EST) From: der Mouse Message-Id: <200504030227.VAA27779@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sat, 2 Apr 2005 21:09:48 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Ben Harris's individual submissions: arcfour-fixes and rsa-kex In-Reply-To: References: <1112213215.20951.264.camel@thunk> <1112213215.20951.264.camel@thunk> <200503310027.TAA04837@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt >>> http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-01.txt >> I haven't implemented this yet, but I certainly intend to. > I've got client and server implementations of the -00 version in > OpenSSH, and Simon's done an independent client implementation of it > for PuTTY. I don't think either of us has yet updated for -01. Well, I have what I think is an implementation of both kex methods from rsa-kex-01 now too. My code interoperates with itself, of course, but I'd like to do interop testing with others' implementations of any of these algorithms. Anyone game? >>> rsa-kex is a weaker kex >> Well, it's weaker in some respects, > [D]iscussions of SHA-1 have convinced me that there's a slight > weakness here that I should perhaps guard against. Because the > client can see all the other input to the exchange hash before it > generates K, if it's got a working collision attack against HASH it > can create two sessions with the same session ID. I'm not sure this buys you anything of significance. Even granting all the above, what can go wrong if a client (or two clients in collusion, which amounts to the same thing) gets two sessions with the same session ID? It allows the client to get the server to sign the same data twice, which could be a weakness if the host key algorithm involves random elements in signing, and is weak against such an attack. ssh-rsa does not involve any random element, so the same data signed by the same key gives the same signature and, perforce, no new information. ssh-dsa does involve random data in signing; I haven't looked at it enough to have more than a wild guess whether it leaks information if the same data is signed twice with the same key. (If forced to guess, I would guess it does not; the designers of DSA had plenty of competence on tap to build something strong against that if they wanted to, and it's an obvious potential attack.) If the session ID *and the shared secret* are the same, so will all the derived keys and IVs, which means that for some ciphers, like arcfour, the resulting connection is insecure against passive attackers (since it then involves encrypting different data with the same keystream). But as I pointed out earlier, a client that wants to leak session data to a passive listener has lots of easier methods available. Even if it doesn't want to leak it directly, the protocol makes no effort to prevent covert channels from either endpoint to passive snoopers - and such a client could just leak the keys and IVs directly, thus letting the snooper read the traffic without taking the risk of alerting the server that arranging two connections with the same session ID does. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Apr 3 04:53:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05704 for ; Sun, 3 Apr 2005 04:53:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A924051FF; Sun, 3 Apr 2005 08:53:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpc.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.13]) by mail.netbsd.org (Postfix) with ESMTP id B9645517E for ; Sun, 3 Apr 2005 08:53:07 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 74FF434F25; Sun, 3 Apr 2005 20:53:06 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08217-03; Sun, 3 Apr 2005 20:53:06 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 46EB734F23; Sun, 3 Apr 2005 20:53:05 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4178137746; Sun, 3 Apr 2005 20:53:05 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DI0r1-0002gV-00; Sun, 03 Apr 2005 20:53:11 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: draft-harris-ssh-rsa-kex-01.txt In-Reply-To: <200504030127.UAA27141@Sparkle.Rodents.Montreal.QC.CA> Message-Id: Date: Sun, 03 Apr 2005 20:53:11 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse squeeked: >Now, RFC3447 *does* specify that conversion. But the encoding of this data >blob as a string is deceptively close to the encoding of the big number as an >mpint (the major difference is exactly how and when leading zero bits are >included). I'd like to see this similarly explicitly acknowledged and >clarified. Why is it encoded as a string in the first place when the value is quite clearly an integer? For the equivalent DH keyex, the corresponding quantities e and f are encoded as mpints and not strings. Making a subtle change to the encoding for this alternative keyex method seems to be asking for implementor confusion. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Apr 3 07:31:55 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15302 for ; Sun, 3 Apr 2005 07:31:55 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 33BEF52EF; Sun, 3 Apr 2005 11:31:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id C5D01531A for ; Sun, 3 Apr 2005 11:31:38 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id HAA21102; Sun, 3 Apr 2005 07:31:38 -0400 (EDT) From: der Mouse Message-Id: <200504031131.HAA21102@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sun, 3 Apr 2005 07:24:48 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex-01.txt In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Now, RFC3447 *does* specify that conversion. But the encoding of >> this data blob as a string is deceptively close to the encoding of >> the big number as an mpint (the major difference is exactly how and >> when leading zero bits are included). I'd like to see this >> similarly explicitly acknowledged and clarified. > Why is it encoded as a string in the first place when the value is > quite clearly an integer? I don't know, of course, since I didn't design it - but I suspect it was done in order to directly use the existing RSAES-OAEP mode from RFC3447 (or perhaps I should be saying PKCS #1, but 3447 is the reference I used), as the existing definition is octet-string -> octet-string encryption. > For the equivalent DH keyex, the corresponding quantities e and f are > encoded as mpints and not strings. Making a subtle change to the > encoding for this alternative keyex method seems to be asking for > implementor confusion. Yes. But I can understand a desire to use an existing spec directly, rather than making slight changes to it. Encoding that as an mpint instead of a string would require draft-harris-ssh-rsa-kex to go under the hood of RFC3447 (or else specify converting it back from an octet string to a big number, which is almost uglier). If you have existing RSAES-OAEP library code, you can use it directly with the current spec. That's why I suggested emphasizing that it's a string rather than an mpint, as opposed to suggesting switching from opaque-blob-as-string to big-number-as-mpint. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Apr 3 09:11:41 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22029 for ; Sun, 3 Apr 2005 09:11:41 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7DABF540C; Sun, 3 Apr 2005 13:11:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 688FB5243 for ; Sun, 3 Apr 2005 13:11:33 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DI4t2-0000CF-00 for ietf-ssh@netbsd.org; Sun, 03 Apr 2005 14:11:32 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex-01.txt In-Reply-To: <200504030127.UAA27141@Sparkle.Rodents.Montreal.QC.CA> References: <200504030127.UAA27141@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Message-Id: Date: Sun, 03 Apr 2005 14:11:32 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200504030127.UAA27141@Sparkle.Rodents.Montreal.QC.CA> you write: >Now, RFC3447 *does* specify that conversion. But the encoding of this >data blob as a string is deceptively close to the encoding of the big >number as an mpint (the major difference is exactly how and when >leading zero bits are included). I'd like to see this similarly >explicitly acknowledged and clarified. Maybe something like > > Note that the encoding of the encrypted secret is similar to the > "mpint" encoding of the raw RSA encryption result, but differs in > its handling of high-order 0 bits. The packet contains the octet > sequence as a "string", not the raw RSA output as an "mpint". > >(Assuming of course that that's what is intended; if not, the wording >needs even mroe work.) That is the intention, yes, and I agree that it would probably be best to make this difference explicit. Your text seems good to me. Secsh-transport has a similar problem with the output of RSASSA-PKCS1-v1_5-SIGN, which is similarly an I2OSP-encoded integer. For comparison, the text there is: The value for 'rsa_signature_blob' is encoded as a string containing s (which is an integer, without lengths or padding, unsigned and in network byte order). I think yours is better, since it still defers to PKCS#1. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Apr 3 09:22:10 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22888 for ; Sun, 3 Apr 2005 09:22:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0E19E540D; Sun, 3 Apr 2005 13:22:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 2AAAB5243 for ; Sun, 3 Apr 2005 13:22:05 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DI53E-0001ta-00 for ietf-ssh@netbsd.org; Sun, 03 Apr 2005 14:22:04 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex-01.txt In-Reply-To: <200504031131.HAA21102@Sparkle.Rodents.Montreal.QC.CA> References: <200504031131.HAA21102@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Message-Id: Date: Sun, 03 Apr 2005 14:22:04 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200504031131.HAA21102@Sparkle.Rodents.Montreal.QC.CA> you write: >>> Now, RFC3447 *does* specify that conversion. But the encoding of >>> this data blob as a string is deceptively close to the encoding of >>> the big number as an mpint (the major difference is exactly how and >>> when leading zero bits are included). I'd like to see this >>> similarly explicitly acknowledged and clarified. > >> Why is it encoded as a string in the first place when the value is >> quite clearly an integer? > >I don't know, of course, since I didn't design it - but I suspect it >was done in order to directly use the existing RSAES-OAEP mode from >RFC3447 (or perhaps I should be saying PKCS #1, but 3447 is the >reference I used), as the existing definition is octet-string -> >octet-string encryption. That's precisely it. I wanted to be able to treat RSAES-OEAP as a black box that operated on octet-strings. This seemed reasonable since it's precisely how secsh-transport handles RSASSA-PKCS1-v1_5, which similarly emits an I2OSP-encoded integer as the signature, which then gets wrapped up in an SSH "string" when used as an ssh-rsa signature. >If you have existing RSAES-OAEP library code, you can use it directly with >the current spec. This was another consideration. My first implementation was in OpenSSH, which could just use OpenSSL's existing OAEP code without having to jump through hoops to change the encoding. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 08:54:50 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02449 for ; Mon, 4 Apr 2005 08:54:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 362D254AA; Mon, 4 Apr 2005 12:54:21 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from beacon.PSC.process.com (unknown [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id 4B70D54AC for ; Mon, 4 Apr 2005 12:54:18 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: filexfer-07 Date: Mon, 4 Apr 2005 08:55:08 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> Thread-Topic: filexfer-07 Thread-Index: AcU3Fy+oM7JkDpEhTOekNU2RE62q6AB/Ta0A From: "Richard Whalen" To: "Joseph Galbraith" , "Jeffrey Hutzelman" Cc: "der Mouse" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Friday, April 01, 2005 7:01 PM > To: Jeffrey Hutzelman > Cc: Richard Whalen; der Mouse; ietf-ssh@NetBSD.org > Subject: Re: filexfer-07 >=20 >=20 : >=20 > What if we were to call them BLOCK_ instead of LOCK_; > that might not intefere with pre-existing terminalogy > and still expresses the meaning well. (That is block > as in prevent, not B-LOCK.) >=20 > As flags, they'd be: >=20 > BLOCK_READ > BLOCK_WRITE > BLOCK_DELETE >=20 > And as enums, they'd be: >=20 > BLOCK_NONE > BLOCK_READ > BLOCK_WRITE > BLOCK_READ_WRITE > BLOCK_DELETE > BLOCK_DELETE_READ > BLOCK_DELETE_WRITE > BLOCK_DELETE_READ_WRITE >=20 > and in supported2: > byte block-mode > If bit 0 is on, block mode 0 (BLOCK_NONE) is supported, > if bit 1 is on, block mode 1 (BLOCK_READ) is supported, > and so on. >=20 >=20 I like the idea of naming the flags BLOCK_, as it states the actual intention and removes some of the confusion that is out there in the names that various operating systems use. It will also make implementors work to understand what they need to do rather than just match it to the similar sounding name on the operating system (and possibly have it wrong). Richard Whalen Process Software From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 14:01:30 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05162 for ; Mon, 4 Apr 2005 14:01:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 81AB55511; Mon, 4 Apr 2005 18:01:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 9EAE25315 for ; Mon, 4 Apr 2005 18:01:21 +0000 (UTC) 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 j34I1IX8016690; Mon, 4 Apr 2005 12:01:18 -0600 (MDT) Received: from thunk (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 j34I1HOp010869; Mon, 4 Apr 2005 14:01:17 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j34I1HbW014872; Mon, 4 Apr 2005 14:01:17 -0400 (EDT) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j34I1Grf014871; Mon, 4 Apr 2005 14:01:16 -0400 (EDT) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt From: Bill Sommerfeld To: Joseph Galbraith Cc: Ben Harris , ietf-ssh@NetBSD.org In-Reply-To: <4241E11E.50303@vandyke.com> References: <200503212034.PAA15411@ietf.org> <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <4241B4EF.3080102@vandyke.com> <1111603611.16353.42.camel@thunk> <4241E11E.50303@vandyke.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112637674.13395.61.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 04 Apr 2005 14:01:15 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-03-23 at 16:35, Joseph Galbraith wrote: > Should I hold off a while before assaulting the draft editor with > another version or repost now? We have reached the end of this two-week last-call period. >From reviewing the traffic on this document it looks like we collected a couple more changes along the way that have not yet been published. Joe: can you submit your current working copy as -08 ? - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 15:36:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15437 for ; Mon, 4 Apr 2005 15:36:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C13C95561; Mon, 4 Apr 2005 19:35:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 908655386 for ; Mon, 4 Apr 2005 19:35:52 +0000 (UTC) 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 j34JZpRr016516 for ; Mon, 4 Apr 2005 13:35:52 -0600 (MDT) Received: from thunk (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 j34JZpOp007379; Mon, 4 Apr 2005 15:35:51 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j34JZpGT015659; Mon, 4 Apr 2005 15:35:51 -0400 (EDT) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j34JZpTR015658; Mon, 4 Apr 2005 15:35:51 -0400 (EDT) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: [Fwd: Enforcement of Updated IPR Boilerplate] From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112643350.13395.258.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 04 Apr 2005 15:35:50 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Note to document authors: Yet another process rollover. - Bill -----Forwarded Message----- From: IETF Secretariat To: IETF Announcement list Cc: wgchairs@ietf.org, chair@ietf.org Subject: Enforcement of Updated IPR Boilerplate Date: Mon, 04 Apr 2005 13:05:48 -0400 As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions," has been obsoleted by RFC 3978 (BCP 78), which was published in March 2005, and which bears the same title. The major difference between the two RFCs is that the IPR-related notices and disclaimers that the IETF requires in all Internet-Drafts have been updated to correct anomalies. The updated versions of the required notices and disclaimers are specified in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in Section 3, "IPR-Related Notices Required in Internet-Drafts," of the recently revised "Guidelines to Authors of Internet-Drafts" (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" document also provides additional guidance regarding the placement of these notices. Currently, the IETF Secretariat accepts and posts Internet-Drafts that include *either* the RFC 3667 or the RFC 3978 version of these notices. However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will accept *only* those Internet-Drafts that comply with the requirements of RFC 3978, and with the most recent version of the "Guidelines" document. Please note that the required notices and disclaimers must be reproduced verbatim since they have been legally reviewed and formally adopted as part of the IETF process. The Secretariat will not accept deviations from the specified text, nor will it correct the text. Any documents that do not comply with the requirements will be returned to the submitter. The IETF Secretariat From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 15:53:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20289 for ; Mon, 4 Apr 2005 15:53:05 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 267985578; Mon, 4 Apr 2005 19:52:27 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 8221E5582 for ; Mon, 4 Apr 2005 19:52:16 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19908; Mon, 4 Apr 2005 15:52:13 -0400 (EDT) Message-Id: <200504041952.PAA19908@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-publickeyfile-08.txt Date: Mon, 04 Apr 2005 15:52:13 -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 Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-08.txt Pages : 14 Date : 2005-4-4 This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-08.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-publickeyfile-08.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-publickeyfile-08.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: <2005-4-4161620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-4161620.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 16:09:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26095 for ; Mon, 4 Apr 2005 16:09:33 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A7ED8557B; Mon, 4 Apr 2005 20:09:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id B735B5214 for ; Mon, 4 Apr 2005 20:09:27 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DIXt0-0001uq-D4; Mon, 04 Apr 2005 16:09:26 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , secsh mailing list , secsh chair Subject: Protocol Action: 'SSH Protocol Architecture' to Proposed Standard Message-Id: Date: Mon, 04 Apr 2005 16:09:26 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has approved the following documents: - 'SSH Authentication Protocol ' as a Proposed Standard - 'SSH Protocol Assigned Numbers ' as a Proposed Standard - 'SSH Protocol Architecture ' as a Proposed Standard - 'SSH Connection Protocol ' as a Proposed Standard - 'SSH Transport Layer Protocol ' as a Proposed Standard These documents are products of the Secure Shell Working Group. The IESG contact persons are Russ Housley and Sam Hartman. Technical Summary SSH is a protocol for providing an authenticated, integrity protected and encrypted stream between two end-points. It can optionally provide compression as well as multiplexing several virtual streams within a single TCP connection. This multiplexing feature is particularly useful for "tunneling" other protocols such as the X Window System. A Main focus of the SSH protocol is to provide a transport for remote login from a client computer system to a server system. Working Group Summary There is working group consensus around this set of documents. Protocol Quality These documents were reviewed by Jeffrey I. Schiller for the IESG. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 16:12:20 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26684 for ; Mon, 4 Apr 2005 16:12:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5AF335571; Mon, 4 Apr 2005 20:12:14 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 9D5CA5198 for ; Mon, 4 Apr 2005 20:12:12 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7292547; Mon, 04 Apr 2005 14:12:11 -0600 Message-ID: <42519FC0.70309@vandyke.com> Date: Mon, 04 Apr 2005 14:12:48 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: Ben Harris , ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt References: <200503212034.PAA15411@ietf.org> <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <4241B4EF.3080102@vandyke.com> <1111603611.16353.42.camel@thunk> <4241E11E.50303@vandyke.com> <1112637674.13395.61.camel@thunk> In-Reply-To: <1112637674.13395.61.camel@thunk> 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 Bill Sommerfeld wrote: > On Wed, 2005-03-23 at 16:35, Joseph Galbraith wrote: > >>Should I hold off a while before assaulting the draft editor with >>another version or repost now? > > > We have reached the end of this two-week last-call period. > >>From reviewing the traffic on this document it looks like we collected a > couple more changes along the way that have not yet been published. > > Joe: can you submit your current working copy as -08 ? Done Friday. I see it just cleared the process too... how's that for a fast response :-) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 16:31:30 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01480 for ; Mon, 4 Apr 2005 16:31:30 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F1A3F54B5; Mon, 4 Apr 2005 20:31:27 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 26F9B5198 for ; Mon, 4 Apr 2005 20:31:26 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa00513; 4 Apr 2005 16:30 EDT Date: Mon, 04 Apr 2005 16:30:34 -0400 From: Jeffrey Hutzelman To: Richard Whalen , Joseph Galbraith Cc: der Mouse , ietf-ssh@NetBSD.org Subject: RE: filexfer-07 Message-ID: <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> Originator-Info: login-token=Mulberry:016EKEGVKq+Y00jfyaG8C0iH+0u0Rvdv1Vt7J+HsI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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, April 04, 2005 08:55:08 AM -0400 Richard Whalen wrote: > I like the idea of naming the flags BLOCK_, as it states the > actual intention and removes some of the confusion that is out > there in the names that various operating systems use. It will > also make implementors work to understand what they need to do > rather than just match it to the similar sounding name on the > operating system (and possibly have it wrong). Me too. I am still a little concerned about the specification of only mandatory locking, when there are common server platforms on which mandatory locking is used infrequently, if at all, while advisory locking is commonplace. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 18:01:11 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16661 for ; Mon, 4 Apr 2005 18:01:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1BE5851EE; Mon, 4 Apr 2005 22:01:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 9833E5190 for ; Mon, 4 Apr 2005 22:01:02 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7292963; Mon, 04 Apr 2005 16:01:00 -0600 Message-ID: <4251B93D.6080008@vandyke.com> Date: Mon, 04 Apr 2005 16:01:33 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Richard Whalen , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> In-Reply-To: <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> 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 Jeffrey Hutzelman wrote: > > > On Monday, April 04, 2005 08:55:08 AM -0400 Richard Whalen > wrote: > > >> I like the idea of naming the flags BLOCK_, as it states the >> actual intention and removes some of the confusion that is out >> there in the names that various operating systems use. It will >> also make implementors work to understand what they need to do >> rather than just match it to the similar sounding name on the >> operating system (and possibly have it wrong). > > > Me too. > > I am still a little concerned about the specification of only mandatory > locking, when there are common server platforms on which mandatory > locking is used infrequently, if at all, while advisory locking is > commonplace. Hmmm... I'm not terribly familar with the advisory locking implemenated on most unix platforms (I could dig, I suppose, but that would take me some time.) I presume it has basically three levels of locking, none, read (don't allow writers) and write (exclusive.) I presume the lock request fails if there is already a violation? What happens when a new access request comes along that violates the advisory lock? Is the original lock holder notified in some fashion? Is it appropraite to lock a open time, or should it be a seperate request? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 18:29:03 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19815 for ; Mon, 4 Apr 2005 18:29:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C38255208; Mon, 4 Apr 2005 22:28:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.netbsd.org (Postfix) with ESMTP id C7E235188 for ; Mon, 4 Apr 2005 22:28:56 +0000 (UTC) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2005 00:28:56 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34MSqt5013650; Tue, 5 Apr 2005 00:28:52 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA17199; Mon, 4 Apr 2005 23:28:51 +0100 (BST) Date: Mon, 4 Apr 2005 23:28:51 +0100 From: Derek Fawcus To: Jeffrey Hutzelman Cc: Richard Whalen , Joseph Galbraith , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 Message-ID: <20050404232851.S18235@mrwint.cisco.com> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu>; from jhutz@cmu.edu on Mon, Apr 04, 2005 at 04:30:34PM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Apr 04, 2005 at 04:30:34PM -0400, Jeffrey Hutzelman wrote: > > I am still a little concerned about the specification of only mandatory > locking, when there are common server platforms on which mandatory locking > is used infrequently, if at all, while advisory locking is commonplace. Agreed. It also seems rather pointless to mandate mandatory locking. Some unices do not support it at all. Which means if they support the protocol locking commands, they'll simply be lying about the ability of the lock to exclude local (non SFTP) access. However (depending upon the use) this may actually be valid. I do tend to prefer advisory lock, simply because then I can peek under the covers to check what running apps are doing. DF From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 18:39:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20634 for ; Mon, 4 Apr 2005 18:39:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 293DA519F; Mon, 4 Apr 2005 22:39:10 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 181DF5185 for ; Mon, 4 Apr 2005 22:39:07 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa00585; 4 Apr 2005 18:39 EDT Date: Mon, 04 Apr 2005 18:39:05 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith Cc: Richard Whalen , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 Message-ID: In-Reply-To: <4251B93D.6080008@vandyke.com> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> Originator-Info: login-token=Mulberry:01SMXe7bItU2GUEFZue0MOXN83FRjP+Ve1OgxSfkU=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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, April 04, 2005 04:01:33 PM -0600 Joseph Galbraith wrote: > Jeffrey Hutzelman wrote: >> >> >> On Monday, April 04, 2005 08:55:08 AM -0400 Richard Whalen >> wrote: >> >> >>> I like the idea of naming the flags BLOCK_, as it states the >>> actual intention and removes some of the confusion that is out >>> there in the names that various operating systems use. It will >>> also make implementors work to understand what they need to do >>> rather than just match it to the similar sounding name on the >>> operating system (and possibly have it wrong). >> >> >> Me too. >> >> I am still a little concerned about the specification of only mandatory >> locking, when there are common server platforms on which mandatory >> locking is used infrequently, if at all, while advisory locking is >> commonplace. > > Hmmm... > > I'm not terribly familar with the advisory locking implemenated > on most unix platforms (I could dig, I suppose, but that would > take me some time.) > > I presume it has basically three levels of locking, > none, read (don't allow writers) and write (exclusive.) Correct. The difference is pretty simple. An advisory lock prevents other processes from obtaining conflicting locks. A mandatory lock also prevents other processes from performing conflicting file accesses. On most Unix systems, an SFTP server can guarantee to its client that I can't get a lock on a file, but it can't guarantee that I won't just write to the file without bothering to get a lock. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 18:54:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22011 for ; Mon, 4 Apr 2005 18:54:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A46B351BC; Mon, 4 Apr 2005 22:54:30 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id 9CD7C5185 for ; Mon, 4 Apr 2005 22:54:28 +0000 (UTC) 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 j34MsLZO010127; Mon, 4 Apr 2005 15:54:21 -0700 (PDT) Received: from thunk (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 j34MsKOp019830; Mon, 4 Apr 2005 18:54:20 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j34MsKXt017008; Mon, 4 Apr 2005 18:54:20 -0400 (EDT) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j34MsJoK017007; Mon, 4 Apr 2005 18:54:19 -0400 (EDT) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: filexfer-07 From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: Joseph Galbraith , Richard Whalen , der Mouse , ietf-ssh@NetBSD.org In-Reply-To: References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112655257.13395.530.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 04 Apr 2005 18:54:18 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-04-04 at 18:39, Jeffrey Hutzelman wrote: > On most Unix systems, an SFTP server can guarantee to its client that I > can't get a lock on a file, but it can't guarantee that I won't just write > to the file without bothering to get a lock. unix systems which implement mandatory file locking (typically SVR4-derived) typically do so on a file-by-file basis -- one particular combination of file mode bits was recast to mean that normally-advisory byte-range locks become mandatory, blocking attempts to do I/O in conflict with the lock. this prevents you from mixing advisory and mandatory locks on the same file. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 19:07:55 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23150 for ; Mon, 4 Apr 2005 19:07:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0F7CB5248; Mon, 4 Apr 2005 23:07:50 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 26D7C5185 for ; Mon, 4 Apr 2005 23:07:48 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa00617; 4 Apr 2005 19:07 EDT Date: Mon, 04 Apr 2005 19:07:07 -0400 From: Jeffrey Hutzelman To: Bill Sommerfeld Cc: Joseph Galbraith , Richard Whalen , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 Message-ID: <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> In-Reply-To: <1112655257.13395.530.camel@thunk> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <1112655257.13395.530.camel@thunk> Originator-Info: login-token=Mulberry:01BmAd+HDIkmxSq5V5Od5NZ53SVCONlJZz1UtdPOA=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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, April 04, 2005 06:54:18 PM -0400 Bill Sommerfeld wrote: > On Mon, 2005-04-04 at 18:39, Jeffrey Hutzelman wrote: > >> On most Unix systems, an SFTP server can guarantee to its client that I >> can't get a lock on a file, but it can't guarantee that I won't just >> write to the file without bothering to get a lock. > > unix systems which implement mandatory file locking (typically > SVR4-derived) typically do so on a file-by-file basis -- one particular > combination of file mode bits was recast to mean that normally-advisory > byte-range locks become mandatory, blocking attempts to do I/O in > conflict with the lock. this prevents you from mixing advisory and > mandatory locks on the same file. Correct. It also means that changing the locking mode requires changing the file mode bits, which normally can be done only by the file's owner or by a superuser. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 19:10:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23425 for ; Mon, 4 Apr 2005 19:10:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D1C08527E; Mon, 4 Apr 2005 23:10:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 146185275 for ; Mon, 4 Apr 2005 23:10:01 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7293272; Mon, 04 Apr 2005 17:09:54 -0600 Message-ID: <4251C966.9040303@vandyke.com> Date: Mon, 04 Apr 2005 17:10:30 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Richard Whalen , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> In-Reply-To: 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 Jeffrey Hutzelman wrote: > > > On Monday, April 04, 2005 04:01:33 PM -0600 Joseph Galbraith > wrote: > >> Jeffrey Hutzelman wrote: >> >>> >>> >>> On Monday, April 04, 2005 08:55:08 AM -0400 Richard Whalen >>> wrote: >>> >>> >>>> I like the idea of naming the flags BLOCK_, as it states the >>>> actual intention and removes some of the confusion that is out >>>> there in the names that various operating systems use. It will >>>> also make implementors work to understand what they need to do >>>> rather than just match it to the similar sounding name on the >>>> operating system (and possibly have it wrong). >>> >>> >>> >>> Me too. >>> >>> I am still a little concerned about the specification of only mandatory >>> locking, when there are common server platforms on which mandatory >>> locking is used infrequently, if at all, while advisory locking is >>> commonplace. >> >> >> Hmmm... >> >> I'm not terribly familar with the advisory locking implemenated >> on most unix platforms (I could dig, I suppose, but that would >> take me some time.) >> >> I presume it has basically three levels of locking, >> none, read (don't allow writers) and write (exclusive.) > > > Correct. The difference is pretty simple. An advisory lock prevents > other processes from obtaining conflicting locks. A mandatory lock also > prevents other processes from performing conflicting file accesses. > > On most Unix systems, an SFTP server can guarantee to its client that I > can't get a lock on a file, but it can't guarantee that I won't just > write to the file without bothering to get a lock. I was just locking at the advisory locks under linux (I think I was looking at the advisory locks.) They appear to allow locking of a byte range, not just the whole file? It looks like it would make more sense to support this as a seperate request rather than as part of open? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 19:25:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24804 for ; Mon, 4 Apr 2005 19:25:28 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CD94D5190; Mon, 4 Apr 2005 23:25:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id E600B5185 for ; Mon, 4 Apr 2005 23:25:23 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7293397; Mon, 04 Apr 2005 17:25:22 -0600 Message-ID: <4251CD06.8070506@vandyke.com> Date: Mon, 04 Apr 2005 17:25:58 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Bill Sommerfeld , Richard Whalen , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <1112655257.13395.530.camel@thunk> <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> In-Reply-To: <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> 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 Jeffrey Hutzelman wrote: > > > On Monday, April 04, 2005 06:54:18 PM -0400 Bill Sommerfeld > wrote: > >> On Mon, 2005-04-04 at 18:39, Jeffrey Hutzelman wrote: >> >>> On most Unix systems, an SFTP server can guarantee to its client that I >>> can't get a lock on a file, but it can't guarantee that I won't just >>> write to the file without bothering to get a lock. >> >> >> unix systems which implement mandatory file locking (typically >> SVR4-derived) typically do so on a file-by-file basis -- one particular >> combination of file mode bits was recast to mean that normally-advisory >> byte-range locks become mandatory, blocking attempts to do I/O in >> conflict with the lock. this prevents you from mixing advisory and >> mandatory locks on the same file. > > > Correct. It also means that changing the locking mode requires changing > the file mode bits, which normally can be done only by the file's owner > or by a superuser. But the server can tell what locking mode is available, and respond correctly? Though it may have to advertise both modes and responde with UNSUPPORTED for some files. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 19:32:01 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25364 for ; Mon, 4 Apr 2005 19:32:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D594152FA; Mon, 4 Apr 2005 23:31:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id AC49552D1 for ; Mon, 4 Apr 2005 23:31:55 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa00636; 4 Apr 2005 19:31 EDT Date: Mon, 04 Apr 2005 19:31:47 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith Cc: Richard Whalen , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 Message-ID: <21ED1FD23E3963DB1CA23DAB@sirius.fac.cs.cmu.edu> In-Reply-To: <4251C966.9040303@vandyke.com> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <4251C966.9040303@vandyke.com> Originator-Info: login-token=Mulberry:01jUlPafexxN3ZlMfqwMd/2CS7hpQUfcj6vn3Ow8k=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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, April 04, 2005 05:10:30 PM -0600 Joseph Galbraith wrote: > I was just locking at the advisory locks under linux (I think I was > looking at the advisory locks.) > > They appear to allow locking of a byte range, not just the whole > file? > > It looks like it would make more sense to support this as a seperate > request rather than as part of open? Like Windows, UNIX provides both whole-file and byte-range locking interfaces. Both types are generally advisory; as Bill pointed out, the decision as to whether to use advisory or mandatory locking is made on a file-by-file basis, and is controlled by the file mode bits (attributes). The interface is exactly the same in either case. I agree it would be appropriate to support byte-range locking, if it is desirable for sftp to be used as the back-end for something that looks like a filesystem. In particular, our experiences with AFS indicate that while relatively few UNIX programs use byte-range locking at all, some software, particularly on Windows, simply will not function correctly without it. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 19:34:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25627 for ; Mon, 4 Apr 2005 19:34:21 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 049DE5188; Mon, 4 Apr 2005 23:34:21 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id A5F8D5185 for ; Mon, 4 Apr 2005 23:34:18 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa00639; 4 Apr 2005 19:33 EDT Date: Mon, 04 Apr 2005 19:33:51 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith Cc: Bill Sommerfeld , Richard Whalen , der Mouse , ietf-ssh@NetBSD.org Subject: Re: filexfer-07 Message-ID: <8D08CBF45F9CFC8C527D27FA@sirius.fac.cs.cmu.edu> In-Reply-To: <4251CD06.8070506@vandyke.com> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <1112655257.13395.530.camel@thunk> <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> <4251CD06.8070506@vandyke.com> Originator-Info: login-token=Mulberry:01I/p5NI1i7qhvRfG1Vnipo7pssF+qLvKQb6eZWXo=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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, April 04, 2005 05:25:58 PM -0600 Joseph Galbraith wrote: > Jeffrey Hutzelman wrote: >> >> >> On Monday, April 04, 2005 06:54:18 PM -0400 Bill Sommerfeld >> wrote: >> >>> On Mon, 2005-04-04 at 18:39, Jeffrey Hutzelman wrote: >>> >>>> On most Unix systems, an SFTP server can guarantee to its client that I >>>> can't get a lock on a file, but it can't guarantee that I won't just >>>> write to the file without bothering to get a lock. >>> >>> >>> unix systems which implement mandatory file locking (typically >>> SVR4-derived) typically do so on a file-by-file basis -- one particular >>> combination of file mode bits was recast to mean that normally-advisory >>> byte-range locks become mandatory, blocking attempts to do I/O in >>> conflict with the lock. this prevents you from mixing advisory and >>> mandatory locks on the same file. >> >> >> Correct. It also means that changing the locking mode requires changing >> the file mode bits, which normally can be done only by the file's owner >> or by a superuser. > > But the server can tell what locking mode is available, and > respond correctly? Though it may have to advertise both modes > and responde with UNSUPPORTED for some files. This requires platform-specific knowledge, but yes, the server can generally tell what sort of locking is available. If sftp is to support both types of locking, then the spec should be written such that a server can claim to support advisory locking even when locks it sets are actually mandatory. Put another way, an advisory lock should not require the server to prohibit other processes from accessing the file, but it should not preclude it from doing so, either. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 20:28:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29337 for ; Mon, 4 Apr 2005 20:28:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 954E1520C; Tue, 5 Apr 2005 00:27:57 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from shitei.mindrot.org (shitei.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 192745165 for ; Tue, 5 Apr 2005 00:27:55 +0000 (UTC) Received: from baragon.mindrot.org (adsl-226-34.swiftdsl.com.au [218.214.226.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id 3743B27C188 for ; Tue, 5 Apr 2005 10:27:22 +1000 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by baragon.mindrot.org (Postfix) with ESMTP id E085516F7B8 for ; Tue, 5 Apr 2005 10:27:20 +1000 (EST) Message-ID: <4251DB68.10805@mindrot.org> Date: Tue, 05 Apr 2005 10:27:20 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 1.0 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: filexfer-07 References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <1112655257.13395.530.camel@thunk> <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> <4251CD06.8070506@vandyke.com> <8D08CBF45F9CFC8C527D27FA@sirius.fac.cs.cmu.edu> In-Reply-To: <8D08CBF45F9CFC8C527D27FA@sirius.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 With all this talk of adding yet more complexity to sftp/filexfer, I have to ask: what is the purpose? If people want nfs-like functionality in filexfer, then they should just specify a subsystem for using NFS over ssh. If filexfer is supposed to be simple and lightweight, then the boat has already been missed. Sure, much of the functionality mentioned in the draft is optional, but there is a cost to implementors in implementing fallbacks, etc. If an implementation needs multiple revisions of the draft (all do), then the cost is much higher. Because of this, we (OpenSSH) don't have any plans to implement filexfer > 03. The two or three things that 03 doesn't do that our users ask for can easily be done through the extension mechanism. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 4 21:28:42 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03589 for ; Mon, 4 Apr 2005 21:28:41 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C501C5368; Tue, 5 Apr 2005 01:28:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 77E6F534E for ; Tue, 5 Apr 2005 01:28:22 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7293592; Mon, 04 Apr 2005 19:28:21 -0600 Message-ID: <4251E9D9.4030204@vandyke.com> Date: Mon, 04 Apr 2005 19:28:57 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Miller Cc: ietf-ssh@NetBSD.org Subject: Re: filexfer-07 References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <1112655257.13395.530.camel@thunk> <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> <4251CD06.8070506@vandyke.com> <8D08CBF45F9CFC8C527D27FA@sirius.fac.cs.cmu.edu> <4251DB68.10805@mindrot.org> In-Reply-To: <4251DB68.10805@mindrot.org> 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 Damien Miller wrote: > With all this talk of adding yet more complexity to sftp/filexfer, I > have to ask: what is the purpose? > > If people want nfs-like functionality in filexfer, then they should just > specify a subsystem for using NFS over ssh. If filexfer is supposed to > be simple and lightweight, then the boat has already been missed. I believe it is still simpler and lighter weight than NFS; in particular, filexfer excels in the same area that SSH does: ad-hoc secure networks (or in this case ad-hoc secure file-sharing.) Adding NFS to the mix, at least in my opinion, makes it a lot less ad-hoc in nature. > Sure, much of the functionality mentioned in the draft is optional, but > there is a cost to implementors in implementing fallbacks, etc. Well, if you don't use any optional functionality, you don't need to implement any fallbacks. Take for example the locking functionality that has just been discussed; if you don't ever request any locks, mandatory or advisory, you never even need to worry about whether the server supports them or not. No fallback behavior needed. > If an > implementation needs multiple revisions of the draft (all do), then the > cost is much higher. The current draft allows you to skip implementating intermediate versions. (You have to implement at least version three so extensions work.) > Because of this, we (OpenSSH) don't have any plans to implement filexfer > > 03. The two or three things that 03 doesn't do that our users ask for > can easily be done through the extension mechanism. That would be a shame (both for us who still have to interoperate with openssh, and for you customers), but I don't expect I'll change your mind. I guess I understand. To be honest, 03 supported unix secure file transfers pretty well. It isn't a problem to generate the long listings under unix. And as long as you don't get to wild in the variations, you don't care that clients are parsing the string to get the data that isn't in the attributes. You don't really have need of most of the new attribute fields, because unix doesn't support them. The extra open control doesn't buy you anything, because unix doesn't really support any of it anyway, and the original open was modelled after the unix open semantics. Mode bits express the access control on the file. And so on. On the other hand, on windows, we do have real problems, even with plain-old ftp applications. For example, we have problems with customers wanting to be able to control the locking mode. Under windows, opening files for exclusive access is customary; have the server do so is what customers expect in most cases. But in some cases, for example, when reading a active log file, customers want an exception to that rule. Customers doing a listing expect to see create time in the listing, not ctime. uid/gid is meaningless-- windows uses a variables sized structure to express this information. If a customer wants information about the files access control, it can't be expressed as mode bits. In most cases, the added complexities of the draft are similar in nature-- they support operating systems that aren't unix in nature while striving to enable unix platforms to continue to have complete coverage and pay the minimal price in mandatory complexity. There are, admittedly, some new features in the draft do exist solely to support file-sharing better... but, they aren't the majority of the complexity. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 00:06:52 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13808 for ; Tue, 5 Apr 2005 00:06:51 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 149F553BA; Tue, 5 Apr 2005 04:06:47 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id C337C5180 for ; Tue, 5 Apr 2005 04:06:44 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA13558; Tue, 5 Apr 2005 00:06:35 -0400 (EDT) From: der Mouse Message-Id: <200504050406.AAA13558@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 4 Apr 2005 23:53:20 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: filexfer-07 In-Reply-To: <4251B93D.6080008@vandyke.com> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I'm not terribly familar with the advisory locking implemenated on > most unix platforms [...]. > I presume it has basically three levels of locking, none, read (don't > allow writers) and write (exclusive.) Right. > I presume the lock request fails if there is already a violation? Depends. With all interfaces I know of, when you request a lock, you specify (typically by setting or not setting an optional bit) what to do if the lock requested cannot be acquired immediately, one behaviour being to sleep until it can be acquired and the other being to return immediately with a distinctive error. > What happens when a new access request comes along that violates the > advisory lock? Is the original lock holder notified in some fashion? By "access request" you mean I/O attempt? Nothing. That's the "advisory" bit: the locks have nothing whatever to do with actually reading or writing the file; all they really affect is other lock attempts on the file. > Is it appropraite to lock a open time, or should it be a seperate > request? Recent BSD has the O_SHLOCK and O_EXLOCK flags to open(2), which take a shared or exclusive lock atomically with opening the file. Since opening an existing file is not an operation with semantic significance to anyone else, the atomicity is irrelevant except when the open actually creates the file. Similar remarks apply to opening and locking over sftp, as far as I can see. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 00:28:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15177 for ; Tue, 5 Apr 2005 00:28:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C899B53BE; Tue, 5 Apr 2005 04:28:02 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 7CC035180 for ; Tue, 5 Apr 2005 04:28:00 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA13626; Tue, 5 Apr 2005 00:27:59 -0400 (EDT) From: der Mouse Message-Id: <200504050427.AAA13626@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 5 Apr 2005 00:25:11 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: filexfer-07 In-Reply-To: <4251E9D9.4030204@vandyke.com> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <1112655257.13395.530.camel@thunk> <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> <4251CD06.8070506@vandyke.com> <8D08CBF45F9CFC8C527D27FA@sirius.fac.cs.cmu.edu> <4251DB68.10805@mindrot.org> <4251E9D9.4030204@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> If an implementation needs multiple revisions of the draft (all do), >> then the cost is much higher. > The current draft allows you to skip implementating intermediate > versions. (You have to implement at least version three so > extensions work.) Except version three isn't documented, is it? (Unless you're lucky enough to have a saved copy of the I-D for it from back when, that is.) /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 00:44:48 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16259 for ; Tue, 5 Apr 2005 00:44:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1709353C6; Tue, 5 Apr 2005 04:44:44 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 4CA545180 for ; Tue, 5 Apr 2005 04:44:42 +0000 (UTC) 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 j354ifX8012850; Mon, 4 Apr 2005 22:44:41 -0600 (MDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j354iQOp012291; Tue, 5 Apr 2005 00:44:26 -0400 (EDT) Subject: Re: filexfer-07 From: Bill Sommerfeld To: der Mouse Cc: ietf-ssh@NetBSD.org In-Reply-To: <200504050427.AAA13626@Sparkle.Rodents.Montreal.QC.CA> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <1112655257.13395.530.camel@thunk> <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> <4251CD06.8070506@vandyke.com> <8D08CBF45F9CFC8C527D27FA@sirius.fac.cs.cmu.edu> <4251DB68.10805@mindrot.org> <4251E9D9.4030204@vandyke.com> <200504050427.AAA13626@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain Message-Id: <1112676247.9762.9115.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Tue, 05 Apr 2005 00:44:08 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-04-05 at 00:25, der Mouse wrote: > >> If an implementation needs multiple revisions of the draft (all do), > >> then the cost is much higher. > > The current draft allows you to skip implementating intermediate > > versions. (You have to implement at least version three so > > extensions work.) > > Except version three isn't documented, is it? (Unless you're lucky > enough to have a saved copy of the I-D for it from back when, that is.) old versions of working group drafts are available from a multitude of archives, and have recently been made available officially via an ietf site. in this case, look at: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 00:58:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17552 for ; Tue, 5 Apr 2005 00:58:26 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 06D7353ED; Tue, 5 Apr 2005 04:57:49 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 17F7C5411 for ; Tue, 5 Apr 2005 04:57:30 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA13933; Tue, 5 Apr 2005 00:57:29 -0400 (EDT) From: der Mouse Message-Id: <200504050457.AAA13933@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 5 Apr 2005 00:54:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: filexfer-07 In-Reply-To: <1112676247.9762.9115.camel@unknown.hamachi.org> References: <3EF96AF20489A34296050FBD5C36ECB905A35C@beacon.PSC.process.com> <9487709A1D59CC0FAAA1D75F@sirius.fac.cs.cmu.edu> <4251B93D.6080008@vandyke.com> <1112655257.13395.530.camel@thunk> <12CD45B21891ACF58D6D16FF@sirius.fac.cs.cmu.edu> <4251CD06.8070506@vandyke.com> <8D08CBF45F9CFC8C527D27FA@sirius.fac.cs.cmu.edu> <4251DB68.10805@mindrot.org> <4251E9D9.4030204@vandyke.com> <200504050427.AAA13626@Sparkle.Rodents.Montreal.QC.CA> <1112676247.9762.9115.camel@unknown.hamachi.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> The current draft allows you to skip implementating intermediate >>> versions. (You have to implement at least version three so >>> extensions work.) >> Except version three isn't documented, is it? (Unless you're lucky >> enough to have a saved copy of the I-D for it [...].) > old versions of working group drafts are available from a multitude > of archives, and have recently been made available officially via an > ietf site. > in this case, look at: > http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ Oh, good. Thank you. I didn't know they were now available. What about the implications for standardization? Won't the eventual standard need to have an explicit description of at least some of version 3? Surely referring to an expired I-D won't cut it for a standard? /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 01:33:07 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20298 for ; Tue, 5 Apr 2005 01:33:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C10EA5403; Tue, 5 Apr 2005 05:32:58 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id A29F853DD for ; Tue, 5 Apr 2005 05:32:55 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA14093; Tue, 5 Apr 2005 01:32:54 -0400 (EDT) From: der Mouse Message-Id: <200504050532.BAA14093@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 5 Apr 2005 00:59:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt In-Reply-To: <200504041952.PAA19908@ietf.org> References: <200504041952.PAA19908@ietf.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I jsut read over draft-ietf-secsh-publickeyfile-08.txt; herewith comments. Bare numbers flush left are section numbers. 3 A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 bytes excluding line termination characters. 3.1 Implementations are REQUIRED to read files using any of the common line termination sequence, , or . I see problems here, both philosophical and practical. A file containing a sequence of lines does not necessary have *any* line termination sequence. Across the OSes I've used, I've seen at least three ways of storing a sequence of lines in a text file, only one of which fits the termination-sequence model. (One way is a termination sequence; another way is a length attached to each line, but returned by the interface not as in-band octets but rather as the length of the record read; a third way is a record length attached to the file, equal for all records in the file.) Line termination sequences make sense only for files that are conceptually sequences of octets, rather than files that are conceptually sequences of lines ("records" is the usual word in filesystem docs I've seen). If you want to provide a spec for encoding public keys as octet streams containing sequences of lines delimited by line termination sequences, that's fine, but that's (a) less useful (because it requires converting between octet-stream representations and native representations for filesystems that don't use line termination sequences) and (b) not what publickeyfile-08 calls itself. At various other places, I see wording such as "excluding line termination characters" which I think needs an ", if any" attached. Of course, depending on how the line termination wording is resolved, this may become a non-issue. 3.3 The Header-tag MUST NOT be more than 64 bytes, and is case-insensitive. The Header-value MUST NOT be more than 1024 bytes. Each line in the header MUST NOT be more than 72 bytes. Since the Header-tag is explicitly declared case-insensitive, I'd prefer to see the case-sensitivity of the Header-value mentioned, even if only with wording like "...more than 1024 bytes, and, depending on the Header-tag, may or may not be case-sensitive.". 3.3 A line that is not a continuation line that has no ':' in it is the first line of the base 64 encoded body (See Section 3.4.) s/base 64/base-64/ here? 3.3.1 No indication is given here what to do if the login name in question does not exist or is not available. Is the format unusable? Should Subject: be omitted? Should whatever username is available be used? Or something else? 3.3.2 existing implementations fail if these quotation marks are omitted There's an end-of-sentence . missing here. 3.3.2 Implementations MAY include the quotation marks. If the first and last characters of the Header-value are matching quotation marks, implementations SHOULD remove them before using the value. "matching quotation marks" sounds as though there are other characters than " that count as quotation marks. I'd prefer to see this list explicitly described, or else an indication that any character can function as a quotation mark (or possibly any character except a letter, or some such). 4 I'd like to see a specific public key quoted here together with its fingerprint, for the same reason crypto specs include test vectors. 6 intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main s/E. J/E. J/ surely? 6 is for historical purposes, and the particular use made of it depends solely one it's 2nd-preimage resistance, not on it's s/it's/its/g on the second of the quoted lines. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 08:36:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15072 for ; Tue, 5 Apr 2005 08:36:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5D81D5410; Tue, 5 Apr 2005 12:36:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 37DDD5193 for ; Tue, 5 Apr 2005 12:36:15 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DInHy-0000mF-00 for ietf-ssh@netbsd.org; Tue, 05 Apr 2005 13:36:14 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: Ben Harris's individual submissions: arcfour-fixes and rsa-kex In-Reply-To: <200504030227.VAA27779@Sparkle.Rodents.Montreal.QC.CA> References: <1112213215.20951.264.camel@thunk> <200504030227.VAA27779@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Message-Id: Date: Tue, 05 Apr 2005 13:36:14 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200504030227.VAA27779@Sparkle.Rodents.Montreal.QC.CA> you write: >>>> rsa-kex is a weaker kex >>> Well, it's weaker in some respects, >> [D]iscussions of SHA-1 have convinced me that there's a slight >> weakness here that I should perhaps guard against. Because the >> client can see all the other input to the exchange hash before it >> generates K, if it's got a working collision attack against HASH it >> can create two sessions with the same session ID. > >I'm not sure this buys you anything of significance. Even granting all >the above, what can go wrong if a client (or two clients in collusion, >which amounts to the same thing) gets two sessions with the same >session ID? Nothing that I can think of, but SSH is an extensible protocol, which means we need to allow for possible future developments. At the moment, I think that duplicate session IDs are only a problem if the client in one session colludes with (or is) the server in another, in which case they can MITM a session from the other client to the other server. I think this is only by chance, though, and I can't be sure that future extensions won't assume the uniqueness of session IDs in other ways. Imagine, for instance, a backwards version of my RSA KEX, in which the client generates a key and the server encrypts the secret under it. This might be useful if your server is particularly short of CPU. Given a client, A, which supports this imaginary KEX method, a server, B, which supports my KEX method, and an adversary, M, which can generate collisions in SHA-1, M can MITM a connection between A and B despite the fact that neither A nor B supports both protocols. This is all getting a bit silly really. I'm arguing that my protocol is insecure despite the fact that I think it's secure enough (cracking the RSA keys should be about as hard as generating hash collisions, and is a lot more dangerous since it can be done off-line). -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 08:52:47 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16906 for ; Tue, 5 Apr 2005 08:52:46 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5146F545B; Tue, 5 Apr 2005 12:52:39 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id E13415193 for ; Tue, 5 Apr 2005 12:52:36 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DInXo-0002iG-00 for ietf-ssh@netbsd.org; Tue, 05 Apr 2005 13:52:36 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt In-Reply-To: <200504050532.BAA14093@Sparkle.Rodents.Montreal.QC.CA> References: <200504041952.PAA19908@ietf.org> <200504041952.PAA19908@ietf.org> <200504050532.BAA14093@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Message-Id: Date: Tue, 05 Apr 2005 13:52:36 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200504050532.BAA14093@Sparkle.Rodents.Montreal.QC.CA> you write: >If you want to provide a spec for encoding public keys as octet streams >containing sequences of lines delimited by line termination sequences, >that's fine, but that's (a) less useful (because it requires converting >between octet-stream representations and native representations for >filesystems that don't use line termination sequences) and (b) not what >publickeyfile-08 calls itself. Um, section 2 makes it fairly clear that the format described is for exchanging public keys between implementations, rather than necessarily for use within an implementation. It could probably be clearer. >3.3 > The Header-tag MUST NOT be more than 64 bytes, and is > case-insensitive. The Header-value MUST NOT be more than 1024 bytes. > Each line in the header MUST NOT be more than 72 bytes. > >Since the Header-tag is explicitly declared case-insensitive, I'd >prefer to see the case-sensitivity of the Header-value mentioned, even >if only with wording like "...more than 1024 bytes, and, depending on >the Header-tag, may or may not be case-sensitive.". I don't think case-sensitivity is a useful concept to apply to header-values in the abstract. To take an analogy, would you say that the RFC-822 "Subject" header is case-sensitive or not? >3.3 > A line that is not a continuation line that has no ':' in it is the > first line of the base 64 encoded body (See Section 3.4.) > >s/base 64/base-64/ here? "base64-encoded", actually. See RFC 2045. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 09:38:11 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20383 for ; Tue, 5 Apr 2005 09:38:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7FA4154DE; Tue, 5 Apr 2005 13:38:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id DA00A5248 for ; Tue, 5 Apr 2005 13:38:01 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DIoFl-0006wn-00 for ietf-ssh@netbsd.org; Tue, 05 Apr 2005 14:38:01 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt In-Reply-To: <200504041952.PAA19908@ietf.org> References: <200504041952.PAA19908@ietf.org> Organization: Linux Unlimited Message-Id: Date: Tue, 05 Apr 2005 14:38:01 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200504041952.PAA19908@ietf.org> you write: > Title : SSH Public Key File Format > Author(s) : J. Galbraith, R. Thayer > Filename : draft-ietf-secsh-publickeyfile-08.txt > Pages : 14 > Date : 2005-4-4 One semantic problem: Both sections 3.4 and 4 refer to a "public key blob". This term isn't clearly defined by [SSH-TRANS], and in particular it's hinted there that it doesn't include the name of the key type: The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. It would appear from the first example given that publickeyfile expects the "public key blob" to include the key type name, though, since it begins with the string "ssh-rsa". I'd suggest removing the word "blob" wherever it occurs, since it appears that "public key" in [SSH-TRANS] includes the key type string. I echo der Mouse's suggestion that an example of a key and its corresponding fingerprint would be useful. I'd suggest putting the examples in a section of their own after the definition of fingerprints, and including the fingerprint of each key. It might be polite to acknowledge Markus Friedl, who wrote the previous fingerprint drafts. Simple nits, presented as a diff as usual: --- draft-ietf-secsh-publickeyfile-08.txt Mon Apr 4 17:47:10 2005 +++ draft-ietf-secsh-publickeyfile-bjh.txt Tue Apr 5 14:23:53 2005 @@ -283 +283 @@ - first line of the base 64 encoded body (See Section 3.4.) + first line of the base64-encoded body (See Section 3.4.) @@ -308 +308 @@ - existing implementations fail if these quotation marks are omitted + existing implementations fail if these quotation marks are omitted. @@ -327,2 +327,2 @@ - described in [I-D.ietf-secsh-transport], section 4.6, "Public Key - Algorithms", encoded in base 64 as specified in [RFC2045], section + described in [I-D.ietf-secsh-transport], section 6.6, "Public Key + Algorithms", encoded in base64 as specified in [RFC2045], section @@ -357 +357 @@ - (note that the examples all wrap before 72 lines to meet ietf + (note that the examples all wrap before 72 columns to meet IETF @@ -454 +454,2 @@ - difficult for a human to verify an entire host key. Even with a PKI + difficult for a human to verify an entire host key. Even with a + public key infrastructure @@ -566 +567 @@ - stored in such files. Given the potential of an adversarial + stored in such files. Given the potential for an adversary's @@ -571 +572 @@ - trusted channel. + secure channel. @@ -585 +586 @@ - solely one it's 2nd-preimage resistance, not on it's + solely on its 2nd-preimage resistance, not on its -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 10:09:59 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23189 for ; Tue, 5 Apr 2005 10:09:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5200651CD; Tue, 5 Apr 2005 14:09:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id A60715175 for ; Tue, 5 Apr 2005 14:09:53 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 5C7BD1B80E1 for ; Tue, 5 Apr 2005 16:09:52 +0200 (CEST) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 08014-01-11 for ; Tue, 5 Apr 2005 16:09:42 +0200 (CEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 5742B1B806C for ; Tue, 5 Apr 2005 16:09:42 +0200 (CEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j35E9gGQ025609 for ; Tue, 5 Apr 2005 16:09:42 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j35E9cQd025605; Tue, 5 Apr 2005 16:09:38 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex-01.txt References: <200504030127.UAA27141@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?=) In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Date: 05 Apr 2005 16:09:38 +0200 Message-ID: Lines: 35 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit [ This is a repost, by mistake I first replied only to Ben Harris, not to the list. ] Ben Harris writes: > In article <200504030127.UAA27141@Sparkle.Rodents.Montreal.QC.CA> you write: > > Note that the encoding of the encrypted secret is similar to the > > "mpint" encoding of the raw RSA encryption result, but differs in > > its handling of high-order 0 bits. The packet contains the octet > > sequence as a "string", not the raw RSA output as an "mpint". > > > >(Assuming of course that that's what is intended; if not, the wording > >needs even mroe work.) > > That is the intention, yes, and I agree that it would probably be best to > make this difference explicit. I don't quite like the old choice of the "string" type for rsa_signature_blob (and dss_signature_blob) instead of mpint, although I understand it may make the interface to off-the-shelf RSA libraries a little easier. At a first look, it seems like you're introducing yet another almost-mpint representation for one particular bignum in the protocol, which at least to me appears as a very bad idea; my gut reaction was the same as Peter's. If you want to do it this way, it's easier to accept if you make clear that you're really using the same representation as for rsa_signature_blob (at least I hope you *are* using the same representation, but I haven't looked into this in sufficient detail yet). Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 12:34:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06935 for ; Tue, 5 Apr 2005 12:34:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 031F553CE; Tue, 5 Apr 2005 16:34:17 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id C81B453BB for ; Tue, 5 Apr 2005 16:34:14 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA15768; Tue, 5 Apr 2005 12:34:14 -0400 (EDT) From: der Mouse Message-Id: <200504051634.MAA15768@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 5 Apr 2005 12:22:10 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt In-Reply-To: References: <200504041952.PAA19908@ietf.org> <200504041952.PAA19908@ietf.org> <200504050532.BAA14093@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> If you want to provide a spec for encoding public keys as octet >> streams containing sequences of lines delimited by line termination >> sequences, that's fine, but that's (a) less useful (because it >> requires converting between octet-stream representations and native >> representations for filesystems that don't use line termination >> sequences) and (b) not what publickeyfile-08 calls itself. > Um, section 2 makes it fairly clear that the format described is for > exchanging public keys between implementations, rather than > necessarily for use within an implementation. It could probably be > clearer. It's clear that's what motivated it. It's not clear that it's intended to be restricted to that. I'm also not convinced that it makes any difference. A text file is a reasonable unit for interchange; there is no need to reduce it to an octet sequence of defined contents. After all, such interchange may well be between implementations running on the same OS or even the same machine. While most storage mechanisms do reduce a text file to an octet sequence at some point, that octet sequence does not need to fall under the jurisdiction of the spec - nor would it be particularly useful for it to do so. >> Since the Header-tag is explicitly declared case-insensitive, I'd >> prefer to see the case-sensitivity of the Header-value mentioned, >> even if only with wording like "...more than 1024 bytes, and, >> depending on the Header-tag, may or may not be case-sensitive.". > I don't think case-sensitivity is a useful concept to apply to > header-values in the abstract. I do (see below). Your I-D defines only two headers, though, and neither of them is for routine automated consumption, so neither of them really needs a case-sensitivity spec - though they need to be case-preserved, it seems to me. > To take an analogy, would you say that the RFC-822 "Subject" header > is case-sensitive or not? Since Subject: is an unstructured header field, I'm not sure it is useful in that case. But as an abstract concept it is useful; consider Content-Transfer-Encoding:, which is defined to be case-insensitive. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 15:27:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23036 for ; Tue, 5 Apr 2005 15:27:17 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F24E153E2; Tue, 5 Apr 2005 19:27:12 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from liandra.pc.cs.cmu.edu (unknown [128.237.235.97]) by mail.netbsd.org (Postfix) with SMTP id 32A385164 for ; Tue, 5 Apr 2005 19:27:10 +0000 (UTC) Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa08085; 5 Apr 2005 13:26 EDT Date: Tue, 05 Apr 2005 13:26:34 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt Message-ID: <3890000.1112721994@liandra.pc.cs.cmu.edu> In-Reply-To: <200504051634.MAA15768@Sparkle.Rodents.Montreal.QC.CA> References: <200504041952.PAA19908@ietf.org> <200504041952.PAA19908@ietf.org> <200504050532.BAA14093@Sparkle.Rodents.Montreal.QC.CA> <200504051634.MAA15768@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 Tuesday, April 05, 2005 12:22:10 -0400 der Mouse wrote: >>> If you want to provide a spec for encoding public keys as octet >>> streams containing sequences of lines delimited by line termination >>> sequences, that's fine, but that's (a) less useful (because it >>> requires converting between octet-stream representations and native >>> representations for filesystems that don't use line termination >>> sequences) and (b) not what publickeyfile-08 calls itself. >> Um, section 2 makes it fairly clear that the format described is for >> exchanging public keys between implementations, rather than >> necessarily for use within an implementation. It could probably be >> clearer. > > It's clear that's what motivated it. It's not clear that it's intended > to be restricted to that. > > I'm also not convinced that it makes any difference. A text file is a > reasonable unit for interchange; there is no need to reduce it to an > octet sequence of defined contents. After all, such interchange may > well be between implementations running on the same OS or even the same > machine. While most storage mechanisms do reduce a text file to an > octet sequence at some point, that octet sequence does not need to fall > under the jurisdiction of the spec - nor would it be particularly > useful for it to do so. On the contrary, this document essentially specifies a wire format for the interchange of SSH public keys. As such, it MUST specify details like line termination. Otherwise it is underspecified, and it may not be possible to create interoperable implementations. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 16:10:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08830 for ; Tue, 5 Apr 2005 16:10:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 85C09520D; Tue, 5 Apr 2005 20:10:37 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 0D7225164 for ; Tue, 5 Apr 2005 20:10:35 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7309217 for ietf-ssh@netbsd.org; Tue, 05 Apr 2005 14:10:34 -0600 Message-ID: <4252F0E2.9010702@vandyke.com> Date: Tue, 05 Apr 2005 14:11:14 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-ssh@netbsd.org" Subject: I've cycled the filexfer draft... 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 I've sent the new filexfer draft in for publishing. For those that can't wait, you can preview it here: http://www.swcp.com/~galb/draft-ietf-secsh-filexfer-08.txt The xml source is here: http://www.swcp.com/~galb/draft-ietf-secsh-filexfer.xml (I simply run it through xml.resource.org to generate the .txt file.) Please send feedback. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 21:34:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10304 for ; Tue, 5 Apr 2005 21:34:31 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 699C052A1; Wed, 6 Apr 2005 01:34:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by mail.netbsd.org (Postfix) with ESMTP id AEB505164 for ; Wed, 6 Apr 2005 01:34:24 +0000 (UTC) Received: from libra.cus.cam.ac.uk ([131.111.8.19]:34916) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp id 1DIzR0-0001Gc-R4 (Exim 4.44) for ietf-ssh@netbsd.org (return-path ); Wed, 06 Apr 2005 02:34:22 +0100 Received: from bjh21 (helo=localhost) by libra.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1DIzR0-0002Ag-8p for ietf-ssh@netbsd.org; Wed, 06 Apr 2005 02:34:22 +0100 Date: Wed, 6 Apr 2005 02:34:22 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: draft-harris-ssh-arcfour-fixes-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: ietf-ssh-owner@NetBSD.org Precedence: list I've put together a new arcfour-fixes draft: It mostly just improves the security considerations by describing what I now think are the true consequences of Fluhrer and McGrew's distinguisher. My plan is that unless someone comes up with a serious flaw in this version, I'll fix any minor errors, post -02 using algorithm names from the IETF namespace, wait two weeks and then send it to the IESG as a proposed Proposed Standard. If this is a bad idea, someone should tell me so. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 21:55:20 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11874 for ; Tue, 5 Apr 2005 21:55:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 883B8529B; Wed, 6 Apr 2005 01:55:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpb.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.12]) by mail.netbsd.org (Postfix) with ESMTP id 73FD05164 for ; Wed, 6 Apr 2005 01:55:13 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id DEBDE352AC; Wed, 6 Apr 2005 13:54:24 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19029-12; Wed, 6 Apr 2005 13:54:24 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id D2B50352CE; Wed, 6 Apr 2005 13:54:23 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 9A8E03774E; Wed, 6 Apr 2005 13:54:23 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DIzkR-00062H-00; Wed, 06 Apr 2005 13:54:27 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, jhutz@cmu.edu, mouse@Rodents.Montreal.QC.CA Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt In-Reply-To: <3890000.1112721994@liandra.pc.cs.cmu.edu> Message-Id: Date: Wed, 06 Apr 2005 13:54:27 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jeffrey Hutzelman writes: >On the contrary, this document essentially specifies a wire format for the >interchange of SSH public keys. As such, it MUST specify details like line >termination. Otherwise it is underspecified, and it may not be possible to >create interoperable implementations. This is just getting silly... no, more than that, it's ridiculously pedantic. Yes, it is in theory possible to find a record-oriented system that doesn't support flat text files. However, if anyone were ever to port SSH to CICS, I'm sure they could write a special profile for it that would allow it to interoperate with all the other CICS implementations of SSH. In the meantime since MIME, PGP, XML, and a million other flat-text formats have somehow managed to struggle by without worrying about this, why is it a concern here? The coverage of the flat-text format in the spec seems perfectly clear and completely adequate to me, I'd suggest that if anyone feels the need to add 20 pages of additional wording explaining to readers what a text file is, they may prefer another line of work. Writing ETSI PKI standards springs to mind. Peter :-). From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 23:44:48 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18958 for ; Tue, 5 Apr 2005 23:44:47 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 311A5535B; Wed, 6 Apr 2005 03:44:43 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id D5A2E5164 for ; Wed, 6 Apr 2005 03:44:40 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA18559; Tue, 5 Apr 2005 23:44:39 -0400 (EDT) From: der Mouse Message-Id: <200504060344.XAA18559@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 5 Apr 2005 23:34:34 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt In-Reply-To: <3890000.1112721994@liandra.pc.cs.cmu.edu> References: <200504041952.PAA19908@ietf.org> <200504041952.PAA19908@ietf.org> <200504050532.BAA14093@Sparkle.Rodents.Montreal.QC.CA> <200504051634.MAA15768@Sparkle.Rodents.Montreal.QC.CA> <3890000.1112721994@liandra.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > On the contrary, this document essentially specifies a wire format > for the interchange of SSH public keys. That's not what it says it specifies, but it's approximately what it does specify. That dissonance is, essentially, what I think needs fixing. > As such, it MUST specify details like line termination. Otherwise it > is underspecified, and it may not be possible to create interoperable > implementations. Yes - if it were a wire format. But a wire format without a protocol to transmit it over is an odd thing, and, conceptually, it really does make sense to specify the format in terms of a stream of lines. It really needs, it seems to me, to decide whether it is specifying a stream of lines (in which case line termination should not even be mentioned, since that is outside the scope of the spec, how lines are represented in storage being a local matter and how lines are encoded for transmission being a matter for the transmission protocol in use) or a stream of octets (in which case it should not call itself a file format, and definitely does need to specify how lines are encoded into octet streams). Personally, I prefer the stream-of-lines model, but it's not my draft. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 5 23:55:00 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19736 for ; Tue, 5 Apr 2005 23:54:59 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1E87952D4; Wed, 6 Apr 2005 03:54:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 909C15164 for ; Wed, 6 Apr 2005 03:54:56 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA18590; Tue, 5 Apr 2005 23:54:55 -0400 (EDT) From: der Mouse Message-Id: <200504060354.XAA18590@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 5 Apr 2005 23:44:50 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > This is just getting silly... no, more than that, it's ridiculously > pedantic. Yes, it is in theory possible to find a record-oriented > system that doesn't support flat text files. However, that's not what I'm talking about. I'm talking about systems that support "flat text files", but in ways other than as an octet stream with line boundaries marked by distinctive octet sequences. Some text file types on VMS, for example. > However, if anyone were ever to port SSH to CICS, I'm sure they could > write a special profile for it that would allow it to interoperate > with all the other CICS implementations of SSH. Quite possibly, but, as written, they would not be able to use publickeyfile (assuming, that is, that CICS text files cannot use line-termination octets). They would at best use a similar format that did not require line-termination octets to represent line breaks - basically, publickeyfile without the folderol about line termination characters. > In the meantime since MIME, PGP, XML, and a million other flat-text > formats have somehow managed to struggle by without worrying about > this, why is it a concern here? Quite so. I would prefer that all the language about line-termination characters be ripped out and the spec be written purely in terms of lines, without specifying anything about how those lines are represented. > The coverage of the flat-text format in the spec seems perfectly > clear and completely adequate to me, I'd suggest that if anyone feels > the need to add 20 pages of additional wording explaining to readers > what a text file is, they may prefer another line of work. (1) I point out to you the language about line termination characters, which is unimplementable nonsense on OSes that don't use line termination characters to delimit lines; (2) 20 pages is a gross exaggeration; (3) I am not suggesting adding any text, but rather removing text (unless someone is steadfastly opposed to removing the line termination language, and even then only the occasional "if any" note or equivalent); and (4) this (proposed) change is not an attempt to explain or specify what a text file is, but to avoid constraining what a text file is in ways that are incompatible with some environments. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 6 14:05:09 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11204 for ; Wed, 6 Apr 2005 14:05:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9EA1D52FE; Wed, 6 Apr 2005 18:05:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (unknown [IPv6:3ffe:1ce1:0:12:20e:9bff:fe1b:4e1]) by mail.netbsd.org (Postfix) with ESMTP id 2A8145182 for ; Wed, 6 Apr 2005 18:04:59 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1EAC4E0063; Wed, 6 Apr 2005 14:04:51 -0400 (EDT) To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex-01.txt References: <200504030127.UAA27141@Sparkle.Rodents.Montreal.QC.CA> From: Sam Hartman Date: Wed, 06 Apr 2005 14:04:50 -0400 In-Reply-To: (Ben Harris's message of "Sun, 03 Apr 2005 14:11:32 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Ben" == Ben Harris writes: Ben> In article Ben> <200504030127.UAA27141@Sparkle.Rodents.Montreal.QC.CA> you Ben> write: >> Now, RFC3447 *does* specify that conversion. But the encoding >> of this data blob as a string is deceptively close to the >> encoding of the big number as an mpint (the major difference is >> exactly how and when leading zero bits are included). I'd like >> to see this similarly explicitly acknowledged and clarified. >> Maybe something like >> >> Note that the encoding of the encrypted secret is similar to >> the "mpint" encoding of the raw RSA encryption result, but >> differs in its handling of high-order 0 bits. The packet >> contains the octet sequence as a "string", not the raw RSA >> output as an "mpint". >> >> (Assuming of course that that's what is intended; if not, the >> wording needs even mroe work.) Ben> That is the intention, yes, and I agree that it would Ben> probably be best to make this difference explicit. Your text Ben> seems good to me. Secsh-transport has a similar problem with Ben> the output of RSASSA-PKCS1-v1_5-SIGN, which is similarly an Ben> I2OSP-encoded integer. For comparison, the text there is: I'm a strong proponent of reuse of primitives and of other specifications where appropriate. Personally, I believe your decision is correct. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 6 15:35:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20722 for ; Wed, 6 Apr 2005 15:35:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5781F5392; Wed, 6 Apr 2005 19:35:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id BC6CE521D for ; Wed, 6 Apr 2005 19:34:58 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20695; Wed, 6 Apr 2005 15:34:55 -0400 (EDT) Message-Id: <200504061934.PAA20695@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-filexfer-08.txt Date: Wed, 06 Apr 2005 15:34:55 -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 File Transfer Protocol Author(s) : J. Galbraith, et al. Filename : draft-ietf-secsh-filexfer-08.txt Pages : 63 Date : 2005-4-6 The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-08.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-filexfer-08.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-filexfer-08.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: <2005-4-6160711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-6160711.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 6 23:55:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09995 for ; Wed, 6 Apr 2005 23:55:42 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 30A5451C6; Thu, 7 Apr 2005 03:55:37 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.11]) by mail.netbsd.org (Postfix) with ESMTP id 0AE055175 for ; Thu, 7 Apr 2005 03:55:35 +0000 (UTC) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 8FDA0346CC; Thu, 7 Apr 2005 15:55:33 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16573-26; Thu, 7 Apr 2005 15:55:33 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 9A3BE33F95; Thu, 7 Apr 2005 15:55:32 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 96A2D37755; Thu, 7 Apr 2005 15:55:32 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DJO7E-00070p-00; Thu, 07 Apr 2005 15:55:36 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt In-Reply-To: <200504060354.XAA18590@Sparkle.Rodents.Montreal.QC.CA> Message-Id: Date: Thu, 07 Apr 2005 15:55:36 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse squeeked: >(1) I point out to you the language about line termination characters, >which is unimplementable nonsense on OSes that don't use line >termination characters to delimit lines; Which OSes can't handle flat text files? Yes, I know it's possible with a bit of effort to dig up some OS relic that has record-format files *alongside text files*, but the only OS I can think of right now that *only* has record-format files is CICS, and since AFAIK cryptlib is the only SSH implementation than runs on CICS and I don't care how it stores its files, this isn't an issue. Thus my comment that your objection is ridiculously pedantic - I can claim (for example) that QNX version 2 and earlier use record separators instead of CR or LF and that the spec is therefore completely unworkable for people running QNX on their PC AT, but in practice I think if anyone's still using that they'll be able to cope. The text as is (that is, saying that you need to be able to handle CR and/or LF terminators) is just fine, and as a vast number of other IETF specs that work with flat text have shown is perfectly workable and adequate. This is starting to sound like those X3J11 arguments about needing trigraphs... Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 7 04:05:45 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25096 for ; Thu, 7 Apr 2005 04:05:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C81FA51D2; Thu, 7 Apr 2005 08:05:40 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 2DC2C517C for ; Thu, 7 Apr 2005 08:05:37 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id EAA14871; Thu, 7 Apr 2005 04:05:36 -0400 (EDT) From: der Mouse Message-Id: <200504070805.EAA14871@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Thu, 7 Apr 2005 00:02:35 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> (1) I point out to you the language about line termination >> characters, which is unimplementable nonsense on OSes that don't use >> line termination characters to delimit lines; > Which OSes can't handle flat text files? What is a "flat text file"? You appear to be using it to mean something close to "file which uses line termination characters to delimit text lines", which seems..wrong. > Yes, I know it's possible with a bit of effort to dig up some OS > relic that has record-format files *alongside text files*, I don't know what you think a text file is, but back when I used VMS, and as I understand the terms, it had record-format files that *were* text files: one of the ways of storing a text file - the commonest, if my memory from then is accurate - involved records with lengths associated with them, each line being its own record. > [...] and I don't care how it stores its files, this isn't an issue. So anything you don't care about isn't an issue? That's an..interesting..point of view. But your remark actually reinforces my point of view: you *don't* care how it stores its files - so why should the the publickeyfile spec? > Thus my comment that your objection is ridiculously pedantic - I can > claim (for example) that QNX version 2 and earlier use record > separators instead of CR or LF and that the spec is therefore > completely unworkable for people running QNX on their PC AT, but in > practice I think if anyone's still using that they'll be able to > cope. Yes - but they will do so by ignoring that aspect of the spec. And that is why I think that aspect should be fixed: it unreasonably and unnecessarily constrains implementations. Writing the spec such that the only reasonable way to approximate it on some OSes is by violating part of it is a Bad Thing, it seems to me, unless of course excluding those OSes is a deliberate goal. > The text as is (that is, saying that you need to be able to handle CR > and/or LF terminators) is just fine, If that's what it's intended to say, it needs some touchup. What it actually says is Implementations are REQUIRED to read files using any of the common line termination sequence, , or . Reading this with your interpretation in mind, I can see how it can be interpreted that way. But it can also be interpreted as saying that implementations must treat any of those octet sequences as a line terminator, even if the file is such that lines are not normally delimited with line termination octets, which is a peculiar and unnecessary (and arguably wrong) thing to do for such files. The rest of the draft also contains language that assumes line termination characters are used, such as the next sentence Implementations may generate files using whichever of these line termination conventions is most convenient. which I argue needs to be rewritten to take into account the possibility that the "most convenient" format does not use line terminations at all, but instead, say, record lengths. As written, I cannot but read it as specifying that one of those line termination conventions be used, but exactly which one is chosen is up to the implementation. I do think it is possible to serve both this end and the end this is apparently intended to serve, with language such as Implementations for text file formats using line termination characters MUST recognize any of the common line termination sequences (, , or ) as a line termination. When generating such a file, implementations may use whichever sequence they find most convenient. (Note the mnemonic change - when a bare 0x0a is a line termination, it is more correctly called NL than LF.) 3.3 ("formed by removing the '\' and the line termination characters") and 3.4 ("MUST NOT be longer than 72 characters excluding line termination characters") also appear to be written in the assumption that line termination is in use. I argue that they should be modified to fix this. Specifically, I propose "...the '\' and any line termination characters" and "...excluding line termination characters, if any". Your point about other specs is an interesting one. It prompted me to go read 2822 and 2045 with this in mind, and I am surprised and discouraged to find that those specs do include such specification and that when they are supposedly applied to local storage, they have thus been (almost universally, in my experience) "implemented" by ignoring their line-termination aspects. Most such implementations are therefore not implementations of those specs at all, but rather of closely related specs, never formally codified, which use OS-native conventions for representing line boundaries. (The specs as written generally do apply on the wire, which is the proper place for specifying line boundary representation.) I believe that this should be taken not as an indication that it's OK to write another such spec which will undoubtedly draw similar not-quite-implementations - especially since this one is not used by a wire protocol, unlike 2045 and 2822 which are used by the wire protocol defined by 2821 - but rather as an indication that attempts to specify such things do not belong in a file-format spec, only in wire-protocol-format specs. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 7 11:57:32 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07953 for ; Thu, 7 Apr 2005 11:57:31 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D5346543A; Thu, 7 Apr 2005 15:57:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 5B4865186 for ; Thu, 7 Apr 2005 15:57:24 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7313499; Thu, 07 Apr 2005 09:57:22 -0600 Message-ID: <4255588F.1080208@vandyke.com> Date: Thu, 07 Apr 2005 09:58:07 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] References: <200504070805.EAA14871@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200504070805.EAA14871@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: > I don't know what you think a text file is, but back when I used VMS, > and as I understand the terms, it had record-format files that *were* > text files: one of the ways of storing a text file - the commonest, if > my memory from then is accurate - involved records with lengths > associated with them, each line being its own record. Yes. Each 'line' is preceeded by a two-byte, big endian, length field, and has no delimitting sequence. An interesting side effect is that if you accidentally transfer a binary file in text-mode, it can often be repaired. Shall I include this format in the draft and require that implementations be able to read files in such a format? I believe that the current draft specifies cr, crlf, or lf for a very good reason-- I suppose we could have require that any transport translate from the source to the destination text formats. In which case we could omit specifying how lines are delimitted and leave that as an implemenation detail. However, that wasn't the route we chose to take. >>[...] and I don't care how it stores its files, this isn't an issue. > > > So anything you don't care about isn't an issue? That's > an..interesting..point of view. > > But your remark actually reinforces my point of view: you *don't* care > how it stores its files - so why should the the publickeyfile spec? > > >>Thus my comment that your objection is ridiculously pedantic - I can >>claim (for example) that QNX version 2 and earlier use record >>separators instead of CR or LF and that the spec is therefore >>completely unworkable for people running QNX on their PC AT, but in >>practice I think if anyone's still using that they'll be able to >>cope. > > Yes - but they will do so by ignoring that aspect of the spec. No. QNX version 2 may not consider a publickey file as a text file, but that is irrelevant. SSH implementations on QNX version 2 will read the *binary* (from QNX's point of view) file containing \r, \n, \r\n. Such an implementation, if it wishes, might convert publickey files files to a a format the QNX does consider to be a text file (by removing the \r, \n, or \r\n delimiters and inserting record seperators) but this is an implementation detail. Such an implementation might also choose to support reading files stored in the QNX native format... again, an implementation detail. The whole purpose of the spec is to define a file format that can be read by multiple implementations, spanning multiple platforms. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 7 16:15:41 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03930 for ; Thu, 7 Apr 2005 16:15:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 377F55349; Thu, 7 Apr 2005 20:15:37 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8BFDD51D3 for ; Thu, 7 Apr 2005 20:15:35 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7314164 for ietf-ssh@netbsd.org; Thu, 07 Apr 2005 14:15:30 -0600 Message-ID: <4255950F.1000107@vandyke.com> Date: Thu, 07 Apr 2005 14:16:15 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-filexfer-08.txt References: <200504061934.PAA20695@ietf.org> In-Reply-To: <200504061934.PAA20695@ietf.org> 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 Comments? I'm sure the new locking stuff needs work? If nobody has comments, I'm out of a job :-) Thanks, Joseph 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 File Transfer Protocol > Author(s) : J. Galbraith, et al. > Filename : draft-ietf-secsh-filexfer-08.txt > Pages : 63 > Date : 2005-4-6 > > The SSH File Transfer Protocol provides secure file transfer > functionality over any reliable data stream. It is the standard file > transfer protocol for use with the SSH2 protocol. This document > describes the file transfer protocol and its interface to the SSH2 > protocol suite. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-08.txt From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 00:15:59 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10154 for ; Fri, 8 Apr 2005 00:15:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6D3CA522A; Fri, 8 Apr 2005 04:15:49 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by mail.netbsd.org (Postfix) with ESMTP id D7D12515B for ; Fri, 8 Apr 2005 04:15:46 +0000 (UTC) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 8872834455; Fri, 8 Apr 2005 16:15:33 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23455-01; Fri, 8 Apr 2005 16:15:33 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 7419B356DB; Fri, 8 Apr 2005 16:15:32 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4FFAE37757; Fri, 8 Apr 2005 16:15:32 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DJku8-00087V-00; Fri, 08 Apr 2005 16:15:36 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] In-Reply-To: <200504070805.EAA14871@Sparkle.Rodents.Montreal.QC.CA> Message-Id: Date: Fri, 08 Apr 2005 16:15:36 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse squeeked: >And that is why I think that aspect should be fixed: it unreasonably and >unnecessarily constrains implementations. There's a simple way to solve this debate. Is anyone on this list (which seems to include most SSH implementors) going to have their SSH implementation inconvenienced by the current text? That is, does it affect any real SSH implementation? If it directly affects your code, please let us know. (As I've already mentioned, my code runs on OSes that optionally have record- style files, and one that AFAIK only has record-style files, and I'm not inconvenienced in any way, the spec is fine for me). >It prompted me to go read 2822 and 2045 with this in mind, and I am surprised >and discouraged to find that those specs do include such specification and >that when they are supposedly applied to local storage, they have thus been >(almost universally, in my experience) "implemented" by ignoring their line- >termination aspects. Most such implementations are therefore not >implementations of those specs at all, but rather of closely related specs, >never formally codified, which use OS-native conventions for representing >line boundaries. "Gee, look at all these specs and implementations (many of which have been around for years), they're all interpreting them incorrectly except for me". Peter (who still can't believe we're actually debating something like this. It's trigraphs all over again). From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 00:51:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12169 for ; Fri, 8 Apr 2005 00:51:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1A3CD5185; Fri, 8 Apr 2005 04:51:52 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 52E8B515B for ; Fri, 8 Apr 2005 04:51:49 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA29207; Fri, 8 Apr 2005 00:51:47 -0400 (EDT) From: der Mouse Message-Id: <200504080451.AAA29207@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Fri, 8 Apr 2005 00:20:40 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > There's a simple way to solve this debate. > Is anyone on this list (which seems to include most SSH implementors) > going to have their SSH implementation inconvenienced by the current > text? That is, does it affect any real SSH implementation? If it > directly affects your code, please let us know. Probably not. It certainly won't affect the code I write; it'll just mean the resulting files won't conform unless the text file format underlying the interfaces I use actually has line terminations (which is something I can't easily determine when writing at the C level). > (As I've already mentioned, my code runs on OSes that optionally have > record-style files, and one that AFAIK only has record-style files, > and I'm not inconvenienced in any way, the spec is fine for me). No, it won't inconvenience you, unless you bother to actually implement the spec as written, instead of its apparent intent - and probably not even then unless you're on an OS where the local convention for text files isn't to use line terminators. And even *then*, it won't unless you care about the difference between a file that uses the local conventions for text files and a file that manages to use line terminators despite the local conventions being otherwise. >> It prompted me to go read 2822 and 2045 with this in mind, and I am >> surprised and discouraged to find that those specs do include such >> specification and that when they are supposedly applied to local >> storage, they have thus been (almost universally, in my experience) >> "implemented" by ignoring their line-termination aspects. > "Gee, look at all these specs and implementations (many of which have > been around for years), they're all interpreting them incorrectly > except for me". More likely, just implementing their apparent intent rather than implementing the spec as written. If the current language stands, that's basically what I'll do for publickeyfile (but I'll be careful to not claim conformance, of course). > Peter (who still can't believe we're actually debating something like > this. It's trigraphs all over again). I wouldn't be, except that I'd like to be able to conform without having to go to extreme lengths to do so (like making sure that if it's built on VMS it uses a stream-LF file rather than a varying-record file for output, something I'm not even sure how to do from C). I also want the spec to be as good as possible. It really is quite good; this one point of line terminations, small as it is, is the largest (in my opinion) flaw I found in the whole thing. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 09:40:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19565 for ; Fri, 8 Apr 2005 09:40:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D9E6C524B; Fri, 8 Apr 2005 13:39:40 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from MTLFS1.montreal.hcl.com (unknown [198.168.185.55]) by mail.netbsd.org (Postfix) with ESMTP id 7AE4D51A4 for ; Fri, 8 Apr 2005 13:39:38 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] Date: Fri, 8 Apr 2005 09:38:40 -0400 Message-ID: <88C8B14D74194F409F0E4AEC20DF228432E6B6@MTLFS1.montreal.hcl.com> Thread-Topic: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] Thread-Index: AcU78dGWRA6BLyX8QuyBcGf1pudsWwATT6jQ From: "Glen Matthews" To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hi, >Is anyone on this list (which seems to include most SSH implementors) going >to >have their SSH implementation inconvenienced by the current text? That is, >does it affect any real SSH implementation? If it directly affects your >code, >please let us know. I agree the debate is silly, but I certainly don't want to have to support so-called flat files using the equivalent of lrecl and recfm (I used to program on MVS a few, well, quite a few, years ago). I did this once for an ftp implementation and would rather never do it again. To convert data between systems is damn annoying, frankly - eg ASCII vs. EBCDIC - and why we'd wish this upon ourselves is mystifying. I supposed the point of standards was to make specs system independent.=20 As far as I am concerned, to support anything *other* than the current draft recommendations of and combinations would seriously inconvenience my implementation. And I frankly probably wouldn't bother unless a customer specifically requested this.=20 Clearly, the ambiguity in the and characters is designed to satisfy *nix and MS systems. I'd prefer just one, and don't care which. Glen Matthews Hummingbird From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 13:06:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13918 for ; Fri, 8 Apr 2005 13:06:43 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EC2ED529E; Fri, 8 Apr 2005 17:06:35 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 84F9E528D for ; Fri, 8 Apr 2005 17:06:33 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa25413; 8 Apr 2005 13:06 EDT Date: Fri, 08 Apr 2005 13:06:14 -0400 From: Jeffrey Hutzelman To: Glen Matthews , ietf-ssh@NetBSD.org Subject: RE: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] Message-ID: <16AC3D75617B929CC03C9539@sirius.fac.cs.cmu.edu> In-Reply-To: <88C8B14D74194F409F0E4AEC20DF228432E6B6@MTLFS1.montreal.hcl.com> References: <88C8B14D74194F409F0E4AEC20DF228432E6B6@MTLFS1.montreal.hcl.com> Originator-Info: login-token=Mulberry:01z/j7mDlgcAwbQ3MZAnYrB2ZqMsNWLHQ8bSn9BXg=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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, April 08, 2005 09:38:40 AM -0400 Glen Matthews wrote: > Hi, > > >> Is anyone on this list (which seems to include most SSH implementors) > going >to >> have their SSH implementation inconvenienced by the current text? That > is, >> does it affect any real SSH implementation? If it directly affects > your >code, >> please let us know. > > I agree the debate is silly, but I certainly don't want to have to > support so-called flat files using the equivalent of lrecl and recfm (I > used to program on MVS a few, well, quite a few, years ago). I did this > once for an ftp implementation and would rather never do it again. To > convert data between systems is damn annoying, frankly - eg ASCII vs. > EBCDIC - and why we'd wish this upon ourselves is mystifying. I supposed > the point of standards was to make specs system independent. > > As far as I am concerned, to support anything *other* than the current > draft recommendations of and combinations would seriously > inconvenience my implementation. And I frankly probably wouldn't bother > unless a customer specifically requested this. > > Clearly, the ambiguity in the and characters is designed to > satisfy *nix and MS systems. I'd prefer just one, and don't care which. OK; this is starting to get out of hand. We are debating a solution without a clear or consistent view of the requirements. So, let me ask a question... Are we specifying a local storage format, or a portable interchange format? If we're specifying a local storage format, then it should be defined in terms of lines, using whatever the local conventions happen to be. The document should make no mention of line terminators. If we're specifying a portable interchange format, then it is essentially a wire protocol, and we must specify the exact format of the octet stream that will actually be exchanged, via whatever protocol (http, ftp, scp, email). If it's going to be text-based, then we should REQUIRE that lines be separated by the Internet-standard line terminator, which is CRLF. We should also RECOMMEND that implemenations be able to handle CR-only and LF-only line terminators, because doing so will likely increase interoperability. We should probably also consider registering a MIME type. (application/ssh-public-key ?) Now, which is it? -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 13:17:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14782 for ; Fri, 8 Apr 2005 13:17:18 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 05C7352A5; Fri, 8 Apr 2005 17:17:14 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id CD337515B for ; Fri, 8 Apr 2005 17:17:10 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7316200; Fri, 08 Apr 2005 11:17:09 -0600 Message-ID: <4256BCC4.5080105@vandyke.com> Date: Fri, 08 Apr 2005 11:17:56 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Glen Matthews , ietf-ssh@NetBSD.org Subject: Re: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] References: <88C8B14D74194F409F0E4AEC20DF228432E6B6@MTLFS1.montreal.hcl.com> <16AC3D75617B929CC03C9539@sirius.fac.cs.cmu.edu> In-Reply-To: <16AC3D75617B929CC03C9539@sirius.fac.cs.cmu.edu> 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 > OK; this is starting to get out of hand. We are debating a solution > without a clear or consistent view of the requirements. So, let me ask > a question... > > Are we specifying a local storage format, or a portable interchange format? portable interchange format. > If we're specifying a portable interchange format, then it is > essentially a wire protocol, and we must specify the exact format of the > octet stream that will actually be exchanged, via whatever protocol > (http, ftp, scp, email). Exactly. > If it's going to be text-based, then we should > REQUIRE that lines be separated by the Internet-standard line > terminator, which is CRLF. This is what I'm leaning towards doing. > We should also RECOMMEND that implemenations > be able to handle CR-only and LF-only line terminators, because doing so > will likely increase interoperability. This seems reasonable... so basically, we are just relaxing the requirement to be able to read all three formats to requiring CRLF, but recommending the other two. > We should probably also consider > registering a MIME type. (application/ssh-public-key ?) How do we do this? Do I just add a note in the iana consideration section, or is there other stuff that needs doing? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 13:23:57 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15583 for ; Fri, 8 Apr 2005 13:23:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 966D052A6; Fri, 8 Apr 2005 17:23:53 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id DF89B515B for ; Fri, 8 Apr 2005 17:23:51 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa25427; 8 Apr 2005 13:23 EDT Date: Fri, 08 Apr 2005 13:23:33 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith Cc: Glen Matthews , ietf-ssh@NetBSD.org Subject: Re: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] Message-ID: <4C2B6BDA6D6A70A32F3BBB66@sirius.fac.cs.cmu.edu> In-Reply-To: <4256BCC4.5080105@vandyke.com> References: <88C8B14D74194F409F0E4AEC20DF228432E6B6@MTLFS1.montreal.hcl.com> <16AC3D75617B929CC03C9539@sirius.fac.cs.cmu.edu> <4256BCC4.5080105@vandyke.com> Originator-Info: login-token=Mulberry:01OYfpSqPvXr6F0mHLbAUZudD5IHXAu2Km/Bevbwc=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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, April 08, 2005 11:17:56 AM -0600 Joseph Galbraith wrote: >> We should probably also consider >> registering a MIME type. (application/ssh-public-key ?) > > How do we do this? Do I just add a note in the iana consideration > section, or is there other stuff that needs doing? See RFC2048 and the other references mentioned in From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 13:32:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16281 for ; Fri, 8 Apr 2005 13:32:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9D89351E9; Fri, 8 Apr 2005 17:32:37 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from zipp.bitvise.com (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by mail.netbsd.org (Postfix) with ESMTP id 8CB27515B for ; Fri, 8 Apr 2005 17:32:35 +0000 (UTC) Received: from ([127.0.0.1]) with MailEnable ESMTP; Fri, 08 Apr 2005 19:18:48 +0200 From: "denis bider" To: Subject: RE: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] Date: Fri, 8 Apr 2005 19:17:47 +0200 Message-ID: <000001c53c5e$e28c11f0$d7b7fea9@devel.testdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <200504070805.EAA14871@Sparkle.Rodents.Montreal.QC.CA> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable It is fine for the public key spec to explain that the ability to parse = any CR/LF line termination is desired. However, the draft does so clumsily = and without explaining the problem. The strength of this requirement needs = to be reduced to make it a recommendation, and it needs to be explained that = the requirement is there so that no human intervention is required to make public key files work after being transferred in binary form, e.g. using SFTP version 3 (the most common mechanism for transferring public keys). From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 16:42:00 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10985 for ; Fri, 8 Apr 2005 16:42:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 81D9B52B4; Fri, 8 Apr 2005 20:41:52 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 44A8F52B3 for ; Fri, 8 Apr 2005 20:41:50 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7316758 for ietf-ssh@netbsd.org; Fri, 08 Apr 2005 14:41:49 -0600 Message-ID: <4256ECBF.2020400@vandyke.com> Date: Fri, 08 Apr 2005 14:42:39 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-ssh@netbsd.org" Subject: Interop for gss-gex-sha1-* 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 I've an implementation of gss-gex-sha1-* that we are looking at shipping soon. Does anyone else implement this? I'm looking to do a interop test before we put our implementation in the wild. I recall someone out there mentioning having an implementation, but I can't find the email anymore. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 16:48:52 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11526 for ; Fri, 8 Apr 2005 16:48:52 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4A56652B5; Fri, 8 Apr 2005 20:48:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id DFE5B515B for ; Fri, 8 Apr 2005 20:48:44 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j38KmirO029396 for ; Fri, 8 Apr 2005 13:48:44 -0700 (PDT) Received: from thunk (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 j38KmhOp004938; Fri, 8 Apr 2005 16:48:43 -0400 (EDT) Received: from ::1 (localhost [IPv6:::1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j38KmhIS012156; Fri, 8 Apr 2005 16:48:43 -0400 (EDT) Subject: secure shell minutes from ietf62 From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1112993322.10649.38.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Fri, 08 Apr 2005 16:48:43 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit here's my stab at the minutes, including updates. send comments to this list. (I've already sent this in to the Secretariat; the initial submission deadline was today but it's possible to revise it once it's sent in for another couple weeks). ----- Minutes of the Secure Shell [secsh] meeting at the 62nd IETF. Thursday 10 March 2005, 1pm-1:20pm We met briefly to review the working group status and to allow a security AD to beat us up. [A lot has happened since the meeting, so I'm putting updates in square brackets so as to not confuse people] 1) AD Commentary: Russ Housley is the shepherding AD for the core drafts. They have been before the IESG for 18 months, waiting for resolutions to various issues. Through the entire period, there was always one major blocking issue; exactly which one was blocking changed several times. It currently takes 9 IESG members to approve a document; these have been waiting so long (partly due to waiting for IESG members or the IPR WG's to act) that due to IESG turnover, only 8 original votes are left. Russ gave us 6 weeks to get them on the IESG agenda; if that deadline was not met, he will send the documents back to the WG requiring full AD review, IETF-wide last call, etc., because they've been paged out for so long. However, he permitted us to proceed assuming the IPR-WG's in-room consensus on trademark references will withstand review. That removes the last non-nit issue. 2) WG Status: Document authors should note that the required draft boilerplate has just changed again. Update your tools, etc., 2.1) Core documents: At the time of the meeting the core drafts were waiting for a respin which was itself dependent on the resolution to the IPR-WG's conclusions about trademarks. The one technical change to the specification of note related to the use of UTF8 to encode usernames and password and its interaction with UTF8 normalization; the approach adopted is parallel to what other working groups (particularly SASL) have been pursuing in this area. [As of April 8th, the core drafts have been approved by the IESG and are now in the RFC Editor's queue. many thanks to all who helped this to happen.] 2.2) Extension drafts: dh-group-exchange: Before the IESG, with several open DISCUSS points. [draft author has promised to send in a revision when he gets back from vacation] newmodes: Expired [Resurrected and in WG last call with editorial comments only so far] filexfer: Still active and continued slow work [Main issue seems to be one of complexity vs.] Several other drafts have expired and are in need of reissuance. [And have been. A few stragglers still haven't reappeared yet..] Hopefully the unblocking of the core drafts will permit forward progress. 3) Milestones. Milestones badly in need of revision. Will be updated after discussion on the list. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 17:34:11 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14103 for ; Fri, 8 Apr 2005 17:34:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A964452CD; Fri, 8 Apr 2005 21:34:08 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cs.gmu.edu (cs.gmu.edu [129.174.87.2]) by mail.netbsd.org (Postfix) with ESMTP id E1E0252CA for ; Fri, 8 Apr 2005 21:34:06 +0000 (UTC) Received: from cs1.gmu.edu (cs1 [129.174.87.240]) by cs.gmu.edu (8.12.9+Sun/8.12.9) with ESMTP id j38LY6Nm007908 for ; Fri, 8 Apr 2005 17:34:06 -0400 (EDT) Received: from cs1.gmu.edu (localhost [127.0.0.1]) by cs1.gmu.edu (8.12.9+Sun/8.12.2) with ESMTP id j38LY5Oh014920 for ; Fri, 8 Apr 2005 17:34:05 -0400 (EDT) Received: (from mgyger@localhost) by cs1.gmu.edu (8.12.9+Sun/8.12.2/Submit) id j38LY5on014919 for ietf-ssh@netbsd.org; Fri, 8 Apr 2005 17:34:05 -0400 (EDT) Message-Id: <200504082134.j38LY5on014919@cs1.gmu.edu> Subject: Re: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] In-Reply-To: <16AC3D75617B929CC03C9539@sirius.fac.cs.cmu.edu> from Jeffrey Hutzelman at "Apr 8, 2005 01:06:14 pm" To: ietf-ssh@NetBSD.org Date: Fri, 8 Apr 2005 23:34:05 +0200 (CEST) From: markus@gyger.org (Markus Gyger) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 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 writes: > If it's going to be text-based, then we should REQUIRE that lines > be separated by the Internet-standard line terminator, which is CRLF. We > should also RECOMMEND that implemenations be able to handle CR-only and > LF-only line terminators, because doing so will likely increase > interoperability. Unicode has also some recommendations in the 4.0 book chapter 5 ("5.8 Newline Guidelines" pg 116): http://unicode.org/versions/Unicode4.0.0/ch05.pdf Markus From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 8 18:43:21 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19065 for ; Fri, 8 Apr 2005 18:43:20 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4D5FA51A5; Fri, 8 Apr 2005 22:43:09 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from shitei.mindrot.org (unknown [IPv6:3ffe:8001:22:0:203:47ff:fe94:4d37]) by mail.netbsd.org (Postfix) with ESMTP id 0488E515B for ; Fri, 8 Apr 2005 22:43:07 +0000 (UTC) Received: from baragon.mindrot.org (unknown [172.29.84.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id 2554127C187; Sat, 9 Apr 2005 08:43:02 +1000 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by baragon.mindrot.org (Postfix) with ESMTP id 8C04016F4C6; Sat, 9 Apr 2005 08:43:02 +1000 (EST) Message-ID: <425708F5.4070801@mindrot.org> Date: Sat, 09 Apr 2005 08:43:01 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 1.0 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] References: In-Reply-To: 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 Peter Gutmann wrote: > der Mouse squeeked: > > >>And that is why I think that aspect should be fixed: it unreasonably and >>unnecessarily constrains implementations. > > > There's a simple way to solve this debate. > > Is anyone on this list (which seems to include most SSH implementors) going to > have their SSH implementation inconvenienced by the current text? That is, > does it affect any real SSH implementation? If it directly affects your code, > please let us know. I agree that this debate is utterly silly and no, it doesn't effect OpenSSH. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Apr 9 06:05:59 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23416 for ; Sat, 9 Apr 2005 06:05:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9ED1851DF; Sat, 9 Apr 2005 10:05:52 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id 9B67C5179 for ; Sat, 9 Apr 2005 10:05:50 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 61EF03412B; Sat, 9 Apr 2005 22:05:49 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20655-26; Sat, 9 Apr 2005 22:05:49 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 495C4340D1; Sat, 9 Apr 2005 22:05:48 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 9E5DE37747; Sat, 9 Apr 2005 22:05:48 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DKCqh-0000dr-00; Sat, 09 Apr 2005 22:05:55 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Glen@montreal.hcl.com, ietf-ssh@NetBSD.org Subject: RE: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt] In-Reply-To: <88C8B14D74194F409F0E4AEC20DF228432E6B6@MTLFS1.montreal.hcl.com> Message-Id: Date: Sat, 09 Apr 2005 22:05:55 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list "Glen Matthews" writes: >I agree the debate is silly, but I certainly don't want to have to support >so-called flat files using the equivalent of lrecl and recfm (I used to >program on MVS a few, well, quite a few, years ago). Even under MVS, wouldn't "rb,byteseek" (for read) and "wb,byteseek,recfm=*" (for write) take care of it? That's what I've been using, and it works fine (at least for OpenPGP, S/MIME, and PKCS #15 files), provided you remember to convert the charset to/from EBCDIC, which is another thing the spec would have to cover if you wanted to get that pedantic about it. Actually come to think of it [pause, sfx = keyboard allegro prestissimo] yep, my code's been using SSH text-format keys under MVS since one of the early drafts for this appeared, despite the potential file-format and EBCDIC issues this hasn't caused any problems. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Apr 10 15:49:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14951 for ; Sun, 10 Apr 2005 15:49:14 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C31F2543E; Sun, 10 Apr 2005 19:49:04 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id AE9E55434 for ; Sun, 10 Apr 2005 19:48:59 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA10118; Sun, 10 Apr 2005 15:48:54 -0400 (EDT) From: der Mouse Message-Id: <200504101948.PAA10118@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sun, 10 Apr 2005 14:04:28 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Copy-edit comments on filexfer-08 In-Reply-To: <200504061934.PAA20695@ietf.org> References: <200504061934.PAA20695@ietf.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Filename : draft-ietf-secsh-filexfer-08.txt I finally got around to doing a copy-edit read over this. As compared to filexfer-07: - channel in [I-D.ietf-secsh-architecture]. and that the server has + channel in [I-D.ietf-secsh-architecture]. and that the server has This change is good, but s/\. /, / surely? At the end of 3.3, I see new text Values 210-255 are reserved for use in conjunction with these extensions. The SSH_FXP_EXTENDED packet can be used to negotiate the meaning of these reserved types. It is suggested that the actual value to be used also be negotiated, since this will prevent collision among multiple uncoordinated extensions. The server MUST respond with SSH_FXP_STATUS(SSH_FX_OP_UNSUPPORTED) if it receives a packet it does not recognize. The protocol version (Section 4) MUST be incremented if the server is to send new packets to the client (because the client has no way to respond indicating that the packet isn't recognized.) Except for the first sentence in each of these paragraphs, they appear to me to be in conflict: the first is saying "here's how to negotiate new packet types in this version" and the second is saying "the protocol version must be changed to send new packet types". At the beginning of 4.4, I see It is often necessary to detect the version of a the server so that "a the server"? Surely that needs fixing. Just after the page break there, there's a missing ): so. (It may also be sent by the client using an EXTENDED request. In 4.5, supported-open-block-masks and supported-block-masks are uint64s. Is there any reason they aren't simply 16-bit fields (probably uint32 on the wire), with each bit indicating whether a particular combination is supported? (There are four BLOCK bits, thus, 16 possible combinations.) Also, the current spec does not provide any indication of how many of the 16 four-bit fields are valid in the uint64; while the sender clearly must pad with multiple copies of some combination (as in the example given, which pads with multiple copies of 0b0000), I'd prefer to see this mentioned explicitly too - especially in the example; the current wording implies that only the low two nibbles are used in that example. (Since at least one combination must be supported for sftp to be useful at all, it's true that there's no problem finding a combination to pad with.) It also occurs to me that you might want to require that 0b0000 be accepted. There's a blank line missing between supported-block-masks's description and attrib-extension-count's. In 4.6, the example given for comma-separated-versions includes a version not in the list of permitted version numbers. I'm not sure whether I think this needs to change or not, but it looks at least a little odd. Also, shouldn't "higher than version '3'" at the beginning of the next paragraph be "at least as high as version '3'" or "no lower than '3'" or some such? In the version-select request, the version-from-list is a uint32. Since version numbers may be other than simple integers (the comma-separated-versions is defined to include the DNS extensibility mechanism), shouldn't this be a string? Otherwise, how is the client supposed to indicate whether that (say) 8 it's sending is 8@rodents.montreal.qc.ca or 8@openssh.org or 8@new-ssh.example.net - and for that matter what should the client do if the server's list includes totally non-numeric values such as "fnord@example.com"? Also, there is wording such as "higher than" that implies there is a total order on version "number"s. It isn't obvious to me that this is true in the presence of the DNS extensibility mechanism. In section 5, Servers SHOULD interpret a path name component ".." (Section 11) as an extra space seems to have got inserted between " and (. I conjecture some automated tool mistook ." for an end-of-quoted-sentence and inserted end-of-sentence space in consequence. In 6.9, comminicute only the bits it knows about without inadvertantly s/comminicute/communicate/ There's a misplaced "only" that I apparently missed before: mechanism is recommended for most purposes; additional flags bits should only be defined by an IETF standards action that also increments the protocol version number. The use of such new fields s/only be defined/be defined only/ Various places in the document speak of SSH_FXF_TEXT. This appears to be undefined as to numerical value; the placement of its description in 7.1.1.3, and the lack of a description of the SSH_FXF_ACCESS_TEXT_MODE flag which appears in the list early in 7.1.1.3, leads me to suspect that the one is a mistake for the other. In any case, something needs to be fixed. The description of SSH_FXF_TEXT (see the previous paragraph) says that When a file is opened with the FXF_TEXT flag, the offset field in the read and write functions is ignored. but it also says Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned for read or write operations that are not sequential. Which is it? Is the offset ignored, or is the server permitted to check it and return OP_UNSUPPORTED errors for non-sequential I/O? SSH_FXF_ACCESS_BLOCK_READ's description begins The server MUST guarantee that no other open has taken place which blocked handle has been opened with ACE4_READ_DATA access, and This looks like fragments of two sentences pasted together ("no other open has taken place which blocked ...??... handle has been opened with"). SSH_FXF_ACCESS_BLOCK_WRITE's description begins The server MUST guarantee that no other lock has been opened with ACE4_WRITE_DATA or ACE4_APPEND_DATA access, and that no other "no other lock has been opened"? s/lock/handle/, or something else? SSH_FXF_ACCESS_DELETE_ON_CLOSE appears to be intended for operations that, in the traditional Unix model, unlink an open file. But that operation, while it does not delete the file, *does* delete the *name* immediately. It is not clear whether DELETE_ON_CLOSE is permitted to destroy the name immediately even if it does not destroy the file, since as far as sftp clients who do not have a file open are concerned, the file's existence is indistinguishable from its name's existence. 7.2.1, describing the offset argument; 7.2.3's "offset" is similar: 'offset' is the offset (in bytes) relative to the beginning of the file that the read MUST start at. 'offset' is ignored if SSH_FXF_TEXT was specified during the open. The end-of-sentence space after "at." has shrunk. 7.2.1 again, describing "length": If the server specified a non-zero 'max-read-size' in it's s/it's/its/ 7.7, third paragraph, typo fix: The SSH_FXP_LINK request creates a link (either hare or symbolic) on the server. s/hare/hard/ In 7.7, after describing SSH_FXP_LINK, the text charges right into a description of SSH_FXP_LOCK, or SSH_FXP_BLOCK - the running text says _LOCK but the request description says _BLOCK. There also is no heading break; I'd expect to see 7.8 begin here. Also, the first sentence seems to either have a spurious article or lack a noun: The SSH_FXP_LOCK creates a ... Either s/The // or s/LOCK/& request/, it seems to me. I also note that LOCK/BLOCK is specified as not working on directories; I see no particular reason for the protocol to forbid this (though of course some servers won't support it). (Of course, it's not that useful for non-advisory locks, but now that the protocol has advisory locks, it does have its uses.) The description is also missing two blank lines between offset and length, and length and uLockMask. Also, the studlyCaps style of uLockMask is rather at odds with the style of most other packet field names, which would argue for u-lock-mask instead. SSH_FXP_UNLOCK is similar: it is confused between UNLOCK and UNBLOCK, it has either a spurious article or a missing noun, it has no heading, it is specced to fail on directories, and it's missing a blank line between offset and length. In 7.8, The server MUST take the 'original-path' and apply the 'compose-path' [page-break] as a modification to it. 'compose-path' MAY be relative to 'original- path' or may be an absolute path, in which case 'original-path' will be discarded. The 'compose-path' may be zero length. s/. '/. '/ in the second line. I also think that if you're going to use "MAY" there, you should use it for the other one, the one that's now spelled "may", too. In 7.8.1, in view of the RFCEDITOR REMOVE BEFORE PUBLISHING paragraphs, I note that the current REALPATH mechanism does have a downside which is not described: when composing more than two pieces, multiple server roundtrips are required. How much of a pain would it be to make REALPATH take a more or less arbitrary number of compose-paths? 8.1 seems to be missing a blank line between "language tag" and "". In passing, why does the description have <> around "error-specific data" when the packet description doesn't? 8.1, describing SSH_FX_OP_UNSUPPORTED, has a stray ) at the end of the description. 8.1, describing SSH_FX_UNKNOWN_PRINCIPAL, missed changing one "principle" to "principal" (the fourth-last word in the description). 8.1 says, in SSH_FX_BYTE_RANGE_LOCK_CONFLICT, that "the SFTP protocol does not support byte-range locks natively" even though SSH_FXP_{,B}LOCK (see above for the ambiguity) does indeed support byte-range locks. 9.1.2, describing hash-algorithm-list: A comma separated list of hash alogirthms the client is willing to s/alogirthms/algorithms/ Also in 9.1.2's hash-algorithm-list description, an end-of-sentence space has shrunk: and SHA-512 are decribed in [FIPS-180-2]. crc32 is described in In 9.3, the absolute-pathname is said to be "suitable for use in operations such as REALPATH or OPEN" - surely s/OPEN/&DIR/? /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 11 02:39:32 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15685 for ; Mon, 11 Apr 2005 02:39:32 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 65B12552D; Mon, 11 Apr 2005 06:39:27 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id C985A536C for ; Mon, 11 Apr 2005 06:39:25 +0000 (UTC) Received: from wall.tick-it.de (boron [127.0.0.1]) by mail.vapor.com (Postfix) with ESMTP id 3F17839025D; Mon, 11 Apr 2005 08:39:19 +0200 (CEST) Received: from [192.168.1.110] (unknown [192.168.1.110]) by wall.tick-it.de (Postfix) with ESMTP id 2328E52A10; Mon, 11 Apr 2005 08:39:19 +0200 (CEST) Message-ID: <425A1E12.4020402@siliconcircus.com> Date: Mon, 11 Apr 2005 08:49:54 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: secure shell minutes from ietf62 References: <1112993322.10649.38.camel@thunk> In-Reply-To: <1112993322.10649.38.camel@thunk> 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 Bill Sommerfeld wrote: > > filexfer: > Still active and continued slow work > [Main issue seems to be one of complexity vs.] vs. required functionality? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 11 14:47:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08014 for ; Mon, 11 Apr 2005 14:47:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9B3B456B5; Mon, 11 Apr 2005 18:47:36 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id EE28E51E1 for ; Mon, 11 Apr 2005 18:47:34 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa12937; 11 Apr 2005 14:47 EDT Date: Mon, 11 Apr 2005 14:47:14 -0400 From: Jeffrey Hutzelman To: Sam Hartman Cc: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gss-keyex and null host keys Message-ID: In-Reply-To: References: Originator-Info: login-token=Mulberry:01Adx2vGtE6zBNJ+49NFqmK5hOreeIEO9uUaQhN1w=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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 Thursday, March 31, 2005 02:51:21 PM -0500 Jeffrey Hutzelman wrote: > I'm adding the following text to the next version of the draft: Well, there's been some discussion on this issue, and I can't add any text without a consensus. Bill? -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 11 20:49:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17876 for ; Mon, 11 Apr 2005 20:49:27 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 13C7954C1; Tue, 12 Apr 2005 00:49:20 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 43A9B5272 for ; Tue, 12 Apr 2005 00:49:18 +0000 (UTC) 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 j3C0n9K2022013; Mon, 11 Apr 2005 18:49:09 -0600 (MDT) Received: from thunk (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 j3C0n9Qp022035; Mon, 11 Apr 2005 20:49:09 -0400 (EDT) Received: from ::1 (localhost [IPv6:::1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j3C0n80G026166; Mon, 11 Apr 2005 20:49:08 -0400 (EDT) Subject: Re: draft-ietf-secsh-gss-keyex and null host keys From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: Sam Hartman , ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1113266947.23542.199.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 11 Apr 2005 20:49:08 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-04-11 at 14:47, Jeffrey Hutzelman wrote: > On Thursday, March 31, 2005 02:51:21 PM -0500 Jeffrey Hutzelman > wrote: > > > I'm adding the following text to the next version of the draft: > > Well, there's been some discussion on this issue, and I can't add any text > without a consensus. Bill? i'm not sure we have consensus but don't let that stop you from resurrecting the draft. wg last call is when consensus really matters and I may be the outlyer here. we have a conflict between: 1) the true paranoids who exchange server keys or key hashes out of band. vs 2) the average guy who "just says yes". (and complicating #1 is the interaction with the SSH DNS fingerprint document, because that *is* a way of securely exchanging the fingerprints out of band, at least if dnssec is turned on...) - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 12 10:38:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04982 for ; Tue, 12 Apr 2005 10:38:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 28B845305; Tue, 12 Apr 2005 14:38:35 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (unknown [IPv6:3ffe:1ce1:0:12:20e:9bff:fe1b:4e1]) by mail.netbsd.org (Postfix) with ESMTP id 3CA59516D for ; Tue, 12 Apr 2005 14:38:33 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 49C14E0063; Tue, 12 Apr 2005 10:38:32 -0400 (EDT) To: Bill Sommerfeld Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gss-keyex and null host keys References: <1113266947.23542.199.camel@thunk> From: Sam Hartman Date: Tue, 12 Apr 2005 10:38:31 -0400 In-Reply-To: <1113266947.23542.199.camel@thunk> (Bill Sommerfeld's message of "Mon, 11 Apr 2005 20:49:08 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Bill" == Bill Sommerfeld writes: Bill> (and complicating #1 is the interaction with the SSH DNS Bill> fingerprint document, because that *is* a way of securely Bill> exchanging the fingerprints out of band, at least if dnssec Bill> is turned on...) I'd argue that gss-authenticated keys are out-of-band in the same sense that the dns document is. The signed key is exchanged by a mechanism that does not depend on that key being a trust anchor for the security of the exchange. I.E. in one case my trust anchor is some DNS related key, in another case it is a Kerberos key or some other GSS credential. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 12 23:13:38 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10392 for ; Tue, 12 Apr 2005 23:13:37 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1175C5246; Wed, 13 Apr 2005 03:13:31 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id 0A1BE5165 for ; Wed, 13 Apr 2005 03:13:29 +0000 (UTC) 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 j3D3DIjG027834; Tue, 12 Apr 2005 20:13:19 -0700 (PDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j3D3DIOp012390; Tue, 12 Apr 2005 23:13:18 -0400 (EDT) Subject: Re: draft-ietf-secsh-gss-keyex and null host keys From: Bill Sommerfeld To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org In-Reply-To: References: <1113266947.23542.199.camel@thunk> Content-Type: text/plain Message-Id: <1113361972.18060.3324.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Tue, 12 Apr 2005 23:12:53 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-04-12 at 10:38, Sam Hartman wrote: > >>>>> "Bill" == Bill Sommerfeld writes: > > Bill> (and complicating #1 is the interaction with the SSH DNS > Bill> fingerprint document, because that *is* a way of securely > Bill> exchanging the fingerprints out of band, at least if dnssec > Bill> is turned on...) > > I'd argue that gss-authenticated keys are out-of-band in the same > sense that the dns document is. The signed key is exchanged by a > mechanism that does not depend on that key being a trust anchor for > the security of the exchange. I.E. in one case my trust anchor is > some DNS related key, in another case it is a Kerberos key or some > other GSS credential if there are multiple potential sources for a given host's key, they could disagree. at the very least we need to provide a clue to implementors for what to do in the event of a disagreement between allegedly-authoritative sources of information on the host-to-host-key binding. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 13 15:41:46 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26863 for ; Wed, 13 Apr 2005 15:41:45 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 39DFB5236; Wed, 13 Apr 2005 19:41:38 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (c-24-61-15-250.hsd1.ma.comcast.net [24.61.15.250]) by mail.netbsd.org (Postfix) with ESMTP id 2B2CA5188 for ; Wed, 13 Apr 2005 19:41:36 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C7B47E0063; Wed, 13 Apr 2005 15:21:25 -0400 (EDT) To: Bill Sommerfeld Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gss-keyex and null host keys References: <1113266947.23542.199.camel@thunk> <1113361972.18060.3324.camel@unknown.hamachi.org> From: Sam Hartman Date: Wed, 13 Apr 2005 15:21:25 -0400 In-Reply-To: <1113361972.18060.3324.camel@unknown.hamachi.org> (Bill Sommerfeld's message of "Tue, 12 Apr 2005 23:12:53 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Bill" == Bill Sommerfeld writes: Bill> if there are multiple potential sources for a given host's Bill> key, they could disagree. Bill> at the very least we need to provide a clue to implementors Bill> for what to do in the event of a disagreement between Bill> allegedly-authoritative sources of information on the Bill> host-to-host-key binding. I actually think this may be the best approach. Describe the tradeoffs and give one or two reasonable example implementation strategies. For example point out that if a key was actually verified by a user from a trusted source like a printout then automatic replacement would probably decrease security. However it is desirable to allow mechanisms like GSS to facilitate rekeying of machines especially since that is very difficult in the base protocol. One suggestion might be to have a warning noting that the key had changed but had been verified by GSS. The warning could suggest that unless the user had knowledge otherwise, accepting the new key would be reasonable. The warning might be disabled for users whose key management strategy never involved particularly trusted sources. Or perhaps the warning defaults to off and can be enabled. Most of the options in this space seem like reasonable implementation decisions. I think the things I'm fairly sure you want are the ability to disable GSS-based key replacement, the ability to do it automatically and the ability to get a warning. Beyond suggesting these alternatives and explaining the tradeoffs I don't think we can do much. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 14 04:40:03 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15793 for ; Thu, 14 Apr 2005 04:40:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 32BC0527C; Thu, 14 Apr 2005 08:39:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.cablapalma.es (unknown [217.76.135.168]) by mail.netbsd.org (Postfix) with ESMTP id 3FAD7522B for ; Thu, 14 Apr 2005 08:39:52 +0000 (UTC) Received: from cablapalma.es [213.97.128.69] by mail.cablapalma.es with ESMTP (SMTPD32-6.06) id AA0773190120; Thu, 14 Apr 2005 10:29:59 +0200 From: To: Date: Thu, 14 Apr 2005 08:29:05 +0100 Subject: =?UTF-8?Q?Warning_generated_by_Panda_GateDefender.?= MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200504141030521.SM02464@cablapalma.es> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable 04/14/05 08:28:29 [GMT+0100] = Malware has been found in a message that included your e-mail address as = the sender of the message! Check if your computer is infected. virus found: W32/Netsky.P.worm File name: [d4334938_hipermac.zip][document.txt = .exe] Sender: ietf-ssh@netbsd.org Recipients: hipermac@hipermaco.es CC: = Subject: Does it matter? Source IP address: 192.168.29.39= From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 14 15:50:09 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16907 for ; Thu, 14 Apr 2005 15:50:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 52C9C5339; Thu, 14 Apr 2005 19:50:02 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 96438532A for ; Thu, 14 Apr 2005 19:50:00 +0000 (UTC) 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 j3EJnxQ1025368 for ; Thu, 14 Apr 2005 12:50:00 -0700 (PDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j3EJnxQp016688; Thu, 14 Apr 2005 15:49:59 -0400 (EDT) Subject: draft-ietf-secsh-newmodes-04: ready to go forward. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1113508171.20584.1058.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 14 Apr 2005 15:49:33 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I haven't seen an announcement come through for newmodes-04 but it looks like it was posted to the internet-drafts database on Monday. All the changes from -03 appear to be editorial and match what we've discussed on this list. Based on comments during the last-call period for -03, we have WG consensus to publish newmodes-04 as a Proposed Standard. I'll be preparing a writeup for our AD in the near future. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 14 17:42:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03409 for ; Thu, 14 Apr 2005 17:42:33 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8EFCA5371; Thu, 14 Apr 2005 21:42:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id D5E3D5344 for ; Thu, 14 Apr 2005 21:42:27 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DMC6V-0007KR-00; Thu, 14 Apr 2005 22:42:27 +0100 From: Ben Harris To: sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-newmodes-04: ready to go forward. In-Reply-To: <1113508171.20584.1058.camel@unknown.hamachi.org> References: <1113508171.20584.1058.camel@unknown.hamachi.org> Organization: Linux Unlimited Message-Id: Date: Thu, 14 Apr 2005 22:42:27 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1113508171.20584.1058.camel@unknown.hamachi.org> you write: >I haven't seen an announcement come through for newmodes-04 but it looks >like it was posted to the internet-drafts database on Monday. > >All the changes from -03 appear to be editorial and match what we've >discussed on this list. FWIW, the following comments from my list still apply. The abstract mentions [ACM CCS 2002], which doesn't appear in the references. The key size of cast128-ctr should be specified. In section 6.2, the phrase "Although there may be networks savings for padding to only 8-bytes" should read "Although there may be network savings from padding to only 8 bytes". I'd also mention that the statement of IDEA's block size seems to have been lost. None of these is serious enough to be allowed to hold up the standard. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 05:07:12 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28923 for ; Mon, 18 Apr 2005 05:07:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B7DF651EE; Mon, 18 Apr 2005 09:07:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av9-1-sn2.hy.skanova.net (av9-1-sn2.hy.skanova.net [81.228.8.179]) by mail.netbsd.org (Postfix) with ESMTP id B97C851E7 for ; Mon, 18 Apr 2005 09:07:01 +0000 (UTC) Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id A382A3869A; Mon, 18 Apr 2005 10:48:26 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8ED9338690 for ; Mon, 18 Apr 2005 10:48:26 +0200 (CEST) Received: from [192.168.0.105] (h85n2fls33o850.telia.com [217.208.157.85]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 6AF4237E42 for ; Mon, 18 Apr 2005 10:48:23 +0200 (CEST) Message-ID: <42637455.9060703@streamsec.se> Date: Mon, 18 Apr 2005 10:48:21 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Authenticated cipher modes 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 While trying to figure out how to support CCM, EAX and OCB cipher modes or the Helix cipher (http://www.schneier.com/paper-helix.pdf), I spotted an issue with SSH-TRANS. These cipher modes have built in data integrity, but the SSH-TRANS algorithm negotiation mechanism clearly isn't designed to handle such encryption. There are three reasons such encryption algorithms should be supported: 1. Performance. They are twice as fast since the encryption mode provides data integrity by itself. 2. Resources. Helix in particular consumes very little resources. There are no memory consuming s-boxes and the algorithm might be implemented to hold the entire state in CPU registers (at least on CPUs such as AMD64/EM64T and M680x0 that have a relatively high number of general purpose registers). 3. Security. According to http://cr.yp.to/papers.html#cachetiming, encryption algorithms that use sboxes are vulnerable to timing attacks, and fixed time algorithms such as Helix should be used for online transport encryption. Here is the problem: Suppose I define an encryption I name "helix@streamsec.com". I would then want the following: 1. If the server and the client negotiate this encryption, they MUST also negotiate a designated data integrity name, which is specified to be coupled with the encryption in question. There is no point in adding a second layer of data integrity to e.g. Helix encryption. This is unfortunately not consistent with the algorithm selection mechanism specified in section 7.1 of SSH-TRANS. If the standard algorithm selection mechanism is followed, the client and the server might end up with e.g. helix@streamsec.com for encryption and an unrelated data integrity algorithm. For example, this would happen if the client is sending "rijndael128-ocb@streamsec.com,helix@streamsec.com,3des-cbc" for encryption and "hmac-sha1,helix@streamsec.com" for data integrity, and the server is sending "twofish128-ocb@streamsec.com,helix@streamsec.com,3des-cbc" for encryption and "hmac-sha1,helix@streamsec.com" for data integrity. 2. The processing rules of section 6.4 "Data integrity" of SSH-TRANS MUST be integrated into the encryption processing, if e.g. Helix encryption is selected. That is, the message counter should be processed by the encryption as unencrypted header data, in accordance with the Helix specification. (One should note that CCM mode is less of an issue in this respect, since an implicit message counter is part of the mode itself. Selecting CCM mode and the "none" data integrity algorithm would result in the desired state.) -- Henrick Hellström www.streamsec.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 05:34:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00548 for ; Mon, 18 Apr 2005 05:34:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A5C9051CE; Mon, 18 Apr 2005 09:34:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.netbsd.org (Postfix) with ESMTP id 676CF5185 for ; Mon, 18 Apr 2005 09:34:09 +0000 (UTC) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2005 11:34:09 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3I9Y554024935; Mon, 18 Apr 2005 11:34:06 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA10664; Mon, 18 Apr 2005 10:34:00 +0100 (BST) Date: Mon, 18 Apr 2005 10:34:00 +0100 From: Derek Fawcus To: =?iso-8859-1?Q?Henrick_Hellstr=F6m?= Cc: ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes Message-ID: <20050418103359.A13997@mrwint.cisco.com> References: <42637455.9060703@streamsec.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: <42637455.9060703@streamsec.se>; from henrick@streamsec.se on Mon, Apr 18, 2005 at 10:48:21AM +0200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit On Mon, Apr 18, 2005 at 10:48:21AM +0200, Henrick Hellström wrote: > While trying to figure out how to support CCM, EAX and OCB cipher modes > or the Helix cipher (http://www.schneier.com/paper-helix.pdf), I spotted > an issue with SSH-TRANS. These cipher modes have built in data > integrity, but the SSH-TRANS algorithm negotiation mechanism clearly > isn't designed to handle such encryption. > Selecting CCM mode and the "none" data integrity algorithm would > result in the desired state.) I've not read Helix. However in general I'd assumed that use of a encryption including integrity algorithm could always simply be used with SSH by choosing a SSH MAC of "none". Certainly that's what I thought when I was considering hacking in use of OCB. DF From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 05:39:41 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01024 for ; Mon, 18 Apr 2005 05:39:41 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AEA2151F3; Mon, 18 Apr 2005 09:39:36 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from shitei.mindrot.org (shitei.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id B56A85165 for ; Mon, 18 Apr 2005 09:39:34 +0000 (UTC) Received: from baragon.mindrot.org (unknown [172.29.84.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id F2EF827C187; Mon, 18 Apr 2005 19:39:02 +1000 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by baragon.mindrot.org (Postfix) with ESMTP id 118F516F4D0; Mon, 18 Apr 2005 19:39:02 +1000 (EST) Message-ID: <42638035.8030803@mindrot.org> Date: Mon, 18 Apr 2005 19:39:01 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 1.0 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= , ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes References: <42637455.9060703@streamsec.se> In-Reply-To: <42637455.9060703@streamsec.se> 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 Henrick Hellström wrote: > 2. The processing rules of section 6.4 "Data integrity" of SSH-TRANS > MUST be integrated into the encryption processing, if e.g. Helix > encryption is selected. That is, the message counter should be processed > by the encryption as unencrypted header data, in accordance with the > Helix specification. (One should note that CCM mode is less of an issue > in this respect, since an implicit message counter is part of the mode > itself. Selecting CCM mode and the "none" data integrity algorithm would > result in the desired state.) The problem with this arrangement is preventing the null MAC from being inadvertantly selected with cipher modes that don't provide integrity. Perhaps these modes need a modified key-exchange to negotiate them? -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 06:42:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05775 for ; Mon, 18 Apr 2005 06:42:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DE7E5520B; Mon, 18 Apr 2005 10:42:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av8-1-sn3.vrr.skanova.net (av8-1-sn3.vrr.skanova.net [81.228.9.183]) by mail.netbsd.org (Postfix) with ESMTP id D41BC5206 for ; Mon, 18 Apr 2005 10:42:17 +0000 (UTC) Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 09CE337E8E; Mon, 18 Apr 2005 12:10:00 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D56F137E5D for ; Mon, 18 Apr 2005 12:09:59 +0200 (CEST) Received: from [192.168.0.105] (h85n2fls33o850.telia.com [217.208.157.85]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id BBE1F37E48 for ; Mon, 18 Apr 2005 12:09:59 +0200 (CEST) Message-ID: <42638775.2090600@streamsec.se> Date: Mon, 18 Apr 2005 12:09:57 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes References: <42637455.9060703@streamsec.se> <20050418103359.A13997@mrwint.cisco.com> In-Reply-To: <20050418103359.A13997@mrwint.cisco.com> 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 Derek Fawcus wrote: > I've not read Helix. However in general I'd assumed that use of a encryption > including integrity algorithm could always simply be used with SSH by choosing > a SSH MAC of "none". Certainly that's what I thought when I was considering > hacking in use of OCB. I see two problems with that. Firstly, what happens if the client lists both an OCB mode encryption algorithm and the "none" data integrity algorithm on top, and the server turns out not to support the OCB mode encryption algorithm? It seems the outcome of the algorithm negotiation would be an encryption algorithm that doesn't support data integrity, coupled with the "none" data integrity algorithm. Should the client simply disconnect if this happens, or what? It seems to me that would only result in unnecessary round-trips. Secondly, using the "none" data integrity algorithm implies that the implicit message counter is simply unprocessed (since this is what the "none" data integrity algorithm does with the message counter), which would open up for replay attacks. -- Henrick Hellström www.streamsec.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 06:42:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05802 for ; Mon, 18 Apr 2005 06:42:36 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 726B4520D; Mon, 18 Apr 2005 10:42:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpb.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.12]) by mail.netbsd.org (Postfix) with ESMTP id 751125206 for ; Mon, 18 Apr 2005 10:42:31 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 911C13487A; Mon, 18 Apr 2005 22:41:34 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16381-05; Mon, 18 Apr 2005 22:41:34 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id C38E734889; Mon, 18 Apr 2005 22:41:33 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BDC1E37744; Mon, 18 Apr 2005 22:41:33 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DNThF-0006Yw-00; Mon, 18 Apr 2005 22:41:41 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dfawcus@cisco.com, henrick@streamsec.se Subject: Re: Authenticated cipher modes Cc: ietf-ssh@NetBSD.org In-Reply-To: <20050418103359.A13997@mrwint.cisco.com> Message-Id: Date: Mon, 18 Apr 2005 22:41:41 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Derek Fawcus writes: >I've not read Helix. However in general I'd assumed that use of a encryption >including integrity algorithm could always simply be used with SSH by >choosing a SSH MAC of "none". Certainly that's what I thought when I was >considering hacking in use of OCB. That doesn't seem right, it implies there's no MAC at all, and could lead to problems with e.g. an encryption algorithm of 3DES and a MAC of none. I think it'd be more intuitive (and safer) to require that both the crypto and MAC algorithm to have the same value, since crypto = MAC and MAC = crypto. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 10:01:03 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20997 for ; Mon, 18 Apr 2005 10:01:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AF879523B; Mon, 18 Apr 2005 14:00:56 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id DD0BF5164 for ; Mon, 18 Apr 2005 14:00:53 +0000 (UTC) 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 j3IE0qjG016328; Mon, 18 Apr 2005 07:00:52 -0700 (PDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j3IE0oOp000605; Mon, 18 Apr 2005 10:00:51 -0400 (EDT) Subject: Re: Authenticated cipher modes From: Bill Sommerfeld To: Derek Fawcus Cc: Henrick Hellstr?m , ietf-ssh@NetBSD.org In-Reply-To: <20050418103359.A13997@mrwint.cisco.com> References: <42637455.9060703@streamsec.se> <20050418103359.A13997@mrwint.cisco.com> Content-Type: text/plain Message-Id: <1113832846.22040.37.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 18 Apr 2005 10:00:48 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-04-18 at 05:34, Derek Fawcus wrote: > > I've not read Helix. However in general I'd assumed that use of a encryption > including integrity algorithm could always simply be used with SSH by choosing > a SSH MAC of "none". Certainly that's what I thought when I was considering > hacking in use of OCB. [wg chair hat off; just a suggestion] how about listing the combined mode cipher in both the "cipher" and the "mac" lists? that avoids the unambiguity problem -- if you know what it is, you'll know to accept it on an all-or-none basis; if you don't know what it is, you'll reject both instances of it. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 10:06:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21515 for ; Mon, 18 Apr 2005 10:06:26 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 803E051C2; Mon, 18 Apr 2005 14:06:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id B4A2F5164 for ; Mon, 18 Apr 2005 14:06:20 +0000 (UTC) Received: from wall.tick-it.de (boron [127.0.0.1]) by mail.vapor.com (Postfix) with ESMTP id 52471390208; Mon, 18 Apr 2005 16:06:10 +0200 (CEST) Received: from [192.168.1.110] (unknown [192.168.1.110]) by wall.tick-it.de (Postfix) with ESMTP id 6826652A10; Mon, 18 Apr 2005 16:06:10 +0200 (CEST) Message-ID: <4263C152.50407@siliconcircus.com> Date: Mon, 18 Apr 2005 16:16:50 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: Derek Fawcus , Henrick Hellstr?m , ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes References: <42637455.9060703@streamsec.se> <20050418103359.A13997@mrwint.cisco.com> <1113832846.22040.37.camel@unknown.hamachi.org> In-Reply-To: <1113832846.22040.37.camel@unknown.hamachi.org> 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 Bill Sommerfeld wrote: > > how about listing the combined mode cipher in both the "cipher" and the > "mac" lists? that avoids the unambiguity problem -- if you know what it > is, you'll know to accept it on an all-or-none basis; if you don't know > what it is, you'll reject both instances of it. I was going to suggest the same thing. And if someone worked up a draft for the cipher, the draft could say if the MAC "blahblah" is chosen, the cipher "blahblah" MUST be chosen. If the cipher "blahblah" is chosen, the MAC "blahblah" SHOULD be chosen. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 10:27:54 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23822 for ; Mon, 18 Apr 2005 10:27:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2F55B517D; Mon, 18 Apr 2005 14:27:52 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by mail.netbsd.org (Postfix) with ESMTP id 336F55164 for ; Mon, 18 Apr 2005 14:27:49 +0000 (UTC) Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1DNXDp-0006D4-00; Mon, 18 Apr 2005 15:27:33 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <1113832846.22040.37.camel@unknown.hamachi.org> Subject: Re: Authenticated cipher modes Message-Id: Date: Mon, 18 Apr 2005 15:27:33 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld wrote: > how about listing the combined mode cipher in both the "cipher" and the > "mac" lists? that avoids the unambiguity problem -- if you know what it > is, you'll know to accept it on an all-or-none basis; if you don't know > what it is, you'll reject both instances of it. I think the problem is that this is inconsistent with the algorithm mandated by the transport protocol for choosing ciphers and MACs: the chosen cipher must be the first one on the client's list which is also in the server's list, and likewise with MACs. Suppose, for example, that a client's cipher list has (say) AES followed by Helix, but its MAC list has Helix followed by (say) HMAC-SHA-1, and suppose the server supports all of these things. The transport protocol then _requires_ that both sides agree to use AES as cipher and Helix as MAC, which makes no sense. You could solve this by having the (hypothetical?) Helix-for-SSH draft specify an override to the normal cipher/MAC selection process: `if the normal cipher and MAC selection selects Helix as only one of or MAC for a particular direction, then Helix must be used as both cipher and MAC for that direction, superseding whatever the normal selection algorithm chose for the other slot'. It isn't 100% clear that this gives you the right priorities, but it would at least be unambiguous. -- Simon Tatham "_shin_, n. An ingenious device for finding tables and chairs in the dark." From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 10:37:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25037 for ; Mon, 18 Apr 2005 10:37:17 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DDD0F5247; Mon, 18 Apr 2005 14:37:14 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.netbsd.org (Postfix) with ESMTP id A13C7516D for ; Mon, 18 Apr 2005 14:37:12 +0000 (UTC) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2005 16:37:12 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3IEb854020602; Mon, 18 Apr 2005 16:37:09 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA08691; Mon, 18 Apr 2005 15:37:08 +0100 (BST) Date: Mon, 18 Apr 2005 15:37:08 +0100 From: Derek Fawcus To: Peter Gutmann Cc: henrick@streamsec.se, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes Message-ID: <20050418153707.H13997@mrwint.cisco.com> References: <20050418103359.A13997@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pgut001@cs.auckland.ac.nz on Mon, Apr 18, 2005 at 10:41:41PM +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Apr 18, 2005 at 10:41:41PM +1200, Peter Gutmann wrote: > Derek Fawcus writes: > > >I've not read Helix. However in general I'd assumed that use of a encryption > >including integrity algorithm could always simply be used with SSH by > >choosing a SSH MAC of "none". Certainly that's what I thought when I was > >considering hacking in use of OCB. > > That doesn't seem right, it implies there's no MAC at all, and could lead to > problems with e.g. an encryption algorithm of 3DES and a MAC of none. I think > it'd be more intuitive (and safer) to require that both the crypto and MAC > algorithm to have the same value, since crypto = MAC and MAC = crypto. Well it depends upon what one is trying to convey. Strictly there is no outer SSH MAC in this case, so I'd argue that "none" is correct. Unfortunatly as has been pointed out the the selection rules rather mess things up here wrt to the effect on other cypher+MAC combinations if a combined algorithm ends up not being selected. I guess the simplest approach is to say that if a combined algorithm is chosen, then the MAC offered is simply ignored, and the protocol then proceeds as if both ends had offered "none" as their preferred MAC. DF From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 11:07:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27325 for ; Mon, 18 Apr 2005 11:07:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A62715254; Mon, 18 Apr 2005 15:07:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id EA8DF524C for ; Mon, 18 Apr 2005 15:07:00 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DNXpz-0005w6-00; Mon, 18 Apr 2005 16:06:59 +0100 From: Ben Harris To: henrick@streamsec.se, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes In-Reply-To: <42637455.9060703@streamsec.se> References: <42637455.9060703@streamsec.se> Organization: Linux Unlimited Message-Id: Date: Mon, 18 Apr 2005 16:06:59 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <42637455.9060703@streamsec.se> you write: >While trying to figure out how to support CCM, EAX and OCB cipher modes >or the Helix cipher (http://www.schneier.com/paper-helix.pdf), I spotted >an issue with SSH-TRANS. These cipher modes have built in data >integrity, but the SSH-TRANS algorithm negotiation mechanism clearly >isn't designed to handle such encryption. I'd noticed this too, and was planning to address it once I'd got my current SSH projects out of the way. I'm glad to see that someone else is working on it. >1. If the server and the client negotiate this encryption, they MUST >also negotiate a designated data integrity name, which is specified to >be coupled with the encryption in question. There is no point in adding >a second layer of data integrity to e.g. Helix encryption. This is >unfortunately not consistent with the algorithm selection mechanism >specified in section 7.1 of SSH-TRANS. My feeling about this is that the simplest way is to have the definition of helix@streamsec.com and friends include a rule like this: If the negotiated cipher algorithm for a direction is helix@streamsec.com, the negotiated MAC algorithm for that direction shall be ignored and the integrity protection provided by Helix be used instead. Note that this _isn't_ the same as just using Helix for the MAC, since the MAC and encryption keys in SSH are usually different. >2. The processing rules of section 6.4 "Data integrity" of SSH-TRANS >MUST be integrated into the encryption processing, if e.g. Helix >encryption is selected. That is, the message counter should be processed >by the encryption as unencrypted header data, in accordance with the >Helix specification. (One should note that CCM mode is less of an issue >in this respect, since an implicit message counter is part of the mode >itself. Selecting CCM mode and the "none" data integrity algorithm would >result in the desired state.) My understanding was that the nonce in Helix and OCB had the same purpose as the sequence number in the usual SSH MAC, so as to make the latter technically unnecessary if using those modes. It doesn't really matter, of course, since feeding an extra four bytes into the MAC is hardly going to kill performance. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 13:24:51 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08134 for ; Mon, 18 Apr 2005 13:24:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AB9C252AE; Mon, 18 Apr 2005 17:24:43 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from zipp.bitvise.com (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by mail.netbsd.org (Postfix) with ESMTP id 640845164 for ; Mon, 18 Apr 2005 17:24:41 +0000 (UTC) Received: from ([127.0.0.1]) with MailEnable ESMTP; Mon, 18 Apr 2005 19:26:03 +0200 From: "denis bider" To: "'Ben Harris'" , Subject: RE: Authenticated cipher modes Date: Mon, 18 Apr 2005 19:24:52 +0200 Message-ID: <000001c5443b$88312ad0$d7b7fea9@devel.testdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable [Ben Harris] > My understanding was that the nonce in Helix and OCB had the=20 > same purpose as the sequence number in the usual SSH MAC, so=20 > as to make the latter technically unnecessary if using those=20 > modes. It doesn't really matter, of course, since feeding an=20 > extra four bytes into the MAC is hardly going to kill performance. The problem is that a higher-level layer can rely on the SSH sequence = number - for example, it is used in SSH_MSG_UNIMPLEMENTED, so it must be there = and must be authenticated, or replaced by something 100% equivalent. = Therefore any Helix-in-SSH draft needs to spell out what happens to the SSH = sequence number: - whether it is replaced entirely by some other field, in which case the = SSH sequence number is discarded and that other field needs to have the same form and characteristics as the SSH sequence number (word32, incremented = by one, etc); - or whether the SSH sequence number stays there but is also appended or prepended to the plaintext before encryption, thereby authenticating it; - or something else that works. denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 14:12:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12892 for ; Mon, 18 Apr 2005 14:12:04 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A8A28516D; Mon, 18 Apr 2005 18:11:58 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from pigeon.alphaweb.net (69-12-155-130.dsl.static.sonic.net [69.12.155.130]) by mail.netbsd.org (Postfix) with ESMTP id D1ED1515B for ; Mon, 18 Apr 2005 18:11:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=peiscg33m) by pigeon.alphaweb.net with smtp (Exim 4.10) id 1DNZdJ-00021g-00 for ietf-ssh@NetBSD.org; Mon, 18 Apr 2005 10:02:01 -0700 Message-ID: <002d01c5443b$fd4df0f0$5c8be5a9@ohr.berkeley.edu> From: "Sara Golemon" To: References: <20050418103359.A13997@mrwint.cisco.com> <20050418153707.H13997@mrwint.cisco.com> Subject: Re: Authenticated cipher modes Date: Mon, 18 Apr 2005 10:28:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit As a more general solution to this problem, how about an ability to renegotiate methods? If the client notices that there's a common cipher available that allows for data integrity, it can send a new KEXINIT requesting just that cipher and a mac of 'none'. The server could then respond with it's own KEXINIT which agrees with that request, or perhaps another response rejecting the renegotiation (a KEXINIT with empty methods would probably suffice for an explicit rejection). If the server never sends a KEXINIT in response then it can just be assumed by the client that renegotiation is not supported. This way, not only is the specific case being discussed covered, but so are other edge cases (perhaps a session wants compression off initially--for an interactive terminal-- Then on later for a large file transfer). As to implementation specifics, I'd see a key exchange following the KEXreINIT being reasonable, but the session_id should remain the same (as with other key re-exchanges). If that's just too wasteful, maybe one of the reserved bits in the KEXINIT packet can be used to suppress key re-exchange. -Sara From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 14:43:55 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15849 for ; Mon, 18 Apr 2005 14:43:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4AA5051A4; Mon, 18 Apr 2005 18:42:28 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cs.gmu.edu (cs.gmu.edu [129.174.87.2]) by mail.netbsd.org (Postfix) with ESMTP id 75DD95272 for ; Mon, 18 Apr 2005 18:42:24 +0000 (UTC) Received: from cs1.gmu.edu (cs1 [129.174.87.240]) by cs.gmu.edu (8.12.9+Sun/8.12.9) with ESMTP id j3IIgGNm004257 for ; Mon, 18 Apr 2005 14:42:16 -0400 (EDT) Received: from cs1.gmu.edu (localhost [127.0.0.1]) by cs1.gmu.edu (8.12.9+Sun/8.12.2) with ESMTP id j3IIgGOh000661 for ; Mon, 18 Apr 2005 14:42:16 -0400 (EDT) Received: (from mgyger@localhost) by cs1.gmu.edu (8.12.9+Sun/8.12.2/Submit) id j3IIgGbR000660 for ietf-ssh@netbsd.org; Mon, 18 Apr 2005 14:42:16 -0400 (EDT) Message-Id: <200504181842.j3IIgGbR000660@cs1.gmu.edu> Subject: Re: Authenticated cipher modes In-Reply-To: <002d01c5443b$fd4df0f0$5c8be5a9@ohr.berkeley.edu> from Sara Golemon at "Apr 18, 2005 10:28:08 am" To: ietf-ssh@NetBSD.org Date: Mon, 18 Apr 2005 20:42:16 +0200 (CEST) From: markus@gyger.org (Markus Gyger) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sara Golemon writes: [re 2nd KEXINIT] > This way, not only is the specific case being discussed covered, but so are > other edge cases (perhaps a session wants compression off initially--for an > interactive terminal-- Then on later for a large file transfer). FYI, there is an OpenSSH patch that turns off encryption this way after authentication is done: http://www.psc.edu/networking/projects/hpn-ssh/ Markus From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 14:45:00 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15991 for ; Mon, 18 Apr 2005 14:44:59 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2BE0D51C6; Mon, 18 Apr 2005 18:43:45 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id BF9C351B6 for ; Mon, 18 Apr 2005 18:43:42 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DNbDh-00015B-00; Mon, 18 Apr 2005 19:43:41 +0100 From: Ben Harris To: ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes In-Reply-To: <000001c5443b$88312ad0$d7b7fea9@devel.testdomain> References: <000001c5443b$88312ad0$d7b7fea9@devel.testdomain> Organization: Linux Unlimited Message-Id: Date: Mon, 18 Apr 2005 19:43:41 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <000001c5443b$88312ad0$d7b7fea9@devel.testdomain> you write: >[Ben Harris] > >> My understanding was that the nonce in Helix and OCB had the >> same purpose as the sequence number in the usual SSH MAC, so >> as to make the latter technically unnecessary if using those >> modes. It doesn't really matter, of course, since feeding an >> extra four bytes into the MAC is hardly going to kill performance. > >The problem is that a higher-level layer can rely on the SSH sequence number >- for example, it is used in SSH_MSG_UNIMPLEMENTED, so it must be there and >must be authenticated, or replaced by something 100% equivalent. Therefore >any Helix-in-SSH draft needs to spell out what happens to the SSH sequence >number: The obvious approach is that it effectively becomes part of the nonce. To avoid too much wheel-reinvention, I'd make the nonce the same as the counter used by newmodes, so you could extract the sequence number by: seq(pkt) = nonce(pkt) - nonce(NEWKEYS) + seq(NEWKEYS) (where seq(x) is the sequence number of packet x, nonce(x) is the nonce of packet x (as an integer), and NEWKEYS is the SSH_MSG_NEWKEYS packet that started the use of this key. nonce(NEWKEYS) is the IV generated by the KEX algorithm.) Of course, you wouldn't actually do that -- you'd just keep a counter the same way you do now and increment it when you received a packet MAC'ed with the next nonce in sequence. I'm still not entirely sure that this is safe, or that all authenticated-encryption modes have this kind of nonce, but then I'm also not sure they all have the facility to MAC data without also encrypting them. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 15:10:01 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19174 for ; Mon, 18 Apr 2005 15:10:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7A34951A9; Mon, 18 Apr 2005 19:09:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 9E832515B for ; Mon, 18 Apr 2005 19:09:53 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DNbcx-00041M-00; Mon, 18 Apr 2005 20:09:47 +0100 From: Ben Harris To: ietf-secsh@libssh2.org, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes In-Reply-To: <002d01c5443b$fd4df0f0$5c8be5a9@ohr.berkeley.edu> References: <20050418103359.A13997@mrwint.cisco.com> <20050418153707.H13997@mrwint.cisco.com> <002d01c5443b$fd4df0f0$5c8be5a9@ohr.berkeley.edu> Organization: Linux Unlimited Message-Id: Date: Mon, 18 Apr 2005 20:09:47 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <002d01c5443b$fd4df0f0$5c8be5a9@ohr.berkeley.edu> you write: >As a more general solution to this problem, how about an ability to >renegotiate methods? We already have that to a large extent. Either end can send a KEXINIT at any time apart from during key exchange, and negotiate a different set of settings from last time, and this could actually be used to accomplish what you want: client enc: helix@bjh21.me.uk,3des-cbc mac: hmac-sha1 server enc: helix@bjh21.me.uk,3des-cbc mac: hmac-sha1 < both notice that this is silly > client enc: helix@bjh21.me.uk,3des-cbc mac: none,hmac-sha1 server enc: helix@bjh21.me.uk,3des-cbc mac: none,hmac-sha1 My worry here is that this kind of renogotiation opens up the possibility of the two ends getting into a loop, with one end thinking it can do better after each negotiation. >If the client notices that there's a common cipher >available that allows for data integrity, it can send a new KEXINIT >requesting just that cipher and a mac of 'none'. The server could then >respond with it's own KEXINIT which agrees with that request, or perhaps >another response rejecting the renegotiation (a KEXINIT with empty methods >would probably suffice for an explicit rejection). Is this actually necessary? In the example above, the server could reject the overture by just sending the same KEXINIT it sent the first time. >If the server never >sends a KEXINIT in response then it can just be assumed by the client that >renegotiation is not supported. All servers are already required to support it. >This way, not only is the specific case being discussed covered, but so are >other edge cases (perhaps a session wants compression off initially--for an >interactive terminal-- Then on later for a large file transfer). 2005-04-18 20:05:55 Server version: SSH-1.99-OpenSSH_3.8.1p1 Debian-8.sarge.4 2005-04-18 20:05:55 We claim version: SSH-2.0-PuTTY_Local:_Apr_18_2005_20:04:17 ... 2005-04-18 20:06:13 Initiating key re-exchange (compression setting changed) 2005-04-18 20:06:13 Doing Diffie-Hellman group exchange 2005-04-18 20:06:13 Doing Diffie-Hellman key exchange 2005-04-18 20:06:14 Initialised AES-256 SDCTR client->server encryption 2005-04-18 20:06:14 Initialised HMAC-SHA1 client->server MAC algorithm 2005-04-18 20:06:14 Initialised zlib (RFC1950) compression 2005-04-18 20:06:14 Initialised AES-256 SDCTR server->client encryption 2005-04-18 20:06:14 Initialised HMAC-SHA1 server->client MAC algorithm 2005-04-18 20:06:14 Initialised zlib (RFC1950) decompression -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 15:45:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22718 for ; Mon, 18 Apr 2005 15:45:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B22E9521A; Mon, 18 Apr 2005 19:44:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from pigeon.alphaweb.net (69-12-155-130.dsl.static.sonic.net [69.12.155.130]) by mail.netbsd.org (Postfix) with ESMTP id 629FA515B for ; Mon, 18 Apr 2005 19:44:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=peiscg33m) by pigeon.alphaweb.net with smtp (Exim 4.10) id 1DNblf-0002xu-00; Mon, 18 Apr 2005 12:18:47 -0700 Message-ID: <012801c5444f$18d1b970$5c8be5a9@ohr.berkeley.edu> From: "Sara Golemon" To: "Ben Harris" , References: <20050418103359.A13997@mrwint.cisco.com> <20050418153707.H13997@mrwint.cisco.com> <002d01c5443b$fd4df0f0$5c8be5a9@ohr.berkeley.edu> Subject: Re: Authenticated cipher modes Date: Mon, 18 Apr 2005 12:44:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > >If the client notices that there's a common cipher > >available that allows for data integrity, it can send a new KEXINIT > >requesting just that cipher and a mac of 'none'. The server could then > >respond with it's own KEXINIT which agrees with that request, or perhaps > >another response rejecting the renegotiation (a KEXINIT with empty methods > >would probably suffice for an explicit rejection). > > Is this actually necessary? In the example above, the server could reject > the overture by just sending the same KEXINIT it sent the first time. > Sending the same methods may (and most likely would) yield an agreeable set of methods and allow the renegotiation to take place. My intent with sending blank methods is to allow the endpoint to say, "No, I don't support renegotiation at all, even if it makes sense to do so." > >If the server never > >sends a KEXINIT in response then it can just be assumed by the client that > >renegotiation is not supported. > > All servers are already required to support it. > I'm sorry, where in the draft does it say that? It mentions KEY re-exchange (and recommends it be done regularly), but not methods. Of course, method renegotiation isn't explicitly prohibited either... Given that method renegotiation is appearantly part of the spec, I'd be inclined to ask: "So why not use it for this ciphers containing data integrity issue?" It seems like a much more straightforward approach than adding per-cipher specific logic to the method selection criteria. > My worry here is that this kind of renogotiation opens up the possibility of > the two ends getting into a loop, with one end thinking it can do better > after each negotiation. > Excellent point. Given that method renegotiation is already allowed, what is the accepted policy for dealing with such a situation? Left to individual vendor implementation to 'be the bigger stack' and give up eventually? Taking another tack, how about a psuedo-mac? e.g. none-ocb Which is "none MAC available only when coupled with an ocb cipher". This could be placed at the front of the methods list (avoiding any major changes to the selection criteria), but its use would be dependant on the selected cipher. This is similar to the coupling between kex method and hostkey method (If kex requires an encryption capable hostkey method, then signing only methods are ignored). -Sara -Sara From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 16:03:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28406 for ; Mon, 18 Apr 2005 16:03:18 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8A1135231; Mon, 18 Apr 2005 20:02:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 89601522A for ; Mon, 18 Apr 2005 20:02:53 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DNcSK-0000nR-00; Mon, 18 Apr 2005 21:02:52 +0100 From: Ben Harris To: ietf-secsh@libssh2.org, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes In-Reply-To: <012801c5444f$18d1b970$5c8be5a9@ohr.berkeley.edu> References: <20050418103359.A13997@mrwint.cisco.com> <002d01c5443b$fd4df0f0$5c8be5a9@ohr.berkeley.edu> <012801c5444f$18d1b970$5c8be5a9@ohr.berkeley.edu> Organization: Linux Unlimited Message-Id: Date: Mon, 18 Apr 2005 21:02:52 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <012801c5444f$18d1b970$5c8be5a9@ohr.berkeley.edu> you write: >> >If the server never >> >sends a KEXINIT in response then it can just be assumed by the client that >> >renegotiation is not supported. >> >> All servers are already required to support it. >> >I'm sorry, where in the draft does it say that? It mentions KEY re-exchange >(and recommends it be done regularly), but not methods. Of course, method >renegotiation isn't explicitly prohibited either... transport-24, section 9, second paragraph, fourth sentence: It is permissible to change some or all of the algorithms during the re-exchange. >Given that method renegotiation is appearantly part of the spec, I'd be >inclined to ask: "So why not use it for this ciphers containing data >integrity issue?" It seems like a much more straightforward approach than >adding per-cipher specific logic to the method selection criteria. 1: I'm scared of infinite loops. 2: It's expensive. Diffie-Hellman takes quite a lot of CPU, and doing it several times is going to make session set-up quite a lot slower. >Excellent point. Given that method renegotiation is already allowed, what >is the accepted policy for dealing with such a situation? I think the accepted policy is not to trigger a re-key based on the results of a previous key-exchange. That way, you can never end up in a loop. >Taking another tack, how about a psuedo-mac? e.g. none-ocb Which is "none >MAC available only when coupled with an ocb cipher". This could be placed >at the front of the methods list (avoiding any major changes to the >selection criteria), but its use would be dependant on the selected cipher. >This is similar to the coupling between kex method and hostkey method (If >kex requires an encryption capable hostkey method, then signing only methods >are ignored). I don't think there's anything intrinsically wrong with that idea, but I don't see that it has any advantage over having OCB just override the selected MAC (which is equivalent to always having "none-ocb" at the start of the MAC list). Are there circumstances where one might want to use OCB (or similar) with an external MAC? -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 18 17:26:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14381 for ; Mon, 18 Apr 2005 17:26:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 36F635244; Mon, 18 Apr 2005 21:26:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from pigeon.alphaweb.net (69-12-155-130.dsl.static.sonic.net [69.12.155.130]) by mail.netbsd.org (Postfix) with ESMTP id 57E3A515B for ; Mon, 18 Apr 2005 21:26:30 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=peiscg33m) by pigeon.alphaweb.net with smtp (Exim 4.10) id 1DNdLx-0003fS-00; Mon, 18 Apr 2005 14:00:21 -0700 Message-ID: <019e01c5445d$493e3cb0$5c8be5a9@ohr.berkeley.edu> From: "Sara Golemon" To: "Ben Harris" , References: <20050418103359.A13997@mrwint.cisco.com> <002d01c5443b$fd4df0f0$5c8be5a9@ohr.berkeley.edu> <012801c5444f$18d1b970$5c8be5a9@ohr.berkeley.edu> Subject: Re: Authenticated cipher modes Date: Mon, 18 Apr 2005 14:26:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > transport-24, section 9, second paragraph, fourth sentence: > > It is permissible to > change some or all of the algorithms during the re-exchange. > Thanks! > >Taking another tack, how about a psuedo-mac? e.g. none-ocb Which is "none > >MAC available only when coupled with an ocb cipher". This could be placed > >at the front of the methods list (avoiding any major changes to the > >selection criteria), but its use would be dependant on the selected cipher. > >This is similar to the coupling between kex method and hostkey method (If > >kex requires an encryption capable hostkey method, then signing only methods > >are ignored). > > I don't think there's anything intrinsically wrong with that idea, but I > don't see that it has any advantage over having OCB just override the > selected MAC (which is equivalent to always having "none-ocb" at the start > of the MAC list). Are there circumstances where one might want to use OCB > (or similar) with an external MAC? > I can't honestly imagine any. Both methods rely on understanding of one assumption or another. The only real difference is that one is implicit, the other is explicit. I'm just offering my thoughts to the discussion for whatever they're worth. -Sara From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 19 00:58:50 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13466 for ; Tue, 19 Apr 2005 00:58:49 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3E41F5231; Tue, 19 Apr 2005 04:58:45 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 1154F515B for ; Tue, 19 Apr 2005 04:58:38 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7335892; Mon, 18 Apr 2005 22:58:37 -0600 Message-ID: <42649050.5020006@vandyke.com> Date: Mon, 18 Apr 2005 23:00:00 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Copy-edit comments on filexfer-08 References: <200504061934.PAA20695@ietf.org> <200504101948.PAA10118@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200504101948.PAA10118@Sparkle.Rodents.Montreal.QC.CA> 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 Thanks to der Mouse for the reviews. I've gone through and fixed these. I'm going to cycle the draft again in a couple of days, so let me know if anything else needs changing. (I believe this round introduced one incompatible change. If you are shipping or getting ready to ship a v6 implementation, let me know... I think we are getting close to being done...) der Mouse wrote: > As compared to filexfer-07: > > - channel in [I-D.ietf-secsh-architecture]. and that the server has > + channel in [I-D.ietf-secsh-architecture]. and that the server has > > This change is good, but s/\. /, / surely? Fixed. > At the end of 3.3, I see new text > > Values 210-255 are reserved for use in conjunction with these > extensions. The SSH_FXP_EXTENDED packet can be used to negotiate the > meaning of these reserved types. It is suggested that the actual > value to be used also be negotiated, since this will prevent > collision among multiple uncoordinated extensions. > > The server MUST respond with SSH_FXP_STATUS(SSH_FX_OP_UNSUPPORTED) if > it receives a packet it does not recognize. The protocol version > (Section 4) MUST be incremented if the server is to send new packets > to the client (because the client has no way to respond indicating > that the packet isn't recognized.) > > Except for the first sentence in each of these paragraphs, they appear > to me to be in conflict: the first is saying "here's how to negotiate > new packet types in this version" and the second is saying "the > protocol version must be changed to send new packet types". Not quite. Notice that the restriction is applied to new packets being sent to the client, not the other way around. The client _can_ send new packets. I have, however, revised the section to hopefully be more clear: The server MUST respond with SSH_FXP_STATUS(SSH_FX_OP_UNSUPPORTED) if it receives a packet it does not recognize. The use of additional packet types in the non-extension range MUST be introduced through IETF consensus. New packet types to be sent from the client to the server MAY be introduced without changing the protocol version (Section 4). Because the client has no way to respond to unrecognized packet types, new packet types to be sent from the server to the client the client MUST not used unless the protocol version is changed or the client has negotiated to received them. This negotiation MAY be explicit, through the use of extensions, or MAY be implicit, by the client itself using a packet type not defined above. > At the beginning of 4.4, I see > > It is often necessary to detect the version of a the server so that > > "a the server"? Surely that needs fixing. Fixed. > > Just after the page break there, there's a missing ): > > so. (It may also be sent by the client using an EXTENDED request. > > In 4.5, supported-open-block-masks and supported-block-masks are > uint64s. Is there any reason they aren't simply 16-bit fields > (probably uint32 on the wire), with each bit indicating whether a > particular combination is supported? Well, I set out to do it that way originally, but it was easier to specify this way. Can you come up with some language that specs it reasonably clearly with adding a whole bunch of new identifiers? I also suspect that it will be easier to use as a series of bitmasks. > (There are four BLOCK bits, thus, > 16 possible combinations.) Also, the current spec does not provide any > indication of how many of the 16 four-bit fields are valid in the > uint64; while the sender clearly must pad with multiple copies of some > combination (as in the example given, which pads with multiple copies > of 0b0000), I'd prefer to see this mentioned explicitly too - > especially in the example; the current wording implies that only the > low two nibbles are used in that example. I origanally had wording specifying that it should be padded out with 0b0000, but it got lost somewhere. I'm still not entirely happy with this whole thing... but nothing better is coming to mind at the moment. > (Since at least one > combination must be supported for sftp to be useful at all, it's true > that there's no problem finding a combination to pad with.) It also > occurs to me that you might want to require that 0b0000 be accepted. Right; I've added that 0b0000 MUST be accepted, and that no other mask other than 0b0000 may occur more than once. > There's a blank line missing between supported-block-masks's > description and attrib-extension-count's. Thanks, fixed. > In 4.6, the example given for comma-separated-versions includes a > version not in the list of permitted version numbers. Fixed. I'm not sure > whether I think this needs to change or not, but it looks at least a > little odd. Also, shouldn't "higher than version '3'" at the beginning > of the next paragraph be "at least as high as version '3'" or "no lower > than '3'" or some such? Fixed. > In the version-select request, the version-from-list is a uint32. > Since version numbers may be other than simple integers (the > comma-separated-versions is defined to include the DNS extensibility > mechanism), shouldn't this be a string? Yikes! Thanks, indeed. It is a string (and the uint32 version is left over from a prior proposal.) > Otherwise, how is the client > supposed to indicate whether that (say) 8 it's sending is > 8@rodents.montreal.qc.ca or 8@openssh.org or 8@new-ssh.example.net - > and for that matter what should the client do if the server's list > includes totally non-numeric values such as "fnord@example.com"? > > Also, there is wording such as "higher than" that implies there is a > total order on version "number"s. It isn't obvious to me that this is > true in the presence of the DNS extensibility mechanism. Pedantically, what you say is true; however, there is order (at least in time and features set) to the versions specified so far. I've changed it to read: Typically, the client SHOULD NOT down-grade the protocol version using this extension; however, it is not forbidden to do so. One reason a client might do so is to work around a buggy implementation. Is that better? > In section 5, > > Servers SHOULD interpret a path name component ".." (Section 11) as > > an extra space seems to have got inserted between " and (. I > conjecture some automated tool mistook ." for an end-of-quoted-sentence > and inserted end-of-sentence space in consequence. Argh... I can't seem to convince it to stop. I don't care enough about this to do manual edits before publishing... if the RFC editor cares, I'll do a manual edit before we go RFC :-) > In 6.9, > > comminicute only the bits it knows about without inadvertantly > > s/comminicute/communicate/ Thanks. > There's a misplaced "only" that I apparently missed before: > > mechanism is recommended for most purposes; additional flags bits > should only be defined by an IETF standards action that also > increments the protocol version number. The use of such new fields > > s/only be defined/be defined only/ Thanks. > Various places in the document speak of SSH_FXF_TEXT. This appears to > be undefined as to numerical value; the placement of its description in > 7.1.1.3, and the lack of a description of the SSH_FXF_ACCESS_TEXT_MODE > flag which appears in the list early in 7.1.1.3, leads me to suspect > that the one is a mistake for the other. In any case, something needs > to be fixed. > > The description of SSH_FXF_TEXT (see the previous paragraph) says that > > When a file is opened with the FXF_TEXT flag, the offset field in > the read and write functions is ignored. > > but it also says > > Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned > for read or write operations that are not sequential. > > Which is it? Is the offset ignored, or is the server permitted to > check it and return OP_UNSUPPORTED errors for non-sequential I/O? Thanks... I took out the second one-- the offset is ignored. > SSH_FXF_ACCESS_BLOCK_READ's description begins > > The server MUST guarantee that no other open has taken place which > blocked handle has been opened with ACE4_READ_DATA access, and > > This looks like fragments of two sentences pasted together ("no other > open has taken place which blocked ...??... handle has been opened > with"). > > SSH_FXF_ACCESS_BLOCK_WRITE's description begins > > The server MUST guarantee that no other lock has been opened with > ACE4_WRITE_DATA or ACE4_APPEND_DATA access, and that no other > > "no other lock has been opened"? s/lock/handle/, or something else? Thanks, fixed both of them. > SSH_FXF_ACCESS_DELETE_ON_CLOSE appears to be intended for operations > that, in the traditional Unix model, unlink an open file. But that > operation, while it does not delete the file, *does* delete the *name* > immediately. It is not clear whether DELETE_ON_CLOSE is permitted to > destroy the name immediately even if it does not destroy the file, > since as far as sftp clients who do not have a file open are concerned, > the file's existence is indistinguishable from its name's existence. Hmmm... in this case, I think I'm inclined to make it undefined whether the filename is removed immediately or on close. (In windows, I believe neither the name nor the file is removed until close.) Does anyone think this is a problem? > 7.2.1, describing the offset argument; 7.2.3's "offset" is similar: > > 'offset' is the offset (in bytes) relative to the beginning of the > file that the read MUST start at. 'offset' is ignored if > SSH_FXF_TEXT was specified during the open. > > The end-of-sentence space after "at." has shrunk. Thanks. Fixed to be a little less awkward to (hopefully.) > 7.2.1 again, describing "length": > > If the server specified a non-zero 'max-read-size' in it's > > s/it's/its/ Thanks. > 7.7, third paragraph, typo fix: > > The SSH_FXP_LINK request creates a link (either hare or symbolic) on > the server. > > s/hare/hard/ Thanks. > In 7.7, after describing SSH_FXP_LINK, the text charges right into a > description of SSH_FXP_LOCK, or SSH_FXP_BLOCK - the running text says > _LOCK but the request description says _BLOCK. There also is no > heading break; I'd expect to see 7.8 begin here. Also, the first > sentence seems to either have a spurious article or lack a noun: > > The SSH_FXP_LOCK creates a ... > > Either s/The // or s/LOCK/& request/, it seems to me. Fixed. > I also note that LOCK/BLOCK is specified as not working on directories; > I see no particular reason for the protocol to forbid this (though of > course some servers won't support it). (Of course, it's not that > useful for non-advisory locks, but now that the protocol has advisory > locks, it does have its uses.) Fixed. > The description is also missing two blank lines between offset and > length, and length and uLockMask. Also, the studlyCaps style of > uLockMask is rather at odds with the style of most other packet field > names, which would argue for u-lock-mask instead. Fixed. > SSH_FXP_UNLOCK is similar: it is confused between UNLOCK and UNBLOCK, > it has either a spurious article or a missing noun, it has no heading, > it is specced to fail on directories, and it's missing a blank line > between offset and length. Fixed. > > In 7.8, > > The server MUST take the 'original-path' and apply the 'compose-path' > [page-break] > as a modification to it. 'compose-path' MAY be relative to 'original- > path' or may be an absolute path, in which case 'original-path' will > be discarded. The 'compose-path' may be zero length. > > s/. '/. '/ in the second line. Argh... xml2rfc is doing this... I'm going to ignore it for now... maybe eventually, it will get smarter? > I also think that if you're going to use "MAY" there, you should use it > for the other one, the one that's now spelled "may", too. Done. > > In 7.8.1, in view of the RFCEDITOR REMOVE BEFORE PUBLISHING paragraphs, > I note that the current REALPATH mechanism does have a downside which > is not described: when composing more than two pieces, multiple server > roundtrips are required. How much of a pain would it be to make > REALPATH take a more or less arbitrary number of compose-paths? Done. I switched the order of the control byte and compose path and let compose path have multiple elements. Read until EOP. > 8.1 seems to be missing a blank line between "language tag" and > "". In passing, why does the description have <> > around "error-specific data" when the packet description doesn't? Fixed; and removed <>. > 8.1, describing SSH_FX_OP_UNSUPPORTED, has a stray ) at the end of the > description. Thanks. > 8.1, describing SSH_FX_UNKNOWN_PRINCIPAL, missed changing one > "principle" to "principal" (the fourth-last word in the description). Thanks. > 8.1 says, in SSH_FX_BYTE_RANGE_LOCK_CONFLICT, that "the SFTP protocol > does not support byte-range locks natively" even though > SSH_FXP_{,B}LOCK (see above for the ambiguity) does indeed support > byte-range locks. It's gone now. > 9.1.2, describing hash-algorithm-list: > > A comma separated list of hash alogirthms the client is willing to > > s/alogirthms/algorithms/ Fixed. > Also in 9.1.2's hash-algorithm-list description, an end-of-sentence > space has shrunk: > > and SHA-512 are decribed in [FIPS-180-2]. crc32 is described in xml2rfc has a grudge. I reordered the sentance to make it do the right thing (TM) > In 9.3, the absolute-pathname is said to be "suitable for use in > operations such as REALPATH or OPEN" - surely s/OPEN/&DIR/? Fixed. Thanks again for you reviews. Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 19 01:59:58 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17393 for ; Tue, 19 Apr 2005 01:59:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7E4F9518C; Tue, 19 Apr 2005 05:59:52 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 04F7B517E for ; Tue, 19 Apr 2005 05:59:47 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA03385; Tue, 19 Apr 2005 01:59:43 -0400 (EDT) From: der Mouse Message-Id: <200504190559.BAA03385@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 19 Apr 2005 01:12:54 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Copy-edit comments on filexfer-08 In-Reply-To: <42649050.5020006@vandyke.com> References: <200504061934.PAA20695@ietf.org> <200504101948.PAA10118@Sparkle.Rodents.Montreal.QC.CA> <42649050.5020006@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > (I believe this round introduced one incompatible change. [...]) It might help to call out what it is. I assume you're talking about the REALPATH change, but it could also be the version-select switch from uint32 to string. (Your reply makes it clear *you've* been thinking of the latter as a string, but that's not what it said.) > The use of additional packet types in the non-extension range MUST be > introduced through IETF consensus. [...] Thank you, that helps greatly. The "in the non-extension range" semantics were missing from the previous language - or at least, unclear enough that I read them as missing - and it makes all the difference. (The rest of the wording changes are less critical, though I find the new text significantly better nevertheless.) >> In 4.5, supported-open-block-masks and supported-block-masks are >> uint64s. Is there any reason they aren't simply 16-bit fields >> (probably uint32 on the wire), with each bit indicating whether a >> particular combination is supported? > Well, I set out to do it that way originally, but it was easier to > specify this way. Can you come up with some language that specs it > reasonably clearly with adding a whole bunch of new identifiers? Probably. Let's see, how about this (using supported-open-block-masks for the sake of argument): uint32 supported-open-block-masks (actually, I'd prefer uint16, but I don't think we have one - maybe put both block-masks in a single uint32?) supported-open-block-masks A 16-bit mask specifying which combinations of blocking flags are supported. Each bit corresponds to one combination of the SSH_FXF_ACCESS_BLOCK_READ, SSH_FXF_ACCESS_BLOCK_WRITE, SSH_FXF_ACCESS_BLOCK_DELETE, and SSH_FXF_ACCESS_BLOCK_ADVISORY bits from Section 7.1.1.3, with a set bit corresponding to a supported combination and a clear bit an unsupported combination. The index of a bit, bit zero being the least significant bit, viewed as a four-bit number, corresponds to a combination of flag bits, shifted right so that BLOCK_READ is the least significant bit. The combination `no blocking flags' MUST be supported, so the low bit will always be set. For example, a server supporting only the classic advisory read (shared) and write (exclusive) locks would set the bits corresponding to READ+WRITE+ADVISORY, 0b1011, and WRITE+ADVISORY, 0b1010, plus the always-set bit 0b0000, giving a mask value of 0b0000110000000001, or 0x0c01; a server supporting no locking at all would set only bit zero, giving 0x0001. Bits other than the low 16 are reserved for possible future use and MUST NOT be set. The last sentence does not apply if both masks are packed into a single uint32, of course. > I also suspect that it will be easier to use as a series of bitmasks. Well, as a code author, if I had to deal with the masks as specified, I'd use the 16-bit mask form internally, converting to the spec's form very late on output and very early on input. I suspect this says more about what kind of internal data structures I prefer (and to some extent what language I'd likely be using) than about anything else.... > I origanally had wording specifying that it should be padded out with > 0b0000, but it got lost somewhere. Well, if the current spec is kept, I think it needs to be found. :) > I've changed it to read: > Typically, the client SHOULD NOT down-grade the protocol version > using this extension; however, it is not forbidden to do so. One > reason a client might do so is to work around a buggy implementation. > Is that better? Somewhat. There is still the implication that of two versions, one will be a downgrade compared to the other, which, even if it's true now, surely will not remain true forever. However, I think the implication is loose enough that that language is OK. I'm still not clear whether totally non-numeric version strings are acceptable or not. I see nothing that would forbid, say, "illuminati@fnord.mil" from appearing in the list, nor any simple way to decide whether it would be a downgrade as compared to "infibulated-gonkulator@example.net". But if you're going to allow DNS extensibility at all, that is, ultimately, unavoidable - it's entirely possible that of two "private" versions, neither is a feature subset of the other, regardless of how they're named. >> It is not clear whether DELETE_ON_CLOSE is permitted to destroy the >> name immediately even if it does not destroy the file, [...] > Hmmm... in this case, I think I'm inclined to make it undefined > whether the filename is removed immediately or on close. I think that's probably the route I'd go. > Thanks again for you reviews. No problem! /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 19 02:34:47 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10610 for ; Tue, 19 Apr 2005 02:34:47 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D8F29521F; Tue, 19 Apr 2005 06:34:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 0BC8B5187 for ; Tue, 19 Apr 2005 06:34:33 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 82D381B8183; Tue, 19 Apr 2005 08:34:10 +0200 (CEST) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 31874-01-42; Tue, 19 Apr 2005 08:34:05 +0200 (CEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id AE7BF1B817C; Tue, 19 Apr 2005 08:34:05 +0200 (CEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j3J6Y5GQ015864; Tue, 19 Apr 2005 08:34:05 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j3J6Xvv7015861; Tue, 19 Apr 2005 08:33:57 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Simon Tatham Cc: ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes 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: 19 Apr 2005 08:33:55 +0200 In-Reply-To: Message-ID: Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Simon Tatham writes: > Bill Sommerfeld wrote: > > how about listing the combined mode cipher in both the "cipher" and the > > "mac" lists? that avoids the unambiguity problem -- if you know what it > > is, you'll know to accept it on an all-or-none basis; if you don't know > > what it is, you'll reject both instances of it. > > I think the problem is that this is inconsistent with the algorithm > mandated by the transport protocol for choosing ciphers and MACs: > `if the normal cipher and MAC selection selects Helix as only one of > or MAC for a particular direction, then Helix must be used as both > cipher and MAC for that direction, superseding whatever the normal > selection algorithm chose for the other slot' I think one could define the procedure as follows: If helix is selected as the cipher to use by the ordinary selection mechanism, *and helix is present* on both parties' lists of authentication methods, then helix must be used for authentication, bypassing the usual selection rules for the authentication method. In effect, it says that implementations supporting helix should do the cipher selection before the authentication selection. This doesn't conflict too badly with current procedures. However, it still shouldn't be done lightly, because it *will* conflict when somebody proposes the analogous change with a reverse dependency If foo is selected as the authentication method, and foo is present on the cipher list of both parties, then foo must be used also for encryption. An alternative of a slightly different flavour, but which still introduces a dependency between cipher selection and authentication selection, is the following rule: If all occurances of helix on the authentication lists must be ignored unless helix is also used for the cipher for the corresponding data stream. Both these alternatives make it possible to use helix + a different mac. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 19 04:20:12 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16728 for ; Tue, 19 Apr 2005 04:20:12 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 98F5B51F6; Tue, 19 Apr 2005 08:20:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from zipp.bitvise.com (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by mail.netbsd.org (Postfix) with ESMTP id 5F875515B for ; Tue, 19 Apr 2005 08:20:05 +0000 (UTC) Received: from ([127.0.0.1]) with MailEnable ESMTP; Tue, 19 Apr 2005 10:21:29 +0200 From: "denis bider" To: "'Sara Golemon'" , Subject: RE: Authenticated cipher modes Date: Tue, 19 Apr 2005 10:20:17 +0200 Message-ID: <000601c544b8$9e96a070$d7b7fea9@devel.testdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <012801c5444f$18d1b970$5c8be5a9@ohr.berkeley.edu> Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable [Sara Golemon] > Given that method renegotiation is appearantly part of the=20 > spec, I'd be inclined to ask: "So why not use it for this=20 > ciphers containing data integrity issue?" It seems like a=20 > much more straightforward approach than adding per-cipher=20 > specific logic to the method selection criteria. The per-cipher specific logic in this case would be very simple = (requiring only very local code change), efficient in terms of additional = roundtrips (none required), and compatible with the installed base (special rules = for helix are orthogonal to rules currently in use), whereas the proposal to = use renegotiation for this purpose is complex (key re-exchange is like = turning a bus on a highway), inefficient (requires many additional roundtrips for something that could be done without any), and not necessarily = compatible with the installed base (though key re-exchange is required, not all implementations support it). I therefore think that harnessing key re-exchange for this purpose would = be a very bad decision. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 19 08:46:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05782 for ; Tue, 19 Apr 2005 08:46:33 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9EE0752FC; Tue, 19 Apr 2005 12:46:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 3536D52FA for ; Tue, 19 Apr 2005 12:46:06 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7336376; Tue, 19 Apr 2005 06:46:04 -0600 Message-ID: <4264FDE1.8020909@vandyke.com> Date: Tue, 19 Apr 2005 06:47:29 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Copy-edit comments on filexfer-08 References: <200504061934.PAA20695@ietf.org> <200504101948.PAA10118@Sparkle.Rodents.Montreal.QC.CA> <42649050.5020006@vandyke.com> <200504190559.BAA03385@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200504190559.BAA03385@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: >>(I believe this round introduced one incompatible change. [...]) > > It might help to call out what it is. I assume you're talking about > the REALPATH change, but it could also be the version-select switch > from uint32 to string. (Your reply makes it clear *you've* been > thinking of the latter as a string, but that's not what it said.) Sorry... you're right, it was the REALPATH change. >>>uint64s. Is there any reason they aren't simply 16-bit fields >>>(probably uint32 on the wire), with each bit indicating whether a >>>particular combination is supported? >> >>Well, I set out to do it that way originally, but it was easier to >>specify this way. Can you come up with some language that specs it >>reasonably clearly with adding a whole bunch of new identifiers? > > > Probably. Let's see, how about this (using supported-open-block-masks > for the sake of argument): > > uint32 supported-open-block-masks > > (actually, I'd prefer uint16, but I don't think we have one - maybe put > both block-masks in a single uint32?) How about we simply define one? > supported-open-block-masks > A 16-bit mask specifying which combinations of blocking flags are > supported. Each bit corresponds to one combination of the > SSH_FXF_ACCESS_BLOCK_READ, SSH_FXF_ACCESS_BLOCK_WRITE, > SSH_FXF_ACCESS_BLOCK_DELETE, and SSH_FXF_ACCESS_BLOCK_ADVISORY > bits from Section 7.1.1.3, with a set bit corresponding to a > supported combination and a clear bit an unsupported combination. > The index of a bit, bit zero being the least significant bit, > viewed as a four-bit number, corresponds to a combination of flag > bits, shifted right so that BLOCK_READ is the least significant > bit. The combination `no blocking flags' MUST be supported, so > the low bit will always be set. > > For example, a server supporting only the classic advisory read > (shared) and write (exclusive) locks would set the bits > corresponding to READ+WRITE+ADVISORY, 0b1011, and WRITE+ADVISORY, > 0b1010, plus the always-set bit 0b0000, giving a mask value of > 0b0000110000000001, or 0x0c01; a server supporting no locking at > all would set only bit zero, giving 0x0001. > > Bits other than the low 16 are reserved for possible future use > and MUST NOT be set. > > The last sentence does not apply if both masks are packed into a single > uint32, of course. Great, I'll use this then (barring the last sentance.) I think I'll introduce uint16 in the data-types section... then if you (the collective you) want to considered it a packed uint32, you can, but it'll be speced seperately, which is the nicer way to do it. >>I've changed it to read: > >> Typically, the client SHOULD NOT down-grade the protocol version >> using this extension; however, it is not forbidden to do so. One >> reason a client might do so is to work around a buggy implementation. > >>Is that better? > > Somewhat. There is still the implication that of two versions, one > will be a downgrade compared to the other, which, even if it's true > now, surely will not remain true forever. However, I think the > implication is loose enough that that language is OK. > > I'm still not clear whether totally non-numeric version strings are > acceptable or not. I see nothing that would forbid, say, > "illuminati@fnord.mil" from appearing in the list, nor any simple way > to decide whether it would be a downgrade as compared to > "infibulated-gonkulator@example.net". But if you're going to allow DNS > extensibility at all, that is, ultimately, unavoidable - it's entirely > possible that of two "private" versions, neither is a feature subset of > the other, regardless of how they're named. I'll explicitly allow non-numeric values (that was the intent.) Nico suggested that we could even allow a-la carte implementation of v6, such as attrib-v6, which would imply whatever version was previously in use, but using v6 attributes. (I'd probably actually allow "3,attrib-v6" as the response, indicating v3 w/ v6 attributes, and specifically disallow two 'numeric' items in the response.) I haven't gone that route... because I'm not convinced it would convince any more people to migrate to v6 (or even to get the benifits of just v6 attributes.) And it would complicate implementations even more and I've got people complaining as is. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 19 15:39:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13019 for ; Tue, 19 Apr 2005 15:39:26 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B581851D4; Tue, 19 Apr 2005 19:39:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id CD3CA5165 for ; Tue, 19 Apr 2005 19:39:17 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13002; Tue, 19 Apr 2005 15:39:13 -0400 (EDT) Message-Id: <200504191939.PAA13002@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-x509-01.txt Date: Tue, 19 Apr 2005 15:39:13 -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 : X.509 authentication in SSH2 Author(s) : O. Saarenmaa, J. Galbraith Filename : draft-ietf-secsh-x509-01.txt Pages : 8 Date : 2005-4-19 The X.509 extension specifies how X.509 keys and signatures are used within the SSH2 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-x509-01.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-x509-01.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-x509-01.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: <2005-4-19154340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-x509-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-x509-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-19154340.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 20 17:05:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20810 for ; Wed, 20 Apr 2005 17:05:02 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 287E252A8; Wed, 20 Apr 2005 21:04:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.siemenscom.com (mail.siemenscom.com [12.146.131.10]) by mail.netbsd.org (Postfix) with ESMTP id 0E3625173 for ; Wed, 20 Apr 2005 21:04:52 +0000 (UTC) Received: from fdns2.rolm.com (localhost [127.0.0.1]) by mail.siemenscom.com (8.12.10/8.12.10) with ESMTP id j3KKAI0O013147 for ; Wed, 20 Apr 2005 13:10:18 -0700 Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id j3KKWhCB017568 for ; Wed, 20 Apr 2005 13:32:43 -0700 (PDT) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72) id <29MZ2B11>; Wed, 20 Apr 2005 13:32:43 -0700 Message-ID: <5F98E47AD7B1C349895ED4E2EDF3918BD35C53@stca209a> From: "Rosenberg, Rochelle" To: "'ietf-ssh@netbsd.org'" Subject: ssh authentication methods Date: Wed, 20 Apr 2005 13:29:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I am not sure this is the appropriate place for me to ask a question on SSH. If it isn't could you please suggest an alternative. Can an ssh server process more than one type of authentication method once it has been started? By that I mean can an ssh server process both public-key authentication and say interactive-keyboard authentication. The is how I would have the sshd_config file for this scenario. Port 22 Protocol 2,1 ListenAddress 0.0.0.0 ServerKeyBits 768 PermitRootLogin yes RsaAuthentication yes DsaAuthentication yes PasswordAuthentication no PermitEmptyPasswords no KbdInteractiveAuthentication yes subsystem sftp sftp thank you. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 20 17:27:59 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22993 for ; Wed, 20 Apr 2005 17:27:59 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7E73752B7; Wed, 20 Apr 2005 21:27:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by mail.netbsd.org (Postfix) with ESMTP id 498CA5176 for ; Wed, 20 Apr 2005 21:27:53 +0000 (UTC) Received: from libra.cus.cam.ac.uk ([131.111.8.19]:53900) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp id 1DOMjc-0005aI-Q3 (Exim 4.44) for ietf-ssh@netbsd.org (return-path ); Wed, 20 Apr 2005 22:27:48 +0100 Received: from bjh21 (helo=localhost) by libra.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1DOMjb-0002cP-Ne for ietf-ssh@netbsd.org; Wed, 20 Apr 2005 22:27:47 +0100 Date: Wed, 20 Apr 2005 22:27:47 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: arcfour-fixes now in PuTTY Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: ietf-ssh-owner@NetBSD.org Precedence: list If anyone wants an implementation of my arcfour-fixes draft to test against, the development sources of PuTTY now contain one, and it'll be in the development snapshots as of tonight's (2005-04-21). Our download page is at . If anyone has any comments on the draft, now would be a good time to send them since I intend the next version to be the one that goes to the IESG. It'll probably rename the ciphers to "arcfour128" and "arcfour256" unless someone can come up with a good reason why it shouldn't. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 20 18:00:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26525 for ; Wed, 20 Apr 2005 18:00:36 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id ADB26517F; Wed, 20 Apr 2005 22:00:32 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id E165C5173 for ; Wed, 20 Apr 2005 22:00:30 +0000 (UTC) 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 j3KM0TQ1003127; Wed, 20 Apr 2005 15:00:30 -0700 (PDT) Received: from thunk (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 j3KM0TQp015187; Wed, 20 Apr 2005 18:00:29 -0400 (EDT) Received: from ::1 (localhost [IPv6:::1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j3KM0T3l007956; Wed, 20 Apr 2005 18:00:29 -0400 (EDT) Subject: Re: ssh authentication methods From: Bill Sommerfeld To: "Rosenberg, Rochelle" Cc: "'ietf-ssh@netbsd.org'" In-Reply-To: <5F98E47AD7B1C349895ED4E2EDF3918BD35C53@stca209a> References: <5F98E47AD7B1C349895ED4E2EDF3918BD35C53@stca209a> Content-Type: text/plain Message-Id: <1114034428.6162.293.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 20 Apr 2005 18:00:29 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-04-20 at 16:29, Rosenberg, Rochelle wrote: > Hi, > I am not sure this is the appropriate place for me to ask a question on SSH. > If it isn't could you please suggest an alternative. > > Can an ssh server process more than one type of authentication method once > it has been started? By that I mean can an ssh server process both > public-key authentication and say interactive-keyboard authentication. > The is how I would have the sshd_config file for this scenario. This is the mailing list for the IETF secure shell working group, which discusses the protocol in general rather than any specific implementation... For user authentication, the protocol allows the client to try several methods, one after the other, until one works. Exactly how you configure your clients and servers to try multiple methods is better asked on a list which is specific to the ssh software you're using; implementors present here should feel free to suggest a better group... - Bill (secure shell wg chair). From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 20 18:39:54 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01542 for ; Wed, 20 Apr 2005 18:39:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B5F7452D1; Wed, 20 Apr 2005 22:39:45 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from shitei.mindrot.org (shitei.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 5D25C5173 for ; Wed, 20 Apr 2005 22:39:42 +0000 (UTC) Received: from baragon.mindrot.org (unknown [172.29.84.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id ACFF827C187; Thu, 21 Apr 2005 08:39:10 +1000 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by baragon.mindrot.org (Postfix) with ESMTP id 35EC216F48A; Thu, 21 Apr 2005 08:39:09 +1000 (EST) Message-ID: <4266DA0C.7000708@mindrot.org> Date: Thu, 21 Apr 2005 08:39:08 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 1.0 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: arcfour-fixes now in PuTTY References: In-Reply-To: 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 Ben Harris wrote: > If anyone wants an implementation of my arcfour-fixes draft to test > against, the development sources of PuTTY now contain one, and it'll be > in the development snapshots as of tonight's (2005-04-21). > > Our download page is at > . There is also a patch for OpenSSH at http://bugzilla.mindrot.org/show_bug.cgi?id=1022 This will probably make its way in before our next major release. > If anyone has any comments on the draft, now would be a good time to > send them since I intend the next version to be the one that goes to the > IESG. It'll probably rename the ciphers to "arcfour128" and "arcfour256" > unless someone can come up with a good reason why it shouldn't. I think that this is a good idea. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 03:44:34 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02324 for ; Thu, 21 Apr 2005 03:44:33 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 387235187; Thu, 21 Apr 2005 07:44:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av12-2-sn2.hy.skanova.net (av12-2-sn2.hy.skanova.net [81.228.8.186]) by mail.netbsd.org (Postfix) with ESMTP id 50BCD516F for ; Thu, 21 Apr 2005 07:44:21 +0000 (UTC) Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 3BDC038B13; Thu, 21 Apr 2005 09:14:15 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 22D3837FB2; Thu, 21 Apr 2005 09:14:15 +0200 (CEST) Received: from [192.168.0.105] (h54n1fls31o850.telia.com [217.208.152.54]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 6B18037E43; Thu, 21 Apr 2005 09:14:14 +0200 (CEST) Message-ID: <426752C5.7000106@streamsec.se> Date: Thu, 21 Apr 2005 09:14:13 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: Ben Harris Cc: ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes References: <000001c5443b$88312ad0$d7b7fea9@devel.testdomain> 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 Ben Harris wrote: > The obvious approach is that it effectively becomes part of the nonce. To > avoid too much wheel-reinvention, I'd make the nonce the same as the counter > used by newmodes, so you could extract the sequence number by: > > seq(pkt) = nonce(pkt) - nonce(NEWKEYS) + seq(NEWKEYS) > > (where seq(x) is the sequence number of packet x, nonce(x) is the nonce of > packet x (as an integer), and NEWKEYS is the SSH_MSG_NEWKEYS packet that > started the use of this key. nonce(NEWKEYS) is the IV generated by the KEX > algorithm.) > I'm still not entirely sure that this is safe, or that all > authenticated-encryption modes have this kind of nonce, but then I'm also > not sure they all have the facility to MAC data without also encrypting them. I'd say that is not a good idea. The best way is to use random per packet nonces sent explicitly by the sender, and process the sequence number as implicit unencrypted header data. This operation is supported by Helix, CCM and EAX. (OCB doesn't support processing of unencrypted header data, but is designed for nonces that are sequence numbers). I am not sure exactly how you would implement your solution, but there are two things to keep in mind: * There are differential attacks against Helix that exploit repeated nonces. Given the nature of differential attacks and how the nonce is processed by Helix, I guess the only safe way to prevent them would be to use independently random nonces. Simply incrementing the nonce by one for each packet would result in nonces with a pair-wise low hamming difference. That gives me chills rather than a warm fuzzy feeling. * One trivial method of making the nonces independent and still mix in the sequence number would unfortunately not provide protection against replay attacks. This would happen if you e.g. used the formula: nonce(pkt) = nonce(NEWKEYS) + seq(pkt) - seq(NEWKEYS) + sentnonce(pkt) (where nonce(pkt) is the effective nonce fed into the algorithm by the implementation, and sentnonce is a random value generated by the sender and prefixed to the packet that is sent to the other peer.) The problem with this is that an active attacker can resend packets simply by modifying sentnonce(X) in accordance with the formula to make the packet pass as having any other sequence number. -- Henrick Hellström www.streamsec.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 10:57:44 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07073 for ; Thu, 21 Apr 2005 10:57:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B54B5523C; Thu, 21 Apr 2005 14:57:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from beacon.PSC.process.com (unknown [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id 7D27051AF for ; Thu, 21 Apr 2005 14:57:30 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: I-D ACTION:draft-ietf-secsh-filexfer-08.txt Date: Thu, 21 Apr 2005 10:58:37 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB905A382@beacon.PSC.process.com> Thread-Topic: I-D ACTION:draft-ietf-secsh-filexfer-08.txt Thread-Index: AcU63+Onz6gxMoR5Tr6401neoVXQqgLon4SQ From: "Richard Whalen" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Sorry for the delay in getting comments in, but I've been out due to my = wife having a baby. section 4.6 version re-negotiation "If the client and server have negotiated any version higher than = version '3'..." should be: "If the client and server have negotiated any version greater than or = equal to version '3'..." (or something with similar meaning) section 3.3 mentions the possibility of using SSH_FXP_EXTENDED to = negotiate the uses for packet types 210-255, and refers to the section = on the extensions. But the section on extensions (9.) does not mention = a formal way of negotiating usage. How about something like: byte SSH_FXP_EXTENDED uint32 request-id string "negotiate-extension" string extension-name the returned packet would be something of: byte SSH_FXP_EXTENDED_REPLY uint32 request-id uint32 status (SSH_FX_OK, SSH_FX_OP_UNSUPPORTED, SSH_FX_FAILURE) uint32 value to use if SSH_FX_OK, optional secondary status if failure A status value of SSH_FX_OP_UNSUPPORTED would indicate that the = "negotiate-extension" extended command is not supported. No secondary = status is present in this case. A status value of SSH_FX_FAILURE would indicate that = "negotiate-extension" is supported, but that a opcode number could not = be assigned. A secondary status of SSH_FX_OP_UNSUPPORTED would indicate = that the requested extension is not supported, or negotiation to assign = it a number is not supported. (Note that support of the extension can = be determined by the "supported-features" extension in the = SSH_FXP_VERSION packet.) 9.1.2 Could "check-file" be modified to be "check-file" or = "check-file-handle" (The first accepting a filename, the second a = handle), this would allow the implementation to avoid having to do an = FXP_OPEN first. Whether or not the suggested change is made, the description for the = handle has some awkwardness to it: "If ACE4_READ_DATA MUST was not included when the file was opened, the = server MUST return STATUS_PERMISSION_DENIED." The first MUST looks like = it is extraneous. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 11:41:23 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10162 for ; Thu, 21 Apr 2005 11:41:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 012565257; Thu, 21 Apr 2005 15:41:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by mail.netbsd.org (Postfix) with ESMTP id 5881B5248 for ; Thu, 21 Apr 2005 15:41:17 +0000 (UTC) Received: from draco.cus.cam.ac.uk ([131.111.8.18]:34162) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1DOdPX-00069G-P1 (Exim 4.51) for ietf-ssh@netbsd.org (return-path ); Thu, 21 Apr 2005 16:16:11 +0100 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1DOdPX-0006zn-L0 for ietf-ssh@netbsd.org; Thu, 21 Apr 2005 16:16:11 +0100 Date: Thu, 21 Apr 2005 16:16:11 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Implementations of 3des-ctr and blowfish-ctr? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: ietf-ssh-owner@NetBSD.org Precedence: list I've implemented 3des-ctr and blowfish-ctr in PuTTY, but I've had to leave them disabled because I haven't found another implementation to test against. Does anyone in the WG know of one? -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 11:52:52 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11190 for ; Thu, 21 Apr 2005 11:52:51 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BF2395254; Thu, 21 Apr 2005 15:52:49 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by mail.netbsd.org (Postfix) with ESMTP id 3572B51AD for ; Thu, 21 Apr 2005 15:52:45 +0000 (UTC) Received: from draco.cus.cam.ac.uk ([131.111.8.18]:34543) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp id 1DOdh7-0002iK-A0 (Exim 4.44) for ietf-ssh@netbsd.org (return-path ); Thu, 21 Apr 2005 16:34:21 +0100 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1DOdh5-0007EC-U6; Thu, 21 Apr 2005 16:34:19 +0100 Date: Thu, 21 Apr 2005 16:34:19 +0100 (BST) From: Ben Harris To: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Cc: ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes In-Reply-To: <426752C5.7000106@streamsec.se> Message-ID: References: <000001c5443b$88312ad0$d7b7fea9@devel.testdomain> <426752C5.7000106@streamsec.se> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1251336619-1114096479=:9770" Content-ID: X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1251336619-1114096479=:9770 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-ID: Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 21 Apr 2005, Henrick Hellstr=F6m wrote: [ Using counters as nonces in authenticated ciphers ] > I'd say that is not a good idea. The best way is to use random per packet= =20 > nonces sent explicitly by the sender, and process the sequence number as= =20 > implicit unencrypted header data. This operation is supported by Helix, C= CM=20 > and EAX. (OCB doesn't support processing of unencrypted header data, but = is=20 > designed for nonces that are sequence numbers). As far as I can see, CCM and EAX aren't interesting, since they're no=20 cheaper than using a separate block cipher and MAC. That suggests that we= =20 should be concentrating on OCB and Helix at present, which appear to have= =20 rather different requirements from one another. > I am not sure exactly how you would implement your solution, but there ar= e=20 > two things to keep in mind: > > * There are differential attacks against Helix that exploit repeated nonc= es.=20 > Given the nature of differential attacks and how the nonce is processed b= y=20 > Helix, I guess the only safe way to prevent them would be to use=20 > independently random nonces. Simply incrementing the nonce by one for eac= h=20 > packet would result in nonces with a pair-wise low hamming difference. Th= at=20 > gives me chills rather than a warm fuzzy feeling. Having read Muller's FSE2004 paper, I agree -- feeding related nonces to=20 Helix looks like being a bad idea, though this is obviously not a problem= =20 for OCB. Thus, I think we have two situations: For OCB, the nonce can be a counter (initialised by the IV from KEX), and= =20 the SSH sequence number need not be directly handled by OCB at all. For Helix, the nonce needs to be effectively random. I see two obvious=20 ways of achieving this: 1: Generate a random nonce for each message and send it with the nonce. This adds extra data to each packet, but is probably relatively cheap. It requires that the SSH sequence number be processed as header data by Helix. 2: Feed a counter through a one-way function (either a block cipher or a hash) to generate the nonce. This is more expensive (at least if you use a hash), but saves on network traffic and means that the sequence number is implicit in the nonce so that it need not be processed by Helix (though it may as well be, since doing so is cheap). --=20 Ben Harris ---559023410-1251336619-1114096479=:9770-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 12:26:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14137 for ; Thu, 21 Apr 2005 12:26:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5DBE55253; Thu, 21 Apr 2005 16:25:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av7-2-sn3.vrr.skanova.net (av7-2-sn3.vrr.skanova.net [81.228.9.182]) by mail.netbsd.org (Postfix) with ESMTP id 6B4A45164 for ; Thu, 21 Apr 2005 16:25:52 +0000 (UTC) Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5F03637F5F; Thu, 21 Apr 2005 17:53:13 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 4F60C37E8E; Thu, 21 Apr 2005 17:53:13 +0200 (CEST) Received: from [192.168.0.105] (h54n1fls31o850.telia.com [217.208.152.54]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A9DB137E43; Thu, 21 Apr 2005 17:53:12 +0200 (CEST) Message-ID: <4267CC68.5030909@streamsec.se> Date: Thu, 21 Apr 2005 17:53:12 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: Ben Harris Cc: ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes References: <000001c5443b$88312ad0$d7b7fea9@devel.testdomain> <426752C5.7000106@streamsec.se> 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 Ben Harris wrote: > 2: Feed a counter through a one-way function (either a block cipher or a > hash) to generate the nonce. This is more expensive (at least if you > use a hash), but saves on network traffic and means that the sequence > number is implicit in the nonce so that it need not be processed by > Helix (though it may as well be, since doing so is cheap). The obvious solution would be to use a separately keyed instance of Helix as a continuous PRNG. The PRNG seed (i.e. the second Helix key and nonce) could be the initial IV from the NEWKEYS. -- Henrick Hellström www.streamsec.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 12:36:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14934 for ; Thu, 21 Apr 2005 12:36:05 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8C1AF527B; Thu, 21 Apr 2005 16:36:02 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id D8B385164 for ; Thu, 21 Apr 2005 16:36:00 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DOeel-0006gA-00; Thu, 21 Apr 2005 17:35:59 +0100 From: Ben Harris To: henrick@streamsec.se, ietf-ssh@NetBSD.org Subject: Re: Authenticated cipher modes In-Reply-To: <4267CC68.5030909@streamsec.se> References: <4267CC68.5030909@streamsec.se> Organization: Linux Unlimited Message-Id: Date: Thu, 21 Apr 2005 17:35:59 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <4267CC68.5030909@streamsec.se> you write: >Ben Harris wrote: > >> 2: Feed a counter through a one-way function (either a block cipher or a >> hash) to generate the nonce. This is more expensive (at least if you >> use a hash), but saves on network traffic and means that the sequence >> number is implicit in the nonce so that it need not be processed by >> Helix (though it may as well be, since doing so is cheap). > >The obvious solution would be to use a separately keyed instance of >Helix as a continuous PRNG. The PRNG seed (i.e. the second Helix key and >nonce) could be the initial IV from the NEWKEYS. Ah yes, of course. Why didn't I think of that? -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 12:37:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15062 for ; Thu, 21 Apr 2005 12:37:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 960F2524E; Thu, 21 Apr 2005 16:37:23 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id AB0365164 for ; Thu, 21 Apr 2005 16:37:21 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA06236; Thu, 21 Apr 2005 12:37:10 -0400 (EDT) From: der Mouse Message-Id: <200504211637.MAA06236@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Thu, 21 Apr 2005 12:33:04 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Implementations of 3des-ctr and blowfish-ctr? In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I've implemented 3des-ctr and blowfish-ctr in PuTTY, but I've had to > leave them disabled because I haven't found another implementation to > test against. Does anyone in the WG know of one? I don't have the code at the moment, but now that I know someone wants it, I can add it to mine, probably within a day or two (the -ctr modes are simple enough that the major problem will be locating round tuits). /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 12:52:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16686 for ; Thu, 21 Apr 2005 12:52:52 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5754A528E; Thu, 21 Apr 2005 16:52:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id CC9D15164 for ; Thu, 21 Apr 2005 16:52:48 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7355830; Thu, 21 Apr 2005 10:52:47 -0600 Message-ID: <4267DABB.9070007@vandyke.com> Date: Thu, 21 Apr 2005 10:54:19 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Whalen Cc: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-filexfer-08.txt References: <3EF96AF20489A34296050FBD5C36ECB905A382@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB905A382@beacon.PSC.process.com> 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 Richard Whalen wrote: > Sorry for the delay in getting comments in, but I've been out due to my wife having a baby. Congratulations! > section 4.6 version re-negotiation > "If the client and server have negotiated any version higher than version '3'..." > should be: > "If the client and server have negotiated any version greater than or equal to version > '3'..." (or something with similar meaning) Got this one. > section 3.3 mentions the possibility of using SSH_FXP_EXTENDED > to negotiate the uses for packet types 210-255, and refers to > the section on the extensions. But the section on extensions (9.) > does not mention a formal way of negotiating usage. How about > something like: > > byte SSH_FXP_EXTENDED > uint32 request-id > string "negotiate-extension" > string extension-name > > the returned packet would be something of: > byte SSH_FXP_EXTENDED_REPLY > uint32 request-id > uint32 status (SSH_FX_OK, SSH_FX_OP_UNSUPPORTED, SSH_FX_FAILURE) > uint32 value to use if SSH_FX_OK, optional secondary status if failure > > A status value of SSH_FX_OP_UNSUPPORTED would indicate that the > "negotiate-extension" extended command is not supported. No > secondary status is present in this case. > > A status value of SSH_FX_FAILURE would indicate that > "negotiate-extension" is supported, but that a opcode > number could not be assigned. A secondary status of > SSH_FX_OP_UNSUPPORTED would indicate that the requested > extension is not supported, or negotiation to assign it > a number is not supported. (Note that support of the > extension can be determined by the "supported-features" > extension in the SSH_FXP_VERSION packet.) Hmmm... I didn't specify this because I don't think we know enough about how somone might possible use this. I'm imagining that the client would send an extension to the server to request that it start using a feature that requires addition packet type(s) (and perhaps to communicate additional information to the server.) The response from the server would either be SSH_FXP_STATUS indicating an error, or a SSH_FXP_EXTENDED_REPLY in the success case. One of the things the EXTENDED_REPLY packet would include is the packet type values the server is going to use for the feature (it might contain other things.) I like this better because it avoids the needed for the nested error conditions, allows additional flexibility (what if additional information needs to be sent to the server or return by the server? What if the feature needs more than one packet type?) I guess I should probably include this in the draft in some form. > 9.1.2 Could "check-file" be modified to be "check-file" > or "check-file-handle" (The first accepting a filename, > the second a handle), this would allow the implementation > to avoid having to do an FXP_OPEN first. Done. Do people think this is superior to the MD5 stuff? This was kind of a off-the-cuff proposal for a way to match more rsync features w/ sftp. If people prefer this one to MD5, I'll pull the md5 one. > Whether or not the suggested change is made, the > description for the handle has some awkwardness to it: > "If ACE4_READ_DATA MUST was not included when the file > was opened, the server MUST return STATUS_PERMISSION_DENIED." > The first MUST looks like it is extraneous. Fixed. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 13:20:55 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19019 for ; Thu, 21 Apr 2005 13:20:55 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9B80352AF; Thu, 21 Apr 2005 17:20:51 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 3D6A65283 for ; Thu, 21 Apr 2005 17:20:49 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA06616; Thu, 21 Apr 2005 13:20:48 -0400 (EDT) From: der Mouse Message-Id: <200504211720.NAA06616@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Thu, 21 Apr 2005 13:09:33 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-filexfer-08.txt In-Reply-To: <4267DABB.9070007@vandyke.com> References: <3EF96AF20489A34296050FBD5C36ECB905A382@beacon.PSC.process.com> <4267DABB.9070007@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> section 3.3 mentions the possibility of using SSH_FXP_EXTENDED to >> negotiate the uses for packet types 210-255, and refers to the >> section on the extensions. But the section on extensions (9.) does >> not mention a formal way of negotiating usage. How about [...] > Hmmm... I didn't specify this because I don't think we know enough > about how somone might possible use this. I think this is the right tack to take. Until we have some experience with such extensions, I think it's premature to standardize how to do them. >> 9.1.2 [...] > Done. Do people think this is superior to the MD5 stuff? I do, because it subsumes the md5-hash stuff: specify an algorithm-list containing only md5 and it amounts to much the same thing. The only difference I see is the quick-check stuff, and that can be done too at the cost of another round trip. However, there is one unclear spot. It's not clear whether there is any spec for which algorithms the server supports - the text says that "[c]urrently supported algorithms are [..list..]", but it's not clear whether that means all servers MUST support all of them, or those are the algorithms supported by all known implementations, or those are the algorithms supported by any known implementations, or those are the algorithms that may be used without DNS extension syntax but there is no intent to imply that anyone does/should/must support any of them, or perhaps even something else. I can't recall whether anyone caught this before, but in case not: in 9, describing "extended-request", I see "..extensions have use the..", which needs to have "have" struck. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 13:58:00 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22272 for ; Thu, 21 Apr 2005 13:57:59 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D771952C8; Thu, 21 Apr 2005 17:57:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 5C423524F for ; Thu, 21 Apr 2005 17:57:54 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7356023 for ietf-ssh@netbsd.org; Thu, 21 Apr 2005 11:57:53 -0600 Message-ID: <4267E9FC.6070906@vandyke.com> Date: Thu, 21 Apr 2005 11:59:24 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-x509-01.txt References: <200504191939.PAA13002@ietf.org> In-Reply-To: <200504191939.PAA13002@ietf.org> 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 We're searching for more feedback here. The discussion got kind of deep and hairy, and we may not have gotten it all. Did we address the things we came to consensus on? Can anyone help us out with text / suggestions for things that still need to be addressed? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 14:42:17 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25575 for ; Thu, 21 Apr 2005 14:42:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8738E52E4; Thu, 21 Apr 2005 18:41:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 2C9E852EC for ; Thu, 21 Apr 2005 18:41:27 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7356099; Thu, 21 Apr 2005 12:41:26 -0600 Message-ID: <4267F431.3090100@vandyke.com> Date: Thu, 21 Apr 2005 12:42:57 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-filexfer-08.txt References: <3EF96AF20489A34296050FBD5C36ECB905A382@beacon.PSC.process.com> <4267DABB.9070007@vandyke.com> <200504211720.NAA06616@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200504211720.NAA06616@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: >>>section 3.3 mentions the possibility of using SSH_FXP_EXTENDED to >>>negotiate the uses for packet types 210-255, and refers to the >>>section on the extensions. But the section on extensions (9.) does >>>not mention a formal way of negotiating usage. How about [...] >> >>Hmmm... I didn't specify this because I don't think we know enough >>about how somone might possible use this. > > > I think this is the right tack to take. Until we have some experience > with such extensions, I think it's premature to standardize how to do > them. > > >>>9.1.2 [...] >> >>Done. Do people think this is superior to the MD5 stuff? > > > I do, because it subsumes the md5-hash stuff: specify an algorithm-list > containing only md5 and it amounts to much the same thing. The only > difference I see is the quick-check stuff, and that can be done too at > the cost of another round trip. > > However, there is one unclear spot. It's not clear whether there is > any spec for which algorithms the server supports - the text says that > "[c]urrently supported algorithms are [..list..]", but it's not clear Does it clear it up if I change it to ...currently defined algorithsm...? > I can't recall whether anyone caught this before, but in case not: in > 9, describing "extended-request", I see "..extensions have use the..", > which needs to have "have" struck. Thanks, I reworded the section to use the boiler-plate text for this with the xref to the architecture draft. I'll probably publish in the next couple of days, so keep the feedback coming. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 21 16:34:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12871 for ; Thu, 21 Apr 2005 16:34:02 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 237855214; Thu, 21 Apr 2005 20:33:56 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 33A56516C for ; Thu, 21 Apr 2005 20:33:53 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA07911; Thu, 21 Apr 2005 16:33:52 -0400 (EDT) From: der Mouse Message-Id: <200504212033.QAA07911@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Thu, 21 Apr 2005 16:31:16 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-filexfer-08.txt In-Reply-To: <4267F431.3090100@vandyke.com> References: <3EF96AF20489A34296050FBD5C36ECB905A382@beacon.PSC.process.com> <4267DABB.9070007@vandyke.com> <200504211720.NAA06616@Sparkle.Rodents.Montreal.QC.CA> <4267F431.3090100@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>>> 9.1.2 [...] >>> Done. Do people think this is superior to the MD5 stuff? >> I do, [...]. However, there is one unclear spot. It's not clear >> whether there is any spec for which algorithms the server supports - >> the text says that "[c]urrently supported algorithms are >> [..list..]", but it's not clear [...] > Does it clear it up if I change it to ...currently defined > algorithsm...? Yes. If any algorithms are MUSTs, they should be listed; if not, I'd prefer to see that explicitly stated, since (almost?) everywhere else, there's at least one MUST-implement algorithm. (In case it's not clear, I have no problem with having no MUST-implement choices here; I just would like to see it stated unambiguously.) /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 26 02:49:49 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06707 for ; Tue, 26 Apr 2005 02:49:49 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 369C951A6; Tue, 26 Apr 2005 06:49:41 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from hotmail.com (bay102-f39.bay102.hotmail.com [64.4.61.49]) by mail.netbsd.org (Postfix) with ESMTP id AD10751A1 for ; Tue, 26 Apr 2005 06:49:39 +0000 (UTC) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Apr 2005 23:47:40 -0700 Message-ID: Received: from 64.4.61.203 by by102fd.bay102.hotmail.msn.com with HTTP; Tue, 26 Apr 2005 06:47:40 GMT X-Originating-IP: [64.4.61.203] X-Originating-Email: [nunotheartist@hotmail.com] X-Sender: nunotheartist@hotmail.com From: "Nuno Rocha" To: ietf-ssh@NetBSD.org Date: Mon, 25 Apr 2005 23:47:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Apr 2005 06:47:40.0401 (UTC) FILETIME=[D72CBE10:01C54A2B] Sender: ietf-ssh-owner@NetBSD.org Precedence: list nunotheartist personal attention ~ professional design 480.231.2975 www.nunotheartist.com nuno@nunotheartist.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 27 02:52:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07293 for ; Wed, 27 Apr 2005 02:52:14 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9C7645182; Wed, 27 Apr 2005 06:52:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 4F0945178 for ; Wed, 27 Apr 2005 06:52:04 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA13936; Wed, 27 Apr 2005 02:52:03 -0400 (EDT) From: der Mouse Message-Id: <200504270652.CAA13936@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 27 Apr 2005 02:45:15 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Ben Harris: 3des-ctr & blowfish-ctr In-Reply-To: <200504270600.CAA13786@Sparkle.Rodents.Montreal.QC.CA> References: <200504270600.CAA13786@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I tried to send mail off-list to Ben Harris, but it timed out in the queue - perhaps they don't like me: > ----- Transcript of session follows ----- > Ben Harris ... Deferred: Connection timed out with mx-relay.chiark.greenend.org.uk. > Message could not be delivered for 5 days > Message will be deleted from queue Perhaps it's just as well, because a response to me likely wouldn't have gotten through - most of Ben's list posts come from .org.uk, which would be blocked, even though the one I replied to came from .ac.uk, which wouldn't. Anyway, others may be interested too. :-) What I wanted to say was.... > I've implemented 3des-ctr and blowfish-ctr in PuTTY, but I've had to > leave them disabled because I haven't found another implementation to > test against. Does anyone in the WG know of one? I just added them to mine - it proved to be even easier than I had expected, a matter of five or ten minutes at most. Care to do some testing? I've got a server running on truly-delicious.rodents.montreal.qc.ca port 22222 that you're welcome to test against. It's running with -neverauth, so you won't be able to authenticate there even if you had a copy of my private key, but that's not necessary for crypto interop tests. (It is set to offer only 3des-ctr and blowfish-ctr for encryption, with all other encryption algorithms disabled.) /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 27 08:39:07 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05571 for ; Wed, 27 Apr 2005 08:39:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7D6775224; Wed, 27 Apr 2005 12:38:59 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 5FC27517F for ; Wed, 27 Apr 2005 12:38:57 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DQloe-0003C3-00 for ietf-ssh@netbsd.org; Wed, 27 Apr 2005 13:38:56 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: Ben Harris: 3des-ctr & blowfish-ctr In-Reply-To: <200504270652.CAA13936@Sparkle.Rodents.Montreal.QC.CA> References: <200504270600.CAA13786@Sparkle.Rodents.Montreal.QC.CA> <200504270600.CAA13786@Sparkle.Rodents.Montreal.QC.CA> <200504270652.CAA13936@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Message-Id: Date: Wed, 27 Apr 2005 13:38:56 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200504270652.CAA13936@Sparkle.Rodents.Montreal.QC.CA> you write: >I tried to send mail off-list to Ben Harris, but it timed out in the >queue - perhaps they don't like me: SAUCE on chiark.greenend.org.uk tries to check your MAIL FROM address, gets a 550 on connecting to your mail server and for some reason only returns this to you as a temporary failure. I'll ask my sysadmin why this doesn't qualify as a permanent failure, but unless you're willing to accept mail from chiark we're stuck communicating through the list. >What I wanted to say was.... > >> I've implemented 3des-ctr and blowfish-ctr in PuTTY, but I've had to >> leave them disabled because I haven't found another implementation to >> test against. Does anyone in the WG know of one? > >I just added them to mine - it proved to be even easier than I had >expected, a matter of five or ten minutes at most. > >Care to do some testing? I've got a server running on >truly-delicious.rodents.montreal.qc.ca port 22222 that you're welcome >to test against. Ooh, crunchy... Well, I've discovered a mutual bug before even getting to NEWKEYS: both PuTTY and Moussh were waiting for the other end to send a KEXINIT before they'd send their own, which led to stalemate. I've fixed this in PuTTY and you should probably do the same for Moussh. Having fixed that, I get your server closing the TCP connection on me after I send the first encrypted packet, which suggests that we're disagreeing on how the encryption should work. I've fixed an obvious bug in our 3des-ctr support (using the keys in the wrong order), bit that didn't help. I've put copies of the packet logs at and . Times there are UTC+1; the connections were from 2002:5212:2743:1:2a0:40ff:fe2a:cb4c. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 27 08:52:09 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07022 for ; Wed, 27 Apr 2005 08:52:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 35D31523C; Wed, 27 Apr 2005 12:52:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from zipp.bitvise.com (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by mail.netbsd.org (Postfix) with ESMTP id DA5EA517F for ; Wed, 27 Apr 2005 12:52:02 +0000 (UTC) Received: from ([127.0.0.1]) with MailEnable ESMTP; Wed, 27 Apr 2005 14:53:33 +0200 From: "denis bider" To: Subject: sftp - transactions? Date: Wed, 27 Apr 2005 14:52:15 +0200 Message-ID: <000001c54b27$f0343c10$d7b7fea9@devel.testdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit It appears that the filesystem in the next version of Windows will support transactions. See this sample code from an MS developer: http://blogs.msdn.com/because_we_can/archive/2005/4/25.aspx This will be useful in file transfer. People will want to have begin transaction, rollback and commit packets in SFTP. I'm not saying we need to put it in the spec now - without an OS that supports this right now, that could be premature, although I can imagine other possible servers implementing this. However, if and when this technology becomes available in Windows, there will be a need to support it in SFTP, and we will want to have interoperable implementations. It does seem that it will be a fairly simple thing of defining a few new packet types with little additional content. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 27 09:27:58 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10568 for ; Wed, 27 Apr 2005 09:27:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A6AFA5244; Wed, 27 Apr 2005 13:27:53 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpb.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.12]) by mail.netbsd.org (Postfix) with ESMTP id C3E1A517F for ; Wed, 27 Apr 2005 13:27:51 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 8A31634851; Thu, 28 Apr 2005 01:27:50 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04662-13; Thu, 28 Apr 2005 01:27:50 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 70B453449E; Thu, 28 Apr 2005 01:27:50 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 191843774D; Thu, 28 Apr 2005 01:27:50 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DQma6-0003EN-00; Thu, 28 Apr 2005 01:27:58 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org Subject: Re: sftp - transactions? In-Reply-To: <000001c54b27$f0343c10$d7b7fea9@devel.testdomain> Message-Id: Date: Thu, 28 Apr 2005 01:27:58 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list "denis bider" writes: >It appears that the filesystem in the next version of Windows will support >transactions. Hasn't Windows had transactions in WinFS since it was introduced in Chicago? (It wasn't called that then, I can't remember the codename at the time but it's the database-filesystem that's been just around the corner for about the last decade). Since the last I heard we won't get these WinFS features until the Blackcomb OS release at the end of the decade, it looks like things will continue in this manner for some time. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 27 10:49:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21643 for ; Wed, 27 Apr 2005 10:49:31 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5BFDE527B; Wed, 27 Apr 2005 14:49:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from zipp.bitvise.com (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by mail.netbsd.org (Postfix) with ESMTP id 400385226 for ; Wed, 27 Apr 2005 14:49:20 +0000 (UTC) Received: from ([127.0.0.1]) with MailEnable ESMTP; Wed, 27 Apr 2005 16:35:54 +0200 From: "denis bider" To: "'Peter Gutmann'" , Subject: RE: sftp - transactions? Date: Wed, 27 Apr 2005 16:34:35 +0200 Message-ID: <000301c54b36$3c413230$d7b7fea9@devel.testdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable You are right about WinFS: the current prediction at MS seems to be that this will be available as an upgrade about 1 year after Longhorn is out. But if you check more info at the link I posted, MS is working on NTFS transaction support for Longhorn, and the technology will apparently = also be included in the Longhorn beta. This is independent of WinFS. > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Peter Gutmann > Sent: Wednesday, April 27, 2005 15:28 > To: ietf-ssh@denisbider.com; ietf-ssh@netbsd.org > Subject: Re: sftp - transactions? >=20 >=20 > "denis bider" writes: >=20 > >It appears that the filesystem in the next version of Windows will=20 > >support transactions. >=20 > Hasn't Windows had transactions in WinFS since it was=20 > introduced in Chicago? (It wasn't called that then, I can't=20 > remember the codename at the time but it's the=20 > database-filesystem that's been just around the corner for=20 > about the last decade). Since the last I heard we won't get=20 > these WinFS features until the Blackcomb OS release at the=20 > end of the decade, it looks like things will continue in this=20 > manner for some time. >=20 > Peter. >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 27 18:25:59 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15112 for ; Wed, 27 Apr 2005 18:25:59 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 88C72533E; Wed, 27 Apr 2005 22:25:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 78ED6517F for ; Wed, 27 Apr 2005 22:25:52 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA18871; Wed, 27 Apr 2005 18:25:51 -0400 (EDT) From: der Mouse Message-Id: <200504272225.SAA18871@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 27 Apr 2005 18:22:37 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Ben Harris: 3des-ctr & blowfish-ctr In-Reply-To: References: <200504270600.CAA13786@Sparkle.Rodents.Montreal.QC.CA> <200504270600.CAA13786@Sparkle.Rodents.Montreal.QC.CA> <200504270652.CAA13936@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> I tried to send mail off-list to Ben Harris, > [...] Ben, I've tried to send you mail through another channel (mouse to bjh21 on mail.netbsd.org). This list message is just to give you a heads-up in case it didn't work. For everyone else - sorry for the chatter, and if everything works as well as I hope this will be the last time Ben and I will have to use the list for what really should be off-list mail. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 28 10:26:41 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20442 for ; Thu, 28 Apr 2005 10:26:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B42FA53E2; Thu, 28 Apr 2005 14:26:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av11-1-sn2.hy.skanova.net (av11-1-sn2.hy.skanova.net [81.228.8.183]) by mail.netbsd.org (Postfix) with ESMTP id A95575305 for ; Thu, 28 Apr 2005 14:26:31 +0000 (UTC) Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 4BD2338321; Thu, 28 Apr 2005 16:26:30 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3ED2C38244 for ; Thu, 28 Apr 2005 16:26:30 +0200 (CEST) Received: from [192.168.0.105] (h54n1fls31o850.telia.com [217.208.152.54]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3330A37E45 for ; Thu, 28 Apr 2005 16:26:29 +0200 (CEST) Message-ID: <4270F30F.4000508@streamsec.se> Date: Thu, 28 Apr 2005 16:28:31 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: FYI: Brief decription of helix@streamsec.com cipher 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 Description: Helix with a 256 bit key, a 128 bit block size and a 3*128 bit IV. The IV is parsed as nonce(128)||key(256) and is used for setting up a second instance of Helix. The second instance is used as a continuous PRNG for generating the per packet nonces for the main instance. The PRNG instance is set up normally, as for encryption, with the key and nonce from the SSH NEWKEYS IV, without processing any unencrypted header data before the first nonce for the main instance is generated. Each nonce for the main instance is the next 4*32 bits of keystream generated by the PRNG instance. The PRNG instance is never generating any MAC and never changes the nonce. If the SSH transport layer rekeys, a new NEWKEYS IV is generated and a new PRNG instance will be keyed by it. This cipher provides integrated data integrity. When used, the negotiated SSH integrity algorithm is simply ignored -- Henrick Hellström www.streamsec.com