Re: [Uta] Updated drafts for MTA-STS & TLSRPT
Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 23 February 2017 21:14 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 0595E129B05 for <uta@ietfa.amsl.com>; Thu, 23 Feb 2017 13:14:06 -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 Yq7EX5kVqR3K for <uta@ietfa.amsl.com>; Thu, 23 Feb 2017 13:14:04 -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 AF67712999C for <uta@ietf.org>; Thu, 23 Feb 2017 13:14:04 -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 D165F7A330A for <uta@ietf.org>; Thu, 23 Feb 2017 21:14:03 +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: <CANtKdUfO5Onw=_c0kPfAB7HDuh+R4Q-svCQgjdS6MZbSh+ksAg@mail.gmail.com>
Date: Thu, 23 Feb 2017 16:14:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <46F3DACC-8C7C-4871-BC40-4CE97E0A4120@dukhovni.org>
References: <a0701ba14a704ac08f2b099a0576e22e@COPDCEX19.cable.comcast.com> <CA+E3Fw2=3QCeeB2hOjzKERwRaF6p_G9z6Gm9GA4Yz2qE0KBhRA@mail.gmail.com> <CANtKdUfO5Onw=_c0kPfAB7HDuh+R4Q-svCQgjdS6MZbSh+ksAg@mail.gmail.com>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/LN0yedAkNwoEmTbNSAXqq97lbz8>
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:14:06 -0000
> On Feb 23, 2017, at 3:35 PM, Daniel Margolis <dmargolis@google.com> wrote: > >> Having pondered it a bit, my suggestion is: >> 1. A SHOULD that max_age is set to at least 6 months, other than during roll-out >> 2. A SHOULD that well-behaved clients with a cached policy should re-check DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed. > > I think the phrasing you give here suggests that if I send > mail to your domain less than once a week, I should run a > cron job to refresh the cache--and I hate cron jobs. That's extremely unlikely to be implemented in Postfix, for example. To avoid a "roach motel" policy cache, refresh will be driven only by actual mail flow. The DNS record needs to be specified as the primary trigger for "early" refresh, wil an optional refresh when >50% of the time from last refresh to expiration has elapsed and sufficient (say 1 hour or more) time remains that the policy isn't about to be refreshed due to actual expiration. A frequency cutoff avoids firing refresh triggers minutes or seconds apart close to expiration. > So to be slightly pedantic, would it work just as well to say senders > SHOULD check for an updated policy if using a policy which is older > than one week? (My phrasing may be unclear, but I mean, of course, > that they need only check for an updated policy if they are otherwise > sending mail to that domain anyway.) See proposed scheme. It has no artificial scale (1 week), and is instead based on the policy lifetime. Sending systems should probably cap the policy lifetime on their end to something sensible (shorter for sites that send lots of mail, and are unlikely to not contact a given peer for a long time, longer for sites that don't send much mail). So if a receiving system advertises a 100-year policy, something more sensible will be stored in the sending side. > Of course, we could still simply suggest/require senders *always* > check for a new policy--it's one more DNS lookup to the recursive > resolver per-send--but I bet in some implementations there are > good reasons not to do this. If/when Postfix implements STS, the DNS id will be checked for each new SMTP connection. Changes in the DNS id will trigger (background) policy refresh. Non-changes in the DNS id will continue to use the cached policy until it is 50% closer to expiration since the last refresh (with a sensible cutoff). -- Viktor.
- [Uta] Updated drafts for MTA-STS & TLSRPT Brotman, Alexander
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT David Illsley
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Daniel Margolis
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Viktor Dukhovni
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Daniel Margolis
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Viktor Dukhovni
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Viktor Dukhovni
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Daniel Margolis
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT David Illsley
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT David Illsley
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Viktor Dukhovni
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Daniel Margolis
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Alberto Bertogli
- Re: [Uta] Updated drafts for MTA-STS & TLSRPT Daniel Margolis