Re: [ietf-smtp] starttls-everywhere

Phil Pennock <ietf-smtp-phil@spodhuis.org> Mon, 01 April 2019 18:56 UTC

Return-Path: <ietf-smtp-phil@spodhuis.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD385120187 for <ietf-smtp@ietfa.amsl.com>; Mon, 1 Apr 2019 11:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=rSjGbX1L; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=nwMyt94R
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 kW7gfkCkqZa4 for <ietf-smtp@ietfa.amsl.com>; Mon, 1 Apr 2019 11:56:03 -0700 (PDT)
Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8B51204CC for <ietf-smtp@ietf.org>; Mon, 1 Apr 2019 11:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=W3Xbkw92aeVREXD3jCXmVvu1xy0iglz8cfuT5GwJQB8=; b=rSjGbX1L8URXEF2OD7NttUlxo+ TilC36JQZLppYJpwoe3EKYIa9c+tK3ojXUUXKepxonn2TDpR8H0kLrtJuTM72lrTlX48N7Fjb3SV2 E6du4/Xa311Xb7S0dZb+P0zv3C6naEVciMvudybLKIMxlUNwyco1/PxVa2wX6WuJXyhKkhhU+00xm 8KBml2Wakk4ciD0XxkNhPIGbys3iKAA2C/BLnZ1GrXR+DdKb5ElPeSbjmLymO7RSlcUBG3SwygCeW Wek0pl/QYlZZH7po47mNWGGkwt+VgHSdElSHGt4SfOinpIggexZHCqALpu0ETtwMG9KTqPg9Oq/E2 DuKsCiEg==;
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902e2; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=W3Xbkw92aeVREXD3jCXmVvu1xy0iglz8cfuT5GwJQB8=; b=nwMyt94Rujq/XCTybIVabO0pn vEifJLsy18q35q67M5Q1eRyhr2CnU7grYN9k+9oZHbgrCFQiREk16nq7iDECQ==;
Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hB266-0008Nr-Hl; Mon, 01 Apr 2019 18:55:54 +0000
Date: Mon, 01 Apr 2019 14:55:51 -0400
From: Phil Pennock <ietf-smtp-phil@spodhuis.org>
To: keld@keldix.com
Cc: Jeremy Harris <jgh@wizmail.org>, ietf-smtp@ietf.org
Message-ID: <20190401185550.GA26192@osmium.pennocktech.home.arpa>
Mail-Followup-To: keld@keldix.com, Jeremy Harris <jgh@wizmail.org>, ietf-smtp@ietf.org
References: <74074d25-26b0-e597-c05d-62b6b5902a7c@wizmail.org> <20190331113321.GA13658@www5.open-std.org> <20190331191653.GA5690@osmium.pennocktech.home.arpa> <20190331201459.GB4408@www5.open-std.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190331201459.GB4408@www5.open-std.org>
OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/kN6QRn0edhMDbC4HeeHHabe8ItA>
Subject: Re: [ietf-smtp] starttls-everywhere
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 18:56:08 -0000

On 2019-03-31 at 22:14 +0200, keld@keldix.com wrote:
> in my mind that is not a good way forward,
> I thnk it will break up email as an internet service.
> I would much rather go the upwards compatible path,
> like we did for smtp/esmtp which I think has been very succcsful. 
> 
> The esmtp transition has been so successful because we designed 
> it to be so, and nobody was hurt. Transition to starttls has been very successful
> also because it was designed to be smooth. Please don't break email!

Nothing breaks except that which is _supposed_ to break.

Sometimes, things are supposed to break, in the place and manner
designed to do so safely.  This is solid engineering: make sure that
when breakage happens, it happens safely, with minimal knock-on
consequences.  "Never break" is the same as "never repaired".

In this case: if domain A has a policy saying "you should always be able
to use TLS to talk to me", and the operators of domain B know that
they're not on heavily broken Internet and that they should be able to
use TLS to talk to anyone else, as long as those people have advertised
the existence of TLS, then opportunistic TLS is a win and the system
described here only interferes with mail delivery when a
Man-in-the-Middle attacker is stripping out STARTTLS.  Exactly the
scenario where continuing in plaintext is breakage.  The operators of
domain B should be able to decide that yes, they want mail to not flow
to something pretending to be domain A in those circumstances.  Their
systems, their rules.

To keep this on-topic for standards work: over in Exim land: we natively
support DANE; I have a strong objection to MTA-STS; STARTTLS-Everywhere
is something which folks can configure their installs to manage,
although we might need feature work to make "constrained list of
allowable MX hosts" easier to configure ... if we wanted to do go out of
our way to encourage STARTTLS-Everywhere.

STARTTLS-Everywhere is at the level of "distribution of hosts.txt files"
and not really scalable, but ... it probably works well enough and is
suitable for toys.  Anyone serious about privacy and integrity should be
deploying DNSSEC and then publishing TLSA records.

-Phil