[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Split Implementations of PGP
Something that would help those of us doing crypto and IMAP would be
for IMAP to be less fussy about message size.
We have the problem that while SMTP and POP consider size information
about a message to be advisory, IMAP considers it to be definitive.
When you have a message that is compressed, encrypted, signed, base64
encoded, put into quoted-printable, etc., it can be very hard to answer
the question, "How big is that message?" definitively.
While POP, for example, will accept the answer "Um, around 15K" and
copes just fine with the real answer being either 3K or 50K, IMAP does
not. The IMAP client will expect the size reported to be accurate down
to the byte. If there is more, the client will never ask for it, and if
there's less, the client hyperventilates and breaks down sobbing.
If there is anything that further work on IMAP, be it Lemonade, or
anything else does that could help security, it would be to break
IMAP's prissiness about message length. The main advantage that this
sesson-key decrypting protocol has is that it exposes the server to
relatively little of the actual plaintext. However, while this is a
theoretic benefit, the practical benefit is lessened by the length
Let's suppose I connect to my server and have ten new messages, all of
which are encrypted, say five with OpenPGP and five with S/MIME. My
client program is going to display the lengths of the messages, but
that isn't knowable without decrypting them. So immediately with the
headers, all ten of those messages have to be decrypted and processed
so that the lengths will be accurate. This slows the system down,
because it requires a complete round-trip of session key decryption for
each message as well as preliminary processing of the message on the
server. If that client program is a mobile device, this is especially
bad because the heavy lifting (the public key crypto) is being done on
the light device, and the easy lifting (the bulk crypto processing) is
being done on the powerful device. What happens is that this
architecture maximally slows the email processing down, with relatively
low security gains, because the server has gotten the session key for
all ten messages, even though I've read exactly zero of them.
I'd like to see a change to IMAP that allows for the message's length
to be advisory until it's actually read. It's relatively easy to do --
you have to have a way to ask the server simply, "Is there more?" as
well as the server to be able to return a short (even zero-length) glob
of message text.
This gives a slightly counter-intuitive display on the client. I might
look at a list of messages and see that one is 8K long, and when I read
that message its length updates to 13K. But in return, we'd be able to
defer the cryptography to when a message is actually read, rather than
when it enters my inbox.