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

On Sat, Apr 30, 2016 at 8: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, we agree that authenticated encryption doesn't provide
authentication. My point was that the reason given in the draft is
misleading.

>
> Jim
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>