Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-psd-12: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 11 May 2021 04:24 UTC

Return-Path: <kaduk@mit.edu>
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 727E53A0799; Mon, 10 May 2021 21:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 yNzWNiwKEQCq; Mon, 10 May 2021 21:24:43 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C85E73A0789; Mon, 10 May 2021 21:24:42 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14B4OW3R014601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 May 2021 00:24:38 -0400
Date: Mon, 10 May 2021 21:24:31 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, IETF DMARC WG <dmarc@ietf.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <20210511042431.GP79563@kduck.mit.edu>
References: <161898146809.1659.6234265375858401838@ietfa.amsl.com> <CADyWQ+F3_tf6QobPnPvb4rgyxZb9vhDsm56iOva0JuYmfO8z-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADyWQ+F3_tf6QobPnPvb4rgyxZb9vhDsm56iOva0JuYmfO8z-g@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/0phQo8ICjfyHHXPrJYVNMQy-KyY>
Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-psd-12: (with DISCUSS and COMMENT)
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: Tue, 11 May 2021 04:24:49 -0000

Hi Tim,

On Mon, May 10, 2021 at 04:45:02PM -0400, Tim Wicinski wrote:
> Ben
> 
> On Wed, Apr 21, 2021 at 1:04 AM Benjamin Kaduk via Datatracker <
> noreply@ietf.org> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dmarc-psd-12: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > There seems to be a bit of internal inconsistency in Appendix B.2:
> >
> >    Names of PSDs participating in PSD DMARC must be registered this new
> >    registry.  New entries are assigned only for PSDs that require use of
> >    DMARC.  [...]
> >
> > These two sentences seem to be in conflict, since a PSD can participate
> > in PSD DMARC without requiring use of DMARC for all its subdomains.  The
> > rest of the section is clear that the registry is only intended to be
> > for PSDs that do require the use of DMARC for subdomains, so I expect
> > that a minor tweak to the wording of "PSDs participating in PSD DMARC"
> > would be an appropriate fix.
> >
> >
> I reworded these two sentences to say:
> 
>     PSDs that are deploying DMARC and are participating in PSD DMARC
>     must register their public suffix domain in this
>     new registry.
> 
> 
> Does this sound better ?

That's at least locally better, though I seem to have lost some of the
context as to what the rest of the section says.

> 
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > This document is generally in pretty good shape; my comments (and,
> > to some extent, my discuss as well) are pretty minor points.
> >
> > Thanks to Sandra Murphy for the secdir review.  I think there were some
> > questions in there that are worth a response and possibly clarifications
> > in the document.
> >
> >
> Sandra did a strong review and I believe we worked through the issues
> raised.

I'm happy to hear it; I may have just been misled by the mailarchive entry
for the secdir list.

> 
> > Section 1.2
> >
> > It seems like the "branded PSD" and "multi-organization PSD" cases would
> > benefit from a protocol-level indication and separate handling by
> > message recipients.  It seems likely that the newly defined np (in
> > combination with the preexisting sp) provides the flexibility to
> > describe the different cases, but it seems like it would be helpful to
> > have some discussion in this document that relates these two cases to
> > the actual protocol mechanisms used to achieve them.
> >
> >
> There is no different handling of between a "Branded PSD" and a
> "multi-organization PSD".  The difference is highlighting the types.

I think I agree that the actual mechanics of handling the protocol
elements, if they exist, shouldn't really differ for the two cases.  It
seems that there may be some subjective differences, though, in that it
would be really surprising if the "multi-organizational PSD" decided to
publish policy for existant subdomains, whereas for branded PSDs that is
normal and expected, since in some sense they really ought not be PSDs at
all.

> 
> > Section 3
> >
> > As Lars and Éric already commented, I suggest using a phrasing that
> > includes something like "this experiment" and maybe "proposes", since
> > actually formally updating the DMARC specification would procedurally be
> > a bit exciting.
> >
> >
> I've updated this text.
> 
> Section 3.2
> >
> >    np:  Requested Mail Receiver policy for non-existent subdomains
> >       (plain-text; OPTIONAL).  Indicates the policy to be enacted by the
> >
> > I assume that "subdomains" here refers only to direct children (i.e.,
> > one additional label), not deeper in the hierarchy.  It's not entirely
> > clear to me whether all readers will do likewise, though...
> >
> >
> It is the direct subdomain.   There is discussion inb RFC7489 if a subdomain
> does not have a _dmarc DNS record, the _dmarc record at the parent domain is
> query/used.

(I'm happy to defer to you on whether adding more text to the document to
clarify this is warranted.)

> 
> > Section 3.3, 3.6
> >
> > It sounds like this entire paragraph is appended to the section?
> > In other subsections we are a bit more explicit about where the new text
> > is going and what part is the new text.
> >
> >
> I added this text to the beginning of each paragraph:
> 
>     If this experiment is successful, this paragraph is added to this
> setion.
> 
> Does that help?

Yes, thanks.  (IIRC it doesn't really matter logically "where" it is added,
in these cases.)

> 
> 
> > Section 4.1
> >
> >    o  Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
> >       usage: Privacy risks for Organizational Domains that have not
> >       deployed DMARC within such PSDs are significant.  For non-DMARC
> >       Organizational Domains, all DMARC feedback will be directed to the
> >       PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
> >       Organizational Domain level) vice opt-in, which would be the more
> >       desirable characteristic.  This means that any non-DMARC
> >       organizational domain would have its feedback reports redirected
> >       to the PSO.  The content of such reports, particularly for
> >       existing domains, is privacy sensitive.
> >
> > It might be worth making some statement about the applicability of PSD
> > DMARC for such PSDs that do not mandate DMARC usage.  (I guess the
> > following paragraphs mostly play that role, though perhaps editorially
> > tying them together more clearly is possible.)
> >
> 
> I'm not sure where you're going on this, but the following paragraphs do
> try to pull it together.  I've been trying to wordsmith these with little
> luck.
> 
> Also, it appears that the word "vice" above should be "versus".

I suspected it might :)

Maybe the following is useful input to your wordsmithing attempts:

By definition the new mechanisms in this document result in PSDs receiving
feedback on non-existent domains.  However, these non-existent domains may
be similar to existing Organizational Domains, and as mentioned above,
feedback on existing organizational domains is privacy-sensitive.  To
minimize the risk of privacy-sensitive information relating to existing
organizational domains being sent to the parent as feedback on a similar
non-existent domain, PSD DMARC feedback MUST be limited to Aggregate
Reports.  Feedback Reports carry more detailed information and present a
greater risk.

> 
> 
> > Or, in the vein of my comment on section 1.2, an explicit protocol
> > mechanism could be introduced that limits the reporting to just the
> > indicated (public suffix) domain and does not apply to subdomains.
> >
> >    organizational PSDs MUST be limited to non-existent domains except in
> >    cases where the reporter knows that PSO requires use of DMARC.
> >
> > Do we have examples of how the reporter might come to know this?
> > Say ... Appendix B.2?
> >
> >
> Roman raised a similiar point.   I was thinking of adding
>     "(by checking the DMARC PSD Registry)"
> 
> or would a full sentence be used to bring the point back home?

I don't see a need for a full sentence.  I would check whether an "e.g." is
warranted, vs the registry being the only way to do so.

> 
> 
> > Appendix A
> >
> >    o  Section 3.2 adds the "np" tag for non-existent subdomains (DNS
> >       NXDOMAIN).  [...]
> >
> > Per §2.7, this is for NXDOMAIN or NODATA, not just NXDOMAIN.
> >
> >
> NODATA is returned when there are Resource Records there, but nothing
> matches the request.  Since the DMARC is a TXT record of the form
> _dmarc.<subdomain>, there will never be any other resource record at
> that location.


Ah, this is what I get for just reading and not thinking, good point :)


> 
> 
> 
> > Appendix B.1
> >
> >    A sample stand-alone DNS query service is available at
> >    [psddmarc.org].  It was developed based on the contents suggested for
> >
> > "DNS query service" is so generic so as to be almost meaningless.  Even
> > if we defer usage instructions to the external site, we should probably
> > say a bit more about what it is expected to do.
> >
> I tend to agree with you here.  The only other options I could come
> up with is "PSD DMARC Lookup service".    I'll try a few others.

Thanks,

Ben