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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 13 March 2019 05:15 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 66E88130E1C; Tue, 12 Mar 2019 22:15:33 -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 PSR17A6Z0HHN; Tue, 12 Mar 2019 22:15:31 -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 54E14130DE3; Tue, 12 Mar 2019 22:15:31 -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 33AD130225D; Wed, 13 Mar 2019 01:15:29 -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 <ietf-dane@dukhovni.org>
In-Reply-To: <CABcZeBOGgKCrvqu0B4Xm3LHqRJfiA682CGYnoCv7CoQvcXVfzA@mail.gmail.com>
Date: Wed, 13 Mar 2019 01:15:27 -0400
Cc: uta@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, uta-chairs@ietf.org
Reply-To: IESG <iesg@ietf.org>, uta@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, uta-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <375DF120-E8F1-45AB-A599-2099339CE4D9@dukhovni.org>
References: <155076162945.8595.2671476533659571699.idtracker@ietfa.amsl.com> <554356ec-de3a-08ed-a920-0397813895e0@bluepopcorn.net> <CABcZeBPOWVhPTpBt3E8GsqH7LMtG4y04voqTCLS=PG3hZk+NaA@mail.gmail.com> <b79b4b8a-a2b9-8954-83fd-e2789b4cd3c3@bluepopcorn.net> <CABcZeBPG3HHPhwoSNJPJGgLbSSOmSWhw43U+T-tnrVTjgtzmiQ@mail.gmail.com> <20190228183553.GA916@straasha.imrryr.org> <CABcZeBPDLr9MizT3bhJzZWuZtk3S6gWtdkvPL1bOQdOXox4Zuw@mail.gmail.com> <05712735-E4EA-4212-BFC3-3DD58A09DFC9@dukhovni.org> <CABcZeBOGgKCrvqu0B4Xm3LHqRJfiA682CGYnoCv7CoQvcXVfzA@mail.gmail.com>
To: IESG <iesg@ietf.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/NyqFe8SbugvZB2z3MijdAAxavhs>
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 <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, 13 Mar 2019 05:15:33 -0000

> On Mar 12, 2019, at 11:00 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
>> 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.
> 
> Surely you're familiar with the term "argument from authority".

Yes, and also quite aware that FWIW, that's in part the argument I'm
making.  The idea is that am I am not just citing the dead trees that
only loosely capture the spirit of the specifications.  Having written
the DANE specification, crafted its first MTA implementation, and worked
hard to see it adopted, I think that while any authority I may bring to
this is by no means dispositive, it still should carry some weight, and
ought to be considered, among whatever other factors you might find
relevant.

Bottom line, while working with the Postfix and broader email community
to bring greater transport security to email, my read is that senders
do not view anything that recipient systems might publish as a mandate
that preëmpts their policy options.

Indeed my experience tells me (as e.g. explained in RFC7435) that we get
greater adoption of security systems when we give participants a range of
options and not just once size fits all.

While a higher fraction of Web traffic than email traffic is *strongly*
protected with authenticated TLS, a larger fraction of email traffic
than Web traffic is protected from passive monitoring, because support
for unauthenticated STARTTLS was easier to deploy and operate.

With Let's Encrypt, HTTP is now starting to catch up on TLS adoption, but
some have rightly noted that it has also become much easier for various
MiTM attackers to obtain fraudulent DV certificates.  We're seeing an
unsurprising tradeoff between ubiquity and security.

We should not deny senders the opportunity to take sender preference
into account, this will ease the adoption path to greater security,
and will help to make security more deployable.  Strong security that
only a few deploy is ultimately not a success story.  Sometimes (e.g.
Let's Encrypt) we compromise in the name of ease of deployment.

-- 
	Viktor.