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

From: Russ Housley <[email-masked]>
Date: Sun, 1 May 2016 11:53:35 -0400

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 <[email-masked]> wrote:

> 
> 
> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Laetitia Baudoin
> Sent: Friday, April 29, 2016 12:44 PM
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Laetitia Baudoin <[email-masked]>
Date: Mon, 2 May 2016 08:07:34 -0700

> 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.

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 May 2016 14:18:17 -0400

> authentication. My point was that the reason given in the draft is

Isn’t this as simple as saying that confidentiality and integrity are provided when auth-enveloped-data is employed?

Russ

---

From: Laetitia Baudoin <[email-masked]>
Date: Mon, 2 May 2016 11:44:24 -0700

> Isn’t this as simple as saying that confidentiality and integrity are provided when auth-enveloped-data is employed?
Agreed, it would be a better wording.

---

From: Wei Chuang <[email-masked]>
Date: Mon, 2 May 2016 12:04:16 -0700

On Sat, Apr 30, 2016 at 8:34 PM, Jim Schaad <[email-masked]> wrote:

> Wei,
>
>
>
> See below.
>
>
>
> *From:* Spasm [mailto:[email-masked]] *On Behalf Of *Wei Chuang
> *Sent:* Friday, April 29, 2016 1:52 PM
> *To:* Laetitia Baudoin <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt
>
>
>
> First thanks goes to the authors of draft-schaad-rfc5751-bis-00 for doing
> the update.
>
>
>
> On Fri, Apr 29, 2016 at 12:44 PM, Laetitia Baudoin <[email-masked]>
> wrote:
>
> Hi,
>
> 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.
>
>
> 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".
>
>
>
>
> +1   Also I'm bothered by the second sentence as too alarming as potential
> uses would presumably find a means to authenticate.
>
>
>
> [JLS] See my comments to Laetitia on why I don’t think authentication is
> a viable option here.
>
>
>
> As this update also adds AES-GCM, can draft-housley-cms-chacha20-poly1305-00
> be considered too?  That would help authenticated encryption algorithm
> diversity.
>
>
>
> [JLS]  As Russ said in his mail, the actual draft is not going through
> this proposed working group.  I would be open to having both AES-GCM and
> ChaCha/Pol1305 as being listed as AEAD algorithms to be supported by the
> message specification.  I added in AES-GCM only because I needed to place
> some algorithm in the draft to motivate the reason for adding the CMS
> authenticated encryption algorithm.
>
>
>
> Also does this means that updating algorithms in general will be covered
> in this pass?  If so, can keysize and algorithm deprecation occur e.g. drop
> md5?
>
>
>
> [JLS] Sean is unhappy, but I do believe that since the draft is open all
> of these issues are open as well.  I am not really sure what I want to say
> about MD5 the current draft says it is supported so you can talk to (and
> potentially read old message from) S/MIME v2 implementations.  Are we
> really sure that we want to shut off this option given that S/MIME v2 was
> only made historical by RFC 5751 in 2010.  I think we need to be careful
> about how we make recommendations on MD5, but potentially doing a verify
> but don’t send makes sense.
>

I understand backwards compatibility is going to be a thorny issue, but at
the same time (and I'm sure this is preaching to choir) the overall
security depends upon the weakest link.  And for md5 and weak 512b RSA key
sizes have (well) known attacks (e.g Flame, and DKIM email hack to Larry
Page hack just as examples).  It'll be much harder to trust a security
protocol that already at the specification level  allows vulnerable
messages as authentic and private.

How about a different approach.  What about allowing support for historic
keysizes and algorithms (of which I think md5 belongs) so archived messages
can be read.  However no assertion about the authenticity, integrity or
privacy of messages using historic key sizes and algorithm be made, and
supporting UI's must not provide assurances as such.  And only messages
using updated v3.5 S/MIME key sizes and algorithm are allowed to be
considered authentic and private.

>
>
> We need to have a strawman to discuss on key sizes, but this is normally a
> very controversial topic.
>
>
>
> For possible work much farther down the road, I would suggest that section
> 3.1 and details of wrapping messages in "message/rfc822" be clarified.
>
>
>
> [JLS] What are the things you want to be able to do that is not covered?
> This was heavily discussed at the time the original RFC was done and it was
> not possible to get any consensus about how to make this clearer than what
> it is.
>

Indeed I was wondering as such.  Hopefully things may be easier this time
as there was strong interest in header privacy recently (certainly at
IETF-94).

Perhaps it might be possible to limit the scope to make it more feasible?
The most useful header will be finding a specification for allowing
"Subject:" to be hidden in the message/rfc822 part, and for it to be
restored upon decryption.  Followed by "Date:".  Ideally the sender and
recipient headers could be protected as well but there's the issues that
you point out.

> Indeed, there were tons of problems with deciding how to address what
> fields are to be duplicated, what fields can be hidden, how to
> show/highlight what happens in the event of a conflict between the fields.
> Think about the situation of sending a signed message to the spasm mailing
> list.  In that event you get a new header added called sender that changes
> how Outlook displays who the message is coming from.  (Consider a case
> where sender privacy is enforced by the mailing list.)   The headers which
> are authenticated by DKIM are no longer the same as the ones in the
> message.
>

Would it help to start a separate discussion thread about this?  Perhaps
break out the scenarios for the different headers of interest?

-Wei

> There are lots of problems that need to be dealt with if we are going to
> “clarify” this language.
>
>
>
> Jim
>
>
>
>
> Thanks,
>
> -Wei
>
>
>
>

---

From: Wei Chuang <[email-masked]>
Date: Mon, 2 May 2016 13:33:09 -0700

On Mon, May 2, 2016 at 12:04 PM, Wei Chuang <[email-masked]> wrote:

>> First thanks goes to the authors of draft-schaad-rfc5751-bis-00 for
>> doing the update.
>>
>>
>>
>> +1   Also I'm bothered by the second sentence as too alarming as
>> potential uses would presumably find a means to authenticate.
>>
>>
>>

I just saw mention of warning for key sizes less 1024 in 6. Security
Considerations.  Can the same be done for md5 digest, and generalized so
that future obsolete algorithm and key sizes can be treated similarly?

-Wei

>> We need to have a strawman to discuss on key sizes, but this is normally
>> a very controversial topic.
>>
>>
>>
>> For possible work much farther down the road, I would suggest that
>> section 3.1 and details of wrapping messages in "message/rfc822" be
>> clarified.
>>
>>
>>