Re: [Uta] Revised wording on security consideration re TLS-Required

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 30 March 2019 19:05 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 2FC79120253 for <uta@ietfa.amsl.com>; Sat, 30 Mar 2019 12:05:28 -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 xRHoZgMFZHfU for <uta@ietfa.amsl.com>; Sat, 30 Mar 2019 12:05:26 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5700612024D for <uta@ietf.org>; Sat, 30 Mar 2019 12:05:26 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 3C51F58B83 for <uta@ietf.org>; Sat, 30 Mar 2019 15:05:25 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <20190330184458.GF35679@kduck.mit.edu>
Date: Sat, 30 Mar 2019 15:05:24 -0400
Content-Transfer-Encoding: 7bit
Reply-To: uta@ietf.org
Message-Id: <1E84FE7F-EE90-459C-A94F-C161524C2AA8@dukhovni.org>
References: <mailman.116.1553713216.11047.uta@ietf.org> <20190330184458.GF35679@kduck.mit.edu>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/qbyOBXmm5o-QJH05uY6DYUjiEuo>
Subject: Re: [Uta] Revised wording on security consideration re TLS-Required
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 30 Mar 2019 19:05:28 -0000

> On Mar 30, 2019, at 2:44 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> This doesn't really say anything about or give guidance to intermediate
> MTAs.  (Do we want to differentiate between initial and intermediate MTAs,
> too?)

Essentially, all MTAs are intermediate MTAs.  The header is added to the
message via the sender's *MUA*, and conveys the same sender preference to
every SMTP relay (MTA) en-route.  For this header to be effective at
achieving its goal, there needs to be no prior difference between the MSA's
first relay hop and further downstream relays.  TLS-related delivery issues
can occur at any hop along the path from sender to recipient.

The header does obligate every en-route MTA to ignore its local policy.
Where such local policy mandates TLS, it will likely trump the header.
Where the MTA has no explicit policy and would otherwise follow the
hints (DANE or MTA-STS) from the next-hop destination, the header should
generally allow delivery when operational errors would otherwise break
such delivery by promising and not delivering on the requirements of DANE
or MTA-STS.

-- 
	Viktor.