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, 21 February 2019 20:43 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 83714131199; Thu, 21 Feb 2019 12:43:02 -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 Du6_EScob6b0; Thu, 21 Feb 2019 12:43:00 -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 9F8261311A4; Thu, 21 Feb 2019 12:43:00 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id B29402B9765; Thu, 21 Feb 2019 15:42:59 -0500 (EST)
Date: Thu, 21 Feb 2019 15:42:59 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: The IESG <iesg@ietf.org>
Cc: uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org
Message-ID: <20190221204259.GZ916@straasha.imrryr.org>
Reply-To: The IESG <iesg@ietf.org>, uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org
References: <155076162945.8595.2671476533659571699.idtracker@ietfa.amsl.com> <9964642F-59A8-41E0-B892-509F0ADEF8F7@dukhovni.org> <CABcZeBPZWjA4Pc0yEwb7DNmE4esxwAqn=0Czc=L1G-qzb4cV6w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBPZWjA4Pc0yEwb7DNmE4esxwAqn=0Czc=L1G-qzb4cV6w@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/R_LbT8YR6_BJ-LCEvvNe8lcfENs>
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, 21 Feb 2019 20:43:03 -0000

On Thu, Feb 21, 2019 at 12:22:32PM -0800, Eric Rescorla wrote:

> > A recipient has no expectation that the sending MTA supports any of
> > DANE, MTA-STS, REQUIRETLS, or even STARTTLS.
> 
> Nor do Web servers have any expectation that clients support HSTS, but we
> still don't allow it to be overridden by some http-no-really:// link.

"http-no-really://" links are not the right analogy, links are
typically delivered to the user, they rarely expressions of the
user's policy choice.

Browers have interactive human users who can on the spot chose to
override whatever security policy is in place.  Firefox by default
offers me the opportunity to make certificate exceptions permanent,
and I always have to remember to uncheck the check-box to make an
exception for just the one connection.

SMTP servers deliver in the background, with the user out of the
loop, hence the need for "REQUIRETLS = no".

> > More harmful to security than acknowledging that either participant
> > has the freedom to choose the policy that works best for them, is
> > restricting their choices to the point of making the use of security
> > mechanisms too burdensome to deploy.
> 
> The problem with this mechanism is that it is denying the recipient the
> right to choose what works for them.

I am not aware of any such right.  The receiving system is announcing
a capability, and the sending system does its best to achieve the
highest common security level.  The input to finding the highest
common level includes software feature availability and local policy,
potentially including user preference.

The receiving system *cannot* expect to enforce its ceiling, all
it can do is offer more security, and hope that it will be used.
For that to happen, more senders would have to support the security
mechanisms, but they are likely to hold back if these offer no way
workable way to manage exceptions.

Firefox and Chrome offer dialogues to bypass the built-in browser
security mechanisms, a somewhat analogous control should be available
to mail user agents.

-- 
	Viktor.