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

[Wei Chuang <[e-mail]>]

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

> Wei,
>
>
>
> See below.
>
>
>
> *From:* Spasm [mailto:[e-mail]] *On Behalf Of *Wei Chuang
> *Sent:* Friday, April 29, 2016 1:52 PM
> *To:* Laetitia Baudoin <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]>
> 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.
>

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
>
>
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>
>
>