SMTP security via opportunistic DANE TLS
draft-dukhovni-smtp-opportunistic-tls-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Viktor Dukhovni | ||
| Last updated | 2013-05-18 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dukhovni-smtp-opportunistic-tls-00
DANE V. Dukhovni
Internet-Draft Unaffiliated
Intended status: Experimental May 18, 2013
Expires: November 19, 2013
SMTP security via opportunistic DANE TLS
draft-dukhovni-smtp-opportunistic-tls-00
Abstract
This memo describes an experimental protocol for opportunistic TLS
security based on the DANE TLSA PKI. The design goal is an
incremental transition of the Internet email backbone (MTA to MTA
SMTP traffic) from today's unauthenticated and typically unencrypted
connections to TLS encrypted and authenticated delivery when the
client is DANE TLSA aware and the server domain publishes DANE TLSA
records for its MX hosts. This protocol has been implemented by
author in the Postfix MTA. It is hoped that other MTA
implementations will find this protocol well suited to their needs
and will adopt interoperable implementations. This protocol may be
suited to other use-cases for opportunistic TLS beyond SMTP, but such
use-cases are not covered here, and will need to be defined in
separate specifications.
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-
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 19, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dukhovni Expires November 19, 2013 [Page 1]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. SMTP Channel Security . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Opportunistic TLS discovery . . . . . . . . . . . . . . . . . 5
3. Locating TLSA records . . . . . . . . . . . . . . . . . . . . 7
4. PKIX certificate usages . . . . . . . . . . . . . . . . . . . 8
4.1. Certificate usage 1 . . . . . . . . . . . . . . . . . . . 9
4.2. Certificate usage 0 . . . . . . . . . . . . . . . . . . . 9
5. Opportunistic TLS for Submission . . . . . . . . . . . . . . 10
6. Hardening opportunistic DANE TLS . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
1.1. Background
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. DNSSEC
is defined in [RFC4033], [RFC4034] and [RFC4035].
As described in the introduction of [RFC6698] TLS authentication via
the existing public CA PKI suffers from an over-abundance of trusted
certificate authorities capable of issuing certificates for any
domain of their choice. DNS-Based Authentication of Named Entities
(DANE) leverages the DNSSEC infrastructure to publish trusted keys
and certificates for use with TLS via a new TLSA record type. DNSSEC
validated DANE TLSA records yield a new PKI designed to augment or
replace the trust model of the existing public CA PKI.
In the context of this memo channel security is assumed to be
provided by TLS. The Transport Layer Security (TLS) protocol
provides communications privacy over the Internet. Used without
Dukhovni Expires November 19, 2013 [Page 2]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
authentication, TLS provides protection only against eavesdropping.
With authentication, TLS also provides protection against man-in-the-
middle (MITM) attacks. Since the publication of the TLS 1.0
specification in [RFC2246], two updates to the protocol have been
published: TLS 1.1 [RFC4346] and TLS 1.2 [RFC5246].
1.2. SMTP Channel Security
With SMTP neither the recipient address, nor the MX records directly
imply or preclude delivery via TLS. The same SMTP TCP endpoint can
serve both TLS and non-TLS clients, with TLS negotiated via the SMTP
STARTTLS command ([RFC3207]).
An MTA may need to forward a message to a particular email recipient
<user@example.com>. To deliver the message the MTA needs to retrieve
the MX hosts of example.com from DNS, and then deliver the message to
one of these. Absent DNSSEC the MX lookup is vulnerable to man-in-
the-middle and cache poisoning attacks. As a result, securing
delivery by verifying the authenticity of the MX host is futile as
the attacker can simply forge DNS replies.
One might try to harden STARTTLS with SMTP against DNS attacks by
requiring each MX host to posess an X.509 certificate for the
recipient domain which is obtained from the message envelope and is
not subject to DNS reply forgery. Unfortunately, this is impractical
as email for many domains is handled by third parties, which are not
in a position to obtain certificates for all the domains they serve.
Deployment of SNI (see [RFC3546] Section 3.1) is no panacea, since
the key management is too difficult unless the email service provider
is also the domain's registrar and its certificate issuer; this is
rarely the case for email.
A man-in-the-middle can also suppress the MX host's STARTTLS EHLO
response. Unless the sending MTA is statically configured to use TLS
for mail sent to example.com, the message will be sent in the clear.
Sender-side configuration of peer-domains for which TLS must be used,
can protect an organization and a few of its business partners, but
is not a viable approach to securing the Internet email backbone.
Dukhovni Expires November 19, 2013 [Page 3]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
Since with the existing public CA PKI neither the recipient domain,
nor the MX hostname are suitable SMTP server authentication
identities, large scale deployment of authenticated TLS based on this
PKI is not possible in the context of MTA to MTA SMTP. SMTP secure
channels authenticated via the public CA PKI are used by a handful of
domains that make bilateral arrangements with their business
partners. At this time, MTA to MTA traffic between Internet
connected organizations typically does not use TLS at all, or uses
TLS opportunistically without authentication, for protection only
against passive eavesdropping.
Note, the above is does not apply to submission [RFC6409], where a
mail user agent is pre-configured to send all email to a fixed
submission server. Submission servers typically offer TLS and the
MUA can be statically configured to use TLS with its submission
server of choice. The situation changes with (as yet not widely
deployed) submission configured dynamically via SRV records (see
[RFC6186] Section 6). We'll discuss applications to submission via
SRV records later in this memo.
With no incentive to use the existing public CA PKI, MX hosts that
support STARTTLS often use self-signed or private-CA issued X.509
certificates, are not configured with a comprehensive list of trusted
CAs and do not check CRLs or implement OCSP. In essence they don't
and can't use the existing public CA PKI. This is not simply a
result of complacency on the part SMTP server administrators and MTA
developers. Nor is it just a result of the relative maturity of the
SMTP infrastructure (as compared to the then young HTTP) when TLS was
introduced. Rather, as we've explained, the use of DNS MX records in
SMTP limits the use of public CA PKI with SMTP to a small set of
sender-configured peer domains.
This does not mean that the Internet email backbone cannot benefit
from TLS. The fact that transport security is not explicitly
specified in either the recipient address or the MX record means that
new protocols can furnish out-of-band information to SMTP, making it
possible to discover both which peer domains support secure delivery
via TLS and simultaneously how to verify the authenticity of the
associated MX hosts. The first such mechanism that can work an
Internet scale is DANE TLSA, but use of DANE TLSA with MTA to MTA
SMTP must be cognizant of the lack of any realistic role for the
existing public CA PKI.
Dukhovni Expires November 19, 2013 [Page 4]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
1.3. Terminology
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. Opportunistic TLS discovery
This section describes opportunistic TLS security, where traffic from
DANE TLSA aware SMTP clients to domains that implement DANE TLSA
records in accordance with this memo is secure, while traffic to
other domains continues to be sent in the same manner as before. It
is hoped that over time more domains will implement DNSSEC and
publish DANE TLSA records for their MX hosts. This will enable an
incremental transition of the email backbobe to authenticated TLS
delivery.
Since email addresses and MX hostnames (or submission SRV records)
neither signal nor deny support for TLS by the receiving domain, it
is possible to use DANE TLSA records to securely signal TLS support
and simultaneously to provide the means by which SMTP clients can
successfully authenticate legitimate SMTP servers.
The following requirements suffice to enable secure opportunistic
TLS:
o When in addition to the TLSA query made by the SMTP client, each
DNSSEC lookup, (e.g. MX, SRV or CNAME) used to obtain the TLSA
base domain is DNSSEC validated, and at least one TLSA record is
found (even if not usable) the client SHOULD assume the server to
be TLS capable.
o When at least one usable TLSA record is found, the client SHOULD
use TLSA records to authenticate the server, in which case the
client MUST send the TLS SNI extension containing the TLSA base
domain to elicit the correct certificate chain from the server.
The client MUST NOT expect the server to confirm the extension.
o SMTP servers for which DANE TLSA records are published MUST
support TLS 1.0 or later with any client authorized to use the
service.
o Each SMTP server MUST present a certificate trust chain (see
[RFC2246] Section 7.4.2) that matches at least one of the TLSA
records. The server MAY rely on SNI to determine which
certificate chain to present to the client. Clients that don't
send SNI information may not see the expected certificate chain.
Dukhovni Expires November 19, 2013 [Page 5]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
o If the server's TLSA RRset includes records with a matching type
other than "0" (that is digest records), the SHA-256 digest of any
object SHOULD be provided along with any other digest published,
since clients may not support SHA-512.
o If the server's TLSA records match the server's default
certificate chain, the server need not support SNI, and is need
not acknowledge the extension, simply returning a matching
certificate chain is sufficient. Servers MUST NOT enforce the use
of SNI by clients, if the client sends no SNI extension, or sends
an SNI extension for an unsupported domain the server MUST simply
use its default certificate chain. The client may be using
unauthenticated opportunistic TLS and may not expect any
particular certificate from the server.
o The client may even even offer to use anonymous TLS ciphersuites
and servers SHOULD support these, no security is gained by forcing
the use of a certificate the client will ignore. Indeed support
for anonymous ciphersuites in the server makes audit trails more
useful if the chosen ciphersuite is logged, as this will in many
cases record which clients did not care to authenticate the
server. (The Postfix SMTP server supports anonymous TLS
ciphersuites by default, and the Postfix SMTP client offers these
at its highest preference when server authentication is not
applicable).
With other protocols where TLS is negotiated separately from the
associated PKI (existing public CA vs. DANE), servers need to be
compatible with two different PKI systems mechanisms and clients need
to be prepared for servers that may not fully support the PKI they
intend to use. In the protocol defined in this memo both the TLS
support implied by the presence of DANE TLSA records and the
verification parameters necessary to authenticate the TLS peer are
obtained together, therefore authentication via this protocol is
expected to be robust.
When a server is assumed to support TLS, but all TLSA records are
unusable, the client SHOULD either establish an unauthenticated TLS
session or use any other sufficiently robust authentication mechanism
at its disposal (possibly the existing public CA PKI). A DANE-aware
client SHOULD NOT make unecrypted connections to such a server.
When usable TLSA records are available, a client SHOULD NOT make use
of a server connection that fails to match at least one TLSA record.
We say SHOULD not MUST in the case of the client, since clients may
incrementally deploy opportunistic DANE TLS only for selected peer
domains. At times clients may need to disable opportunistic DANE TLS
Dukhovni Expires November 19, 2013 [Page 6]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
for peers that fail to interoperate due to misconfiguration or
software defects on either end. For opportunistc DANE TLS to be a
robust protocol, servers MUST live up to their promises, but it is
not possible to compel clients to use a security policy chosen by the
server. We assume instead that given a robust security protocol,
clients will over time choose to adopt it.
3. Locating TLSA records
The party responsible for creating TLSA records for a given service
MUST ensure that at least one of these TLSA records will match either
the server's default certificate chain if SNI is not employed on the
server, or the server's certificate chain when the client signals the
base domain of the TLSA RRset via SNI and a name type of "host_name"
([RFC3546] Section 3.1).
When, for example, the TLSA RRset is published at
_25._tcp.mx1.example.com the base domain is mx1.example.com. At
least one of the TLSA records in the RRset MUST match the server
certificate chain, provided the SMTP client's TLS hanshake included
the SNI extension with a domain of mx1.example.com.
Since the server's ability to respond with the right certificate
chain may be predicated on the TLS client providing the correct SNI
information, DANE PKI aware clients SHOULD send the SNI extension
with a host_name value of the base domain of the TLSA RRset
(otherwise they risk failure to authenticate the server). Since SNI
is not available with SSLv2 or SSLv3, the server MUST support at
least TLS 1.0; ensuring this is the case is the responsibility of the
creator of the TLSA records.
Complications arise when TLSA records for a service are created by
someone other than the server operator. In this situation the server
operator and TLSA record creator must cooperate to ensure that TLSA
records don't fall out of step with the server certificate
configuration.
When the server operator is a hosting provider, the customer's MX
records should contain the primary hostnames of the provider's SMTP
servers. This way, any associated TLSA records will be found in the
hosting provider's DNSSEC zone, thus avoiding the complexity of
bilateral coordination of server certificate configuration and TLSA
record management. If the customer's DNS zone is signed, the
provider hostnames in customer domain's MX records can be securely
used as the base names for locating TLSA records managed by the
hosting provider.
Dukhovni Expires November 19, 2013 [Page 7]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
Redirection of SMTP service from one domain to another is usually
accomplished via MX records (or perhaps SRV records in the case of
submission). Alternatively, the domain part of an email address may
be a CNAME (see [RFC5321] Section 2.3.5). CNAMEs are a more blunt
instrument for this purpose, since unlike MX or SRV records they
remap the origin host to the target host for all protocols. Also
Unlike MX or SRV records CNAME records may chain (though clients will
generally impose implementation dependent maximum nesting depths).
Though CNAMEs are illegal on the right hand side of MX and SRV
records, they are supported by some SMTP software. If the MX or SRV
host is a CNAME alias from a customer's domain to a server in the
provider's domain, the client SHOULD follow the CNAME and SHOULD use
the target hostname as the base domain for TLSA records as well as
the host_name in SNI.
When CNAMEs are employed the sensible place to seek DANE TLSA records
is in the providers domain, as that is the party that best knows
which certificates are deployed on the server. Therefore, clients
implementing opportunistic DANE TLS connecting to a server whose DNS
name is a CNAME alias SHOULD follow the CNAME hop-by-hop to its
ultimate target host (noting at each step whether the CNAME is DNSSEC
validated) and use the resulting target host as the base domain for
TLSA lookups.
If CNAMEs were not followed, to support DANE validation the origin
domain would have to publish TLSA records that match the server
certificate chain. Since the origin domain may not be operationally
responsible for the server this imposes complex operational burdens
on the provider and customer even with SNI.
Accordingly, TLSA records SHOULD NOT be published for a base domain
that is a CNAME. Such TLSA records are not operationally robust, and
MUST NOT be used by opportunistic DANE TLS clients.
4. PKIX certificate usages
Since opportunistic DANE TLS will be used by non-interactive SMTP
agents, with no user to "press OK" when authentication fails,
protocol robustness is paramount. The most robust choice of TLSA
record type for opportunistic DANE TLS is "3 1 1", that is a record
which specifies a SHA-256 digest of the server's public key. This
involves no CA signature checks, and no server name checks, and does
not require SNI when the TLSA record matches the server's default
certificate. It uses the required to support SHA-256 digest, and
works across certificate renewals with the same key. TLSA records
for SMTP servers SHOULD be "3 1 1" records.
Dukhovni Expires November 19, 2013 [Page 8]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
As noted in the introduction, the existing public CA PKI is not
viable for the Internet email backbone. TLSA records for MX hosts or
submission servers that are to be found via SRV records SHOULD NOT
include certificate usage "0" or "1", as clients cannot be expected
to perform [RFC5280] PKIX validation or [RFC6125] identity
verification.
Clients employing opportunistic DANE TLS MAY choose to treat any TLSA
records with certificate usage "0" as unusable. They may then choose
to connect via unauthenticated mandatory TLS if no alternative
authentication mechanisms are available.
If despite this recommendation servers for non-PKIX protocols do
publish TLSA records with certificate usage "0" or "1", clients
SHOULD make use of these to the fullest extent possible.
4.1. Certificate usage 1
SMTP clients that implement this specification SHOULD ignore the PKIX
validation requirement with certificate usage "1", and authenticate
the server per the content of the TLSA record alone. Since some
servers may rely on SNI to select the correct certificate, the client
SHOULD use the SNI extension to signal the base domain of the TLSA
RRset.
4.2. Certificate usage 0
With certificate usage "0" the usability of the TLSA records depends
on its matching type.
If the matching type is "0" the TLSA record contains the full
certificate or full public key of the trusted certificate authority.
In this case the client has all the information it needs to match the
server trust-chain to the TLSA record. The client SHOULD in this
case ignore the PKIX validation requirement, and authenticate the
server via its DANE TLSA records alone (sending SNI with the base
domain as usual).
Dukhovni Expires November 19, 2013 [Page 9]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
If the matching type is not "0", the TLSA record contains only a
digest of the trust certificate authority certificate or public key.
The full certificate may not be included in the server's certificate
chain and the client may not be able to match the server trust chain
against the TLSA record. SMTP clients that implement this
specification SHOULD generally treat such TLSA records as unusable,
but MAY be explicitly configured to support them when it is believed
that the client posesses a sufficiently complete set of trusted
public CA certificates. This is most likely with an MUA which only
needs enough CA certificates to authenticate its chosen submission
service.
5. Opportunistic TLS for Submission
Prior to [RFC6409] the SMTP submission protocol was poster child for
PKIX TLS. The MUA typically connects to one or sometimes a few
submission servers explicitly configured by the user. There is no
indirection via insecure MX records, and unlike the web brower no
need to authenticate a large set of TLS servers. Once TLS is enabled
for the desired submission server or servers, provided the server
certificate is correctly maintained, the MUA is able to reliably use
TLS to authenticate the submission server.
[RFC6409] aims to simplify the configuration of the MUA submission
service by dynamically deriving the submission service from the
user's email address. This is done via SRV records, but at the cost
of introducing the same TLS security problems faced by MTA to MTA
SMTP. Prompting the user when the SRV record domain is different
from the email domain is not a robust solution.
The protocol proposed in this memo can be used to opportunistically
secure the submission service association. If the email domain is
DNSSEC signed, the SRV records are "secure" and the SRV host
publishes secure TLSA records for submission, the MUA can safely
auto-configure to authenticate the submission server via DANE. When
DANE TLSA records are not available, the client SHOULD fall back to
legacy behavior.
6. Hardening opportunistic DANE TLS
An MTA implementing this protocol for sending email to the internet
at large may need a greater security assurance when sending email to
selected destinations to which the sending organization sends
sensitive email and may have regulatory obligations to protect its
content. This protocol is not in conflict with this requirement, in
fact it can often simplify authenticated delivery to such
destinations.
Dukhovni Expires November 19, 2013 [Page 10]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
Specifically, with domains that publish DANE TLSA records for their
MX hosts a sending MTA can be configured to use the receiving
domains's DANE TLSA records to authenticate the corresponding MX
hosts, thereby obviating a complex manual provisioning process. In
anticipation of or in response to failure to obtain the expected TLSA
records the sending system's administrator may choose from a menu of
fallback options if supported by the sending MTA:
o Defer mail if no usable TLSA records are found. This is useful
when the destination is known to publish TLSA records, and lack of
TLSA records is most likely a transient misconfiguration.
o Authenticate the peer via a manually configured certificate
digest. The digest may be a saved copy from a previous successful
TLSA lookup, or may be obtained after a problem is detected and
confirmed to be valid by some out-of-band mechanism.
o Authenticate the peer via the existing public CA PKI, if the peer
server has usable CA issued certificates. In many cases the
sending MTA will need custom certificate name matching rules to
match the destination's gateways.
o Send via unauthenticated mandatory TLS. If the requirement is
merely to always encrypt, and the possibility of MITM attacks is
less of a concern than timely email delivery.
It should be noted that barring administrator intervention email
SHOULD be deferred when DNSSEC lookups fail, (as distinct from
"secure" non-existence of TLSA records, or secure evidence that the
domain is no longer signed). In addition to configuring fallback
strategies when TLSA records are absed administrators may in some
cases need to disable DNSSEC lookups for a destination to work around
a DNSSEC outage.
7. Acknowledgements
Thanks to Tony Finch who finally prodded me into participating in
DANE working group discussions. Thanks to Paul Hoffman who motivated
me to produce this memo and provided feedback on early drafts.
Thanks also to Wietse Venema who created Postfix, and patiently
guided the Postfix DANE implementation to production quality.
8. Security Considerations
This protocol leverages DANE TLSA records to implement MITM resistant
opportunistic channel security for SMTP. For destination domains
that sign their MX records and publish signed TLSA records for their
MX hosts this protocol allows sending MTAs (and perhaps dynamically
Dukhovni Expires November 19, 2013 [Page 11]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
configured MUAs) to securely discover both the availability of TLS
and how to authenticate the destination.
This protocol does not aim to secure all SMTP traffic, that will not
be practical until DNSSEC and DANE adoption are universal (universal
SMTP TLS security via the existing public CA PKI is even less
realistic). The fact that it can be deployed incrementally is a
feature, not a bug. This protocol coexists and interoperates with
the existing insecure Internet email backbone, if the protocol proves
successful, a growing portion of email traffic will be protected over
time.
The protocol does not preclude existing non-opportunistic SMTP TLS
security arrangements, these can continue as before, or may be used
as fallback strategies when this protocol fails to locate the desired
security parameters.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
Dukhovni Expires November 19, 2013 [Page 12]
Internet-Draft SMTP security via opportunistic DANE TLS May 2013
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186, March 2011.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, November 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
Author's Address
Viktor Dukhovni
Unaffiliated
Email: ietf-dane@dukhovni.org
Dukhovni Expires November 19, 2013 [Page 13]