[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         R. Housley
Internet Draft                                            Vigil Security
January 2005
Expires in six months

                 Security Review of Two MASS Proposals


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   A small group conducted a speedy security review of two MASS
   proposals: DomainKeys and Identified Internet Mail (IIM).  This short
   document provides the findings.

Bellovin & Housley                                              [Page 1]

Internet Draft    draft-housley-mass-sec-review-00.txt      January 2005

1. Introduction

   The MASS effort began with many proposed solutions at the first MASS
   BoF held at IETF 60.  Discussions on the mail list have trimmed the
   number of proposals considerably.  The leading contenders are now
   DomainKeys [Delany] and Identified Internet Mail (IIM) [Fenton].

   A small group was gathered by the Security Area Director to conduct a
   speedy security review of DomainKeys and Identified Internet Mail
   (IIM).  The group included (in alphabetical order):

        Steve Bellovin (Columbia University)
        Matt Fanto (NIST)
        Sam Hartman (MIT)
        Russ Housley (Vigil Security)
        Blake Ramsdell (Sendmail)
        Neil Rerup (EDS)
        Jim Schaad (Soaring Hawk)
        Sam Weiler (SPARTA)

2. Security Review

   The DomainKeys and IIM specifications are both in good shape.  They
   represent a lot of work.  This review could not have been conducted
   without well written specifications as an input.  While the syntax
   and semantics could use some futher clarification, the basic intent
   is clear.

   The MASS effort, if it goes forward in the IETF, will specify
   mechanisms to support the automated reduction of Phishing attacks and
   Spam.  The idea is that the email message can be automatically
   filtered if the advertised source of the message is not associated
   with the domain that signed the message.

2.1. Spamming Phishing, Authentication, and Privacy

   Steve Bellovin published an article in the Communication of the ACM
   [Bellovin] That takes the position that authentication is probably
   not going to be a silver bullet that solves this problem.  The review
   team agrees; however, Phishing and Spam have reached epidemic
   proportions, and they demand the attention of the IETF and other
   Internet-related groups.  Further, authentication will provide A
   valuable input to automated filtering, which could eventually aid all
   email users.

Bellovin & Housley                                              [Page 2]

Internet Draft    draft-housley-mass-sec-review-00.txt      January 2005

2.2. S/MIME and OpenPGP

   DomainKeys and IIM claim to be much simpler than S/MIME or OpenPGP.
   The security review team agrees with this assessment.  Since the
   problem trying to be solved is somewhat simpler than previous
   efforts, the problem domain is restricted and the solution is
   simpler.  However, we must be careful that requirements are not added
   during the development process.  If this happens, the final outcome
   could be just as complex (or even more so) than S/MIME and OpenPGP.

2.3. Public Key Infrastructure

   Neither DomainKeys nor IIM makes use of certificates.  The goal is to
   start with something simple; something that does not dependent on the
   deployment of an infrastructure.  The question is: what is simple
   enough?  The solution needs to be complex enough to support the
   evolution to a supporting infrastructure; however, there are also
   concerns with incrementally adding things.  One must ensure that the
   final architecture is not more complex than deploying an
   infrastructure from the beginning.

   The solution space is discontinuous. Both DomainKeys and IIM seem To
   have decided that existing certificate-based technologies are too
   complicated.  That is, Certification Authorities (CAs) and
   certificate revocation are not required by either proposal.  They
   only include a placeholder for the future use of X.509 certificates.

   This decision may be reasonable.  If a mechanism to deal with
   revocation Is added to the architecture several years after
   deployment, then the Internet community can probably live with some
   duplication of effort.  However, if two weeks before the MASS RFC is
   published, the Internet community decides that a revocation mechanism
   is needed, then everyone will be wondering why RFC 3280 and the other
   outputs of the PKIX working group were not employed.  Such a
   transition will be very difficult.

   Overall complexity must be considered.  Enhanced deployment may be a
   reasonable justification for incrementally developing technology.
   Minimizing specification time at the cost of deployment complexity is
   not such a justification.

   Since a transition to X.509 certificates is considered, RFC 2538
   should at least be considered.

Bellovin & Housley                                              [Page 3]

Internet Draft    draft-housley-mass-sec-review-00.txt      January 2005

3. Cryptography

   Nieither DomainKeys nor IIM does a good job specifying the
   Cryptographic algorithms.  Both require RSA (probably the PKCS#1
   version 1.5 variant) and SHA-1.  This is a fine choice, but the
   specification needs to handle other algorithms too.  It is not clear
   how one would migrate to ECDSA with SHA-256, for example.

   The key sizes specified for use with this system are different than
   those specified in other IETF applications.  No justification is
   provided.  RSA with a key size smaller than 1024 bits clearly needs
   justification.  Migration to an RSA key size of 2048 bits should be

   No mechanism to facilitate the transition from one signature
   algorithm to another is included.  One approach might be the support
   for multiple signatures to appear in a message.

4. Potential Security Concerns

4.1. Replay Attacks

   One of the MASS goals is to prevent ISPs from having from their
   addresses forged by spammers.  This service would support the
   construction of a reputation system.  Neither DomainKeys nor IIM
   prevent source address masquerade.  It is fairly easy to send Spam
   with a valid isp.example.com signature by simply getting an account
   from that ISP and use it to send a Spam message to another account
   served by another ISP.  The received message contains a valid
   signature for the Spam message.  The message can be duplicated and
   resent to any recipients, and the ISPs signature will be valid.

   According to the IIM authors, they discuss this attack and some
   solutions.  The solutions all had undesirable properties.

   In security terms, this is a replay attack.  Without replay
   protection DomainKeys and IIM fail to provide the authentication that
   being advertised.

4.2. Denial of Service Attacks

   Much more attention needs to be given to denial of service issues.
   Note that a large number of bogus messages can overload the CPU of a
   verifier.  We have already seen CPU attacks by spammers against anti-
   spam systems.

Bellovin & Housley                                              [Page 4]

Internet Draft    draft-housley-mass-sec-review-00.txt      January 2005

5. Security Differences

5.1. Key Registration Server

   IIM includes the Key Registration Server (KRS).  This provides
   significant flexibility, without requiring every domain name to
   deploy a server.  This separate server has many properties in common
   with an OCSP server used in some PKI deployments.

   It is not as easy to distribute KRS servers as is claimed; they are
   not serving up simple static pages.

   The granularity of control offered by the KRS is desirable.  However,
   the complexity raises questions.  If this complexity is necessary,
   what complexity associated with a PKI is really being avoided?

   The DomainKeys proposal depends entirely on DNS.  Of course, the DNS
   has well known security issues.  DNS responses are essentially
   unauthenticated.  Some day, DNSsec will be deployed, but we should
   not depend on that security solution for the MASS effort.  Note that
   this threat also needs to be discussed in the Security Considerations
   section.  At a minimum, mention DNSsec and point to RFC 3833.

   The type of DNS attacks that would allow arbitrary public key
   substitution are claimed to be " uneconomical."  This assertion is
   completely unsupported.  The spammers have shown great willingness to
   engage in many different forms of attack against anti-spam services.

   KRS involves a reference from the DNS to the KRS server, which is
   accessed with HTTP.  One can either accept a lack of security or
   provided by DNS as seems to be suggested, or TLS can be used to
   protect HTTP.  However, the use of TLS involve the use of PKI to
   authenticate the KRS server.  This leads to a very big question:
   which trust anchors are appropriate for use in this application?  The
   answer involves infrastructure deployment.

5.2. DomainKeys Signature

   Crucial semantics are specified in the DomainKey-Signature: line, but
   it is not covered by the signature.  Can an attacker change the one-
   way hash function (h= portion of the header line)?

   The document should require the signature algorithm (the default is
   a=rsa-sha1) to be present in the header line.

Bellovin & Housley                                              [Page 5]

Internet Draft    draft-housley-mass-sec-review-00.txt      January 2005

6. Open Email Issues

   The DomainKeys and IIM documents employ the same canonicalization
   approaches.  These need further review by the email community.  The
   digital signature processing of DomainKeys and IIM has many
   similarities with digital signing XML.  The canonicalization is very
   simple, much simpler than MIME.  The MIME documents explain mail-
   mangling quite well, so justification for the simpler
   canonicalization needed.

   Several header lines need further investigation.  For example,
   "Resent-*" and the myriad ways that mailing lists mangle email.
   Mailman, for example, can prepend text to a message as well as append
   text to a message, but only the latter case is discussed.  Also, many
   mailing list systems modify the Subject: line, which will break
   signature verification of any messages that covers the Subject: line.
   Anti-virus and anti-spam packages also make changes to messages.

   Another mail-related issue is the existence of
   user+something@example.com Addresses.  Are the wildcards proposed for
   per-user keys sufficient for these addresses?  Should the
   canonicalization algorithm handle this in a special way?

7. Deployment Concerns

   DomainKeys and IIM specify opt-in mechanisms.  Therefore, when a a
   specific domain goes on a black list, a Spammer can simply change
   domains.  If the solution does not achieve full deployment, it is not
   clear that it will meet the stated objectives.

   Deployment requires MUAs to be updated; however, updating to accept
   S/MIME or OpenPGP mail is considered to be too difficult.  Since
   there is already a lot of software for S/MIME and OpenPGP,
   justification is needed.

   ISPs need to update all POP/IMAP mail servers to perform signature
   verification; however, these same servers have not been updated to
   remove constraints on 7-bit mail.  What will make this different?

   ISPs need to update all mail submission points to generate the
   signature and authenticate the originator.  Yet, many ISPs cannot or
   will not deploy TLS to protect passwords.  What will make this

Bellovin & Housley                                              [Page 6]

Internet Draft    draft-housley-mass-sec-review-00.txt      January 2005

8. Security Considerations

   This document provides a security review of DomainKeys and IIM.  The
   review team hopes that the information here will improve the output
   of the MASS effort, if a working group is chartered to pursue this

9. IPR Considerations

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

Bellovin & Housley                                              [Page 7]

Internet Draft    draft-housley-mass-sec-review-00.txt      January 2005

10. Informative References

   [Bellovin]  S. Bellovin.  "Spamming, Phishing, Authentication, and
               Privacy", Communication of the ACM, 47(12):144, 2004.

   [Delany]    M. Delany.  Domain-based Email Authentication Using
               Public-Keys Advertised in the DNS (DomainKeys).  August
               2004.  <draft-delany-domainkeys-base>, work in progress.

   [Fenton]    J. Fenton and M. Thomas.  Identified Internet Mail.
               October 2004.  <draft-fenton-identified-mail>, work in

11. Authors' Address

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   Phone: +1 703-435-1775
   Email: housley@vigilsec.com

12. Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   This document and the information contained herein are provided on an

Bellovin & Housley                                              [Page 8]

Internet Draft    draft-housley-mass-sec-review-00.txt      January 2005


Bellovin & Housley                                              [Page 9]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/