[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
In message <alpine.LSU.2.00.1111141302170.30178@xxxxxxxxxxxxxxxxxxxxxx>, Tony Finch writes:
> Carl S. Gutekunst <csg@xxxxxxxxxxx> 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.
example.net MX 0 mail.example.net
*.example.net MX 0 mail.example.net
(Implict MX "example.net MX 0 example.net")
Without MX and with CNAME
example.net CNAME example.com
(Implict MX "example.net MX 0 example.com")
All the zones involved above are DNSSEC signed with secure delegations.
> f.anthony.n.finch <dot@xxxxxxxx> 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@xxxxxxx