What email encryption is actually in use?

[bear]

On Wed, 2 Oct 2002, Matthew Byng-Maddick wrote:

>I have to say that much as it is a laudable goal to get widespread
>encryption on the SMTP server network, I'm rapidly coming to the conclusion
>that opportunistic encryption in this way doesn't really work. Consider
>where one side believes that it will only accept certificates signed by a
>particular CA (a perfectly plausible scenario in the case of SSL/TLS), and
>I hand it a self-signed one - this is not communicable before the connection
>starts up, and in-protocol, a failure to apply policy causes the connection
>to be shut down (this is by no means the only one, consider one side that
>only use DES and the other that never use it), leaving the connection in an
>undefined state.

I consider that state perfectly well defined -- it is the
"no connection" state.  The only reason any protocol works
is because people prefer abiding by its rules and the
policies each other set up in it to having no connection.

The essence of a protocol is to detect situations where
one party or the other prefers "No connection" over the
rules, and enforce that such detection happens before any
confidential data is shared.  According to this rule, I
would say that the protocol you say is in an "undefined
state" has in fact functioned perfectly.  It detected a
rule that the other was not willing to abide by and dropped
the connection *before* risking any confidential data.
That's precisely what it was supposed to do.


>The problem with this is obvious. You have to treat the failure as a
>temporary failure and try again in a bit. Of course, we know that the
>only way you're going to send this system mail is by sending it in plaintext,
>because otherwise you won't adhere to policy, but also, given that it's an
>automated service, there's no human to turn round and try something slightly
>different, as there is in the case of the Web Browser or mail client talking
>SSL.

But if you are willing to abide by the sending-plaintext
protocol in the first place, this is perfectly reasonable
too. Protocol termination for lack of willingness to trust
single-DES is no different than termination of protocol
for lack of willingness to send (or receive) plaintext.

Where our protocol design fails is in considering "plaintext"
to be something other than "a particularly unreliable and
ineffective encryption algorithm."  Certainly nobody who's
willing to reject a connection for a self-signed certificate
should be willing to accept plaintext, because obviously
plaintext is not as secure as the minimum security they are
requiring.  But experience shows that people willing to
reject self-signed certs and poor ciphers always seem to
be willing to accept the even poorer cipher named plaintext.
This is completely irrational; either you need security or
you don't.

				Bear


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