Internet DRAFT - draft-levine-dns-mailbox
draft-levine-dns-mailbox
Network Working Group J. Levine
Internet-Draft Taughannock Networks
Intended status: Experimental September 20, 2015
Expires: March 23, 2016
Encoding mailbox local-parts in the DNS
draft-levine-dns-mailbox-01
Abstract
Many applications would like to store per-mailbox information
securely in the DNS. Mapping mailbox local-parts into the DNS is a
difficult problem, due to the fuzzy matching that most mail systems
do, and the DNS design that only does exact matching. We propose
several experimental approaches that attempt to implement the
required fuzzy matching through DNS queries.
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 23, 2016.
Copyright Notice
Copyright (c) 2015 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
Levine Expires March 23, 2016 [Page 1]
Internet-Draft DNS mailbox September 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of the approaches . . . . . . . . . . . . . . . . . . 3
3. Literal bytes . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Encoded bytes . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Static or Dynamic name servers . . . . . . . . . . . . . 4
4.2. All names valid . . . . . . . . . . . . . . . . . . . . . 5
5. Encoded regular expressions . . . . . . . . . . . . . . . . . 5
5.1. Representing the DFA in the DNS . . . . . . . . . . . . . 6
5.2. Matching a local-part against a DFA . . . . . . . . . . . 7
6. Pointer to server . . . . . . . . . . . . . . . . . . . . . . 7
7. Scaling Issues . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
E-mail mailboxes consist of a local-part (sometimes informally called
left hand side or LHS), an @-sign and a domain name. While the
domain name works like any other domain name, the local-part can
contain any ASCII characters, up to 64 characters long. Mailboxes in
Internationalized mail [RFC6532] can contain arbitrary UTF-8
characters in the local-part, not just ASCII. (The domain name also
can contain UTF-8 U-labels, but the process to translate U-labels to
ASCII A-labels for DNS resolution is well defined and is not further
addressed here.) The DNS protocol is 8-bit clean, other than ASCII
case folding, although some DNS provisioning software does not handle
characters outside the ASCII set very well.
Mail systems usually handle variant forms of local-parts. The most
common variants are ASCII upper and lower case, which are generally
treated as equivalent. But many other variants are possible. Some
systems allow and ignore "noise" characters such as dots, so local
parts johnsmith and John.Smith would be equivalent. Many systems
allow "extensions" such as john-ext or mary+ext where john or mary is
treated as the effective local-part, and the ext is passed to the
recipient for further handling. Yet other systems use an LDAP or
other directory to do approximate matching, so an address such as
john.smith might also match jsmith so long as there's no other
address that also matches.
Levine Expires March 23, 2016 [Page 2]
Internet-Draft DNS mailbox September 2015
[RFC5321] and its predecessors have always made it clear that only
the recipient MTA is allowed to interpret the local-part of an
address:
"... due to a long history of problems when intermediate hosts
have attempted to optimize transport by modifying them, the local-
part MUST be interpreted and assigned semantics only by the host
specified in the domain part of the address." (Sec 2.3.11.)
This presents a problem when attempting to map local-parts into the
DNS, since the DNS only handles exact matchies, and clients cannot
make any assumptions about variants of local parts, and hence cannot
try to normalize variants to a "standard" version published in the
DNS.
This document suggests some approaches to shoehorn local-parts into
the DNS. Since none of them have, to our knowledge, been implemented
they are all presented as experiments, with the hope that people
implement them, see how well the work, and perhaps later select one
of them for standardization.
1.1. Definitions
The ABNF terms "mailbox" and "local-part" are used as in [RFC5321].
2. Summary of the approaches
o Literal bytes: put the local-part directly into the DNS as a name
o Encoded bytes: encode the local-part into names consisting of
letters and digits
o Regex: encode the set of names as a Deterministic Finite Automaton
(DFA) corresponding to a regular expression that matches the valid
names.
o Pointer to server: securely identify an http server that will
handle the lookup.
3. Literal bytes
Since the DNS protocol is mostly 8-bit clean, one can put the local-
part into the DNS as is. The suggested separator is _lmailbox so the
address Bob.Smith@example.com would be represented as:
Bob\.Smith._lmailbox.example.com
Levine Expires March 23, 2016 [Page 3]
Internet-Draft DNS mailbox September 2015
(The \. is the master file convention for a literal dot in a name.)
The maximum length of a local-part is 64 characters, while a DNS name
component is limited to 63, but actual local-parts of 64 characters
are vanishingly rare, and systems with distinct mailboxes with names
that differ only in the 64th character even rarer. It also cannot
distinguish between upper and lower case ASCII characters, but MTAs
that do not treat them the same are also very rare.
This has the benefit of simplicity--the server can directly see
exactly what name the client is looking up. Its disdvantage is that
some provisioning software does not handle names well if they contain
characters outside the usual ASCII printing character set. Its other
characteristics are similar to those for encoded bytes, described
next.
4. Encoded bytes
To avoid problems with characters in DNS names, we can encode the
local-part with a simple reversible transformation that represents
names using the hostname subset of ASCII. To preserve lexical order,
which might be useful, take the local-part, pad it out to 64 bytes
with xFF bytes, which are invalid both in ASCII and UTF-8, and break
the string into two 32 byte chunks. Then encode each chunk as 52
characters in a variant of base32, with each 5-bit section
represented as a character from the sequence 0-9a-v. Then use the
encoded low part, a dot, and the encoded high part as end of the DNS
name. The suggested separator is _emailbox so the address
Bob.Smith@example.com would be represented as:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvg.
89nm4bijdlkn8q7vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvg.
_emailbox.example.com
(The name is is displayed on several lines to make it fit in the
margins, but the actual name is one long string delimited by dots.)
Since many local parts are 32 bytes or less, a simple optimization
would be to omit the low part if it's all encoded 0xff bytes.
4.1. Static or Dynamic name servers
A mail server with a small set of variants could export the names as
either literal or encoded bytes to be served by an ordinary
authoritative DNS server. A mail server with the more typical wide
range of variants could be lashed up to a special purpose DNS server
that recovers the local-part from the literal or encoded bytes,
figures out what key it corresponds to, and synthesizes an key
record, or NXDOMAIN if there isn't one.
Levine Expires March 23, 2016 [Page 4]
Internet-Draft DNS mailbox September 2015
4.2. All names valid
Synthesizing NXDOMAIN responses is likely to be hard, due to the
difficulty of figuring what the valid addresses above and below it
are (or even worse, the NSEC3 hashes.) Also, a static zone with NSEC
is easily enumerated, which would leak the set of mailboxes in the
domain.
A dynamic server has the option of returning a record for every query
for a syntactically valid encoded name, i.e. anything that is two
names of 52 characters from the set [0-9a-v]. If there is no key for
the mailbox (which may mean the mailbox doesn't exist or that it does
exist but doesn't have a key), the key field in the record is zero
length. This makes dynamic DNSSEC somewhat easier, since the server
doesn't have to synthesize NXDOMAIN responses for valid encoded
names, and for other names it is straightforward to compute the
nearest possible encoded names. It also makes it unproductive to try
to enumerate the names in the domain.
5. Encoded regular expressions
Many variant local-parts are easily described using regular
expressions. For example, the local-parts matching "bobsmith" on a
system that ignores ASCII case distinctions and allows dots between
the characters would be described as
"[Bb].?[Oo].?[Bb].?[Ss].?[Mm].?[Ii].?[Tt].?[Hh]". The local-parts
for the address "bob" with optional + extensions would be
"[Bb][Oo][Bb](\+.*)?" For typical variant rules, it is
straightforward to generate the regular expressions, and even for
variants not easily described by patterns, it is possible to
enumerate distinct variants, e.g.
"([Bb][Oo][Bb]|[Bb][Oo][Bb][Bb][Yy]|[Rr][Oo][Bb][Ee][Rr][Tt])".
Regular expressions are equivalent to Deterministitic Finite Automata
(DFA), often called state machines, and algorithms to translate
betwen them are well known. See, for example, chapter 3 of [ASU86].
Lexical analyzer generators such as lex [LESK75] take a collection of
regular expressions and translate them into a DFA that can be used to
match the regular expressions against input strings efficiently in a
single pass through the input string with one lookup per character in
the string. For Unicode text, one can either treat the string as a
sequence of Unicode characters, or a sequence of the octets in the
UTF-8 repreentation, and translate either into a DFA and a state
machine. In the discussion below we assume the machine matches the
octets, but the implementation using charactrs would be very similar.
This approach stores the state machine in the DNS, to allow DNS
clients to efficiently match valid local-parts against the regular
Levine Expires March 23, 2016 [Page 5]
Internet-Draft DNS mailbox September 2015
expression. The state machine in a DFA consists of a set of states,
conventionally identified by decimal numbers. Each state can be a
terminal state, which means that if the input is at the end of the
string, the regular expression has matched. The state also has a set
of transitions, pairs of (octet,state) that tell the DFA to switch to
the given state based on the next input octet.
To match an input string, the client starts at state zero, then uses
each octet in the input string (in this case the local-part) to
choose a next state. If at any stage the octet does not have a
corresponding next state, the match fails. If at the end of the
string, the final state is a terminal state, the match succeeded and
the terminal state identifies which regular expression it matched.
The DFA matcher here is considerably simpler than the one that lex
and similar programs use, since they repeatedly match expressions
against a long string of input to divide it into lexical tokens,
while in this application there is one input string that either
matches or not.
5.1. Representing the DFA in the DNS
Each state in the DFA is represented by a collection of DNS names and
records. We define a new DFA record that contains a single 16-bit
field, which is the state number of the next state. Most records are
of the form:
cc.ddd._rmailbox.example.com IN DFA 123
In this example, ddd is the current state number as a decimal number,
and cc is the hex value of the next octet. Non-terminal states have
a DFA record to identify the next state. Terminal states (which may
also be non-terminal states if one local-part is a prefix of another)
have key records such as SMIMEA.
For wildcard subexpressions, written as "." , the cc is a * DNS
wildcard. The DNS closest encloser rule allows states where a few
characters have specific matches, and everything goes to a default
state, as in situations were a user calls out a few specific address
extensions, e.g. "bob-dnslist" and "bob-jokes" and every other
extension matches "bob-.*". This encoding makes the zone
considerably smaller than it would be if a record for every possible
octet value had to be stored separately.
Once the local-parts are compiled into the state machine records,
they are an ordinary DNS zone that can be served by an ordinary
authoritative server.
Levine Expires March 23, 2016 [Page 6]
Internet-Draft DNS mailbox September 2015
5.2. Matching a local-part against a DFA
Start by turning the local-part into a list of octets. For
traditional ASCII local-parts, the characters are the octets, for
internationalized local-parts the characters are Unicode characters,
which may be represented by several UTF-8 octets. Set the state
number to zero, which is by convention the initial state.
For each octet, create a DNS name using the hex code of the current
octet, the current state and _rmailbox.domain. If this is not the
last octet in the local-part, look up a DFA record to find the next
state. If the DFA record is found, use its value as the next state
and advance to the next octet. If there is no DFA record, stop,
there is no key for this name.
If this is the last octet of the local-part, look up whatever key
record is desired. If it's found, it's the key for the local-part.
If not, there is no key.
As a minor optimization, state number 65535 in a DFA record means a
trailing wildcard that matches the rest of the local-part. This
permits more efficient matching of the common extension idioms such
as "bob+.*" without having to iterate through the octets in the
extension. If a retrieved DFA record contains 65535, the name
matched so the client fetches the key record at the same name.
6. Pointer to server
Rather than trying to encode local-parts into the DNS, publish a
pointer to a per-domain web server that can provide the keys,
identified by URI RR [RFC7553]. Each key type will have to register
a new enumservice [RFC6117] type for naming the URI record, e.g.:
_smimecert._smtp.example.com URI 0 0 "https://keyserver.example.com/
smimecerts"
The URI has to be https, with the name suitably verified by TLSA
certificates. To find a key, take the URI, add "?mailbox={escmbx}"
where {escmbx} is the full ASCII or UTF-8 mailbox name suitably hex
escaped for a URI, and fetch it. The server will either return a
result as application/pgp-keys or application/pkix-cert or other
appropriate type or a 4xx status if there is no key available.
This is certainly slower than a single DNS lookup, but it's
comparable to the sequence of lookups for the DFA encoding, and it's
about the same speed as the subsequent SMTP session to send a
message, so it's probably fast enough.
Levine Expires March 23, 2016 [Page 7]
Internet-Draft DNS mailbox September 2015
7. Scaling Issues
Mail systems vary from tiny home systems with a handful of users to
giant public systems with hundreds of millions of users. Signing and
publishing a zone with one key per user for a large mail system would
likely exceed the capacity of much DNS software. For comparison, the
largest signed zone as of mid-2015 is probably the .COM TLD, with
about 280 million records and 117 million names. Considering the
large size of key records, a zone with one key per user for a large
mail system could easily be an order of magnitude larger. Hence, any
approach that requires putting all of the keys into a static signed
zone is unikely to be practical at scale.
With this in mind, the more promising approaches appear to be encoded
names (Section 4), which offers the possibility of responses
generated from the underlying database on the fly, or pointer to
server (Section 6) going directly to a web service.
8. Security Considerations
Some approaches may make it somewhat easier to extract valid local
parts for a domain. The All Names Valid option makes name searches
unproductive.
The regular expression representation is difficult to reverse
engineer. With NSEC records it's possible to recover the DFA and in
principle to translate it back into a large regular expression, but
there's no efficient way to take the regular expression and extract a
useful set of distinct names. (It's easy to enumerate lots of
variants of the same name, which is not useful to spammers since a
blast of mail to the same recipient is typically shut down in moments
by bulk counters.)
All of the usual attacks against DNS servers are likely to occur.
The usual techniques for mitigating them should work. Many queries
will cache poorly, but probably no worse than rDNS or DNSBL queries
do now.
If PGP or S/MIME keys are published in the DNS, it is unclear what
security assertions the publishing server is making about them. The
server would presumably be saying this is the key for mailbox so-and-
so, but S/MIME and PGP have historically tried to bind keys to users
or organizations, not just mailboxes.
Levine Expires March 23, 2016 [Page 8]
Internet-Draft DNS mailbox September 2015
9. References
9.1. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template, and IANA
Considerations", RFC 6117, DOI 10.17487/RFC6117, March
2011, <http://www.rfc-editor.org/info/rfc6117>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <http://www.rfc-editor.org/info/rfc6532>.
[RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource
Identifier (URI) DNS Resource Record", RFC 7553, DOI
10.17487/RFC7553, June 2015,
<http://www.rfc-editor.org/info/rfc7553>.
9.2. Informative References
[ASU86] Aho, A., Sethi, R., and J. Ullman, "Compilers: Principles,
Techniques, and Tools", 1986.
[LESK75] Lesk, M., "Lex--A Lexical Analyzer Generator", CSTR 39,
DOI 10.1234/567.890, 1975,
<http://dinosaur.compilertools.net/lex/>.
Author's Address
John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://jl.ly
Levine Expires March 23, 2016 [Page 9]
