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