Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

"Kurt Andersen (b)" <kboth@drkurt.com> Mon, 11 November 2019 15:39 UTC

Return-Path: <kurta@drkurt.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 558711208AB for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 07:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com
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 Y-RQY0Ra8sUq for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 07:39:11 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D07E1208A8 for <dmarc@ietf.org>; Mon, 11 Nov 2019 07:39:11 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id q83so15060556iod.1 for <dmarc@ietf.org>; Mon, 11 Nov 2019 07:39:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mh5UEmYeff083gHhmMqOj+m+XPFtXcJBivzNkrxKjR0=; b=JnpatvK2bYjcZ+2fH1+L394jIEm5LKe/Gw9VeJATHuPFe4Sl7Y8Vy/EML1ovUJM6Ge zCYFm/3QrD7sRD2XW6kFhhtrQnhkfFxrAYNM8/Z+DqsrHXGoUCSqletwuc2T4tMAZf5D RZ8B0EvIrCphu4sJvmASSjEbCH6jLdubcZZrE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mh5UEmYeff083gHhmMqOj+m+XPFtXcJBivzNkrxKjR0=; b=sVR+bx7LB2funGRsAYjMeNh9dfr5Sd9DEr3nCVvFNnRY9VqmCRRsyFl959Qene30hU 6I47zm60yhrRBOmr7tr2buMmAPEj9Ajyc0bgNKWD/RHgmWHM2EH0b6NdRwsjPXDveHcM Zv5UofTiWEi0O7y3rHRDFpZugETkz51ETsJWVhg6IF/oLxOB8hWnik4lvCBXXS8x/jqg CRPJkH0hNsvAQOsrcJlGYIvoG+/5fe0O1ALR2O81dLpsNWubNo3TR+EV6eCyId4pg5GM +CRzYxXlypnX2rFWykjjMQjdoMl2QglBlJ/fT4doh9xpCoah7Pjy4gP5l6uWiXzKLKkt Rqow==
X-Gm-Message-State: APjAAAWMA6EhlINjo23Apm/ZhqZ19y1mFTY7ZksG0Ts7DTVLKIWQOmXv CSz36x40qD4OtYD+hL8OjyF1FXAdjZRlme+94xdvlQ==
X-Google-Smtp-Source: APXvYqwmRT5Y24yp+TJD2DsMQOT7Mdr/nzqB0eg1aaVT7IYaGCYPotnkvBY7cftG1ERPaoHohXNXFEaTBquJiCFgMjE=
X-Received: by 2002:a6b:7e0a:: with SMTP id i10mr6376221iom.120.1573486749841; Mon, 11 Nov 2019 07:39:09 -0800 (PST)
MIME-Version: 1.0
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <CAL0qLwacbAT04tckpPcRcnOt=1QByOBeJ7uDf6rNK6NRwtxZYg@mail.gmail.com> <ffa2bf72-3024-237b-86ae-9cc04babeec6@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <CAL0qLwbp2hNrgF_xxhKRRODQ6HP=U5_K-r3Wtm1wJZOZcKup3g@mail.gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <CADyWQ+GSP0K=Ci22ouE6AvdqCDGgUAg3jZHBOg3EwCmw=QG84A@mail.gmail.com>
In-Reply-To: <CADyWQ+GSP0K=Ci22ouE6AvdqCDGgUAg3jZHBOg3EwCmw=QG84A@mail.gmail.com>
From: "Kurt Andersen (b)" <kboth@drkurt.com>
Date: Mon, 11 Nov 2019 07:38:50 -0800
Message-ID: <CABuGu1o+-32Gc5Ptmps8O-y-6gF2SMY8h8BZkbahpd4vzHs3zA@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: Scott Kitterman <sklist@kitterman.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c89426059713ee4f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ZILbCCGS4TZPh0pCMrXhvAuIZT4>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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: Mon, 11 Nov 2019 15:39:14 -0000

On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski <tjw.ietf@gmail.com>; wrote:

> Scott
>
> PSD DMARC does talk about organizational domains which from the original
> DMARC spec (section 3.2)
> does say 'Acquire a "public suffix" list'
>
> The addition of the preamble text shouldn't move the document in either
> direction.
> I do feel anything which helps focus us on moving forward on DMARC-bis is
> a good thing.
> The WG should be able to start writing the PSL document right away.
>
> Murray and I will be in Singapore if anyone wishes to speak their mind.
>
> thanks
> Tim
>
>
>
>
> On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman <sklist@kitterman.com>;
> wrote:
>
>>
>>
>> On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" <
>> superuser@gmail.com>; wrote:
>> >On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <dcrocker@gmail.com>; wrote:
>> >
>> >> > 1. The change to DMARC should be limited to permitting the query
>> >for the
>> >> > organization domain to be anywhere in the DNS tree, including a
>> >TLD.
>> >> > Within DMARC this would not look like 'extra' mechanism.
>> >> >
>> >> > 2. The mechanism that processes that query should be cast strictly
>> >as a
>> >> > PSL enhancement, independent of DMARC.
>> >>
>> >>
>> >> Trying to refine things further:
>> >>
>> >>
>> >>     DMARC does not care about the PSL.
>> >>
>> >>     What DMARC cares about is the Organizational Domain (OD), as a
>> >> fallback when no DMARC record is found at the desired domain name.
>> >>
>> >>     That is, PSL is literally outside the scope of DMARC.
>> >>
>> >>     At the least, therefore, the DMARC specification should define a
>> >> distinct interface to the outside functionality that tells DMARC
>> >where
>> >> the OD is, which will return what suffix of the full domain name is
>> >the
>> >> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>> >>
>> >>     The PSL-related side of that interface should be a separate
>> >> specification, so that changes to its behavior -- such as has been
>> >> happening with the introduction of ODs that are TLDs or are otherwise
>> >> 'above' where DMARC has been guessing the OD to be -- are isolated
>> >from
>> >> DMARC.
>> >>
>> >>     The current problems are that DMARC has embedded too much detail
>> >> about the PSL world, yet DMARC has no involvement in that world. The
>> >> current proposal embeds assumptions of PSL knowledge further, rather
>> >> than separating PSL knowledge out.
>> >>
>> >
>> >We (the chairs) fully agree with all of this.  What we -- I in
>> >particular
>> >-- have been struggling with is to find a path forward so the PSD
>> >experiment can still take place without being blocked by the need to
>> >first
>> >go back and overhaul RFC 7489 as you've described here, separating
>> >DMARC
>> >and the OD determination.  Because that'll take months.
>> >
>> >We are perhaps in the fortuitous position in our charter now that our
>> >very
>> >next work item is to take up the task of reopening DMARC itself, and
>> >the
>> >separation of function Dave is espousing could be made into a reality
>> >during that work.  Given this, we suggest that the PSD draft be allowed
>> >to
>> >proceed as Experimental, but with appropriate preamble text added to
>> >its
>> >Introduction explaining the deficiency Dave has identified.  So the
>> >order
>> >of operations becomes:
>> >
>> >* add text to the PSD draft making it clear that what it's describing
>> >is an
>> >experiment whose outcome will be taken only as feedback to the revision
>> >of
>> >the standard (i.e., this is not intended to be the final form of
>> >anything),
>> >and it is not intended to be deployed outside of the experiment's
>> >participants;
>> >* publish the experiment with those cautions and allow the experiment
>> >to
>> >begin
>> >* while the experiment is running, spin up the work on two new
>> >standards
>> >track documents, in line with our charter:
>> >a) DMARC, with PSL references replaced by the abstract notion of the OD
>> >that's determined in some non-specific way, as Dave suggests
>> >b) a PSL document that satisfies the abstract notion of OD in the DMARC
>> >document, also as Dave suggests
>> >* when the experiment completes, either augment (b) if it's still in
>> >development, or publish a revision to it, based on what the experiment
>> >has
>> >revealed
>> >
>> >Can this be made to work?
>> >
>> >Honestly, the experiment could start anyway without an RFC published,
>> >but a
>> >formal record of the experiment and its caveats doesn't strike me as a
>> >wrong thing to do.
>>
>> The current revision of the PSD DMARC draft makes no reference to the PSL
>> in the body of the draft (it only comes up in Appendix A and C).    It
>> seems like an odd choice to continue to insist PSD DMARC is specifically
>> tied to the PSL when the text indicating so has been removed (Dave's email
>> was two months ago and things have changed in the interim).
>>
>> I don't think the proposed note says anything the status of experimental
>> shouldn't already communicate.  Given the current state of the draft, I
>> don't think it's necessary to have such a note.
>>
>> Scott K
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>