Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
draft-ietf-smime-cms-auth-enveloped-06
Yes
(Jari Arkko)
(Tim Polk)
No Objection
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
Recuse
(Russ Housley)
Note: This ballot was opened for revision 06 and is now closed.
Jari Arkko Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Sam Hartman Former IESG member
Yes
Yes
(2007-09-19)
Unknown
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".
Tim Polk Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
(2007-09-20)
Unknown
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.
Cullen Jennings Former IESG member
No Objection
No Objection
(2007-09-19)
Unknown
A helpful addition to this draft would be an appendix with one example messages.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2007-09-19)
Unknown
Boilerplate text on IPR is missing?
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
Recuse
Recuse
()
Unknown