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

From: Laetitia Baudoin <[email-masked]>
Date: Fri, 29 Apr 2016 12:44:19 -0700

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

---

From: Wei Chuang <[email-masked]>
Date: Fri, 29 Apr 2016 13:52:13 -0700

First thanks goes to the authors of draft-schaad-rfc5751-bis-00 for doing
the update.

> possible to change the sender without altering the validity of the

+1   Also I'm bothered by the second sentence as too alarming as potential
uses would presumably find a means to authenticate.

As this update also adds AES-GCM, can
draft-housley-cms-chacha20-poly1305-00 be considered too?  That would help
authenticated encryption algorithm diversity.

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?

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.

Thanks,
-Wei

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 Apr 2016 17:24:59 -0400

> As this update also adds AES-GCM, can draft-housley-cms-chacha20-poly1305-00 be considered too?  That would help authenticated encryption algorithm diversity.
> 
> 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?

The Security ADs have asked that algorithm work be done in the CURDLE WG.  So, I have asked that WG to adopt these three drafts:

	draft-housley-cms-eddsa-signatures
	draft-housley-cms-ecdh-new-curves
	draft-housley-cms-chacha20-poly1305

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

If clarification is needed, I’d like to roll it into the rfc5751bis work.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 30 Apr 2016 20:01:52 -0700

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

Currently it states:
-----

-----

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

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 30 Apr 2016 20:34:42 -0700

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

Hi,

Currently it states:
-----

-----

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

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

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

[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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/spasm