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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 28 February 2019 19:59 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 B8092128CB7; Thu, 28 Feb 2019 11:59:09 -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 9FRAXz7Wwv_U; Thu, 28 Feb 2019 11:59:07 -0800 (PST)
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 CD08E124BF6; Thu, 28 Feb 2019 11:59:07 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 1E02C3354F; Thu, 28 Feb 2019 14:59:06 -0500 (EST)
Date: Thu, 28 Feb 2019 14:59:06 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, iesg@ietf.org, uta-chairs@ietf.org
Message-ID: <20190228195906.GB916@straasha.imrryr.org>
Reply-To: uta@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, iesg@ietf.org, uta-chairs@ietf.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190228183553.GA916@straasha.imrryr.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/LftEPWI2n_c0hk9KFZ2cpcyAYnw>
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: Thu, 28 Feb 2019 19:59:10 -0000

On Thu, Feb 28, 2019 at 01:35:53PM -0500, Viktor Dukhovni wrote:

> We should keep in mind that email is often the medium used to
> communicate about operational failures.  And that not infrequently,
> insecure email is the medium through which more essential security
> is brought back into service elsewhere.

I think a note by John Callas from a current thread on the Cryptography
list is apt:

    Remember that the rules of infosec are Confidentiality, Integrity,
    and Availability. You don’t want to do something like maximize
    C and minimize A. I’ve heard several stories about people who
    made that mistake and now do not have available the few thousand
    bitcoins they once had.

Keeping also in mind that providers and users are more likely to
adopt technologies that provide C, so long as they can still get A
when needed.  So to maximize confidentiality *in practice* we must
not over-emphasize it to the detriment of availability.

Hop-by-hop transport security in email is in good measure a concession
to the fact that we're (for good reasons) as far as ever from any
broad deployment of end-to-end email encryption, and that hop-by-hop
TLS is the compromise that can reach broad adoption.  The security
specified in DANE and MTA-STS is ultimately only useful if broadly
deployed.  Let's make that deployment easier.

If after some years of broad deployment, all but a negligible number
of operators learn how to operate their MTAs flawlessly, monitoring
and provisioning tools improve etc., and the need for exceptions
goes away, then we can deprecate "TLS-Required: no" (or whatever
the name is in the end) as having served its purpose by easing the
path to adoption in the years prior.

-- 
	Viktor.