IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Thu, 03 March 2011 21:31 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E589A3A6864 for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 13:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuwXybajMHaC for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 13:31:01 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 7E48F3A6893 for <dnsext@ietf.org>; Thu, 3 Mar 2011 13:31:01 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id DF88D5F98F0; Thu, 3 Mar 2011 21:31:50 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B91F0216C31; Thu, 3 Mar 2011 21:31:48 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2B252B9FEA4; Fri, 4 Mar 2011 08:31:45 +1100 (EST)
To: Tony Finch <dot@dotat.at>
From: Mark Andrews <marka@isc.org>
References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local><alpine.LSU.2.00.1103031107460.14985@hermes-1.csi.cam.ac.uk> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <alpine.LSU.2.00.1103031148130.14985@hermes-1.csi.cam.ac.uk> <20110303133541.C19B6B9E307@drugs.dv.isc.org> <alpine.LSU.2.00.1103031337570.14985@hermes-1.csi.cam.ac.uk> <20110303144600.11178B9E772@drugs.dv.isc.org> <alpine.LSU.2.00.1103031923050.14985@hermes-1.csi.cam.ac.uk>
In-reply-to: Your message of "Thu, 03 Mar 2011 19:39:26 -0000." <alpine.LSU.2.00.1103031923050.14985@hermes-1.csi.cam.ac.uk>
Date: Fri, 04 Mar 2011 08:31:45 +1100
Message-Id: <20110303213145.2B252B9FEA4@drugs.dv.isc.org>
Cc: Niall O'Reilly <Niall.oReilly@ucd.ie>, dnsext@ietf.org
Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2011 21:31:03 -0000

In message <alpine.LSU.2.00.1103031923050.14985@hermes-1.csi.cam.ac.uk>, Tony F
inch writes:
> On Fri, 4 Mar 2011, Mark Andrews wrote:
> >
> > It makes all the difference in the world.  MX records DO NOT AND NEVER
> > HAVE DEFINED FINAL DELIVER they have only ever defined the NEXT HOP.
> 
> MX record define the inter-domain hop, which is where the mail crosses a
> trust boundary, and where authentication is required.
> 
> The other store-and-forward hops (from submission to outgoing border
> relay; and from incoming border MX to final delivery or to alias
> redirector) are within trust boundaries and so they are easier to
> authenticate.
> 
> > > TLS predates DNSSEC.
> >
> > Yes and it did not work securely because there was no way to validate
> > the DNS responses.
> 
> 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. If TLS validation succeeds the DNS lookup must necessarily have
> given you the right result.
> 
> It isn't possible to use DNSSEC to secure a TCP connection to a server
> because it doesn't verify that no-one has hijacked the IP address. I don't
> know why you keep bringing it up.

BECAUSE YOU CAN'T SECURE INTER SITE SMTP WITH OUT BOTH SECURING THE
MX/A/AAAA LOOKUPS *AND* THE TCP CONNECTION THE SMTP TRANSACTION
GOES OVER.

> Note that these issues are not specific to SMTP: XMPP has similar
> difficulties with s2s authentication.
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Sole, Lundy, Fastnet: Mainly northeasterly 4 or 5, occasionally 6 in Sole.
> Slight or moderate, occasionally rough in Sole and Fastnet. Mainly fair.
> Moderate or good.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email