Return-Path: 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 132E1126CAD; Tue, 12 Mar 2019 19:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 2aHZ5zX44fcl; Tue, 12 Mar 2019 19:10: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 E20DF1271FF; Tue, 12 Mar 2019 19:10:25 -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 8BE7F302024; Tue, 12 Mar 2019 22:10:23 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 12 Mar 2019 21:47:54 -0400 Cc: uta@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, uta-chairs@ietf.org Reply-To: IESG , uta@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, uta-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <05712735-E4EA-4212-BFC3-3DD58A09DFC9@dukhovni.org> References: <155076162945.8595.2671476533659571699.idtracker@ietfa.amsl.com> <554356ec-de3a-08ed-a920-0397813895e0@bluepopcorn.net> <20190228183553.GA916@straasha.imrryr.org> To: IESG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Uta] Eric Rescorla'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 02:10:28 -0000 > On Mar 12, 2019, at 8:01 PM, Eric Rescorla wrote: >=20 > I'm sorry, but I don't see how any of this is meaningfully different = from the > situation with HSTS. In both cases, the receiving system indicates = that > the sending system ought to use secure transport, and if the sending > system conforms to the specification providing that indication, it is > required to use secure transport. See: > https://tools.ietf.org/html/rfc8461#section-5 The difference is that MTAs with published DANE and MTA-STS policies nevertheless in the majority of cases still accept email not only from senders who don't do DANE or MTA-STS (and use unauthenticated opportunistic STARTLS), but also in cleartext! Unlike HSTS where the port 80 website typically only serve the HSTS policy and a redirect to HTTPS, the MTA's published DANE or MTA-STS policy is an offer of support for security delivery to the sender, it is NOT a mandate. The normative MUSTs in e.g. the DANE SMTP RFC are there to ensure that senders implement DANE correctly *when* they choose to do that, and = don't do something half-baked leading to a false sense of security. There is no expectation that DANE pre=C3=ABmpts sender policy, and MTAs = use whatever rules they have for a particular "envelope" to determine the relevant security policy. The present draft just adds an important signal from the sending user. My perspective on the SMTP security landscape is based on 18 years of Postfix development and a decade as Postmaster at Morgan Stanley where among other activities (email for the Google IPO) I managed mandatory TLS peering with many business partners, and saw first hand what it takes to deal with all the edge-cases. Email is different from the Web, and experience learned in one doesn't always carry over to the other. --=20 Viktor.