Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 27, 2015 at 08:09:22AM +0100, Patrik F?ltstr?m wrote:

> > On 25 feb 2015, at 19:56, Sam Hartman <hartmans-ietf@xxxxxxx> wrote:
> > 
> > I disagree that SRV or MX introduces similar complexity into standards.
> 
> Sam, I feel I need to understand this.
> 
> For MX, you have to start with a URI like this:
> 
> mailto:paf@xxxxxxxxxx

MTAs don't work with URIs.  Those are for occasional use by MUAs,
which don't use MX records.  MTAs (as SMTP relays) deliver mail to
a nexthop domain to another MTA found in the domain's MX RRset.

> One look up the MX for frobbit.se and get mail.frobbit.se

Most MTAs servers either do not support TLS at all, or do opportunistic
TLS in which there is simply no effort to authenticate the peer.

    https://tools.ietf.org/draft-ietf-dane-smtp-with-dane-14#section-1.3

That document explains why SMTP transport security is fundamentally
dependent on DNS security, and why scalable TLS security for SMTP
requires DANE.  We accept redirection and detail the consequences.

Some MTAs "go though the motions" of pretending to do TLS
authentication, but get it wrong by verifying either the hostname
from an insecure DNS MX lookup or worse.

Other MTAs offer reasonably secure TLS configurations, but this
requires that the peer server has the nexthop domain in its
certificate or (and generally in any case) bilaterally negotiated
security settings.

    http://www.postfix.org/TLS_README.html#client_tls_limits
    http://www.postfix.org/TLS_README.html#client_tls_levels
    http://www.postfix.org/TLS_README.html#client_tls_secure
    http://www.postfix.org/TLS_README.html#client_tls_policy

> One then open an SMTP connection to mail.frobbit.se, and can use TLS where
> the cert is compared to mail.frobbit.se.

Except that this is not done in MTAs written by people with clue,
and is known to be insecure ("going through the motions").

> To me that is a change of a domain name given data in DNS.

That's the naive model, but it is wrong.

-- 
	Viktor.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]