Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt

I think we need to explain this situation in the security considerations, at least to the level that an implementer knows what services they are getting and not getting.

Russ

On Apr 30, 2016, at 11:01 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> 
> 
> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Laetitia Baudoin
> Sent: Friday, April 29, 2016 12:44 PM
> To: spasm@ietf.org
> Subject: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt
> 
> Hi,
> 
> Could we update the text in section 3.4 [Creating an Authenticated
> Enveloped-Only Message]?
> 
> Currently it states:
> -----
> 
> This section describes the format for enveloping a MIME entity
>   without signing it.  It is important to note that sending
>   authenticated enveloped but not signed messages does not provide for
>   authentication or non-repudiation.  It is possible to replace
>   ciphertext in such a way that the processed message will still be
>   valid, but the meaning can be altered.
> 
> -----
> 
> Which is incorrect: alterations to the encrypted part of the message would
> be detected.
> The problem is that authenticated encryption alone does not prove anything
> about the sender.
> 
> [JLS]  It is not totally incorrect, but I would agree that it is misleading.
> The odds of being able change the message are approximately 1 in 2^128
> (assuming a 128-bit authentication tag).  This is much better than the CBC
> world where the odds would be roughly 1 in 256.
> 
> An alternative to the last sentence could be something like "It is possible
> to change the sender without altering the validity of the processed
> message".
> 
> [JLS]  I find this to be a very misleading statement.  I find that the term
> authenticated encryption to be very misleading.  An AE algorithm only gives
> authentication about the sender under some very specific conditions, and
> those conditions are not generally found for many S/MIME messages.  If it
> had been up to me, I would have called this class of algorithms integrity
> protected encryption rather than authenticated encryption.
> 
> Just to be clear, the following conditions would be required to have an
> authenticated encryption in terms of knowing who the sender is.  1) You
> would need to use an authenticated encryption algorithm, 2) One would need
> to have exactly one recipient information structure (otherwise any other
> recipient can change the message or forge a future message), and 3) the CEK
> would need to be a key directly derived from information about both the
> sender and the recipient.  This would require the use of static-static DH
> which is not generally considered to be an option for S/MIME.
> 
> Given these conditions, I believe that it would be very unwise to say that
> one is going to get authentication from an S/MIME message.  One will get
> integrity protection but that is a different service.
> 
> Jim
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm