Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

Viktor Dukhovni <viktor@dukhovni.org> Wed, 27 February 2019 20:12 UTC

Return-Path: <viktor@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 3530B1310AF; Wed, 27 Feb 2019 12:12:08 -0800 (PST)
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 d1vblf6c6vun; Wed, 27 Feb 2019 12:12:06 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1B11310A8; Wed, 27 Feb 2019 12:12:06 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 9136731251; Wed, 27 Feb 2019 15:12:04 -0500 (EST)
Date: Wed, 27 Feb 2019 15:12:04 -0500
From: Viktor Dukhovni <viktor@dukhovni.org>
To: The IESG <iesg@ietf.org>
Cc: uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org
Message-ID: <20190227201204.GW916@straasha.imrryr.org>
Reply-To: The IESG <iesg@ietf.org>, uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org
References: <155072491254.20210.15187912705241578950.idtracker@ietfa.amsl.com> <290706DA-2C5E-4255-8BB7-C6951B385CD6@dukhovni.org> <20190227193541.GR53396@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190227193541.GR53396@kduck.mit.edu>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/WE8v8c8LCTOIxr00G6ERmAHWTn4>
Subject: Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)
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: Wed, 27 Feb 2019 20:12:08 -0000

On Wed, Feb 27, 2019 at 01:35:42PM -0600, Benjamin Kaduk wrote:

> It seems like implicit in this stance is a belief that DANE and/or MTA-STS
> as currently specified are flawed, in that they do not have a reasonable
> path to substantial deployment (in bounded time).

REQUIRETLS "no", is essential for at least the "postmaster" address
(in the rare cases when that still works), or some address scraped
from the destination domain's website, found in the few WHOIS records
that still list contact addresses, or in a working DNS SOA "mrname".
When all else fails, the user can notify the peer end user on the
receiving domain to contact his postmaster, open a support ticket etc.

Both specifications do a fine job of specifying the recipient's
preferred policy.  No specification, regardless of the details, can
ensure that the recipienet lives up to the promised service level.

DANE, MTA-STS, any superior design or security-theatre-de-jour, will
still lead to cases where security degrades delivery.  At the very
least one needs to be able to exempt delivery to the email address
of the domain contact.

And when all else fails, and the message is just "let's do lunch",
nothing will be more effective than a clear user choice to deliver
anyway.  This a fact of life, and not a defect in DANE or MTA-STS.
The need is intrinsic to multi-hop asynchronous delivery, by providing
the equivalent of the "press OK" to skip various warnings in
end-to-end interactive applications.

If your point is that DANE and MTA-STS should have provided an
end-user opt-out from the outset, maybe so, but I should note that
RequireTLS entered the UTA queue about the same time as MTA-STS,
and with the understanding that the "no" mechanism will be a useful
complement for both MTA-STS and DANE or any other techology which
by defers delivery in the face of apparent active attacks (which
are often simply operational negligence on the receiving end).

-- 
	Viktor.