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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 27 February 2015 07:58 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E231A905F for <ietf@ietfa.amsl.com>; Thu, 26 Feb 2015 23:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHnsvpAqnies for <ietf@ietfa.amsl.com>; Thu, 26 Feb 2015 23:58:15 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06281A905D for <ietf@ietf.org>; Thu, 26 Feb 2015 23:58:15 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4317B282FC0; Fri, 27 Feb 2015 07:58:14 +0000 (UTC)
Date: Fri, 27 Feb 2015 07:58:14 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Message-ID: <20150227075813.GT1260@mournblade.imrryr.org>
References: <20150223153757.GI1260@mournblade.imrryr.org> <20150223155241.GJ1260@mournblade.imrryr.org> <tsl8ufoh9ko.fsf@mit.edu> <2DF7230C-D1D8-4B21-9003-B336108A38CB@vpnc.org> <20150224172649.GX1260@mournblade.imrryr.org> <tslvbircj0d.fsf@mit.edu> <0325DF3F-17F3-4400-BDEA-EDB5334BF35C@frobbit.se> <20150225180227.GT1260@mournblade.imrryr.org> <tsla901akgu.fsf@mit.edu> <16ABF6B9-F113-4A1F-8816-EE041CCF4C4B@frobbit.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <16ABF6B9-F113-4A1F-8816-EE041CCF4C4B@frobbit.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/7QTYv4r-WiEX8iKvh5SgiXULElE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Feb 2015 07:58:18 -0000

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@mit.edu> 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@frobbit.se

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.