IETF Logo Mail Archive

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

Jim Fenton <fenton@bluepopcorn.net> Thu, 10 August 2017 22:56 UTC

Return-Path: <fenton@bluepopcorn.net>
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 7D3DB1324A4 for <uta@ietfa.amsl.com>; Thu, 10 Aug 2017 15:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 iBuy23ROtb9f for <uta@ietfa.amsl.com>; Thu, 10 Aug 2017 15:56:37 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB8F1324A2 for <uta@ietf.org>; Thu, 10 Aug 2017 15:56:37 -0700 (PDT)
Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v7AMuZCa022906 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <uta@ietf.org>; Thu, 10 Aug 2017 15:56:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1502405797; bh=v7veokjHhPEfNZDDANnoXL5ULu0nbFHTAwtBFQuVEW0=; h=Subject:To:References:From:Date:In-Reply-To; b=UV6oPY4oV7TTMEFumjg4JCUf9J85Uu80t1/lSaAeY1xCxn9xtXKdXyqAMGPiDK24C kMQmcdrie/dJKjGtZprCHmv3NrDHwSO3gcDfLTmXfHAv0vHPIadc+jaLN193EODsnB BmTpYKIMEDTfhyenccXkaClRDOWTKEZFetaag1as=
To: uta@ietf.org
References: <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> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> <CANtKdUcc5mBNeUd9kPg_VemcbX4vdDwfvVgoXrr=nQtYLDeStQ@mail.gmail.com> <20170810174656.GX8146@mournblade.imrryr.org>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <62416269-a781-0642-f339-5f5ebbbb4146@bluepopcorn.net>
Date: Thu, 10 Aug 2017 15:56:29 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170810174656.GX8146@mournblade.imrryr.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/Jwk2Rvr_6r460_nriOklAxIvcxs>
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 22:56:39 -0000

On 8/10/17 10:46 AM, Viktor Dukhovni wrote:
> On Thu, Aug 10, 2017 at 10:02:41AM -0700, Daniel Margolis wrote:
>
>> If anyone else has read this far on the thread, I'm happy to get feedback
>> on this proposal from others on the list.
> Yes, please!
>
I have been following the discussion, although not in as much detail as
the two of you.

One small adjustment: When removing the policy, after removing the TXT
record, you should probably wait the former record's TTL before removing
the "none" policy because the TXT record could be cached elsewhere, even
if it looks like it's gone when you ask for it.

At a higher level: I agree that including a procedure policy removal is
an essential part of the specification. But we also have to make sure
that that procedure doesn't present an opportunity for an attacker to
downgrade the policy associated with a recipient domain. I *think* this
satisfies this requirement but I'm not completely sure.

-Jim

v2.23.0 | Report a Bug | By Email