Reliance on Microsoft called risk to U.S. security

[Jerrold Leichter]

| >> "Can be relied on to _only_ deliver text" is a valuable and important
| >> piece of functionality, and a capability that has been cut out of too
| >> many protocols with no replacement in sight.
While I agree with the sentiment, the text/code distinction doesn't capture
what's important.

Is HTML text or code?  Well ... it's actually neither.  There is a set of tags
in HTML that is perfectly safe.  Setting fonts and font colors, describing a
table ... all kinds of stuff like that isn't text, but it can't hurt you
either.  (Whether these are *useful* in mail is a whole other question....)
On the other hand, embedded references that reach out over the network are
inherently dangerous, since the very act of autonomously opening a connection
to a system of someone else's choosing is something I, personally, don't want
my mail reader doing, ever.

Text is code, too!  A plain ASCII message received by Pine is run through the
Pine Interpretation Engine - the Pine MUA under another name.  Some character
sequences cause entries to be made into a list of subject lines.  Others
may trigger automatic refiling.  Most cause bits to be written to a terminal
window.  Those bits in turn are really code, interpreted by my xterm (or
whatever), causing it do to all kinds of complicated things that ultimately
light some pixels on my screen.

The real distinction is:  Which of *my* resources are *you* able to manipulate
by sending me mail?  I'm willing to give you complete access to send characters
to the terminal in which pine runs ... well, almost.  There's a long history
of security holes *in terminals* - e.g., escape sequences that load the "WRU"
buffer, and then a control character that causes the "WRU" to send back
"qyy|rm *\n"!  You have to carry this analysis *all the way through all the
levels of interpretation*.  Way back, when I worked on designing terminals at
DEC, we were aware of the security issues and it was a design rule that there
was no way to send characters to the terminal and have exactly those read back
automatically.  (Usually, you couldn't read it back at all.  Otherwise, they
were wrapped up in a format that would be innocuous to all but very strange
programs - e.g., as a hex string.)  It was fun evaluating competitor's
terminals against that design rule - almost all of them failed.  (It was not
so much fun telling marketing that no, we would not implement that particular
feature even though the competition had it.)

Anyhow ... if you consider the entire *system*, then the rule is that I will
give you complete access to write a certain "safe" subset of ASCII characters,
or a "safe" subset of ASCII characters plus escape sequences.  That's why mail
clients have long filtered out certain characters.  (An MUA that talks direct
X calls has no reason to filter anything, since writing a text string directly
with X goes into an interpreter that can change *only* the bits on the
screen.)

A resource-based model gives you some basis for deciding which parts of HTML
are acceptable, and which are not.  Given such a model, it's perfectly
possible to write a safe HTML interpreter.  Of course, you lose some features -
that's life.  Life would also be much easier if you never had to lock your
door because no one would ever think of stealing.

BTW, a resource model has to change with time.  The traditional view has been
that I grant anyone full write access to the end of mail file - i.e., anyone
can send me as much mail as they like.  These days, I really *don't* want to
grant that access to spammers - and spam blocking techniques are all about how
to control the "SMTP interpreter" I present to the outside world to protect
my disk resources.
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com