From: Tony Finch [mailto:fanf2(_at_)hermes(_dot_)cam(_dot_)ac(_dot_)uk] On
Behalf Of
A matter that is close to my heart :-)
Why did this draft not get any further?
http://www.watersprings.org/pub/id/draft-hall-email-srv-02.txt
Looking back at something I wrote a year ago, I said that SRV
records don't provide higher-level settings, such as security
requirements. The email configuration problem is much more
than just typing in the right host names and port numbers:
MUAs are generally dreadful at configuring themselves
securely using the in-band capabilities listed by the servers.
(e.g. whether to use TLS, what SASL mechanism to use, etc.)
without detailed hand-holding from the user.
In fact it would be pretty simple for an MUA to configure
itself given just an email address and some intelligent
guesses, falling back to asking the user for more information
if the guesses fail. The intelligent guesses are just based
on informal host naming conventions (i.e. imap.domain,
smtp.domain, etc.) and standard port numbers, which together
make SRV redundant.
That is entirely do-able, all it takes is a policy record to describe the
configurations for the service.
Let us begin by assuming that DNSSEC is in place. It follows in this
circumstance that the DNS is a good place to ask for authoritative answers to
questions that might otherwise lead to a downgrade attack.
_submission._tcp.example.com SRV 1 1 587 submit1.example.com
_submission._tcp.example.com SRV 1 1 587 submit2.example.com
_submission._tcp.example.com TXT "v=submission
STARTTLS=_certroot.example.com SMTP-AUTH=Required"
_certroot.example.com TXT "v=keyrecord
sha1=a12w22wj2j1j2k1k12i1wd76123=="
_mx._tcp.example.com TXT "v=mx STARTTLS=_certroot.example.com"
_pop3._tcp.example.com SRV 1 1 110 pop1.example.com
_pop3._tcp.example.com SRV 1 1 110 pop2.example.com
These records state that two servers support the SUBMIT protocol with equal
weight - we have fault tolerance on our outgoing email submissions - hurray!
The next records are policy records. The first element in each one is simply
there to ensure that wildcarded records do not get accidentally misinterpreted.
The first policy record states that with the SUBMIT protocol for the specified
service the STARTTLS is always offered with a certifcate that chains to a root
specified in the _certroot record. SMTP-AUTH is required.
The second policy record gives the digest value of the certificate root. It
could also include a link to the root itself. This is not necessary in the case
of TLS as the root is exchanged inband.
The third record gives the same information for SMTP. Note that even though the
certificate is almost certainly different it would normally chain to the same
root. We could however skip the certificate hierarchy stuff and simply use self
signed certs and hardcode in their hash values.
For a minimal upfront effort the network admin has enabled his customers using
aware clients to automatically configure themselves without the need for the
user to find out arcane facts about their network that they need never know.
We also have a much more robust configuration since it has the potential to
support fault tolerance and load balancing.
What we do not do in this example is to support a particular feature that some
people have in their email systems whereby the mail system is partitioned and
different users will receive different answers to the question.
One way that this could be fudged which I will mention only so that a troll
does not patent it is that the DNS server might observe who is asking the
question and return a different answer. This is possible in a heavily
partitioned network. In particular it works if you have a multiply partitioned
VLAN with different user classes separated out into different IP address spans.
This is pretty natural in fact if you do this since you will almost certainly
have separate DNS infrastructure for each segment in any case.
Another way which you might want to get into for a large organization (50K +
users) would be to have a dynamic protocol so that the user could query for the
particular servers they should use. This type of feature was certainly demanded
round the time of the Hall draft but I don't think it should be considered a
requirement, it is really a corner case. Very large (500K+) user ISPs have
already solved this problem with multi-level architectures.
This is a principled architecture and an extensible one.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf