S/MIME and AE

[Earle Lowe]

I can't see anyway that S/MIME gets resolved with anything other than
heuristics that look for the footprints of the CBC malleability in efail
(random blocks and/or 8bit content) etc.

There are two other alternatives, only one is plausible, IMO

1) Only allow emails where the signature verifies. It doesn't have to be
valid in terms of chaining to a trusted root, but it does need to verify.
This also means you throw out anything not signed (or signed first, then
encrypted) (both of which are allowed).

This option may turn out to be plausibly implemented - but is a pretty big
change to how most S/MIME implementations in actual clients work - they
usually hardly do anything even with bad signatures.

2) Use the various AE CMS RFCs - This is a long-term effort given the
experience with OpenPGP in deprecating non-MDC packets. First either the
S/MIME RFC needs to be updated to remove AES-CBC as essentially the default
and replace it with another one - AND certificates need to start using the
SMIMECapabilitiesExtensions - or vendors start ignoring the existing RFC
and just go ahead. I don't see any way a sender can have some plausible
idea what the recipient can decrypt without having some knowledge of the
version of S/MIME they are using - and this is what SMIMECapabilities is
for in the certificate.

Then once the vendors get together and decide on the new behaviour, and the
certs get updated with new Capabilities - we can wait about how many years
for it all to percolate through the ecosystem? There is a reason no one
bothered to implement any of those RFCs in the first place.

For OpenPGP and MDC, I vote for completely and fully removing non-MDC SE
Packets - no more generating SE packets for any version of keys or ciphers,
ignoring the MDC feature packet in V4 keys, and refusing to decrypt
anything without MDC. I'm ok if some kind of user option needs to exist to
decrypt old content - but I think it should be clearly seen as a dangerous
and insecure option.

-Earle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180520/014b267d/attachment.html>