Subject: Re: [dmarc-ietf] New authentication method, DNSWL

From: Scott Kitterman <[email-masked]>
Date: Thu, 01 Aug 2019 00:40:18 -0400

On Thursday, June 27, 2019 5:10:39 AM EDT Alessandro Vesely wrote:
> On Wed 26/Jun/2019 22:27:46 +0200 Murray S. Kucherawy wrote:
> > On Tue, Jun 4, 2019 at 4:01 AM Alessandro Vesely <[email-masked]> wrote:
> >> Appendix D1 of rfc7208 mentions DNSWL as a way to mitigate SPF's
> >> reject-on-fail.  The score attributed to the sender by a trusted DNSWL is
> >> also useful after DATA, thence the need to store that value for
> >> downstream filters.>>
> >> However, as an authentication method, a DNSWL TXT response can provide a
> >> domain name, which is possibly aligned with From:.  In that sense, this
> >> method might be of interest for this WG.  Probably not, but I felt
> >> compelled to make sure before trying independent submission.  (Already
> >> tried ART.)  The I-D is here:>>
> >> https://tools.ietf.org/html/draft-vesely-authmethod-dnswl> 
> > With my Designated Expert hat on and co-chair hat off, a procedural point
> > here:
> > 
> > The IANA registry for these is Expert Review, which means you don't have
> > to
> > publish an RFC to get it registered.  You can, but it's not necessary if
> > your registration request can sufficiently describe what you're doing. 
> > See
> > RFC8601 Section 6.2, fourth paragraph.
> 
> I just submitted the form attached.  This path seems to be quicker.  Thanks.
> 
> 
> Let me paste the parameters, for list readers, and point out that dnswl can
> yield a domain name like, e.g., policy.txt=example.com.  Whether the domain
> name alignment can be meaningful or not is the reason why this topic appears
> on this list.
...
> 
>    | ptype | Definition | Description                                  |
> 
>    +-------+------------+----------------------------------------------+
> 
>    | dns   | [this doc] | The property being reported belongs to the   |
>    | 
>    |       |            | Domain Name System                           |

Can we discuss this choice?  I know this has been implemented already, so I'm 
at least slightly reluctant to do the semi-standard lets rename existing stuff 
dance that the IETF often does, but I really don't like this.  There isn't an 
email authentication system out there that doesn't rely on DNS.  I think DNS 
as a ptype is way too broad.

Also, if I rsync a copy of the list and process it locally, is it still OK to 
use the dns ptype when there is no DNS involved?

What about something like extpolicy: The property reported relates to an 
external policy input?

Would you be willing to do something like that?  If so, I think we could also 
register dns, but with status of decprecated since it's in use and documenting 
in use stuff is good.  Then Courier can change at some point when it's 
convenient, but still be using a registered paramet.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Jul 2019 22:27:10 -0700

> convenient, but still be using a registered paramet.

<designated expert hat on>

Thanks for commenting on this.  I'm overdue to provide a review and
feedback.

I rejected this application prior to RFC8601 primarily because the language
used then to restrict what goes in the registry didn't allow for
registrations of stuff that wasn't actually part of the message, and a DNS
whitelist or blacklist result is not (nor for example is the client IP
address, or the result of any query entirely external to the message body,
header, or even envelope).  The good news is that the language of RFC8601
is more relaxed, in particular in Section 2.3 it allows for a
property/ptype that covers "some other aspect of the message's handling",
so that's no longer a blocking factor.

To counter Scott's point, "dns" is a ptype that would exist within the
method of "dnswl", so I think it's hard to see how it could be
misinterpreted.  But I'd like to see how this discussion plays out.  I can
see his point about "dns" being a rather broad ptype.

Appendix C of RFC8601 goes to some length to discourage the practice of
including all the details that were inputs to the evaluation, specifically
because the result of the evaluation at the border MTA is the only thing
that should matter.  I thus have some trouble understanding why "policy.ip"
and "policy.txt" are desirable things to include.  And even if that were
not true, I'm concerned that "policy.ip" could be interpreted as an IP
address even though that's manifestly not what this is.

Nevertheless, Scott's point about documenting current use is well taken and
I like his idea in principle.  The only concern I have is that allowing
this directly into a "deprecated" status still reserves the name "dns"
should anyone later devise a use for it that's appropriate in breadth.  I
suspect though we could just ask IANA to register both, one deprecated and
one current, should that somehow ever come to pass.

Alessandro, others: Comments?

-MSK