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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 28 February 2019 22:57 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 02468131054; Thu, 28 Feb 2019 14:57:29 -0800 (PST)
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 cmYnYllPwBWk; Thu, 28 Feb 2019 14:57:27 -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 F200E130EE8; Thu, 28 Feb 2019 14:57:26 -0800 (PST)
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 27A18337E6; Thu, 28 Feb 2019 17:57:25 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <f939d44f-1262-ca40-4501-755ed05e4674@bluepopcorn.net>
Date: Thu, 28 Feb 2019 17:57:21 -0500
Cc: uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, The IESG <iesg@ietf.org>
Reply-To: uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@ietf.org, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <B822D2C1-184B-4205-ABC4-750A9F140636@dukhovni.org>
References: <155072491254.20210.15187912705241578950.idtracker@ietfa.amsl.com> <7061cefb-0f2d-5257-e10c-95be14a7413f@bluepopcorn.net> <20190227201137.GS53396@kduck.mit.edu> <f939d44f-1262-ca40-4501-755ed05e4674@bluepopcorn.net>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/YtngH9r8OQ5Es_rSc8vb9ZLQotM>
Subject: Re: [Uta] Benjamin Kaduk'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 22:57:29 -0000

> On Feb 28, 2019, at 5:49 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:
> 
>> I'm complaining more about the transition from (3) to (4) than either one
>> per se.  If I open a connection and then establish a (new?) TLS-protected
>> session, that seems to mostly be STARTTLS.  But if I use implicit TLS, why
>> do I need to bother with (3) at all?
> 
> There's one circumstance where implicit TLS might happen, and that's
> message submission. It's probably step 4 that's the problem there, since
> the TLS session is negotiated earlier in that case.

Yes, thanks, indeed there's potential for implicit TLS during initial
submission (now that port 465 is back from the dead) and perhaps also
final delivery via LMTP.  So my note about STARTTLS being the only
relevant protocol may not cover the "edge" cases.

-- 
	Viktor.