Network Working Group                                         M. Pearson
Internet-Draft                                               F. Hendrikx
                          State Services Commission
                                                                 G. Cant
                                                             Catalyst IT
                                                           December 2005


            SecMX: A standard for increasing MTA-MTA privacy
                draft-pearson-hendrikx-cant-secmx-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Working within the current standards where possible, this document
   presents SecMX: a standard to increase MTA-MTA privacy.

Table of Contents

   1.  Requirements notation
   2.  Background
   3.  Motivation
   4.  SecMX
     4.1.  TLS
     4.2.  Postal mail equivalence
     4.3.  SecMX: Level 1
   5.  SecMX: Level 2
     5.1.  Discovery mechanisms
       5.1.1.  SRV records
   6.  Security Considerations
     6.1.  What SecMX is not
     6.2.  SecMX and DNS
   7.  References
   Authors' Addresses
   Intellectual Property and Copyright Statements


1.  Requirements notation

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


2.  Background

   The New Zealand government has been using secure email since 1999.

   An initial pilot used individual S/MIME secure email clients, with
   users being issued individual digital certificates on smart cards.
   This worked, but had a number of issues:

   o  Content: All content was encrypted to individuals; therefore
      agencies were unable to enforce inappropriate content policies

   o  Accessibility: Vendors could not guarantee a continued long-term
      technical ability to decrypt material; therefore agencies were
      unable to ensure long-term access to encrypted material

   o  Client software variability: The four trial agencies between them
      had 7 different email clients; therefore users found email clients
      behaved differently, creating user support issues

   o  Inconvenience: Users had to unlock the smartcard with a PIN after
      a 30 second timeout

   The project then successfully piloted gateway S/MIME, with gateways
   being issued domain-level digital certificates and securing all
   messages to other participating gateways.

   This infrastructure, called SEEMail, is currently used by more than
   60 government agencies to securely exchange email (and attachements)
   over the Internet.  However the government agencies have found that:

   o  Losing the private key on a gateway causes big issues: all
      incoming email has to be stored until the key can be recovered;

   o  The Certificate Revocation List (CRL) is a central point of
      failure.  Whenever the CRL is unavailable most commercially
      available software simply stops;

   o  The different World views of security and email.  Security often
      implies waiting or stopping until the issue has been clarified;
      email is about speedy delivery;

   o  Commercially available software often has management intensive
      processes (e.g. key loading).  Vendors had to be asked to add
      management features such as auto-discovery and auto-renewal.  This
      is obviously not scalable;

   o  Limited ability to test exceptions.  No certificate authorities
      offered a service to generate broken, corrupt or expired
      certificates to test the behaviour of vendor products.


3.  Motivation

   Government agencies and other organisations want to be able to
   communicate securely with their customers using an email system that
   is equivalent, in terms of security, to postal mail.  More recently
   some agencies have started to create webmail accounts for their
   customers.  The problems inherent in this design are:

   o  A proliferation of mail boxes - imagine a customer that interacts
      with 6 government agencies, they would need to check 6 mail boxes;

   o  The mail boxes are completely under the control of the agencies.
      If the service were removed, you would lose your interaction
      history;

   o  A legal requirement to have sending and receiving email systems
      under separate control, to provide the same legal certainty as
      postal mail.

   In the ideal situation, the government agencies could utilise the
   existing SEEMail infrastructure to conduct secure communications with
   their customers, if their ISPs supported SEEMail.

   However, ISPs who would provide SEEMail infrastructure for agency
   customers are concerned with:

   o  Cost: Who will pay for it?

   o  Experience: Who will implement and maintain it?

   o  Robustness: Will it cause problems and will it scale?

   Clearly, SEEMail is not going to be easily scalable to the Internet
   as a whole.


4.  SecMX

   This section introduces SecMX, a standard that will secure email
   communications between government, business and citizens, without the
   issues of SEEMail.

4.1.  TLS

   In SEEMail, security is gateway to gateway.  Experience with SEEMail
   showed that this model worked exceedingly well.  SecMX is a gateway
   based model, without the limitations of SEEMail.  This RFC proposes
   that TLS is a suitable alternative.

   Why TLS?  It is a gateway based model, operating between SMTP
   servers.

   o  Cost: There are not significant capital costs.  TLS is bundled
      with most operating systems;

   o  Experience: It is already active (slightly more than 10% of 4000
      New Zealand domains tested already had TLS enabled on their SMTP
      servers).

   o  Robustness: TLS is a mature standard and operates transparently to
      secure transport protocols;

4.2.  Postal mail equivalence

   SecMX secures the transport of email, in an analogous way to the
   postal system and paper mail.

   Postal system

      *             >|     |<

      *  Government > Post > Citizen

      *  Government > Post > PO Box > Citizen

   SecMX

      *             >|     |<

      *  Government > Email > Mail Box > Citizen

   In addition, ISPs Mail Box services can be securely accessed using
   POPS and IMAPS or HTTPS for Web based services.

4.3.  SecMX: Level 1

   All MTAs must enable TLS if possible.

   SecMX defines two new behaviours for MTAs:

   Best Effort Sender (BES): A BES will attempt to transfer all email
      securely (SMTP over TLS), but will fall back to standard SMTP if a
      TLS session cannot be established with the receiving server.

   Best Effort Receiver (BER): A BER will prefer to receive mail
      securely (SMTP over TLS), but will also receive email over
      standard SMTP if a TLS session cannot be established with the
      sending server.

   MTAs that support BES and BER will be known as Best Effort SecMX
   servers.


5.  SecMX: Level 2

   Best Effort SecMX servers ensure that messages are sent securely when
   possible (using TLS), however, there are cases when organisations
   want to ensure that a message is only sent if it can be securely
   sent.  SecMX therefore defines another class of MTAs: Secure Only
   SecMX servers.  These support the following:

   Best Effort Sender (BES): A BES will attempt to transfer all mail
      securely (SMTP over TLS).  If an appropriate SOR or BER is found,
      then this is utilised in preference to any standard mail servers.
      Standard mail servers can be used if it fails to find any SecMX
      servers (i.e. transfer the email even if a TLS session could not
      be established with the receiving server).

   Best Effort Receiver (BER): A BER will prefer to receive mail
      securely (SMTP over TLS), but will also receive insecure mail
      (i.e. transfer the email even if a TLS session could not be
      established with the sending server).

   Secure Only Sender (SOS): A SOS will attempt to transfer all email
      securely (SMTP over TLS).  If it cannot find a BER or SOR, it will
      bounce the email.

   Secure Only Receiver (SOR): A SOR will only ever receive mail
      securely (SMTP over TLS) from a SOS or BES.

5.1.  Discovery mechanisms

   Given that a SOR will only ever receive mail securely, it cannot be
   considered a genuine MTA (according to [RFC2487]).  This is because
   the RFC clearly states that publicly-referenced MTAs must not require
   TLS connections.  A SOR cannot therefore be listed in the MX records
   for a domain.

   An additional capability of a SecMX server (SOS or BES) is the
   ability to discover SORs and BESs.

5.1.1.  SRV records

   One mechanism to publish SORs would be to list them in the DNS using
   SRV records (see [RFC2782]).  The SecMX SRV records would have their
   Service field set as "secmx".  The protocol for SecMX will be TCP for
   the forseeable future.  An example SRV record might therefore look as
   follows:

   _secmx._tcp.domain.govt.nz IN SRV 10 10 25 secmail.domain.govt.nz

   Where the SecMX service for domain.govt.nz is provided by the host
   secmail.domain.govt.nz on tcp port 25.


6.  Security Considerations

6.1.  What SecMX is not

   SecMX:

   o  Is not about sender authentication.  SecMX simply assumes that it
      happens (the technology and technique utilised are not important
      to SecMX);

   o  Assumes that the TLS connections are negotiated between the two
      parties;

   o  Assumes both parties are responsible for their own internal
      security;

   o  Assumes that DNS is good enough for now (DNSSEC [RFC4033] is a
      future option).

6.2.  SecMX and DNS

   A DNS hijack could potentially see secure email messages being routed
   to spoofed BERs or SORs.  If this were deemed to be a serious threat,
   upgrading the DNS system to DNSSEC ([RFC4033]) could help to
   alleviate this problem.

7.  References

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

   [RFC2487]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              TLS", RFC 2487, January 1999.

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

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


Authors' Addresses

   Michael Pearson
   State Services Commission
   100 Molesworth Street
   Wellington
   New Zealand

   Email: mike.pearson@ssc.govt.nz


   Ferry Hendrikx
   State Services Commission
   100 Molesworth Street
   Wellington
   New Zealand

   Email: ferry.hendrikx@ssc.govt.nz


   Geoff Cant
   Catalyst IT
   Level 2
   150-154 Willis Street
   Wellington
   New Zealand

   Email: geoff@catalyst.net.nz


Intellectual Property Statement

   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
   http://www.ietf.org/ipr.

   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-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.