Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-08: (with DISCUSS and COMMENT)

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 31 July 2019 01:19 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 6F3C512014E; Tue, 30 Jul 2019 18:19:45 -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_HELO_NONE=0.001, 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 4SbaikVOkdtI; Tue, 30 Jul 2019 18:19:43 -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 82213120123; Tue, 30 Jul 2019 18:19:42 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 859BC43A35; Tue, 30 Jul 2019 21:19:40 -0400 (EDT)
Date: Tue, 30 Jul 2019 21:19:40 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Cc: The IESG <iesg@ietf.org>
Message-ID: <20190731011940.GA24255@straasha.imrryr.org>
Reply-To: uta@ietf.org, The IESG <iesg@ietf.org>
References: <156339110885.25873.1576291155471550816.idtracker@ietfa.amsl.com> <c2469336-c6ca-37e1-2a5a-12a9e3a3fec4@bluepopcorn.net> <20190731000222.GV47715@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190731000222.GV47715@kduck.mit.edu>
User-Agent: Mutt/1.11.4 (2019-03-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/avQxa6okTbIFJ0RskmWCw-AuH8U>
Subject: Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-08: (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, 31 Jul 2019 01:19:45 -0000

On Tue, Jul 30, 2019 at 07:02:23PM -0500, Benjamin Kaduk wrote:

> > This work was inspired by a paper, "Neither Snow Nor Rain Nor MITM ...An
> > Empirical Analysis of Email Delivery Security"
> > http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf that there was a
> > presentation about at an IETF meeting a few years ago (can't find it on
> > datatracker currently). If you think the draft would benefit from
> > additional motivation, I could mention this paper and add an informative
> > reference to it.
> 
> This makes it sound like your stance is roughly, "we want to make TLS on by
> default but have to deal with deployed reality in order to get there",
> which would seem to have the consequence that "MTAs implementing
> require-TLS should default to requiring TLS and only request no-TLS in
> special cases".  I would support such a position, and in that case would be
> less concerned about the apparent lack of a "don't care" option, since
> there is less of a decision burden when there is a clear default behavior.

I don't quite understand this comment. :-(  Typically, the "Require-TLS"
signal originates at the submitting MUA, not an MTA.  MTAs may
*support* "Require-TLS", but they generally won't originate the
policy for messages in transit.

Some MSAs (or outbound edge MTAs) may add "Require-TLS" to messages
in transit for "business-partner" destinations where there's a
reasonable prior expectation that authenticated TLS is available
along the entire delivery path.  But this will be the exception,
rather than the rule.

Similar considerations apply even more strongly to explicit "don't
care", which should not be added by a transit MTA, and instead
should result from a user's choice to request delivery even in the
face of degraded transport security.

So I don't know what to make of "MTAs implementing require-TLS
should default to requiring TLS and only request no-TLS in special
cases".

Neither requiring TLS (end-to-end in the sense of the present draft)
nor requesting "no-TLS" (really requesting delivery despite lack
of or failure of authenticated TLS en-route) is somenthing that the
MTA would normally choose.  Rather the MTA, in support of the
present draft, would implement the policy conveyed in the message
envelope (require) or headers (don't care).

Sorry to be so dense, perhaps you can expand your point to make it
more clear...

-- 
	Viktor.