Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 06 May 2018 21:22 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65D012D7F0; Sun, 6 May 2018 14:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l8T5Jvj9vYdE; Sun, 6 May 2018 14:22:21 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476AE120713; Sun, 6 May 2018 14:22:21 -0700 (PDT)
Received: from [10.75.25.89] (CPE00180a4e2dfd-CM00fc8dce3020.cpe.net.cable.rogers.com [174.112.16.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0E8197A3309; Sun, 6 May 2018 21:22:18 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CA+S86mWSNwzG0_y_d=yg8Nqf9gxFud+8TAYWHY3Uw6aqn_JKog@mail.gmail.com>
Date: Sun, 06 May 2018 17:20:57 -0400
Cc: draft-ietf-uta-mta-sts@ietf.org, uta-chairs@ietf.org, The IESG <iesg@ietf.org>, Leif Johansson <leifj@sunet.se>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5B103C6-4A18-4013-95DB-70C2C180871C@dukhovni.org>
References: <152539648489.11713.7895583526344282774.idtracker@ietfa.amsl.com> <CANtKdUeK_HpOYsP-CfhF7m7-DYiSX39xTMLxqZw-1UQsn29xyQ@mail.gmail.com> <78C81C6B-1C5F-4361-A3B7-40D9012E406A@dukhovni.org> <CA+S86mWSNwzG0_y_d=yg8Nqf9gxFud+8TAYWHY3Uw6aqn_JKog@mail.gmail.com>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/K8k0Os7Uie42L6QSE9MVIeLY-wM>
Subject: Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 May 2018 21:22:23 -0000


> On May 6, 2018, at 3:44 PM, Daniel Margolis <dan@af0.net> wrote:
> 
> I don't believe that pre-filtering the MX candidate list is the only way to do it. You could leave the loop as-is and just refuse to connect to (i.e. treat as a transient connection failure) any candidate which fails the policy validation. So this is an implementation question; modifying loop pre-filtering is probably riskier than what we might call "connection early termination", but both are compliant with the protocol. 

It makes a difference with a "testing" policy.  Should mail be sent via
an MX host not listed in the policy, or should it be skipped?  With
"testing" the mail should probably go out, with a report of the authentication
failure (impossible success given unexpected MX name) sent per any "tlsrpt"
policy.

So at least "testing" should probably use all the MX hosts.  Whether "enforce"
does or does not is then a question of whether doing it differently for the
two cases is a potential source of confusion/bugs, and prominent anti-loop
warnings.

There are even some domains where connecting to the backup MX host *before*
trying a connection to the primary will cause firewall rules to be dynamically
added to block the client!

-- 
	Viktor.