Subject: Re: Two comments on the filexfer draft

From: Darren Moffat <[email-masked]>
Date: Fri, 12 Jan 2001 12:04:40 -0800 (PST)

>   I would prefer that all times should be specified as UTC.

This is what I assumed, but the text to make it explicit should be added.

>   Alternatively, adding a mechanism to discover server time
>   zone information would be acceptable.

Timezones are complex enough as it is with out trying to discover what
timezone a remote machine is running in.  If it is a UNIX(like) system
then it is runing in UTC and only displaying time in different
timezones. I know this is not the case for other systems and it is
differences like this that make such a discovery protocol very
difficult to implement in a workable way for all systems.  There are
also platforms that could have SSH clients (and servers) for which
there is no concept of a timezone (PalmOS has no timezone everything is
localtime).

I think the safest and easiest thing to do is say that the protocol uses
UTC it is then upto each client and server implementations to make the
appropriate translations if they need to.

--
Darren J Moffat

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 16 Jan 2001 12:03:04 EST

> I think we should say:
> 
> C. The sender of the filename MUST send it in UTF-8 without any
> normalization. The receiver of the filename SHOULD convert the
> filename to follow the rules of the local file system, if the direct
> UTF-8 filename is not acceptable for the local file system. The
> receiver SHOULD NOT normalize the filename unless it is required by
> the local file system. This allows original sender to get the original
> filename back when it later tries to retrieve the file.

The rules for generation and interpretation of UTF-8 are specified in
Unicode 3.0.1:

  http://www.unicode.org/unicode/uni2errata/UTF-8_Corrigendum.html

Normalization to shortest-form is required before interpretation.
Clearly, its not possible to enforce a restriction on generation of
non-shortest-form representations.  non-shortest-form representations
are very likely to be generated by attackers.

> Also if we do normalization in both ends then we might end up having
> two different files that have identical names after the normalization
> process, thus one of them is inaccesable if we do normalization. 

Filesystems if they are using UTF-8 must use the shortest-form
representation. Otherwise, they are non-compliant.

> > FTP uses the Unix conventions and recently adopted the notion that all
> > names should use UTF-8.  The IETF's requirement for the use of Unicode
> > require the use of canonical representation in order to avoid security
> > issues.  This is true of all external representations. 
> 
> Which security issues? Can you give me example what kind of security
> issues we avoid if we do normalization?

Anytime you have two representations of the same string you have a
security issue.  If I am building an exclude list I certainly should
not have to be intelligent enough to specify all of the different ways
that Unicode can represent the same string. 

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 18 Jan 2001 15:34:15 EST

> > Character sets must be translated from the local into some agreed upon
> > intermediary form.  Otherwise, you run the risk of taking a file name
> > from Windows (CP1252) and placing it on Unix where all the
> > applications use ISO-8859-1 and now suddenly you have file names that 
> > can't be displayed to the user and worse (when using ECMA-48
> > compatible terminals: VT...) the use of the C1 space for printable
> > characters can cause the terminal to be shifted into an undesireable
> > state.
> 
> Of course they will see the filenames, they just might be funny, like
> "h?h?" or h\366h\344 or h:f6:h:e4: etc. If the application does not
> know how to show that kind of filenames then the application is
> broken. Also if the local filesystem completely forbids some
> characters (for example somebody transfers file named "foo:bar" to
> macintosh system), then it is up to the local end (i.e the macintosh)
> to convert the offending characters something it can cope with.
> Hopefully it will use a method that it can reverse when seeing that
> filename again later... 

Please read the ISO standards for character-sets.  An application is
not broken if it cannot display a file name because the file name is
illegal.