This nuance isn't unique to MIME in any case. How many mail messages do
you see these days that incorporate one or more URLs in the text of the
message? Lots!
Ok, I'll reveal my ignorance -- precisely none. I don't even know what you
are talking about! Of the three mail lists that I am involved with
routinely, I don't even recall seeing something like this, at least that I
know of. Of course I'm not involved in building e-mail products, but on the
other hand you are probably not involved in dealing with cellular fraud to
the extent that I am, either. (Warwick might be. He seems to almost be a
clone of me, or vice versa, we turn up in so many different meetings
together.)
Hmm. Well, I guess it could be that you subscribe to a set of very insular
mailing lists with participation only from folks stuck back in the Dark Ages of
networking. But I doubt it! Let me give you a couple of scenarios to illustrate
what I was talking about.
Suppose you get a message that says, "A new draft of such and such is now
available, but is too large to include in this message. If you want a copy, FTP
to blah, CD to foo and GET bar."
I have routinely received messages like this for over 10 years.
Someone might argue that of course the user realizes that the result of
resolving such a reference doesn't necessarily have the same security as
something that was actually in the message. Problem is, I have lots of
customers who deal with users that are incapable of understanding this nuance.
Nowadays, I'm more likely to receive something like, "A new draft of such and
such is now available. Here's the URL to retrieve it, just paste it into the
"Open URL" window that appears in Mosaic and you'll have the document."
Actually, I'm somewhat in the dark ages myself -- I have to cut and paste. The
eventual intent of this stuff is for the reference to be automatic. That is,
the user agent spots the URL (there's a trick for doing this) in the plain text
of the document and highlights it. When I click on it, it opens the URL and
retrieves the document. You don't even have to cut and paste.
This functionality exists either with or without MIME. All MIME adds is one
particular means of doing it automatically. And as a matter of fact the MIME
mechanism is actually close to obsolete -- we urgently need to do a
specification for a URL access type for MIME.
Classic PEM actually suffers from this problem far more than MIME/PEM, in that
in classic PEM the user is left to resolve the reference themselves, and the
user may be in no position to assess the security implications of their
actions. One of the clear advantages of MIME/PEM is that the enforcement of
security is left to the implementor of the user agent, and that implementor is
free to implement these services in ways that make sense.
Were we to try to specify the entire gamut of future services we could ever
build, we'd end up with an extraordinarily complex document that nobody, but
nobody, will understand. This is far worse than a simple document with
obvious properties -- a signature only covers the material that is signed,
and references within that material to unsigned things are inherently
unreliable.
As long as that is made reasonably clear, I'm quite happy.
I will take steps to insure that this point is clearly made in the next draft.
Presumably you ment to say that this was NOT a matter for the base spec to
deal
with? I'm merely asking whether the need for such awareness by the user
agent's is
common knowledge, and as the expert you may not be the right person to ask!
I don't think user agent implementors are sufficiently aware of the issues in
this area -- especially the ones I raised myself about getting unwitting users
to send threatening messages. That's why I've taken steps to address this in
the next revision of the MIME specification.
There is also another interesting security issue that up until recently
hadn't
been discussed in any document I'm aware of. The act of accessing data
through
MIME external references can itself be a problem -- suppose someone sends
you a
mail-server external reference that specifies a threatening note to be sent
to
whitehouse.gov. (This exact example was recently posted to the URI list.)
This
could cause real trouble. Again, this has nothing to do with security
multiparts, but is a MIME security issue nevertheless, and the next version
of
the MIME specification needs to address it. (Actually, I've already written
the
prose for this, which I'll be happy to post if anyone wants to read it.)
Hmmh. This is turning out to be a pretty sharp sword. I'd better be careful
when
trying to shave with it.
Actually, the problem in MIME is tame compared to the problems inherent in the
World Wide Web. For example, I once saw a button on someone's form that said,
"Do not press -- you'll regret it if you do." Lots of people will of course
press such a button to find out what it does. Examination of the URL behind the
button revealed that it was tied to the local systems (via the loopback IP
address 127.0.0.1) chargen port. So if you pressed it your client would start
receiving an infinite stream of data at system speeds (no network link
involved). The URL was also one that ended up using a spool file in most
implemetnations, so this would fill up the spool disk on the system in a
couple of seconds, and bring most of the people using the system for other
activities (the spool disk being a shared resource that many applications
depend on) to a screeching halt. Moreover, many clients don't deal with the
error condition that results here at all gracefully, and may leave the
file out there, which means that everyone is screwed until someone who
understands the system comes along and fixes it.
It is one thing to send a bogus message that may cause some limited grief. It
is quite another to mount an effective service denial attack on a potentially
large number of users on a remote system. Yes the general utility of the
service the World Wide Web provides is seen as outweighing this particular
"nuance".
There is lots of food for thought here. It would certainly be interesting to
see
someone attempt to write a formal security policy model for such a system and
prove
that it is 'secure" in the sense of nonrepudiation. Now, how do I convince
some
lawyers who are having problems with the concept of an algorithm that we in
the
technical community really know what we are doing here? (Rhetorical question.)
Well, I happen to think the lawyers are right in believing we don't
collectively have a good grasp of what is going on here. My problem with their
reasoning in this matter, though, is that they tend to assume that the issues
we're dealing with are new when in fact they are very old. Signed documents and
ciphers have been around for a long time, and the issues of equating privacy
and signatures with integrity and accuracy are not new. The law has failed to
adequately deal with many of these matters in the past, and this doesn't
inspire me with confidence that they will get it right this time!
This is precisely my problem with a lot of this discussion as well. Almost all
of the issues the security multipart mechanisms bring up existed with classic
PEM as well -- you could have references to other unsigned materials (and no
way to tell if users understood the ramifications of them), you could have
messages where only certain parts are signed, and you could have nested
security envelopes. These issues are not new, and if they are so all-fired
important, why weren't they discussed in the classic PEM specifications?
All security multiparts really do is give us are additional means of
*addressing* these matters, means that we didn't have before. As such, if these
matters really are so important, it seems to me that the most logical course of
action is to get these specifications out the door ASAP so we can start
building these add-on services to solve some of these problems.
Ned