In message
<alpine(_dot_)LSU(_dot_)2(_dot_)00(_dot_)1111141302170(_dot_)30178(_at_)hermes-2(_dot_)csi(_dot_)cam(_dot_)ac(_dot_)uk>,
Tony Finch writes:
Carl S. Gutekunst <csg(_at_)alameth(_dot_)org> wrote:
RFC 3207 punts on the issue of certificate verification. Is there any
interest
in a rigorous specification for certificate verification in SMTP/STARTTLS ?
Is
this the appropriate WG for such a discussion?
I am interested.
STARTTLS as it is currently used is fine for message submission, but it
could do with a more precise specification.
For inter-domain SMTP, STARTTLS is hopeless because the majority of MX
server certificates cannot be verified, as Carl has previously described
on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html
So we need something that allows MXs to say explicitly, "please strictly
verify my certificate". For this to be any use it needs downgrade
prevention, which probably requires a declaration in the DNS protected
with DNSSEC.
There is also the problem of which identity is to be verified. There is no
point verifying the MX target host name unless the recipient's DNS zone is
signed and the sender's MTAs are doing DNSSEC validation.
If you prefer to avoid requiring DNSSEC, you must verify the recipient
mail domain. In this case you have a much greater need for some kind of
support for server certificate selection (either SNI in TLS or perhaps a
new ESMTP TLS service extension), and you have to decide how to deal with
messages that have recipients at multiple different domains on the same MX
target server. This is all rather complicated and messy.
We have RFC's which say that the target of the MX record should be
the canonical name of the server. We have RFC's which allow us to
validate as secure MX records (implicit and explict). DANE is
looking at signalling that secure services for a port exist. We
have everything in these RFCs / drafts to do STARTTLS in general
rather than just submission and avoid downgrade attacks.
With MX
example.net MX 0 mail.example.net
_25._tcp.mail.example.net TLSA
mail.example.net A
mail.example.net AAAA
Wildcard MX
*.example.net MX 0 mail.example.net
_25._tcp.mail.example.net TLSA
mail.example.net A
mail.example.net AAAA
Without MX
example.net A
example.net AAAA
_25._tcp.example.net TLSA
(Implict MX "example.net MX 0 example.net")
Without MX and with CNAME
example.net CNAME example.com
example.com A
example.com AAAA
_25._tcp.example.com TLSA
(Implict MX "example.net MX 0 example.com")
All the zones involved above are DNSSEC signed with secure delegations.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
Lundy, Fastnet, Irish Sea: East or southeast 5 to 7, decreasing 4 at times.
Moderate or rough, occasionally very rough in Fastnet. Fair. Moderate or good,
occasionally poor later.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org