Ned, we may be in violent agreement on most of your points. However:
To be fair to Steve Kent, it is these kinds of semantic traps that can easily
escape the untutored eye, and why it is so important that the broader
community
examine these kinds of protocols.
Well, in this particular case this happens to be something we (or at least I)
have thought through in considerable detail already. I don't mean to be rude,
but I certainly didn't need wider community examination to expose this
particular nuance of MIME. I was one of designers of MIME, after all.
No rudeness implied or taken. And if I can avoid being rude in return, I don't
consider myself to be a dummy in some of these areas either, having implemented
some systems like these almost 10 years ago. Our mutual modesty aside :-), the
question is whether ALL of the readers of the spec, especially the implementors,
but also those who are responsible for deciding what the security
risks/liabilities
are, will understand those nuances. I am now talking about the process through
which concensus is derived in systems like this. A certain amount of informed
discussion, education, and the ventilation of opposing points of view is both
necessary and healthy. Even Moses wouldn't get approval for the 10 commandments
without setting the stage and providing some background, and I think that is
what
the discssion of the last month has been all about.
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.)
This incredibly common usage (far more common than the use of MIME external
references) brings up all the same issues. The only difference is that there's
no infrastructure within with these issues can be addressed, whereas when MIME
is used there is.
I'm not disagreeing.
This is also just the begining -- there are all manner and species of
interesting applications and mechanisms and procedures that arise naturally
from the wedding of security services (PEM or whatever) to email. None of
these issues have been dealt with in any context thus far, mostly because
without something like MIME there is little if anything you can do about it!
Here's an example of yet another possibly interesting future interaction.
Suppose you have an external reference which, in order to be valid, requires
the use of a particular retrieval mechanism that involves the sender signing
the retrieval request. In effect the originator of the message is asking the
sender to sign something for them in order to obtain the material. There are
many possible uses for such a facility. On the other hand, there are obvious
possibilities for abuse here -- getting someone to sign some fairly
arbitrary thing could be quite dangerous. (There is no mechanism in place
at present to request such a signature, so this is a nonissue for now. It may
become an issue in the future, however.)
The point where we seem to differ is in how such services should be handled in
the specification. I believe very very strongly in the "divide and conquer"
approach to protocol development. (MIME is a strong embodiment of this
principle.) This approach lets us take huge problems and break them down into
manageable, comprehensible, and ultimately solvable pieces. The security
multiparts mechanism is just such a piece -- it gives us the way to impose
security on top of MIME objects. Once this is in place, we can proceed to
define security semantics mechanisms that will let us extend the basic service
to cover all sorts of new applications.
Actually, I'm pretty pragmatic, and agree with you here.
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.
Even worse, any such specification will be necessarily incomplete, in that MIME
(and plain text email for that matter) are open frameworks that allow for the
addition of all sorts of services. And in purporting that it is supposed to
*be* complete, such a document actually does a major disservice to the
community and may in fact be responsible for many more security problems than
it ever manages to prevent.
I haven't examined the spec to that level of detail, so I don't know. What
would a PEM/MIME implementation do if it was presented a signed message that
referenced a remote object without the kind of secure connection between the
two that you described? Would it validate the signature, thereby potentially
lulling the user into thinking that the entire assembly had thereby been
validated?
This is an implementation issue. Moreover, it really has nothing to do with the
use of security multiparts per se -- you might be using MIME in, say, a secure
local setup where there's no need to sign anything, but any external references
outside of that setup are suspect. A user agent has to know what the local
policy is in order to resolve such references, signature or no signature. As
such, this is matter for the base MIME specification to deal with.
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!
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.
Since the answer to this questions didn't immediately leap off the page when
reading the spec, maybe we should have a more comprehensive statement or
model
as to what is being assured and what is not?
This is exactly what I don't want to get into doing. We currently have a simple
specification that provides a service whose characteristics are fairly obvious
-- it provides assurance of the directly included content of a message and
nothing more. If we get into trying to deal with all the possible extended uses
of these services we will get bogged down in minutiae. And worse, when you
attempt to grasp some minutiae you always miss others, and the resulting
document will inevitably lead to more security problems, not less.
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.)
Bob