> From: Tony Finch [mailto:fanf2@xxxxxxxxxxxxxxxx] 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf