1. The implementor has managed to design a protocol which will accept
arbitrary numbers of chosen-ciphertext messages and reply to each one with
an exact indication of how the decrypt failed, leaking information about
the decrypted message to an attacker. This is a fairly remarkable feat,
but let's say, just for arguments sake, that someone did do this.
I'm not sure how remarkable this would be. Quite a large number of SSL servers
actually returned the necessary error messages for an attack there. I think
one shouldn't leave the chance here that the implementor makes mistakes and
add some quidelines to the standard.
That's what I'd proposed earlier on in the same thread. In addition you have
to remember that S/MIME and PGP are very different beasties from SSL, unless
you go out of your way to design a protocol which returns decryption results
you'd never get this situation, the best you can hope for is an SMTP-level
"Your mail probably got to some machine from which the recipient can collect
it" which never gets near the security layer. Even though S/MIME has
provisions for signed receipts, the most they can communicate is "I got your
message", which is just a glorified form of the SMTP-level response and doesn't
help with this particular attack.
4. A typical query+response takes half a second (this means opening a
connecting, generating a chosen-ciphertext message, transmitting it, having
the victim decode and try to decrypt it, generating a response, wrapping up
an exact indication of the decryption error it encountered, and sending it
back to the attacker).
The latest that I heard of was a server presented at the RSA conference that
can do 1500 SSL connections per second.
Again, it's a special case for SSL. For it to affect S/MIME or PGP you'd need
to set up an autoresponder running a custom protocol designed to facilitate the
attack (since it can't be done using any feature of standard S/MIME or PGP).