Re: mailserver URL

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Mon, 30 Jan 1995 20:13:36 -0800


To: uri@bunyip.com
Subject: Re: mailserver URL 
In-Reply-To: Your message of "Fri, 27 Jan 1995 09:20:26 MST."
             <v02110100ab4ecdb0a661@[165.227.40.38]> 
Date: Mon, 30 Jan 1995 20:13:36 -0800
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-Id:  <9501302013.aa19151@paris.ics.uci.edu>

>>Arbitrary header fields introduce an unacceptable security hazard.
> 
> Um, we went through this, and I don't think anyone expressed agreement with
> you on the mailing list.

That is a reasonable thing to expect.  Let's make it easy:

******************    ATTENTION URI DENIZENS:   **********************

1) If you strongly believe that the mailserver URL should have the
   ability to include arbitrary header field values, please send a message
   stating such opinion to the list at <uri@bunyip.com> or to the author
   Paul Hoffman <ietf-lists@proper.com>.

2) If you strongly believe that the mailserver URL should NOT have the
   ability to include arbitrary header field values, please send a message
   stating such opinion to the list at <uri@bunyip.com> or to the author
   Paul Hoffman <ietf-lists@proper.com>.

3) If you don't care, don't send a message.

NOTE: This is not a vote -- it merely reflects the need of the author
      for input on this subject from someone other than myself.
**********************************************************************

> Header fields are just header fields: they only
> become hazards when the message is actually sent. People on the list showed
> examples of other valid URLs that have the exact same hazards in them.

There are no other URLs that include header elements (or the equvalent).
The gopher URL has the potential to hide an SMTP command within the URL.
This potential is eliminated by clients refusing to decode %0D and %0A.
RFC 1738 specifies this in section 3.4.1.

All URLs that specify port numbers have a potential to be misused by
directing them to some other reserved port -- this is avoided by having
the client refuse to connect to ports < 1024 other than the one port
assigned to that protocol by IANA (STD 2).  RFC 1738 already cautions
against this hazard, and I believe stronger wording will be added in the
next revision.

Although it is true that header fields only become hazards when the
message is actually sent, it is also true that header fields (other than
MIME's use of Subject in mail-server) are normally generated by the
client at the behest of the user or local system installation.  In no
case (that I know of) are they allowed to be specified external to
the user's environment.  The reason is simple: mail headers define the
control data for the message, and allowing an external source to specify
the content of that control data makes the user vulnerable to a trojan-horse
attack.  It *cannot* be assumed that the user of a mail client knows of
the purpose (or even existance) of header fields which are hazardous, so
having the user verify their content before sending the message is not
sufficient to avoid the hazard.

> If you propose to modify RFC1738 so that no URL can possibly send a message
> to an SMTP port that contains any header field other than "Subject", I
> would certainly change mailserver draft to have that same limitation.
> Otherwise, mailserver is no less safe than the URLs that are already out
> there. Similarly, if you modify RFC822 so that nothing other than "Subject"
> headers are allowed for security reasons, I'd certainly change the
> mailserver draft.

It is already impossible, using an implementation conformant to RFC 1738,
to do what you mention above.  Besides that, it is silly to suggest that we
should specify an additional security hole just because others already exist.

> It seems unnecessary to have a URL that is more restricted than the
> transport protocol it is helping users access. We're trying to write specs
> that are scalable.

That would be extensible.  There are very good reasons why a URL
is more restrictive than the underlying protocol.  First, a URL is intended
to identify the location of a resource -- NOT to perform actions on a 
resource.  Consider how much protocol information is contained in an http URL,
and then compare that to the HTTP specification (51 pages and counting).
Second, 

>>In addition, both subject and body should be restricted to disallow
>>the hex codes for CR and LF (%0D and %0A).
> 
> Why? There are no security concerns for CRLFs in header fields as long as
> the user can see the message in the mail-sending client before it is sent.

That is still a security concern, as I explained above.  But, the reason is
simply to make it harder to disguise additional header fields as a continuation
of the content of a prior field -- i.e. make it easier for someone copying
the link from elsewhere to identify an unsafe construct.

> And I don't see how restricting them from the body will help security at
> all.

It won't unless the client is implemented poorly.  I included both because
there is no need for them if "/" is representing line breaks.

>>Also, the security section
>>should contain a warning to user agent developers to be aware of the
>>security limitations of an external mail agent if one is used to handle
>>the message.
> 
> This is a valid security concern, but it is outside of the scope of a URL
> that is not extending the underlying RFC822 protocol.

As (I think) Larry mentioned, this is the kind of concern that the IESG
likes to see included in any related RFC.  In any case, MIME and the
mailserver spec are alone in allowing the content of a mail message to be
specified by someone other than the one sending the message, and MIME
assumes that the user agent *is* the mail agent. 

> Since this is clearly a major concern for you, I suggest you write
> security-related RFC that addresses these issues in their full scope,
> namely anything that can talk to the SMTP port in an automated fashion.
> That includes most mail clients (few tell you all the headers they are
> including), any URL that can send a message to an alternative port (http,
> gopher, and so on), and mailserver.

That would be a reasonable task for the Site Security Handbook (ssh) WG,
not for me.  In any case, specifying these concerns there would not obviate
the need to include them in a mailserver RFC (if it is intended for RFC
status) or in an update to RFC 1738 (if it included a mailserver URL).

>>If people feel this is too restrictive, than I suggest that the name be
>>changed to "mailmsg".  That is what has been defined by the current draft.
> 
> That is fine with me. We could certainly make it two URLs (mailmsg as what
> I have, mailserver as what you propose). It seems unnecessary, but we seem
> to be aiming towards more than one URL for WAISish requests and such. Heck,
> you could even have your name on another Draft, Roy! :-)
> 
> How does the rest of the list feel about two URLs instead of one?

I had no intention of creating two URLs -- the restricted mailserver URL
would be implemented by people who need mail-server functionality but aren't
crazy enough to implement the full mailmsg concept.  My point was that 
including arbitrary headers in the URL is absolutely unnecessary to fulfill
the requirements of a URL for current and all future mail servers.

>>I would allow a restricted mailserver URL to be implemented on our
>>systems -- its usefulness would justify the risk.  However, I would
>>never allow a "mailmsg" (or its equivalent) to be implemented -- the risk
>>is simply too great to allow arbitrary messaging within a URL.
> 
> Um, how would you prevent a URL from being "implemented"? If you have
> complete control over every possible URL-interpreting client at your site,
> and every one of those clients allowed you to allow or block particular
> URLs, that might be possible: this seems a tad unlikely.

Our site does not allow the installation of any software that would create
an unnecessary security risk ("necessary" being defined by the requirements
of the job it performs).  When such software is uncovered, it is removed
from our site-wide installations (if it was already installed) and a message
is issued to local users warning against it and requiring that they remove
any local copies of their own.  If we have the source, we will sometimes
"fix" the offending problems ourselves and install the fixed versions.

At the present time, I am responsible for our site-wide installations of
Web-related software.  As such, I am quite capable of ensuring that an
equivalent of "mailmsg" is not implemented at our site.  More importantly,
I am quite willing to chew the hide off any software developer who knowingly
implements a security hazard.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>