Internet DRAFT - draft-otis-ipv6-email-authent

draft-otis-ipv6-email-authent






Individual                                                       D. Otis
Internet-Draft                                                   D. Rand
Intended status: Informational                               Trend Micro
Expires: November 10, 2013                                   May 9, 2013


                       IPv6 Email Authentication
                    draft-otis-ipv6-email-authent-01

Abstract

   IPv6 facilitates network routing over an incredibly vast address
   space, but abuse mitigation resolving to underlying structures of
   routes or blocks of prefixes would be highly disruptive due to
   collateral effects.  Use of domains minimizes unintended coincidental
   blocking while offering the consolidation necessary to facilitate
   connection management.  Currently, email lacks conventions ensuring
   SMTP clients can be identified by an authenticated domain.

   DKIM is independent of intended recipients and domains accountable
   for having sent email.  SPF normally requires several text based
   responses imposing high overhead to query various locations.  These
   locations can be constructed by email-address local-part macros which
   can flood caches or leverage DNS name compression to further increase
   network DDoS amplifications when receivers' attempt to verify message
   sources which may then only offer authorization, not authentication
   of accountable domains.  Most email abuse, including what might be
   imposed by SPF, is prevented with comprehensive mapping of the
   address space, but such mapping is impractical with IPv6.

   An effective authenticated domain name alternative is needed to
   provide a basis for assessing and reacting to abusive behavior.  For
   most high scale protocols, this involves cryptography.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-



Otis & Rand             Expires November 10, 2013               [Page 1]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on November 10, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




























Otis & Rand             Expires November 10, 2013               [Page 2]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Maintaining Trust  . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Responding to Defects and Exploitation . . . . . . . . . . . .  5
   4.  SMTP Can't . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  DKIM Vulnerability . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Barriers to an Authenticated Domain  . . . . . . . . . . . . .  8
   7.  Mail From Parameter and SPF  . . . . . . . . . . . . . . . . .  8
   8.  IPv6 and SPF with PTR or local-part Macros . . . . . . . . . .  9
     8.1.  Problems with Macros . . . . . . . . . . . . . . . . . . .  9
   9.  Domains as a Basis for Managing Traffic  . . . . . . . . . . . 11
   10. XMPP Shows the Way Forward . . . . . . . . . . . . . . . . . . 12
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   13. References - Informative . . . . . . . . . . . . . . . . . . . 13
   Appendix A.  DKIM Examples . . . . . . . . . . . . . . . . . . . . 15
   Appendix B.  Stats . . . . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
































Otis & Rand             Expires November 10, 2013               [Page 3]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


1.  Introduction

   There are currently 18,209,211,661,910,032 /64 equivalent IPv6
   [RFC2460] prefixes routed. [v6-BGP-Rpts].  In comparison, for IPv4
   there are 2,614,711,792 IP addresses routed.  While IPv4 is reaching
   its maximum, IPv6 has about 0.1% of the available /64 prefix routed
   and continues to grow rapidly.  Unlike IPv4, there is no practical
   means to scan reverse DNS namespace within IPv6 since each /64 prefix
   may contain any number of PTR records ranging up to
   184,000,000,000,000,000,000.

   A technique commonly employed to automate IPv4 address categorization
   of suitable hosts is to check whether reverse PTR records appear to
   represent valid hostnames.  Those that represent 4 decimal numbers
   are often considered unacceptable, for example.  Our processing of
   reverse DNS namespace in cooperation with network providers now
   exclude about 38%, or about 1,000,000,000 IPv4 addresses.  Comparing
   IPv6 /64 prefixes with the remainder of rout-able IPv4 addresses
   shows there are 11.3 million times more IPv6 /64 prefixes needing
   categorization that also happen to lack a practical means for
   facilitating this effort.

   Management of either a list of names or a list of numbers involves
   logging the associated connections for subsequent review.  Often
   limits are imposed over some period to constrain overall log growth
   when establishing behavior.  When based on currently routed IPv6 /64
   prefixes, storing just a single bit per rout-able prefix requires 6
   million billion bytes or 5,650 Terra-bytes of storage just to track
   simple use.  Storage requirements for simple address use is likely to
   grow another seven fold as more providers adopt IPv6.  Categorization
   of this use will require additional bits to retain counts and indexes
   further multiplying storage needs.

   Some suggest there will not be a significant increase in the number
   of servers running over IPv6 and since the overall number should be
   comparable, email should be dealing with a similar number of IP
   addresses.  Unlike IPv4, IPv6 does not constrain the number of IP
   addresses assigned to a network interface.  This feature allows each
   connection from a server to originate from a different IP address
   over the life of its operation while also having an ability to
   effortlessly change /64 prefixes.  The increase may prove explosive.

   Extending IP address reputation to IPv6 would also indicate which
   mailboxes are used to detect abuse and afford malefactors a means to
   wash mailing lists to sidestep enforcement of subscription policies.
   Detection of unsolicited commercial email is a fundamental element in
   email reputation.  Traditional address reputation techniques with
   IPv6 will not retain effective detection.  Even if detection were



Otis & Rand             Expires November 10, 2013               [Page 4]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   practical, no scheme can distribute highly sparse IP address
   information quickly enough to counter an IPv6 source's agility at
   evading IP address based mitigation.

   Checking reverse DNS entries per SMTP connection requires queries
   against the entire IP address.  For IPv6, reverse DNS checks by SMTP
   servers may inadvertently induce DDoS effects against DNS while also
   consuming the server's connection resources waiting for reverse DNS
   responses.  Prior IPv4 mapping of reverse DNS avoided a sizable waste
   of resources while defending open services.  However, prior mapping
   of reverse DNS is not practical with IPv6 making it impossible to
   defend against DDoS effects or excessive resource loss while checking
   the reverse namespace.

   Alternatively, costs related to blocking port 25 by Customer-Premises
   Equipment should be negligible.  Network providers should offer
   different services to isolate residential from commercial use, in a
   manner analogous to IPv4 reverse PTR records designating dynamic and
   static assignments.  Residential systems sending email to SMTP's
   public port 25, for the most part, represent compromised systems.
   Blocking this category of traffic would be much safer than expecting
   recipients to check the reverse namespace.  Windows, OS X, and iOS
   employ the IPv6 privacy extensions [RFC4941] where any problematic IP
   address is likely to be reassigned different addresses regularly and
   remain valid beyond the reassignment interval.


2.  Maintaining Trust

   Not every subsystem or protocol layer should be expected to repeat
   previous security checks, however critical checks should not be
   assumed, especially those that involve a trivial amount of effort.
   With high levels of abuse resulting from email's open nature,
   delegating checks in a structured manner better conserves essential
   resources.  However, email's highly distributed store and forward
   protocol could not function if rigid message structures were enforced
   by the transport.  New authentication or presentation requirements
   may involve small structural adjustments.  For example,
   internationalization introduced a format negotiation not assured to
   survive beyond the next hop.


3.  Responding to Defects and Exploitation

   With the advent of aviation, the world marveled at the skill and
   intellect taking us to ever greater heights.  With aviation, faults
   threatening security, that when found, demanded our attention and
   diligence to effect repair.  As with aviation, the success of email



Otis & Rand             Expires November 10, 2013               [Page 5]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   has risen to great heights.  Email has become an integral component
   in general commerce and the maintenance of security such as reporting
   system failures, break-in attempts, and facilitating account access
   recovery.

   Reporting or predicting failure should not be viewed as exhibiting a
   lack of respect for achieved accomplishments.  Noting and repairing
   faults only signify the importance of email's prominent role.  As
   with most security related protocols, responding to noted defects is
   fairly common.  Not responding to discovered defects in a security
   related protocol would be shocking.


4.  SMTP Can't

   SMTP [RFC5321] recommends against rejecting messages based upon
   perceived defects in the message structure.  This liberal acceptance
   permits evolutionary changes in message specifications starting at
   [RFC0822] that was based on [RFC0733] replaced by [RFC2822] and again
   by [RFC5322], [RFC6152], [RFC6532], and [RFC6854]; the second to last
   paragraph in section 3 of [RFC5321] provides a definitive statement
   messages should not be rejected due to perceived defects in the
   [RFC0822] message structure.  The initial reference to [RFC0822] in
   this paragraph offers two foot notes with the second referencing the
   latest version of [RFC0822] which is [RFC5322] which itself has
   recently been updated.  The impact of initially removing text
   specifically indicating which header fields are not to repeat is
   unknown.  This information was implied within the then-new ABNF
   notation.  Clarifying text for this requirement did not return until
   the [RFC0822] revision 19 years later which also indicates this
   specification's success at providing a foundation that allowed email
   to flourish.

   Expecting SMTP to validate message formats to protect against
   vulnerabilities pertaining to protocols such as DKIM does not scale.
   The general use of DKIM permits signature checks subsequent to
   acceptance where only the status of signatures determines internal
   placement.  As such, it becomes critical to ensure a valid signature
   is never declared having malformed header field stacks.  To
   accomplish this, the DKIM specification must change.


5.  DKIM Vulnerability

   DKIM permits a vulnerability by not checking the message header field
   stack for invalid repeats when signing or verifying a signature.  The
   DKIM signature process must walk both down and then up the header
   field stack while selecting the header fields to be included in the



Otis & Rand             Expires November 10, 2013               [Page 6]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   hash process of the signature.  The DKIM process will even ignore
   prefixed From header fields which is the only header field always
   included.

   The WG concluded that the "listing non-existent header fields as
   signed" hack added in non-normative language together with opinions
   that checking for invalid repeated header fields is to be considered
   SMTP's problem.  This issue was expressed as not an attack against
   the trust DKIM intends to convey, and thus not a concern for DKIM.
   Nevertheless, improperly formed messages may display only the first
   of multiple header fields that, as a result of erroneous assumptions
   of there being no invalid repeated header fields, the prefixed header
   fields are likely to be displayed in lieu of those signed while not
   impacting DKIM's signature validity.

   DKIM incorrectly assumed the header field stack's starting
   conditions, which itself is best able to determine.  This is likely
   to astonish most recipients that DKIM failed to make a robust effort
   to maintain the trust it is attempting to convey.  As such, DKIM
   Signers may sign malformed messages (e.g., violate [RFC5322]).  In
   addition, receivers will verify these messages as having valid
   signatures despite multiple instances of a header field only
   permitted to occur once.  See addendum for examples.

   Use of DKIM on such messages exposes a vulnerability in the
   evaluation process.  Rather ensuring essential checks are made prior
   to producing a result, a wasteful hack was later suggested where
   extra non-existent header fields could be included in the list of
   signed header fields.  Any pre-pended header field added after
   signing would thereby change resulting hashes and invalidate the
   signature.  Not all domains are attempting to achieve the same level
   of trust and may be more sensitive to incurring incremental storage
   requirements.  Some domains may even inadvertently sign invalid
   repeated header fields because this check had not been required in
   the DKIM process.  These same DKIM domains are also likely to
   establish themselves as being Too Big To Block.  These TBTB domains
   can then be used to spoof other domains that may have otherwise
   established a high level of trust by implementing the hack where, due
   to this defect in DKIM, can still do nothing in their defense from
   the perspective of now deceived recipients.

   This vulnerability in DKIM represents an exploit allowing serious
   attacks caused by erroneous assumptions made in DKIM's signature
   process.  There is also a header field, which because of its label,
   may potentially mislead recipients into believing it contains valid
   "Authentication-Results" [RFC5451].  Common phrases such as
   "Authentication-Results", "pass", and "fail", rather than use of
   result codes belies introductory claims this header is not intended



Otis & Rand             Expires November 10, 2013               [Page 7]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   for direct human consumption.


6.  Barriers to an Authenticated Domain

   Many advocate either SPF or DKIM as a means to obtain domain
   references based on the increased prevalence of these protocols.
   DKIM is independent of the domain actually sending the message and
   the recipient by design.  Unfortunately, DKIM also does not attempt
   to protect against likely abuses that are also beyond the control of
   the signing domain in which DKIM signature validity conveys no
   assurance pre-fixed header fields have not changed what recipients
   see.  As such, DKIM signing domains can not be held accountable for
   incidents of abuse appearing to violate subscription policies or that
   spoof other domains.


7.  Mail From Parameter and SPF

   Access to outbound SMTP servers may or may not restrict the Mail
   Parameter use.  A strategy used to control abuse might rely upon rate
   limits and denial of access subsequent to abuse reports.  Reasons for
   publishing SPF records might be to mitigate backscatter based on
   records that offer Non-Delivery-Notifications (NDNs) authorization by
   the Mail From parameter where the loss of some of these notifications
   is considered acceptable.  This mechanism does not offer a positive
   basis for identification.  Its intent is to constrain the number of
   invalid NDNs being returned when someone spoofs their domain.
   Evidence of this intent might be denoted by SPF record's ending or
   providers overriding them with "?all".

   SPF failure rates of even a few percent are too high for it to offer
   a solid basis for either acceptance or rejection.  There are some
   policy strategies for specific domains that attempt to combine SPF
   and DKIM where when either of their related domains manage to pass,
   only then is the message to be placed in the in-box.

   Domains that reference SPF resource records should not be considered
   authenticated because the SPF process authorized the SMTP client.
   Often an SMTP client is shared by many domains.  As such, it would be
   incorrect to assume SPFv1 records that authorize a provider by way of
   the Mail Parameters is only permitted by authenticated accounts from
   that domain.

   As a result, no domain information in SPF or DKIM, under current
   circumstances, can be used as a domain reference for either
   acceptance or reputation.




Otis & Rand             Expires November 10, 2013               [Page 8]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


8.  IPv6 and SPF with PTR or local-part Macros

   When IPv6 becomes more commonly used, some will attempt white-listing
   IP addresses as a practical albeit non-scalable method to deal with
   the highly increased address range confronted when dealing with IPv6.
   There are currently no practical solutions able to scale to the
   challenging range of IP addresses that might be controlled by
   malefactors.

   Unlike most DNS resources that segregate IPv4 and IPv6 datasets, SPF
   consolidates both IPv4 and IPv6 addresses into a common list
   comprised of a chain of DNS transactions.  In addition to explicit
   chaining, SPF expects receivers to process the first SPF resource
   record which may contain 10 SPF mechanisms.  Each mechanism may then
   require an additional 10 DNS transactions to resolve the mechanism's
   status.  According to [spf-all.com] out of 112,311,175 domains,
   24,073,182 (21.4 %) publish SPF records where only 12,768 (0.053%)
   employ macros.  Even the 0.053% figure overstates use since many
   represent questionable server farm deployments.  These are
   questionable since many major providers do not process SPF records
   that contain macros.  Non-implementation of macros is very good from
   a security and reliability perspective, but problematic for email's
   integrity when used.

8.1.  Problems with Macros

   Ask a group of email providers about SPF, and you'll likely hear SPF
   is used to identify IP addresses used by a domain to send email.
   With this information, they can check these addresses against popular
   reputation services to determine where there are problems.  Silent
   discard or placement into spam folders reduces delivery status
   integrity and makes supporting unreliable delivery difficult.  When
   SPF was first introduced, AOL claimed they used SPF to create IP
   address white-lists based upon domains with whom they collaborate.
   White-listing would be less effective if macros were used in SPF
   records to change results.

   SPF also includes macros run by recipients that can expand the local-
   part of the Mail From parameter or the IP address of the SMTP client
   into labels used in subsequent DNS queries.  Expressing an IPv6
   address using the SPF macro in the reverse order nibble form can
   comprise a query containing more than 32 labels.  If local-part
   macros are used to locate 10 MX records, the combined targets for
   these MX records can comprise a set of 100 separate hostnames.
   Local-part macros can also be used to chain SPF record sets making
   forensic review difficult.  The latest [I-D.ietf-spfbis-4408bis]
   offers a "(do not use)" statement for the PTR mechanism and the {%p}
   macro.  Because macros pose a serious interchange risk when relied



Otis & Rand             Expires November 10, 2013               [Page 9]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   upon, all macros should be listed as "(do not use)".  In the case of
   the PTR mechanism, the {%p} and {%l} macros should include the
   statement "(do not use and do not implement)."

   The use of the PTR mechanism may place a burden on the DNS servers
   offered by the sender's network provider.  The use of {%l} macro can
   potentially place a sizeable burden on ANY network at little cost to
   malefactors.  The change in this version of SPF that limits the
   number of NX Domain responses will constrain attacks to being against
   any wildcard resource.  Unfortunately, synthetic domains have become
   a popular alternative to the use of Web cookies.

   It should also be pointed out use of macros may not function when
   [RFC6531] permits international email addresses which includes both
   local-part and domain portions of the email address.  Tests and
   comments by large email providers show an understandable reluctance
   to process SPF macros where often they simply do not implement the
   macro portion of SPF.

   The SPF review documented in [RFC6686] failed to provide a breakdown
   on macro use.  SPF's macros can prove hazardous, especially with
   IPv6.  Rather than permitting receivers to decide their acceptance
   methods, an SPF resource record based on the Mail From parameter can
   induce 100 DNS transactions using labels constructed from random
   strings found in the message local-part.  While recent changes made
   in the current version of SPF recommends against its use, to process
   the reverse namespace may place an extreme burden on DNS, its cache,
   and the SMTP server's connection resources.  Too bad unrelated DNS
   providers where not afforded similar consideration.

   [I-D.ietf-spfbis-4408bis] purports to be documenting current use.  It
   dropped the SPF resource record (99) due to sparse use and recommends
   against reverse PTR use.  If a similar threshold were applied, all
   the SPF macro expansion aspects of this protocol would be removed as
   well.  Several large providers have offered their assurance that
   their SPF libraries had these macros removed.  Any effort hoping to
   define current use MUST carefully reconsider the inclusion of this
   ill-considered macro feature.  Otherwise, it can not be suggested
   SPF-bis simply documents current use.

   Danger imposed by the use of the local-part macro is inherent in the
   query required to support both an IPv6 expansion, in conjunction with
   the expansion of local-part macros induced by possibly cached SPF
   records.  The local-part, along with a range of IP addresses made
   readily possible by IPv6, can be manipulated to induce a flurry of
   large DNS transactions directed toward any otherwise uninvolved
   domain, all directed by cached DNS records that contain active
   content.



Otis & Rand             Expires November 10, 2013              [Page 10]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   It is never a good idea to allow free attacks enabled through foreign
   scripts.  The SPF local-part macro would allow a cached DNS record to
   be repeatedly exploited by a spam campaign with an attacker consuming
   little of their resources beyond what they already use in the
   campaign.  In this case, their recipients change the domains queried
   on behalf of the attackers based upon the same SPF resource record.
   High levels of amplification still apply if SPF specifications are
   not changed and resulting implementation are then assumed part of
   some greater security requirement and are no longer deemed
   experimental.  The SPF macro DOS overview demonstrated in 2006
   [otis-spf-dos-exploit] did not consider IPv6 use which offers higher
   gain, where the gain achieved sending a single 1KB message to a
   single recipient offered a 1:156 reflected gain over IPv4 that can
   never be filtered or blocked by using BCP38 [RFC2827].  When made
   against a wildcard record, even higher gains can be achieved.

   Logically, local-part macros would not safely provide positive
   results without the query being combined with an IP address list of
   SMTP clients in some form.  A list structure would need to be
   repeated for each user.  Rcpt To using schemes like BATV provides an
   expedient way where the purported sender determines whether a NDN can
   be returned without the risk associated with active content placed
   within DNS resource records.  Several parsers ignore local-part macro
   expansion since they rarely play any role in providing positive
   results.

   The [I-D.ietf-spfbis-4408bis] Addendum E indicates a possible use of
   SPF macros such as exists:{%l}._spf.{%d} or exists:{%i}_spf.{%d} can
   be used in "specialized" DNS servers able to understand encrypted
   local-parts or react to inordinate query rates which suggests use of
   resource records having extremely short TTLs.  Such an approach can
   add a sizeable burden on recipients and targeted DNS servers.  Such a
   scheme represents a poor alternative to providing authenticated
   domain identifiers.  The general intent and purpose of SPF is to
   offer Non-Delivery Notification authorization where no macros are
   required and by most practical measure are not being used.

   The Purported Responsible Address (PRA) alternative attempted to
   overcome the relatively high path registration failure rates normally
   experienced with SPF.  Neither scheme offered authenticated domain
   identifiers and left recipients prone to being spoofed by relying on
   authorizations.  DKIM was intended to help solve these related
   spoofing issues, but failed as currently specified.


9.  Domains as a Basis for Managing Traffic

   A manageable basis for assessments can leverage a smaller number of



Otis & Rand             Expires November 10, 2013              [Page 11]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   related domains, compared to IPv6 or even IPv4 addresses.  Although
   technically the domain name space can be larger than the massively
   large IPv6 address space, in practice it is not.  One hundred
   thousand domains control 90% of Internet traffic out of approximately
   100 million domains active each month.  The top 150 domains control
   50% of the traffic, and the top 2,500 domains control 75%.  This
   level of domain consolidation permits effective fast-path white-
   listing.  Improvements achieved using domains to consolidate the
   threat landscape can easily justify added cryptographic
   authentication burdens.  Even APL resource records [RFC3123] can
   authenticate EHLO using a single DNS transaction, but this would not
   allow IPv6 email to be more easily managed, which cryptographic
   technology can offer.


10.  XMPP Shows the Way Forward

   In addition to SMTP [RFC5321] using StartTLS [RFC3207] XMPP [RFC6122]
   uses StartTLS [RFC6120] over a different port with many of the
   features used by web servers such as [RFC2560] as one means to
   increase scalability.  It seems plausible that by defining SMTP
   access over port 465 is where a new authentication and international
   requirements can be resolved together.

   Many administrators overlook a serious problem made much worse by
   chatty protocols that impose processing delays.  Examining server
   logs will not reveal any problem either, because the limited resource
   being consumed is the number of outstanding connections TCP is able
   to support.  Reaching this limit will prevent new connections from
   being instantiated but this is not logged as an event.  Over time
   administrators may hear complaints email is not being delivered or
   just see an ever growing percentage of spam.


11.  IANA Considerations

   This document requires no IANA consideration.


12.  Security Considerations

   This draft intends to describe serious security concerns raised with
   use of IPv6 email.  The contained recommendations are expected to
   reduce the security concerns.







Otis & Rand             Expires November 10, 2013              [Page 12]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


13.  References - Informative

   [I-D.ietf-spfbis-4408bis]
              Kitterman, D., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1",
              draft-ietf-spfbis-4408bis-14 (work in progress),
              April 2013.

   [RFC0733]  Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
              "Standard for the format of ARPA network text messages",
              RFC 733, November 1977.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3123]  Koch, P., "A DNS RR Type for Lists of Address Prefixes
              (APL RR)", RFC 3123, June 2001.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.



Otis & Rand             Expires November 10, 2013              [Page 13]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4408]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
              for Authorizing Use of Domains in E-Mail, Version 1",
              RFC 4408, April 2006.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC4954]  Siemborski, R. and A. Melnikov, "SMTP Service Extension
              for Authentication", RFC 4954, July 2007.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5451]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 5451, April 2009.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [RFC6122]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Address Format", RFC 6122, March 2011.

   [RFC6152]  Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
              Service Extension for 8-bit MIME Transport", STD 71,
              RFC 6152, March 2011.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", RFC 6376,
              September 2011.

   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 6530, February 2012.

   [RFC6531]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
              Email", RFC 6531, February 2012.

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized



Otis & Rand             Expires November 10, 2013              [Page 14]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


              Email Headers", RFC 6532, February 2012.

   [RFC6577]  Kucherawy, M., "Authentication-Results Registration Update
              for Sender Policy Framework (SPF) Results", RFC 6577,
              March 2012.

   [RFC6686]  Kucherawy, M., "Resolution of the Sender Policy Framework
              (SPF) and Sender ID Experiments", RFC 6686, July 2012.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [RFC6854]  Leiba, B., "Update to Internet Message Format to Allow
              Group Syntax in the "From:" and "Sender:" Header Fields",
              RFC 6854, March 2013.

   [otis-spf-dos-exploit]
              http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01,
              "Otis SPF DoS Exploitation", June 2006.

   [spf-all.com]
              http://spf-all.com/stats.html, "SPF-all.com Stats",
              May 2013.

   [v6-BGP-Rpts]
              http://bgp.potaroo.net/v6/as6447/, "BGP Routing Table
              Analysis Reports/IPv6/AS6447 views", May 2013.


Appendix A.  DKIM Examples

From Random User Tue Mar 12 12:07:37 2013
X-Apparently-To: just4spamdlr@yahoo.com via 72.30.237.8; Tue, 12 Mar 2013 12:08:37 -0700
Return-Path: <Fake.user@gmail.com>
Received-SPF: neutral (192.83.249.65 is neither permitted nor denied by domain of gmail.com)
 A3RleHQvcGxhaW4DAzACA3RleHQvaHRtbAMDMQ--
X-YMailISG: Po8J_9cWLDuz5QIo_tChc7OagZYPBIscsK7APx8FMj835hEX
 clyJxoQr6Ojy40ccEugqmkym_ayJu65fKm.KJY73k6aprxb9s7Bj6P32lpml
 6yGzxWFYdNXCwcxHtFGdhKe3v7Tjh8x051jkxjIqfuS0vo8J5rZOr.Z__6vD
 4wiGFDUwFHNUWAwuz_pwp7pZ5HCivuuuyszYVvH0eIFsrQ9crR.rrk_3EQU2
 Xkv_fInlGDFR8fafFPMOgQ7QOrHhy0zQUbptDEFGdh1QVOyLwIpjwEC7264k
 4MqxUH7zz_M5JOQzj6dJslH0.iz5y9Sgp6y6kTUHAVP2f_t1hMeRvf3F7WJ6
 1yY2rZJALIME1CtiNKQJoDctzgGFRnh_5mo415MvUcEIH7qqS5RFgWtXEQpd
 JIpyYlECDXVUcuASoLmzbuGSiCEVLq7f4EiBTAsaMwXJ07OgXBR.QYDw3VfA
 Z0AcfnFrUVHNLZtLaFukQKzdk9c6SpHFHSuCAsvLPuZeRy4Ij5ndXd7viyCS
 IkAHsnhG_u3.nZr3zUDFOrqw8sEKphobj6ZJ8KEXtuhr_tx.94abE1JRJYi5
 fukj2h8y9s.K10ZxoTClaw41_DD8fxESbyfyTRPytiEXUdK1WEjgS3rAZ0TA



Otis & Rand             Expires November 10, 2013              [Page 15]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


 WPJPDr063xLYk20UY0V.N5J15lBCtqZcde_9pdXwxVySyXo1KEQOaH3TNRBZ
 AKMFuCC7NF56aklkiUgk2EWm8iYoHsFez5_HtOz1zmc1dv4mNFOPTaNrXF2X
 qjFiwfdUipupIlAEc6pIdv0_le.xvz1jnaewEOyxo4dKd2XLVvybLfsLY16U
 FzLS9MJJ1wC0Cmf3G2SbOmT4ZiAvPjyv8QnHzbSDDDy3hqg8F0uEE03sJ5dm
 on5FxOHZZ1wCH7DL1QAXpZYxYWKV.h3q69dKQMl6HbnmfT_WZQY4X8uKXqkZ
 o34v.YmvJxHSRCSmhFpug1EstpJ4gHVitl_eJzT_n6xYQwhNAuMZ9uRjN2xE
 1Lf7NpgzRf9bFvOpJAlyLoK5Xvxbx711cMgEUfGIha_JtL1P7hyfncRszHDv
 txgUYzcsVvRyAyVvwDAM.TEBsFhAtqqwOibqo2l5xCBj2yXRbKJ0EOC1JDMs
HA--
X-Originating-IP: [192.83.249.65]
Authentication-Results: mta1225.mail.bf1.yahoo.com from=gmail.com; domainkeys=neutral (no sig);
from=gmail.com; dkim=pass (ok)
Received: from 127.0.0.1 (EHLO rdaver.bungi.com) (192.83.249.65)
by mta1225.mail.bf1.yahoo.com with SMTP; Tue, 12 Mar 2013 12:08:36 -0700
Received: by rdaver.bungi.com
        via smail with stdio
        id <m1UFUYr-00KeXPC@rdaver.bungi.com>
        for Just4spamdlr@yahoo.com; Tue, 12 Mar 2013 12:08:33 -0700 (PDT)
        (Smail-3.2.0.94 1997-Apr-22 #591 built 2011-Feb-5)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:date:message-id:subject:from:to
        :content-type;
        bh=PS9xMxYwwTGwWXbCd8bjBBm2rwb79wVOSDLhmp+k4b4=;
        b=qnYVUccLSAi2DGJdUgDDIP9A3uPk3PaxgqhYLBn6xU382MsCi/ICFgKAoFPuwM7BvL
        AuSuqL6P54cIJ3Pn36h2xmXy+ucNr5r5OqIY63rtvj6Apjr4uW1PzG47J7BGEiP9iwDZ
        PLTzl9ZLpZXvZZpTCJOXUQP2HF8q6aivCblYZIQcCdVRCftG+A4z0+dEyTHbxoAMx9U3
        GFISRRHcZ7k7GAyYmLrSr3fUTjvpa1YWoNK+IcSALC2tKVSW5FP1IQAT07f1e8+bOgHh
        JleaQIw8b1Vjlzhs4hFKLdedmjQqjDJXVP/K3J+t/ggfYn4H547fu6Pb5syKZIiuPf1e
        yJqA==

MIME-Version: 1.0
X-Received: by 10.220.221.143 with SMTP id ic15mr6773333vcb.32.1363115257152;
 Tue, 12 Mar 2013 12:07:37 -0700 (PDT)
Received: by 10.52.70.169 with HTTP; Tue, 12 Mar 2013 12:07:37 -0700 (PDT)
Date: Tue, 12 Mar 2013 09:07:37 -1000
Message-ID: <CA+VnpPKv0s-p2nKkAkNHS4V2SxZehw_6S9QF5p1p2ji+FMof=Q@mail.gmail.com>
Subject: An example signed message
From: Random User <random.j.user.994@gmail.com>
To: just4spamdlr@yahoo.com
Content-Type: multipart/alternative; boundary=14dae9cdc33bb0ff5204d7bf00ff
Content-Length: 280

                         reporting valid signature


From Fake User Tue Mar 12 12:07:37 2013
X-Apparently-To: just4spamdlr@yahoo.com via 72.30.237.8; Tue, 12 Mar 2013 12:09:01 -0700



Otis & Rand             Expires November 10, 2013              [Page 16]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


Return-Path: <Fake.user@gmail.com>
Received-SPF: neutral (192.83.249.65 is neither permitted nor denied by domain of gmail.com)
 A3RleHQvcGxhaW4DAzACA3RleHQvaHRtbAMDMQ--
X-YMailISG: gFqc.ysWLDtqkdjDpSCH39uGWhgFfnsGdWobzNb5os6sP0We
_L38eAdX.VKZWQ2F75gFwoipcPyj4g0uKMm_vSayLjrnps9lBxMGLvtTE8kT
XYxIw6vZb4aFZ_jEcpoRntvJDkZQl4XSGWGakfmJ5G2blTWZ_i1BVkBvj0Sv
jEymvhoIXZTb_l8C0Jh69ot3MgrNBvjhrBmhCK3sziUtDPpKQPJb_lxCnYKN
O0SiArQ_TUXrCRFRNsyEiJxzVfSgJWIdsCV5BN3cp..NZ17X8fguB.YxNQjt
qjVcGMd4IjQioY.a4f1luQxuiCN1yWvYqiLpP6eOCQhMrHt9XOdk32HAXNuJ
GBraVtjrySTl9Db7PpRC46wlMs3iIUHl3z0d4o6293sMA5qFmnbczGoLRGFs
RUVlBJuRoJCSYZh5LOwbj0RPQNX2Nmw.LHwF7SY3XcZWFUjvUQQ2sdx63m_J
Mgy7JHAwBTVH6ytULsbXvu38a5GIYHccfNnDKVjtsrIg9qBDpVASHrRkncL0
MFLy5FHLb_XBW1TPztCFtlRViKr_HFxMob6aZIte6T57AMqlV2YAHwVNObwx
WE8ZWTkKNWbXqJYytd3vyuyAHfuseBFP_Jfmj0zVtg52EXpIlDiTANEOTamP
zeu23QbeRWJd_Gpz9bbGw_OorPdcV.WJOQ29DHpiYAQRgWjJNLjkd8dI.vuM
vs1Fr7LOiE3wRpSU5AW_hrR4anvGrnwSPOQaFmpNE0pl8n.Vomrp.5NU8cgU
QYI1UCSPoE_HK5Som2HMPYZFQv0pJSu1NeitXlRM3DHkIMvW4aVYqrHSNVjl
gGCFFx77c25QW.XAGtySBYWcTzcUlHP4fMa7Wli4u06C4N3pDPiQoXKOC10U
koXUMKFYmedaZYvEeQRPO3_8xHwKyZ.QInDsnQRwPFWYKvcWCJu4c5zxDMG4
h1AsyT3CM80nZXk8.ZGhzfTgo810Xjn_OJVgUfkG1z3..ReN990deaWJY8F5
_j6lRWLZZRzCMwOGpJ6I.jgaN5mNk38Kj6.NYLFCpMTEIt28jIRHD85cfpa3
iOL3drg1TIKQWrEhS9u3H29niQ_hjHbk7ys6uSJvowilRwO8eB2s.Wz0
X-Originating-IP: [192.83.249.65]
Authentication-Results: mta1266.mail.bf1.yahoo.com
from=gmail.com; domainkeys=neutral (no sig);
from=gmail.com; dkim=pass (ok)
Received: from 127.0.0.1 (EHLO rdaver.bungi.com) (192.83.249.65)
 by mta1266.mail.bf1.yahoo.com with SMTP; Tue, 12 Mar 2013 12:09:00 -0700
 Received: by rdaver.bungi.com
        via smail with stdio
        id <m1UFUZI-00KeXRC@rdaver.bungi.com>
        for Just4spamdlr@yahoo.com; Tue, 12 Mar 2013 12:09:00 -0700 (PDT)
        (Smail-3.2.0.94 1997-Apr-22 #591 built 2011-Feb-5)
From: Fake User <fake.user@gmail.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
     d=gmail.com; s=20120113;
     h=mime-version:x-received:date:message-id:subject:from:to
     :content-type;
     bh=PS9xMxYwwTGwWXbCd8bjBBm2rwb79wVOSDLhmp+k4b4=;
     b=qnYVUccLSAi2DGJdUgDDIP9A3uPk3PaxgqhYLBn6xU382MsCi/ICFgKAoFPuwM7BvL
      AuSuqL6P54cIJ3Pn36h2xmXy+ucNr5r5OqIY63rtvj6Apjr4uW1PzG47J7BGEiP9iwDZ
      PLTzl9ZLpZXvZZpTCJOXUQP2HF8q6aivCblYZIQcCdVRCftG+A4z0+dEyTHbxoAMx9U3
      GFISRRHcZ7k7GAyYmLrSr3fUTjvpa1YWoNK+IcSALC2tKVSW5FP1IQAT07f1e8+bOgHh
      JleaQIw8b1Vjlzhs4hFKLdedmjQqjDJXVP/K3J+t/ggfYn4H547fu6Pb5syKZIiuPf1e
      yJqA==
MIME-Version: 1.0
X-Received: by 10.220.221.143 with SMTP id ic15mr6773333vcb.32.1363115257152;
 Tue, 12 Mar 2013 12:07:37 -0700 (PDT)



Otis & Rand             Expires November 10, 2013              [Page 17]

Internet-Draft             IPv6 EMAIL AUTHENT                   May 2013


Received: by 10.52.70.169 with HTTP; Tue, 12 Mar 2013 12:07:37 -0700 (PDT)
Date: Tue, 12 Mar 2013 09:07:37 -1000
Message-ID: <CA+VnpPKv0s-p2nKkAkNHS4V2SxZehw_6S9QF5p1p2ji+FMof=Q@mail.gmail.com>
Subject: An example signed message
From: Random User <random.j.user.994@gmail.com>
To: just4spamdlr@yahoo.com
Content-Type: multipart/alternative; boundary=14dae9cdc33bb0ff5204d7bf00ff
Content-Length: 280

                     spoofed DKIM with valid signature


Appendix B.  Stats

     Total spams:               9438
     DKIM pass:                  688 (about 25% relayed from large ESPs)
     DKIM fail:                  189
     DKIM pass w/multiple from:   28 (about 2% on average)
     Unsigned:                  8561

                     Looking at a few minutes of spam.


Authors' Addresses

   Douglas Otis
   Trend Micro
   10101 N. De Anza Blvd
   Cupertino, CA  95014
   USA

   Phone: +1.408.257-1500
   Email: doug_otis@trendmicro.com


   Dave Rand
   Trend Micro
   10101 N. De Anza Blvd
   Cupertino, CA  95014
   USA

   Phone: +1.408.257-1500
   Email: dave_rand@trendmicro.com








Otis & Rand             Expires November 10, 2013              [Page 18]