Re: [lamps] More mail madness?

Here is the approach I use for encryption which guards against the IV
attack. It might seem a little over the top but the objective here is to
minimize the number of code paths rather than the length of the code path.

The reason I started on this approach was I was looking for a secure way to
encrypt chat room logs etc. without having to do a key exchange per
message. In the process, I realized that the same approach works remarkably
well in S/MIME like applications where we may have multiple multiparts that
we want to encrypt under one key exchange, we may want to encrypt subject
lines and we may want to encrypt signatures over the plaintext.

1) Generate fresh session key of at least 256 bits which has the property
of being infeasible to guess (note that unguessability is a stronger
requirement than merely being random).

2) Perform a key exchange for each recipient.

2a) If it is a DH or EDH key exchange, use the key exchange result as the
IKM for a KeyDerivation function with info tag "master". Then use the
resulting key to perform an AES Key Wrap of the session key.

3) Create the Enhanced Data Sequences.

For each EDC we create a salt value which needs to be unique within the
context of this particular exchange.

We then use HKDF to derive the encryption (+MAC if needed) and IV.

This approach ensures that the IV is chosen in a rigid fashion and thus
eliminates a possible area of manipulation as any change to the salt will
prevent decryption and authentication of the message as well.

On Mon, May 14, 2018 at 12:39 PM, Richard Barnes <rlb@ipv.sx> wrote:

> Russ: Is there some more work to be done here to address the CBC/CFB
> issues?  Even if the encapsulation has AEAD support, maybe there's some
> negotiation thingy?
>
> On Mon, May 14, 2018, 12:37 Russ Housley <housley@vigilsec.com> wrote:
>
>>
>> On May 14, 2018, at 12:35 PM, Paul Wouters <paul@nohats.ca> wrote:
>>
>> On May 14, 2018, at 12:29, Russ Housley <housley@vigilsec.com> wrote:
>>
>> We are working on text for S/MIME that says that each portion of a MIME
>> multi-part needs to be handled in its own sandbox.  The direct exfiltration
>> that is described happens because the mail user agent glues the various
>> portions together for display to the user, which in the example on the web
>> page causes an image to be fetched from the attacker's website with the
>> message plaintext as part of the URL.
>>
>>
>> So that’s the bandaid. What and where will work be done on a solution?
>>
>>
>> LAMPS just sent an update to the S/MIME message document to the IESG.  My
>> guess is that there will be discussion on the spasm@ietf.org mail list.
>>
>> Russ
>>
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>>
>