Re: [Uta] Updated drafts for MTA-STS & TLSRPT
Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 23 February 2017 21:00 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 23C2512A2CC for <uta@ietfa.amsl.com>; Thu, 23 Feb 2017 13:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tvyCyGI3A-t0 for <uta@ietfa.amsl.com>; Thu, 23 Feb 2017 13:00:16 -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 C6890129AF7 for <uta@ietf.org>; Thu, 23 Feb 2017 13:00:16 -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 D4F7E7A330A for <uta@ietf.org>; Thu, 23 Feb 2017 21:00:15 +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:00:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <905199AC-51EE-42E9-AB54-68C99578A03E@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/8hzEX1fQHU6RDZ0fSk7tuJC-YnM>
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" <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:00:18 -0000
> On Feb 23, 2017, at 3:35 PM, Daniel Margolis <dmargolis@google.com> wrote: > >> 2. It prevents new MX records (eg new servers for increased capacity or backups) not covered by the cached policy from being used until the max_age, or until a failure to send with all the covered servers. This should be a non-problem. The DNS record exists precisely to signal a requirement for "early" policy refresh. So when the domain's policy changes, the DNS record policy "id" SHOULD change to alert remote caches that the cached data is likely stale. This applies whether or not the change is to the list of acceptable "mx" hosts, or to some other property. > So you've pointed out a somewhat subtle pitfall. If I deploy a policy > with "mx: ['*.google.com']" and I later deploy additional MXs with > higher priority on mail.google.net (and, because I'm smart, I > remember to update my deployed policy), senders may nonetheless > only send mail to the old .com MXs, resulting in an unexpected > traffic imbalance. Only if you're negligent, and fail to modify the DNS record. Negligence can cause many other operational issues, there are no designs immune to operator negligence. > 2. This could be fixed if we said that senders MUST seek a > new policy whenever some MXs are filtered out by policy > application (5.2 step 2). That's both unnecessary, and problematic. The issue is that this condition is "sticky", until the policy matches the MX RRset, the sender is in a constant "refetch" condition. It is best to avoid this trigger. The DNS record triggers a single update, and then its "id" is cached with the same or any new policy. > 3. This is optionally fixed by senders refreshing cached > policies at an arbitrary time, which they may (but need not) > do. In addition to the text record trigger, senders should attempt to opportunistically (not triggered by DNS changes) refresh the policy at or after the midpoint between the last retry attempt and the expiration (but at least an ~1 hour after that attempt). Thus when a policy is published for 90 days, and then the policy server goes off-line, the retries would be (approx): <= 45 days left <= 22 days <= 11 days <= 6 days <= 3 days <= 36 hours <= 18 hours <= 9 hours <= 4 hours <= 2 hours <= 1 hour More retry attempts just short of expiration are likely pointless. -- 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