[free-sklyarov] Re: Why don't the subscribers of this mailing list use gpg og pgp?
Karsten M. Self
kmself at ix.netcom.com
Thu Sep 13 10:57:18 PDT 2001
on Thu, Sep 13, 2001 at 12:34:42PM -0400, proclus at iname.com (proclus at iname.com) wrote:
> > OK, I'm sorry, I was over stating my case a little. But people look at
> > your actions more than your words and if almost all the posts here were
> > signed I bet we would increace the use of encryption and digital
> > signatures.. .
>
> My point is that we not only need to have more people using PGP for
> reasonable purposes, but also that we need to show that encryption is
> already used by almost everyone on the web. We need to show that
> encryption is vital to commerce and to our national security interests,
> otherwise it will be a casualty of war ( and rightly so ).
I've written a rant to this effect (following), and a rant generator
containing this and other rants/FAQs.
http://kmself.home.netcom.com/Download/rant-o-matic.tar.gz
It's largely aimed at those who respond to me having problems reading my
email, but it's aimed more broadly, and is intended to generate broader
support for RFC 2015 compliant mailers and mail-handling software (I'm
noting signatures broken by a number of list handlers). I try to
identify other advantages of having a widely used and available
authentication/encryption network.
Note too that your own public key doesn't appear to be available from
keyservers.
Peace.
------------------------------------------------------------------------
A (not so) Short Rant / FAQ
on the Subject of Signed E-Mail
and Public Key Infrastructure
By
Karsten M. Self <kmself at ix.netcom.com>
You're probably reading this because you either stumbled across it
at my website, or I sent it to you in response to an email you sent
me saying you can't read my mail. In the latter case, the short
answer is that:
- Your mailer is broken.
- This is your problem, not mine.
- File a bug report with your vendor.
- I'm going to continue signing my mail, and if you don't change
your end of things, you're going to continue having problems
reading it.
In some cases (you're cute, my mom, or you're offering
sufficient reasons per hour), I'll make exceptions, but this
is on a case-by-case basis, and I'm intentionally leaving it
as a PITA manual process so that each of us is reminded it's
a bad idea: me, when I do it, you, when I forget and you're
stuck with unreadable mail from me. GET A REAL MAILER.
- No, this isn't a virus, a bomb, a bug, a worm, or any other
executable code. And if it is, that's your problem, not mine.
- If your IT or MIS department is brain-dead enough to actually
strip off these attachments before you get your mail,
I'm going to laugh at you in public. Sorry, this ain't the
sympathy department. There's a nice rant below about why this
is such a pathetic action, though, you might enjoy reading it.
The long answer is the rest of this document.
"Your Mail is Weird"
I use a combination of tools in my email to create messages which
are cryptographically signed in such a way that it is readily
possible for the recipient to gain a good level of assurance that
the message:
- Originates from me.
- Hasn't been modified in any way en route.
This is sometimes called a digital signature (a technical term, not
to be confused with the recently passed US legislation on
"electronic signatures", regarding legal contractual powers
associated with various, and largely very weak, methods of inserting
corporate hands into your wallet). The system under which it
operates is known as public key infrastructure, and is based on
public key encryption. You're probably going to start hearing a
whole lot about this over the next year or so.
That's the long description.
The short story is that there's a way for me to keep half a secret
and spread the other half to the world in such a way that you can
tell if a particular message came from my half of the secret. It's
pretty cool.
The other part:
You're responsible for determining whether or not a communication
that purports to come from me is in fact from me. And if I didn't
sign it, it almost certainly didn't. If the message *is* signed,
it's still your obligation to verify the signature itself.
What is RFC 2015 and Why Can't I Read Your Mail?
There's an Internet standard, called a "request for comments", or
RFC, which covers MIME encoded encryption and signatures. This is
RFC 2015, "MIME Security with Pretty Good Privacy", (more info below
under "Resources"), and defines how to handle public key
infrastructure (PKI) encryption and authentication via standard MIME
protocols.
While it is still a draft standard, it is widely supported on
multiple platforms. There are some pieces of Internet mail plumbing
which break the protocol -- multiple mail clients ("email
applications" to you), as well as some server applications.
LISTSERV and beromail are two I'm aware of -- but compatibility
modes are frequently available for such software, and in many cases,
support is planned in future upgrades. But that's another story.
If you're interested in the gory technical details, read on. You
should be able to save my email as a text file and open it in a
simple editor (e.g.: Notepad or Write under Legacy MS Windows).
You'll find that the message body content type of my messages is
expressed as:
Content-Type: text/plain; charset=us-ascii Content-Disposition:
inline Content-Transfer-Encoding: quoted-printable
...which should be handled properly as inline plain-text content.
If your mailer doesn't present the message body in this format, you
should report a bug to the program maintainer or vendor.
The signature is presented as:
Content-Type: application/pgp-signature Content-Disposition:
inline
Again, this is plain text, non-executable, and in no way represents
a threat or possible exploit on your system. For an intelligent
mailer, this should be interpreted, rather than presented, and used
to validate the message content itself. Otherwise, the content can
be presented or concealed, at the user's preference.
So, Why Do You Insist On Signing Your Mail Anyway?
Fair question.
Part of the reason is for your benefit, where you are the reader of
my mail. It is your responsibility to ensure that what you are
reading as attributed to me is in fact my own writing. While
digital (or sometimes "electronic" signatures now carry some legal
standing, I'm not vesting my GPG hash with this power. However, you
can be pretty confident that words appearing over my signature,
verified against my public key, were written by me, or by someone
who has access to my computer, my private key, and the pass-key
necessary to utilize it.
Why is it your responsibility? Simple: you know you've received
mail from me. I may or may not know I've sent it. As is well
known, email is an insecure, unauthenticated medium. It's quite
possible that someone is sending something claiming to be someone
they aren't. In fact, this happens as a matter of course with spam.
Since you (the recipient) have the evidence in front of your eyes,
and I've no idea it's been sent, if it's not from me, the burden of
authentication lies with the recipient.
If it's not signed by me, your assumption should be that it isn't
*from* me.
A large reason though is to encourage and advocate use and adoption
of tools that support public key infrastructure (PKI) methods, both
the ability to create and properly process signed and encrypted
mail. I've found myself at several times needing to send
authenticated or encrypted mail to persons, only to find that the
recipients did not have a public key, PKI support within their
mailer, or even, at times, a mailer capable of supporting PKI.
It's been suggested variously that I sign messages inline, or in
some instances, that mailing lists drop all MIME-encoded
attachments. I believe this is the wrong solution for two reasons:
- It breaks useful behavior. MIME attachments *can* provide
useful information, including support of non-ASCII
charactersets, required for basic communications in much of the
world. In the case of signed messages, a recent SANS alert of
the BIND exploit of the day was copied to a mailing list I'm
subscribed to as cleartext-signed message. The body of the
message was modified in two generations of distribution and the
signature rendered invalid. This is not immediately apparent as
messages which are cleartext- signed must be verified as a
separate, manual, step. In the case of security exploits and
announcements, such verification and authentication is of some
importance.
- It's not the root problem. The root problem is mail clients
which handle untrusted content in an insecure fashion. This is
like dousing 75% of the population with gasoline, then placing
match-confiscating personnel at the doors of all public arenas.
The problem isn't the matches. It's the gasoline.
Palliative measures to reduce the apparent risk without
addressing the actual cause mask the problem without fixing it.
If sufficient people feel the pain, we'll eventually see changes
either to client behavior or choice.
So Where Can I Find RFC 2015 Compliant Mailers
For lists:
http://rmarq.pair.com/pgp/mail-clients-pgp.html
http://www.spinnaker.de/mutt/rfc2015.html
MUA implementations of RFC 2015:
GNU/Linux / UNIX (most also ported to other platforms via
compatibility kits such as Cygwin, UWIN, MKS, MS Unix Services
for NT, etc.)
emacs (through various mail extensions), exmh, ishmail, mew
(an emacs mail reader), mutt, premail (Netscape plugin),
Gnus 5.6.45 with TM and Mailcrypt, KMail, Mixmaster 2.9
(internal mail reader), Sylpheed 0.4.63, TkRat, XCmail,
XFMail 1.3.
Legacy MS Windows, Macintosh, and other platforms.
Claris Em at iler with PGP 5 (?), Datula (plugin), Edmax
(plugin), MS Outlook Express (plugin), MS Outlook (plugin),
Mulberry (plugin), PMMail (native), Qualcomm Eudora (full
and light version for Windows and Mac) since version 3.02
with PGP 5.5.3i and 6.0.2i Plugin, Turnpike (native), Voodo
on Amiga.
Got Any Funny Clueless Luser Stories For Us?
Funny you should ask.
One particularly illuminating response I've receive runs more or
less as follows:
My company's MIS department has recently configured the email
system so that if an email has suspected attachment, it will not
be delivered. Instead, the recipient gets the following
message:
This message uses a character set that is not supported by
the Internet Service. To view the original message content,
open the attached message. If the text doesn't display
correctly, save the attachment to disk, and then open it
using a viewer that can display the original character set.
If you try to save it as instructed, you will see another
message:
<<< MIME ATTACHMENT STRIPPED >>>
I keep getting empty emails as the result of this
reconfiguration.
Thanks
Regards,
<name deleted to protect the lusers>
This prompted the following response from me:
<rant>
So let me get this right.
You use a mail client which allows, among other things,
attachments.
You use a mail client which, among other things, includes
executable content to be sent as attachments.
You use a mail client which, among other things, *automatically
executes* this content, without verifying its source or asking
for user intervention. As an added bonus, there is content
which *does* require the user to launch it but:
- Mail and/or OS features disguise the fact that the
attachment is, in fact, an executable, by hiding such
extensions as might actually reveal such a fact.
- A file content coding scheme (file extensions) which is
bypassed by the fact that a program can be coded to open
content which should be safe (say, a text or RTF document)
but then proceeds to allow execution of unsafe content
within it (MS Word macro viruses).
- There is no ready tool for looking at the raw (text/binary)
form of the attachment to determine its true Buddha nature.
I've got raw text and binary viewers at my fingertips, and
use them.
- OS features and security are such that unprivileged users
can wreak havoc on their own systems, networked storage, and
other users systems, without protections afforded by sane
filesystem security, user permissions, and file
organization.
- OS and application features are such that users routinely
send, and are expected to utilized, arbitrary content, much
of which may be executable. Which might be translated as
"the user is an idiot", but is conditioned by the fact that
the user has been trained that acting like an idiot: running
arbitrary software, or engaging arbitrary methods, which may
or may not include executing code, on arbitrary content, is
not only a perfectly acceptable standard of operation, but
_is required to perform basic job functions_.
- In order to compensate for all these "features", your system
administrators have seen fit, in their divine wisdom, to
extricate all attachments from email. Including such
attachments as might actually serve to provide some level of
authentication as to whether or not the source of a
particular email is who it claims to be, and possibly even a
trust level associated with this.
And this is now a problem for third party sites to deal with on
your behalf?
I'm sorry. I don't follow the logic.
This is your problem, not mine.
If you're going to strip all such features from your email, why
don't you just go back to a plain text mailer and stop asking
the rest of the world to please stop passing bombs your way with
fuses you insist on lighting.
</rant>
Resources:
----------
Some additional informational resources for your benefit:
- RFC 2015, "MIME Security with Pretty Good Privacy", M. Elkins,
October, 1996,
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2015.html , spells
out the standards for encrypted and cryptographically signed
email. Note that signature-as-attachment is required by
RFC2015.
Note also that munging the content of multipart/signed messages
violates RFC2015. This addresses issues with several broken
mailing list management software packages.
- For a list of mailers supporting RFC2015, see:
http://www.spinnaker.de/mutt/rfc2015.html
- For information on GnuPG, the GNU Privacy Guard, see
http://www.gnupg.org/
------------------------------------------------------------------------
Copyright (c) 2001, Karsten M. Self <kmself at ix.netcom.com>
This document may be freely distributed with attribution.
------------------------------------------------------------------------
Thank you.
------------------------------------------------------------------------
--
Karsten M. Self <kmself at ix.netcom.com> http://kmself.home.netcom.com/
Praying for the victims.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://frotz.zork.net/pipermail/free-sklyarov/attachments/20010913/9c52eb58/attachment.pgp
More information about the Free-sklyarov
mailing list