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

Wei,

See below.

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei Chuang
Sent: Friday, April 29, 2016 1:52 PM
To: Laetitia Baudoin <lbaudoin@google.com>
Cc: spasm@ietf.org
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 <lbaudoin@google.com <mailto:lbaudoin@google.com> > wrote:

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.

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.

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, 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.  There are lots of problems that need to be dealt with if we are going to “clarify” this language.

Jim

Thanks, 

-Wei

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