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 23:33 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 88A673A68D9 for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 15:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.039
X-Spam-Level:
X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=4.560, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 oMUQhDVjctC4 for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 15:32:54 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by core3.amsl.com (Postfix) with ESMTP id 35F8E3A68D4 for <dnsext@ietf.org>; Thu, 3 Mar 2011 15:32:54 -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.pao1.isc.org (Postfix) with ESMTPS id A8723C9427; Thu, 3 Mar 2011 23:32:38 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 02B46216C1E; Thu, 3 Mar 2011 23:32:38 +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 70223BA0FA9; Fri, 4 Mar 2011 10:32:35 +1100 (EST)
To: Alex Bligh <alex@alex.org.uk>
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> <618355BCA39C2F7544D51832@nimrod.local>
In-reply-to: Your message of "Thu, 03 Mar 2011 21:31:23 -0000." <618355BCA39C2F7544D51832@nimrod.local>
Date: Fri, 04 Mar 2011 10:32:35 +1100
Message-Id: <20110303233235.70223BA0FA9@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 23:33:14 -0000

In message <618355BCA39C2F7544D51832@nimrod.local>, Alex Bligh writes:
> --On 3 March 2011 19:39:26 +0000 Tony Finch <dot@dotat.at> 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.

Which is learnt from the MX record (real or synthesised from the A/AAA
records) or manually configured in the case of a smart relay.

> >    -  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
-- 
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