Re: [Uta] Implementing STS

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 14 April 2016 16:59 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 BA89012DAF7 for <uta@ietfa.amsl.com>; Thu, 14 Apr 2016 09:59:39 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 rOxK_5wYbdDK for <uta@ietfa.amsl.com>; Thu, 14 Apr 2016 09:59:38 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B2E12D9B6 for <uta@ietf.org>; Thu, 14 Apr 2016 09:59:38 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 65185284DCA; Thu, 14 Apr 2016 16:59:37 +0000 (UTC)
Date: Thu, 14 Apr 2016 16:59:37 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <20160414165937.GH26423@mournblade.imrryr.org>
References: <570FA711.9060307@thehathcocks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <570FA711.9060307@thehathcocks.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/QLdp8DbOLWs7xHK-U1RDyQjQlI0>
Subject: Re: [Uta] Implementing STS
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, 14 Apr 2016 16:59:39 -0000

On Thu, Apr 14, 2016 at 09:20:01AM -0500, Arvel Hathcock wrote:

> ... one way to handle it (as I think was mentioned before) is by deferring
> back to queue any delivery attempt which finds a previously unknown STS
> policy record until such time (not long) as a separate thread safely
> dedicated to the task can validate the policy and update the cache file.
> I will have to take this approach due to my MTA's internal design.

Doing background policy validation makes sense, but deferring
delivery until that completes is requires some care.  A policy
might be invalid for some time, and during that time you want to
periodically retest (in the background, subject to some minimum
inter-probe delay) while continuing normal email delivery to the
domain.

This means that if background validation is your approach, you
would defer mail only until the first validation succeeds or fails.
In case of failure, keep retesting the policy periodically, but
continue delivery without delay.

> A couple of tiny minor spec things for starters:  Section 3 says that MX
> patterns are required yet the example at the end of the doc doesn't have
> them.  Also,  "_.example.com" has the _ char as the wild-card.  Maybe
> there's a reason not to use * for this?  See, minor stuff.  It would be good
> to have some reference STS records/hosts setup somewhere that implementers
> can test against.

It is still much too early for that, the draft proposal is I think
due for some major incompatible changes.

-- 
	Viktor.