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

[Alex Bligh <[e-mail]>]

--On 3 March 2011 19:39:26 +0000 Tony Finch <[e-mail]> wrote:

> TLS doesn't try to validate the DNS responses, it verifies that you have
> successfully connected to a server that can act for the domain you wanted
> to reach.

What does "can act for" mean? Any smarthost "can act for" (in the
sense of can deliver mail to" any given domain, but it may require
information for the server to determine whether it "can act" at the
time of TLS (e.g. it might require authentication).

I had thought the purpose of SMTP on TLS was to verify that the
server was the server it claimed to be in the HELO line. Whether
the sending server uses that as a decision point as to whether
to send email on it is pretty much up to the sending server.

>From RFC3207
>    The decision of whether or not to believe the authenticity of the
>    other party in a TLS negotiation is a local matter.  However, some
>    general rules for the decisions are:
>
>    -  A SMTP client would probably only want to authenticate an SMTP
>       server whose server certificate has a domain name that is the
>       domain name that the client thought it was connecting to.
>    -  A publicly-referenced  SMTP server would probably want to accept
>       any verifiable certificate from an SMTP client, and would possibly
>       want to put distinguishing information about the certificate in
>       the Received header of messages that were relayed or submitted
>       from the client.

This is a similar degree of usefulness/uselessness to HTTP certs,
which in the vast majority of cases (DN validated) simply tell you
that the server you are visiting has a certificate purchased
by someone who could receive mail at that domain or administer
the zone. And before we get on our high horses about the usefulness
or otherwise of other cert systems, that's not too much different
from DNSSEC.

-- 
Alex Bligh