Re: Are we done with draft-hoffman-ftp-uri-02.txt?

At 4:22 PM +0100 10/29/04, Graham Klyne wrote:
>I assume this reference:
>   draft-fielding-uri-rfc2396bis [2396bis]
>will be updated as this goes forward for publication?

It will be handled by the RFC Editor, yes.

>2.  Scheme Definition:
>[[
>    A FTP URL follows the standard syntax described in
>    draft-fielding-uri-rfc2396bis [2396bis].  If :<port> is omitted, the
>    port defaults to 21.
>]]
>That's the command channel port, right?  Does the FTP URI spec have 
>anything to say about the data channel port?  I guess not.

Right. Should I change this to day "command channel port"?

>2.2  FTP url-path:
>[[
>    Historical note: Most FTP client implementations precede the <cwd1>
>    with a "/" before sending the CWD command.  This is arguably in
>    conflict with RFC 1738, although the practice is quite widespread.
>    Thus, a client that is presented with the URL
>    <URL:ftp://myname@example.com/abc/def> might send the two commands
>    "CWD /abc" and "RETR def" or it might send the two commands "CWD abc"
>    and "RETR def".  Server implementers should be aware of these two
>    different interpretations of the same URL.
>]]
>
>That looks like a potential security problem to me... shouldn't FTP 
>servers avoid allowing accesses outside the indicated user's area 
>(subtree)?

To which Alun replied:

>No.  If the user isn't allowed outside of his subtree, the user will not
>be allowed outside of his subtree.  He will receive access errors, or
>more likely, will already be prevented from going outside his subtree.
>Usually this is accomplished by hiding anything outside of the home
>directory, and treating all absolute path names as paths relative to the
>home directory.

Actually, I think Alun meant to start with "Yes", as in, "the servers 
should avoid that". And they do (at least every single one I have 
used does). This has nothing to do with the URI scheme. The rest of 
what Alun says matches my experience.

>I don't recall the details of how FTP works here, but is this topic 
>worth a note under security considerations?

Sounds OK. I'll review all of the security considerations sections 
and look for things like this.


At 9:27 AM -0700 10/29/04, Alun Jones wrote:
>Section 2.2, penultimate paragraph - the historical note.  It's not
>"arguably in conflict", it _is_ in conflict.

Good point; fixed.

>   The wording "quite
>widespread" is not sufficient, IMHO, to convey that this is the
>behaviour of the major browsers (which, let's face it, are close to the
>only FTP clients that operate on URIs) - it's also possible that
>regional variations may cause this phrase to be misinterpreted.  In some
>usage, "quite widespread" means "completely widespread", and in other
>usage, it would mean "slightly widespread".  I would prefer "so common
>as to be almost universal."

I'm hesitant to go that far without surveying all the FTP clients 
that handle URLs, of which there are dozens if not hundreds. "Quite 
widespread" should be a sufficient warning to developers that they 
need to handle both methods.

>I would also like to see some sort of guideline as to what behaviour new
>implementors should be doing.  My gut feeling is that the widespread
>practice of including the "/" means that new implementations should
>default to doing that, and fall back to RFC-behaviour if that fails.
>There's a certain robustness in that, since any server that can not
>accept a "/" in the argument will fail immediately on that command.
>Going the other way - starting with RFC-behaviour and failing over to
>the rooted format - doesn't produce any syntax errors, only access
>errors, which may or may not be perfectly valid.  Starting with the
>practice of prefixing the path with a stroke also means that existing
>URLs that work in browsers will work immediately in such a new
>implementation.
>
>Unless anyone strongly disagrees, I'd like to propose the following
>text:
>
>"Developers of new FTP client implementations that consume FTP URIs
>should attempt access to the file using the slash-prefixed
>('/<cwd1>...') path first, and only use the format specified in RFC 1738
>('<cwd1>...') if that operation fails."

This works for me; how do others feel?

>Section 3, "Security Considerations" - is it appropriate to list also
>RFC2577, "FTP Security Considerations", RFC2228 "FTP Security
>Extensions" (although the GSSAPI extension listed in its appendix is
>horribly flakey), and the upcoming draft-murray-auth-ftp-ssl-15.txt
>"Securing FTP with TLS"?  [The latter is hopefully going to result in an
>"ftps:" URI]

Yep.

--Paul Hoffman, Director
--Internet Mail Consortium

Received on Friday, 29 October 2004 17:55:45 UTC