Internet DRAFT - draft-srose-smimelock
draft-srose-smimelock
Network Working Group S. Rose
Internet-Draft NIST
Intended status: Standards Track September 23, 2013
Expires: March 27, 2014
Using Secure DNS to Assert S/MIME Usage
draft-srose-smimelock-00
Abstract
This draft defines and discusses the use of a new DNS resource record
(RR) type to address S/MIME downgrade attacks. The SMIMELOCK RR
allows a domain to convey general message security policy.
Primarily, this RR allows the domain owner to advertise a policy that
all legitimate messages from this domain will be signed by a
verifiable certificate.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [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-
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 March 27, 2014.
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
Rose Expires March 27, 2014 [Page 1]
Internet-Draft S/MIME SMIMELOC RRType September 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The SMIMELOCK Resource Record . . . . . . . . . . . . . . . . . 4
2.1. The SMIMELOCK RDATA Format . . . . . . . . . . . . . . . . 4
2.2. SMIMELOCK RR Example . . . . . . . . . . . . . . . . . . . 4
3. Use of SMIMELOCK Resource Records in S/MIME . . . . . . . . . . 5
3.1. DNSSEC considerations . . . . . . . . . . . . . . . . . . . 5
3.2. Signature Checks . . . . . . . . . . . . . . . . . . . . . 5
3.3. Status Checks . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SMIMELOCK RRType . . . . . . . . . . . . . . . . . . . . . 5
4.2. SMIMELOCK Policy Statement Types . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Rose Expires March 27, 2014 [Page 2]
Internet-Draft S/MIME SMIMELOC RRType September 2013
1. Introduction
1.1. Overview
While it is difficult to change the content of an S/MIME signed
message without detection, it is not difficult to remove the S/MIME
wrapper and change the content of the resulting unsigned message. If
the recipient of the altered message did not know that the message
originally contained a digital signature then there would be no
indication of foul play.
Likewise, attackers masquerading as valid users can send messages
purporting to be from those users. Without digital signatures it is
difficult for the recipient to know whether or not the message was
legitimate.
The introduction of a new DNS record type, SMIMELOCK, provides a
DNSSEC [RFC4033], [RFC4034], and [RFC4035] authenticated mechanism to
enable MUAs to determine whether a message sender's policy was to
digitally sign all messages before sending. Based on SMIMELOCK query
results, each domain is assigned one of two policy states: MUST SIGN
or POLICY UNKNOWN.
To reduce unnecessary DNS queries, the SMIMELOCK policy applies to
all users within a domain (the "right-hand side" of the email
address, called the "domain" in RFC 5322 [RFC5322]).
This proposal is produced in conjunction with a DANE/SMIME proposal,
but the two MAY be used independently. The lock concept is based on
the RLOCK record proposed in draft-gersch-grow-revdns-bgp-02.
[I-D.gersch-grow-revdns-bgp]
1.2. Scope
We limit the scope of this internet draft to associating S/MIME
message signing policy with all users of a given domain. S/MIME
enveloped- only (encrypted) messages provide no data integrity or
source authentication. If a message was wrongly sent in plaintext
then the damage was already done once it was sent. Conversely, if a
message is received without a signature then damage occurs only when
trust or lack of trust is incorrectly assigned to the message.
SMIMELOCK results SHOULD be used only by MUAs processing received
messages. MUAs preparing messages to send SHOULD NOT base message
signature decisions on SMIMELOCK results.
This proposal is limited to authenticating message contents and end-
entity senders. It is distinct and complementary to existing
Rose Expires March 27, 2014 [Page 3]
Internet-Draft S/MIME SMIMELOC RRType September 2013
processes (like SPF [RFC4408] or DKIM [RFC6376] and ADSP[RFC5617]).
2. The SMIMELOCK Resource Record
The SMIMELOCK DNS resource record (RR) is used to convey a domain's
message signing policy to MUAs processing received messages. This
provides the ability for MUAs to identify and flag messages in
violation of their originating domain's advertised signing policy.
The type value for the SMIMELOCK RR type is to be assigned.
The SMIMELOCK RR is class independent.
The SMIMELOCK RR has no special TTL requirements.
A zone MUST NOT contain more than one SMIMELOCK record for the same
owner name.
2.1. The SMIMELOCK RDATA Format
The RDATA of an SMIMELOCK consists of a single octet. The values
have the following meanings:
0: reserved
1: ALL (interpreted as MUST SIGN all messages)
Any result other than ALL is interpreted as POLICY UNKNOWN
Other values (i.e. policies) could be added in the future, but
conditional policies are discouraged as they increase the opportunity
for downgrade attacks.
2.2. SMIMELOCK RR Example
The SMIMELOCK policy applies to all users in a domain (where domain
refers to the "right hand side" of an email address). For example,
to request an SMIMELOCK RR applicable to "alice@example.com", the
QNAME would be "example.com". The query result would apply equally
to any message originator from the example domain (e.g.
"bob@example.com", "chuck@example.com", etc.). A wildcard RR will
extend the policy to cover fictitious subdomains (e.g.
frank@fake.example.com") and individual hostnames in the zone.
SMIMELOCK resource records for the example.com zone:
example.com. IN SMIMELOCK ALL
*.example.com. IN SMIMELOCK ALL
Rose Expires March 27, 2014 [Page 4]
Internet-Draft S/MIME SMIMELOC RRType September 2013
3. Use of SMIMELOCK Resource Records in S/MIME
Use of SMIMELOCK is opt-in by the sending domain and by the receiving
MUA. If a domain owner creates an SMIMELOCK RR, there is no
guarantee that MUAs will check it.
3.1. DNSSEC considerations
Responses for SMIMELOCK RR's SHOULD be disregarded unless the RRSet
passes DNSSEC validity checks. Criteria in [RFC6698] section 4.1 MAY
be used. The absence of a valid SMIMELOCK result (either NOERROR/
NODATA RCODE or SMIMELOCK RR with unknown RDATA values) SHOULD be
interpreted as POLICY UNKNOWN by the client.
3.2. Signature Checks
A compliant MUA MUST check SMIMELOCK status for the domain of each
message received unless the message is S/MIME signed. MUST SIGN
status MAY be cached and re-used up to the life of the SMIMELOCK RR
TTL value. POLICY UNKNOWN status MAY be cached by the MUA for up to
24 hours before issuing a new SMIMELOCK request for the domain.
A compliant MUA MUST flag SMIMELOCK signature policy violations (i.e.
unsigned messages originating from domains with MUST SIGN policy).
Unsigned messages from domains with MUST SIGN policy MUST NOT be
presented to the recipient as free from errors. Unsigned messages
from domains with MUST SIGN policy MAY be presented to the recipient
as having failed signature verification.
3.3. Status Checks
Since this process fails silently, active checks SHOULD be
implemented by administrators of domains and MUAs.
4. IANA Considerations
4.1. SMIMELOCK RRType
This document uses a new DNS RR type, SMIMELOCK whose value [TBD] has
been allocated by IANA from the Resource Record (RR) TYPEs
subregistry of the Domain Name System (DNS) Parameters registry.
Rose Expires March 27, 2014 [Page 5]
Internet-Draft S/MIME SMIMELOC RRType September 2013
4.2. SMIMELOCK Policy Statement Types
This document creates a new registry, "SMIMELOCK Policy Statement
Types". The registry policy is "Specification Required". The
initial entries in the registry are:
Value Short description Reference
----------------------------------------------------------
0 Reserved [this doc]
1 ALL [this doc]
2-255 Unassigned
Applications to the registry can request specific values that have
yet to be assigned.
5. Security Considerations
There is an acknowledged shortcoming in this current proposal that an
attacker need only block or alter the DNS response to disable the
SMIMELOCK capability. However, the ability to affect DNS (signed
with DNSSEC) for a recipient's MUA is considerably more difficult
than sending a spoofed email to the recipient.
This draft also seeks input on the best way to convey signature
policy violations to message recipients. It is possible that a poor
implementation could make matters worse. If a MUA treats a signature
policy violation as a failed signature verification, then it SHOULD
NOT present views of the data in which the message appears to be
signed unless it is clear that the signature verification failed.
6. Acknowledgements
Todd Larsen, Doug Montgomery, and Stephen Nightingale contributed
technical ideas and support to this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M.,
Massey, D., and S. Rose, "DNS Security
Introduction and Requirements",
RFC 4033, March 2005.
Rose Expires March 27, 2014 [Page 6]
Internet-Draft S/MIME SMIMELOC RRType September 2013
[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.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-
Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
7.2. Informative References
[I-D.gersch-grow-revdns-bgp] Gersch, J., Massey, D., Olschanowsky,
C., and L. Zhang, "DNS Resource Records
for Authorized Routing Information",
draft-gersch-grow-revdns-bgp-02 (work
in progress), February 2013.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy
Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RFC5322] Resnick, P., Ed., "Internet Message
Format", RFC 5322, October 2008.
[RFC5617] Allman, E., Fenton, J., Delany, M., and
J. Levine, "DomainKeys Identified Mail
(DKIM) Author Domain Signing Practices
(ADSP)", RFC 5617, August 2009.
[RFC6376] Crocker, D., Hansen, T., and M.
Kucherawy, "DomainKeys Identified Mail
(DKIM) Signatures", STD 76, RFC 6376,
September 2011.
Rose Expires March 27, 2014 [Page 7]
Internet-Draft S/MIME SMIMELOC RRType September 2013
Author's Address
Scott Rose
NIST
100 Bureau Dr.
Gaithersburg, MD 20899
USA
Phone: +1-301-975-8439
EMail: scott.rose@nist.gov
Rose Expires March 27, 2014 [Page 8]
