Re: [Uta] Updated drafts for MTA-STS & TLSRPT

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 23 February 2017 21:21 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 42378129984 for <uta@ietfa.amsl.com>; Thu, 23 Feb 2017 13:21:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 98NydvbqI1TS for <uta@ietfa.amsl.com>; Thu, 23 Feb 2017 13:21:40 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83E41297F1 for <uta@ietf.org>; Thu, 23 Feb 2017 13:21:40 -0800 (PST)
Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0A3087A330A for <uta@ietf.org>; Thu, 23 Feb 2017 21:21:40 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CANtKdUeiUrvzYmVW3_pEojtOzwG8nMdx8H8OwGK=JA0GaefaNQ@mail.gmail.com>
Date: Thu, 23 Feb 2017 16:21:39 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <94042B6B-F408-4C53-A831-F0912F117D64@dukhovni.org>
References: <a0701ba14a704ac08f2b099a0576e22e@COPDCEX19.cable.comcast.com> <CA+E3Fw2=3QCeeB2hOjzKERwRaF6p_G9z6Gm9GA4Yz2qE0KBhRA@mail.gmail.com> <CANtKdUfO5Onw=_c0kPfAB7HDuh+R4Q-svCQgjdS6MZbSh+ksAg@mail.gmail.com> <905199AC-51EE-42E9-AB54-68C99578A03E@dukhovni.org> <CANtKdUeiUrvzYmVW3_pEojtOzwG8nMdx8H8OwGK=JA0GaefaNQ@mail.gmail.com>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/x6ufMT-8LyWbMhXGpmmj75TAcg0>
Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: uta@ietf.org
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, 23 Feb 2017 21:21:42 -0000

> On Feb 23, 2017, at 4:04 PM, Daniel Margolis <dmargolis@google.com> wrote:
> 
>> This applies whether or not the change is to the list of acceptable "mx"
>> hosts, or to some other property.
> 
> Yes, but my point was that we don't (to my recollection) actually require
> senders to check for new policies on every mail send--they can legitimately
> keep using an old, cached policy as long as it works.

Poorly crafted implementations will err in many interesting ways, but with
luck their users will clamour for fixes or switch to less broken systems.

The DNS lookup is cheap and should happen frequently, and doing so on each
SMTP connection should be recommended in the draft.

> As you say below, there are many optional strategies for senders to refresh
> policies in a reasonable way, so I am not of the opinion this is a fatal flaw.
> On whether it would be better to say senders SHOULD take one of these policies,
> though, I am open to feedback.

I think recommending well thought-out approaches to these issues is useful:

   1.  It makes implementors think about the issues.
   2.  It gives them usable solutions that they can adopt or improve on.

Nothing this proposed RFC can say will force compliance, the SMTP server
is a passive actor in this space, and has no idea whether the client is
using STS at all, let alone correctly.

-- 
	Viktor.