IETF Logo Mail Archive

Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 10 August 2017 04:05 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 304DD13254B for <uta@ietfa.amsl.com>; Wed, 9 Aug 2017 21:05:04 -0700 (PDT)
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 eOJ7WwittTmL for <uta@ietfa.amsl.com>; Wed, 9 Aug 2017 21:05:02 -0700 (PDT)
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 8F614132545 for <uta@ietf.org>; Wed, 9 Aug 2017 21:05:02 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (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 D28E47A3302 for <uta@ietf.org>; Thu, 10 Aug 2017 04:05:00 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CANtKdUcqcoKjRctyGJ6Qc41vOxEvt8Knzjc6CZGn-0jqN9g5BA@mail.gmail.com>
Date: Thu, 10 Aug 2017 00:05:24 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: uta@ietf.org
Message-Id: <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org>
References: <CANtKdUfJs=p-jiZ-QQ6Mk=iKh_2h6=596SYWLJ=mJsf61R0=9g@mail.gmail.com> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <CANtKdUcmqsRG7aV8poqOCe=qMAk5qAkw2WY3JZqvnf1WVAknUw@mail.gmail.com> <20170808210631.GO8146@mournblade.imrryr.org> <CANtKdUfcn=Z73pxXTov70e2+-0kc9Q6PGTchS=aUhRR0V+RNMw@mail.gmail.com> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <CANtKdUc6PaDyBOcG_LhvezbnZ8JEv=xFf=MosQWSY8dg4MxjLg@mail.gmail.com> <20170809174827.GQ8146@mournblade.imrryr.org> <CANtKdUdqHM-bu_Z_GVcCN_Jca9SNNNdBkQKPOOtX_a=zW_EJZA@mail.gmail.com> <20170809183310.GU8146@mournblade.imrryr.org> <CANtKdUcqcoKjRctyGJ6Qc41vOxEvt8Knzjc6CZGn-0jqN9g5BA@mail.gmail.com>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/NkaHX76u0A47sMgyvtxMdD2h1R0>
Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
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, 10 Aug 2017 04:05:04 -0000

> On Aug 9, 2017, at 8:05 PM, Daniel Margolis <dmargolis@google.com> wrote:
> 
> 1. Publish a new policy (as with any new policy, updating the TXT record's ID) with mode=none. 
> 2. After all pre-existing policies have expired (e.g. the time of step 1 plus the existing policy's max_age), safely remove the TXT record and current policy.

One corner of the problem space we did not consider:

  * I'd like to be able to delete the "none" policy promptly, by noticing
    a removed TXT record.

  * So it would be nice to be able to remove the TXT record promptly.

  * However, you're suggesting that policy refresh should not happen
    when the TXT record is absent.

  * This implies that the TXT record removal must wait until everyone's
    max_age has expired.

  * Consequently "none" policies will linger in caches needlessly long.

If instead NXDOMAIN/NODATA triggers a policy refresh (new logically
empty id) then senders can flush "none" policies as soon as they
also see the TXT record deleted, and that deletion can reduce the
number of required DNS changes.  Instead of modifying the TXT to
trigger refresh and later deleting it, it can be deleted right
away.

The only complication is that deleted TXT is then, for senders with
a cached policy other than none, just another TXT value (NULL if
using a SQL database or similar) that triggers refresh and cached
policies can then have a NULL id, but a "none" policy with a NULL
id can be deleted right away.

Please think it over...

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email