Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Tony F
inch writes:
> On Thu, 3 Mar 2011, Mark Andrews wrote:
> > Tony Finch writes:
> > >
> > > The situation with TLS and SMTP is a mess. Inter-domain SMTP with TLS doe
> s
> > > not work with certificate validation. There is no specification for how t
> o
> > > validate the TLS certificate for an MX server, and it is not obvious what
> > > such a specification should say. In practice the vast majority of deploye
> d
> > > MX TLS certificates cannot be validated, neither against the MX owner nam
> e
> > > nor against the MX target.
> >
> > If you read RFC 821 the HELO response should be used to check that
> > you are talking to the machine you are expecting to.
> 
> RFC 821 is thorougly obsolete. In particular the canonicalization
> requirements that existed in the 1980s were relaxed in the 1990s and no
> longer apply.
> 
> In any case, the server's host name indicators are useless for secure
> server authentication, which is the whole point of TLS.

But they show what *should* be checked.   The MX record also needs 
to be checked.
 
> If I am sending mail to an address at dotat.at, I need to securely verify
> that the server I am talking to is supposed to receive mail for dotat.at.
> So the TLS certificate must authenticate the MX owner name, dotat.at, not
> the MX target mx.cam.ac.uk, nor the virtual service instance name
> ppsw-mx-e.csi.cam.ac.uk nor the physical service machine name
> ppsw-51.csi.cam.ac.uk. If you authenticate the MX target name or the
> server's claimed canonical host name, you are open to attack.

No.  SMTP is store and forward.  The MX records (cryptographically
verifiable with DNSSEC) say that you should be talking to mx.cam.ac.uk
and if you don't get a TLS connection that says you are talking to
that machine you should drop the SMTP connection.
 
> Note that SMTP is able to use one transaction to send a message with
> multiple recipients at different domains hosted on the same server. So the
> server needs to be able to present a certificate authenticating all of the
> mail domains it hosts. The server can't use TLS SNI to select a
> certificate dynamically because SNI only allows one name of each type
> which is incompatible with SMTP's multi-domain transaction support. In
> fact, if the client uses persistent connections it probably does not know
> at the time it negotiates TLS which mail domains it might encounter that
> deliver to the server.

No.
 
> Now perhaps this mess - both the protocol mess and the deployment mess -
> can be fixed by using the firmer foundations that DNSSEC provides, but
> that requires protocol development.
> 
> Tony.
> -- 
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> Fisher: Westerly or northwesterly 3 or 4, occasionally 5, increasing 6 later
> in north. Mainly moderate, occasionally rough later. Fog patches for a time.
> Moderate or good, occasionally very poor.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]