Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
draft-ietf-smime-cms-auth-enveloped-06

[Ballot discuss]
There is an important security consideration for all CMS encrypted
messages that was not documented in the CMS base specification (see
the comment).  I would like to have a discussion of how others on the
IESG feel about the importance of this consideration and whether it
should be documented here as an interim measure, or should wait for
an update to CMS.

[Ballot comment]
Here's a rough attempt to describe the threat and mitigation:

A significant security threat to messaging environments today involves
various forms of unsolicited messages (spam and phishing).  Present
mitigation strategies for this threat involve analysis of message
plaintext by fingerprint engines that typically require access to
proprietary infrastructure on the Internet or intranet.  CMS recipients
that accept unsolicited encrypted messages are vulnerable to such
attacks and CMS defeats many common mitigation strategies.  Software
that receives encrypted CMS messages MUST provide a mechanism to
counter the threat of unsolicted messages.  One approach is to reject
or discard encrypted messages unless they meet some reasonable
definition of solicited (for example, if the validated originator is
present in the recipient's personal or corporate addressbook).  An
alternative approch would provide a client mechanism to call out to
a server-based service that filters for such inappropriate content.

Thankfully, CMS clients are not widely deployed enough (or easy enough
to use) for this threat to manifest yet.  But if continued work to
improve CMS support changes that situation we need to be prepared
for the most likely attack on the system.  IMHO, an in depth
discussion of the _many_ approaches to mitigation is
out-of-scope for this document and for IETF standards.

[Ballot discuss]
There is an important security consideration for all CMS encrypted messages that was not documented in the CMS base specification (see the comment).  I would like to have a discussion of how others on the IESG feel about the importance of this consideration and whether it should be documented here as an interim measure, or should wait for an update to CMS.

[Ballot comment]
I still believe the paragraph about generic pre-computation attacks in
the security considerations section is misleading and the document
would be approved by citing the specific attacks David mentioned in
his mail.  This is a really minor issue and I understand if you disagree.

Having read the text, I definitely think Jari's concern about the
ASN.1 is valid.  I suggest replacing explicit set of tag with "the
universal tag for the set of type".

[Ballot discuss]
I realize that my ASN.1 knowledge is rusty, but:

> AuthEnvelopedData ::= SEQUENCE {
>      version CMSVersion,
>      originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
>      recipientInfos RecipientInfos,
>      authEncryptedContentInfo EncryptedContentInfo,
>      authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
>      mac MessageAuthenticationCode,
>      unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
...
> The IMPLICIT [1] tag in the
> authAttrs field is not used for the DER encoding, rather an EXPLICIT
> SET OF tag is used.  That is, the DER encoding of the SET OF tag,
> rather than of the IMPLICIT [1] tag, is to be included in the
> construction of the AAD along with the length and content octets of
> the authAttrs value.

I see that the same scheme is used in RFC 3582 for
something else. However, I do not understand either
what the RFC 3582 text or this text means.

There is no EXPLICIT tag in the syntax anywhere.
Your text is ambiguous with regards to whether
one should use an explicit tag for the SET OF
universal tag (resulting in two tag fields in
the DER output), or just the SET OF universal
tag (resulting in one tag field).

Finally, it is unclear what should be done if
the component authAttrs is missing. Should
the input to AAD be an empty string, or
something else?

[Ballot discuss]
I realize that my ASN.1 knowledge is rusty, but:
Comment: I realize that my ASN.1 knowledge is rusty, but:

> AuthEnvelopedData ::= SEQUENCE {
>      version CMSVersion,
>      originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
>      recipientInfos RecipientInfos,
>      authEncryptedContentInfo EncryptedContentInfo,
>      authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
>      mac MessageAuthenticationCode,
>      unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
...
> The IMPLICIT [1] tag in the
> authAttrs field is not used for the DER encoding, rather an EXPLICIT
> SET OF tag is used.  That is, the DER encoding of the SET OF tag,
> rather than of the IMPLICIT [1] tag, is to be included in the
> construction of the AAD along with the length and content octets of
> the authAttrs value.

I see that the same scheme is used in RFC 3582 for
something else. However, I do not understand either
what the RFC 3582 text or this text means.

There is no EXPLICIT tag in the syntax anywhere.
Your text is ambiguous with regards to whether
one should use an explicit tag for the SET OF
universal tag (resulting in two tag fields in
the DER output), or just the SET OF universal
tag (resulting in one tag field).

Finally, it is unclear what should be done if
the component authAttrs is missing. Should
the input to AAD be an empty string, or
something else?

[Ballot discuss]
I realize that my ASN.1 knowledge is rusty, but:

There is no EXPLICIT tag in the syntax anywhere.
Your text is ambiguous with regards to whether
one should use an explicit tag for the SET OF
universal tag (resulting in two tag fields in
the DER output), or just the SET OF universal
tag (resulting in one tag field).

Finally, it is unclear what should be done if
the component authAttrs is missing. Should
the input to AAD be an empty string, or
something else?

[Ballot discuss]
I realize that my ASN.1 knowledge is rusty, but:

> AuthEnvelopedData ::= SEQUENCE {
>      version CMSVersion,
>      originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
>      recipientInfos RecipientInfos,
>      authEncryptedContentInfo EncryptedContentInfo,
>      authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
>      mac MessageAuthenticationCode,
>      unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
...
> The IMPLICIT [1] tag in the
> authAttrs field is not used for the DER encoding, rather an EXPLICIT
> SET OF tag is used.  That is, the DER encoding of the SET OF tag,
> rather than of the IMPLICIT [1] tag, is to be included in the
> construction of the AAD along with the length and content octets of
> the authAttrs value.

I see that the same scheme is used in RFC 3582 for
something else. However, I do not understand either
what the RFC 3582 text or this text means.

First, you have a freedom to specify this in the way that you
want to. Why not use the IMPLICIT/EXPLICIT tag you want to,
rather than have the text disagree with the formal syntax.
I would expect such differences to cause interesting
problems for automatic encoder/decoder generation by
a compiler.

Second, there is no EXPLICIT tag in the syntax anywhere.
As I recall ASN.1, types either have their natural
tags, their natural tag is implicitly changed to something
else, or there's an explicit additional tag. So what is
the EXPLICIT tag that this text refers to?