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, 14 March 2019 16:40 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 9CA26130EFE; Thu, 14 Mar 2019 09:40:33 -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_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 aoAEep2OAa8g; Thu, 14 Mar 2019 09:40:31 -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 2D5BC130E58; Thu, 14 Mar 2019 09:40:31 -0700 (PDT)
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 660FD303E7D; Thu, 14 Mar 2019 12:40:30 -0400 (EDT)
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: <CABcZeBO30t6vYXO1TdjSriwoB=NYoEGUDB3P2r2mietFAeJy4Q@mail.gmail.com>
Date: Thu, 14 Mar 2019 12:40:29 -0400
Cc: uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-smtp-require-tls@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: <A26C2BA8-134C-45F1-A6B2-1DCFBEFE701F@dukhovni.org>
References: <155076162945.8595.2671476533659571699.idtracker@ietfa.amsl.com> <b60988cd-ef8a-46db-8d70-795954109bd3@www.fastmail.com> <CABcZeBP-qzG4c2SX5P3HeDC2P5ChVTDA43MSvQXk1=bxBEr=2A@mail.gmail.com> <E2B60AD7-2CED-4480-AAAA-38714E95EBD0@dukhovni.org> <CABcZeBOWw=XEbyxu94_v-kkYxyuuPDTnJeJ+_-44VoCOFTyOBw@mail.gmail.com> <CABcZeBO30t6vYXO1TdjSriwoB=NYoEGUDB3P2r2mietFAeJy4Q@mail.gmail.com>
To: The IESG <iesg@ietf.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/iSP9VNN9jw-D9WSqZIAfbO2m7aw>
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, 14 Mar 2019 16:40:45 -0000

> On Mar 14, 2019, at 11:53 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> We had a bunch more discussion on this on the IESG call. It seems like
> the primary use case for TLS-Required=no may be to exempt what's basically
> the control channel from the requirement to use TLS. So, for instance,
> I am getting persistent bounces from you and I want to notify you
> about it, so I send that notification with the TLS-Required=no flag set
> [0].

That's one use case, but another important use case, is giving *users*
the ability to resent low-sensitivity but time-sensitive messages, that
bounced or were delayed because of downstream misconfiguration.

Think "Happy Birthday Grandma" (ideally not belated) postcard (i.e.
cleartext OK).

> Assuming that's right, then ISTM that actually this is not the ideal
> design, both because it's not clear how the flag gets set and because
> the recipient has had no chance to weigh in.

The "flag" gets set by the MUA, by adding the appropriate header.  For
webmail clients, that'd be something the WebUI could provide as option
when the user is reviewing a bounce or a delay notice for a message he
sent that did not (yet? and will likely not as-is) make it to the intended
recipient.

For power-users (postmasters, or other technologists) using Mutt, Pine, ...
the header can just be added in their favourite message editor.

> What I would suggest would
> instead be to extend MTA-STS and DANE to exempt specific "control"
> addresses (e.g., Postmaster) from mandatory TLS. This seems like it
> would solve the main problem while avoiding opening the can of
> users just marking routine messages as non-sensitive.

Unfortunately, that does not work.  These days, a large fraction of
domains have no working "postmaster" addresses.  The technical contact
addresses for many domains are no longer published in WHOIS, but one
may be able to scrape a responsible user from the website, or from
the DNS SOA "mrname".

There are no "control address" localparts that work for (essentially)
all domains, and email to "postmaster" may actually in some cases be
sensitive, and unrelated to transport security obstacles.

By far the more reliable notification channel, is email to an actual
user, who knows how to reach support for his provider, or in SOHO
cases knows (or is) the administrator in person.

[ I've been sending DANE-related misconfiguration notices since 2014,
 and postmaster@ bounces back as undeliverable in ~30% of the cases,
 and is not necessarily read by anyone even if delivered, I typically
 include additional notice recipients whenever available. ]

-- 
	Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


-- 
	Viktor.