Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

Scott Kitterman <sklist@kitterman.com> Wed, 07 November 2018 12:26 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBA712D4E9 for <dmarc@ietfa.amsl.com>; Wed, 7 Nov 2018 04:26:02 -0800 (PST)
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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=sJrbMwpv; dkim=pass (2048-bit key) header.d=kitterman.com header.b=jobYPn9/
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 gXMUygohxlxY for <dmarc@ietfa.amsl.com>; Wed, 7 Nov 2018 04:26:01 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A64128CF2 for <dmarc@ietf.org>; Wed, 7 Nov 2018 04:26:00 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541593557; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=r78c+XZckmGdTQQxve3rp/PbCkZklJHBgizxke/smug=; b=sJrbMwpvw7bcXH0cqqOzQQhGwlMJokv8+3eKz5mdD5PEkAS4T1+Tig+j LVLwGJqbCpfOum4WbOi4DPoL+LKGDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541593557; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=r78c+XZckmGdTQQxve3rp/PbCkZklJHBgizxke/smug=; b=jobYPn9/0d3PgGVL/Le7W3c6a9gxWvkmvVRFNcwv2ixAq8CXE4AgMIT3 C8AR9VaiqGhas65626YQMzHwDyo5T+tWHu/UYkxGVgSBtxRQkFLb6NYn8t ZlLOxobmAN76mFEU46/Rded0Fp0USh+IaceRBVzP9h7k+TTtCeLqOYndiJ gmPfUvDj8Se2ilkfpsLG8hD/LKWdWDaVS0w1rlP19nyiE9/rYcsz95qVpM ekJD4LRyx2NtWW6wkOSCneE1AMuTnmV34iioj70DLyd8IWudkUKVb1+W5o OoTJUOwe+Oj1NImJl27dF8XMmtb59iVR6QnPBfanKGH3EYf/6SpsdA==
Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 37A5FC400F8; Wed, 7 Nov 2018 06:25:57 -0600 (CST)
Date: Wed, 07 Nov 2018 12:25:52 +0000
In-Reply-To: <CAL0qLwafw_1ksJDLoHn4HM5N6hmgHXA=McjE9grbD=t-e5J48A@mail.gmail.com>
References: <CABuGu1o4E-Svt9N++RaFvO4SATt3Wh1w7gZb1OdBSVRCm7Odmg@mail.gmail.com> <CAL0qLwZXRD6jmbZDR+ETK+N3kW96i8mChaP1yHqsqnyzYw8T3Q@mail.gmail.com> <CAL0qLwa6jE_0DxHZYHu7n3v2nF2b90vWGeBgJB_XyyPj0Oz-ng@mail.gmail.com> <4226992.SIzckGkbUk@kitterma-e6430> <CAL0qLwafw_1ksJDLoHn4HM5N6hmgHXA=McjE9grbD=t-e5J48A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: "Murray S. Kucherawy" <superuser@gmail.com>
CC: IETF DMARC WG <dmarc@ietf.org>
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/smx-rIcwvetloD_TRooHXm_9U_A>
Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 12:26:03 -0000


On November 7, 2018 7:56:14 AM UTC, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>On Wed, Nov 7, 2018 at 11:54 AM Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>> My estimation is that this would change very rarely.  If I were
>developing
>> software for this, I'd probably check at build time and use that
>unless
>> there
>> are some reason to update.  Not that people won't try, but I think
>not
>> very
>> real time is sufficient.
>>
>
>Sure, but:
>
>(a) You are probably a more reasonable and thoughtful implementer than
>average; and
>
>(b) It only takes one large operator to, through neglect or a desire to
>ensure up-to-the-minute data, disregard any query rate advice we give
>and
>accidentally DoS IANA off the 'net.
>
>If IANA doesn't have a highly scalable CDN in front of it, which I
>doubt,
>then this is something the IESG would legitimately raise (as they did
>with
>WEIRDS) when this goes up for formal review.
>
>DBOUND tried to do this inside the DNS, which solves the CDN problem,
>but
>it couldn't reach consensus on the preferred approach, and shut down
>not
>long ago without producing anything.

Unfortunately, I didn't come up with an idea for how to do this in DNS.  This seems like a legitimate issue for the WG to work through.

There are lots of ways to do denial of service attack protection without a CDN.  I would hope it's not so trivial to bounce IANA off the net.  

Scott K