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 
requirements.
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.
        Jon