Re: [dmarc-ietf] PSD simplification

Scott Kitterman <sklist@kitterman.com> Thu, 13 December 2018 01:27 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 19722129BBF for <dmarc@ietfa.amsl.com>; Wed, 12 Dec 2018 17:27:14 -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=CmYUmpjs; dkim=pass (2048-bit key) header.d=kitterman.com header.b=yn7B9JG+
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 OImprTzK9C7l for <dmarc@ietfa.amsl.com>; Wed, 12 Dec 2018 17:27:12 -0800 (PST)
Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5F9128B14 for <dmarc@ietf.org>; Wed, 12 Dec 2018 17:27:11 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544664429; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=Ad81SD0Vvwv6EbglQBn4evn8ZY11/aCqVY1+irfGhmo=; b=CmYUmpjso0Ca0mDdgwSYrj5q9WR0uRIGjdGwGEEiHYbDwYeHAIUKHvDi Erbd+CBX+KfPj+CGJTEy1viN6zuhCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544664429; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=Ad81SD0Vvwv6EbglQBn4evn8ZY11/aCqVY1+irfGhmo=; b=yn7B9JG+Yzn+RezOD4C+LX9Lq5mcu5ZqxJ0RC3iWSNf5cFfeMSqfGeDI iuvqeDo6Muho5qlfYJeuClvPBBQs3ity/2QwnEXhQ1K+8BCKXUNwZ8MMZ2 HfRYFJRfrEngSzr5xOFCKR2CpT4t97JQL4lWfy7UzU1SfEZGhAn7FD6bfx yjfegEi+eg9eYP/MHRn+uisjXcBJ36xCnK6mvRwKmpSHldUrEjebvw980k KiowJEsoY9STg5thXexKSnymKUoECHlRm+s5GrWUkH7WVoJo7IrVnTiUnR phFKVr6CiSlddCFHal2FztbheIqHZCYMM5rTvoTrdzm6z7g1lRQkrA==
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 softlayer.kitterman.com (Postfix) with ESMTPSA id EE1992D4062B; Wed, 12 Dec 2018 19:27:08 -0600 (CST)
Date: Thu, 13 Dec 2018 01:27:03 +0000
In-Reply-To: <3003562c-e2df-2ab0-e34b-8bda4f881d40@dcrocker.net>
References: <b3ab712a-74b3-d580-65bc-a97bf8c4652d@gmail.com> <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com> <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> <8090288.RMFQGzStmc@kitterma-e6430> <3003562c-e2df-2ab0-e34b-8bda4f881d40@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <B64DD715-DFC4-42E1-87FC-15A5ED0B83F9@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/3BrmdLxJWa5Bh2Z0vQUEskpteQY>
Subject: Re: [dmarc-ietf] PSD simplification
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: Thu, 13 Dec 2018 01:27:14 -0000


On December 12, 2018 3:30:20 PM UTC, Dave Crocker <dhc@dcrocker.net> wrote:
>On 12/11/2018 9:01 PM, Scott Kitterman wrote:
>> On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:
>
>>> 1.  If the registry is to constrain which public suffix operators 
>>> are constrained to assert a default record, then I'll claim that's
>>> a false sense of security, given the range of unrelated and even
>>> more serious powers a parent domain can exert over a subordinate
>>> one.
>>> 
>>> 2.  If it is to avoid wasting a DNS a query to a record that won't 
>>> be there, that's false economy.  Most queries to the registry will
>>> fail. And most queries to both the From: domain name and its
>>> organizational domain already fail. The incremental cost of a
>>> wasted query to the organizational domain's parent is pretty
>>> small.
>>> 
>>> And the cost of creating and running a query-able database that is
>>> kept current is high and error-prone (as the existing PSL
>>> demonstrates.)
>....
>
>> I think your analysis is essentially correct, but I think point 1 is 
>> backwards.  Since (in the current draft), based on the registry
>> entries, the third level queries will usually not take place. It's
>> not that the PSOs are constrained not to publish records (they
>> aren't), it's that no one will (should) query for them based on the
>> third level test if they aren't in the registry.
>> 
>> This may seem like a small thing, but I believe it makes all the
>difference.  
>> You are certainly correct that nothing in an RFC can prevent a PSO
>from 
>> publishing such records.  What we can do is give guidance on when not
>to look 
>> at them.
>
>That's a cost-saving line of concern.  My point is that the existing
>mechanism already has quite a bit operational inefficiency from queries
>that fail, so that adding one more is a minor issue, especially as
>against the considerable administrative and operational cost of
>creating
>and running a registry.
>
>
>> I believe avoiding the privacy implications of the related feedback
>> are worth the transactional costs of the registry (but then I would,
>> wouldn't I).  I don't think a bad situation justifies making it
>> worse.
>
>Sorry but I don't know what privacy implications you are referring to.
>I don't even have a guess.
>
>And the draft makes no reference to privacy issues.  Or rather, the 
>Privacy Considerations section says the draft doesn't introduce any.

As written, it doesn't.  If you change it the way you propose, it will.

Scott K