Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)
Viktor Dukhovni <viktor@dukhovni.org> Thu, 28 February 2019 04:21 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 B904F1274D0; Wed, 27 Feb 2019 20:21:38 -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 blYvGRG1LmxR; Wed, 27 Feb 2019 20:21:36 -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 261391294FA; Wed, 27 Feb 2019 20:21:35 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 49EBE318DA; Wed, 27 Feb 2019 23:21:33 -0500 (EST)
Date: Wed, 27 Feb 2019 23:21:33 -0500
From: Viktor Dukhovni <viktor@dukhovni.org>
To: uta@ietf.org
Cc: uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, The IESG <iesg@ietf.org>
Message-ID: <20190228042133.GZ916@straasha.imrryr.org>
Reply-To: uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, The IESG <iesg@ietf.org>
References: <155072491254.20210.15187912705241578950.idtracker@ietfa.amsl.com> <7061cefb-0f2d-5257-e10c-95be14a7413f@bluepopcorn.net> <20190227201137.GS53396@kduck.mit.edu> <20190227202659.GX916@straasha.imrryr.org> <20190228021819.GY53396@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190228021819.GY53396@kduck.mit.edu>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/jeftTWuEOvpKpwcpBD_0evdUk44>
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: Thu, 28 Feb 2019 04:21:39 -0000
On Wed, Feb 27, 2019 at 08:18:19PM -0600, Benjamin Kaduk wrote: > > With MTA-STS, yes, the name would have to match the certificate. > > (Which makes deployment more difficult in some use-cases, but > > c'est la vie). > > Section 2 has this nice note about "MUST verify successfully using DANE as > specified in RFC 7672". I am demanding an equivalent level of > specification for the previous clause, about "verify successfully in a > trust chain leading to a certificate trusted by the SMTP client", which > sadly lacks a current single comprehensive reference. What's happening here is that there are three ways to satisfy the authenticated delivery requirements, the last of which could perhaps be made more explicit, even if largely obvious from context: 1. DANE per RFC7672 2. MTA-STS per RFC8461 3. DNSSEC-validated MX records + WebPKI authentication of the MX host. The reason 3 is new with this specification, is that both DANE and MTA-STS are opportunistic security, to be used when supported by the peer and enabled at the sending system, but otherwise messages are sent with "traditional" unauthenticated opportunistic TLS, (perhaps even cleartext). DANE and MTA-STS therefore first and foremost provide a more robust way to signal that TLS should be available, and only then about how to authenticate the peer over that expected (STARTTLS) channel. With "RequireTLS yes", the signal that TLS should be expected, is no longer needed, it is instead provided by the sender. Which leaves just the authentication part, which is not viable unless the MX hostname can be obtained securely. But once the MX hostname is not subject to forgery, authentication is just basic WebPKI. Which means that absent DANE, the peer can be authenticated either once DNSSEC provides a tamper-resistant MX RRset, or MTA-STS validates the MX RRset out of band (HTTPS). So one way to frame the sender's decision-tree is: 1. If the MX RRset is not DNSSEC validated, use MTA-STS 2. Otherwise if the current MX host has no TLSA records, do WebPKI by the book with the MX hostname as the reference identifier. 3. With both DNSSEC and TLSA records present, do DANE. What's new here is the second possibility which is not covered by any previous SMTP security specification. > > There is no implicit TLS for MTA-to-MTA relay, and none in the > > foreseeable future, so this issue is moot. > > So why can't (4) use the string "STARTTLS" and be less confusing to the > reader? No objections if you feel that's less confusing, either way it is STARTTLS. FWIW, I did not take into account the possibility of some sort of local policy for a particular destination that routes email via an alternate port (not 25) possibly via an SSH tunnel, implicit TLS or IPSec, etc. Such arrangements are rare, but an exhaustive list of all the various encrypted channels is difficult to compile. Also, what are the requirements for authenticating an SSH tunnel or an IPSec tunnel? -- Viktor.
- [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-… Benjamin Kaduk
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Viktor Dukhovni
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Jim Fenton
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Viktor Dukhovni
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Jim Fenton
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Viktor Dukhovni
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Viktor Dukhovni
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Viktor Dukhovni
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Viktor Dukhovni
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Viktor Dukhovni
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Jeremy Harris
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Jim Fenton
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Jim Fenton
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Viktor Dukhovni
- Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk