Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Apr 19, 2016 at 9:50 AM, Alessandro Vesely <[e-mail]> wrote:

> > The definition of ptype includes:
> >
> >    The "ptype" in the ABNF above indicates the general type of property
> >    being described by the result being reported, upon which the reported
> >    result was based.  Coupled with the "property", which is more
> >    specific, they indicate from which particular part of the message the
> >    reported data were extracted.
> >
> > The exception to ptype + property indicating which particular part of the
> > message from which the data is extracted is policy.
>
> Section 2.4 does not present "policy" as an exception in that sense.  It
> highlights the possibility to alter the result of established protocols,
> and
> the local nature.
>

The very reason "policy" has its own section of the document is because it
is an exception.  You're doing something -- reporting a local configuration
parameter with no context outside of the receiving ADMD -- that's not
specified as part of some other protocol, and identifies something not
found in the message.  Currently, a DNSWL lookup fits both of those
criteria.  Even if we register "dnswl" as a method, the latter point
remains true.

The example given in that section actually shows what I would think of as
an ideal use of "dnswl", namely:

Authentication-Results: dnswl={pass/fail/whatever}
policy.zone={your.dnswl.here}

"policy.zone" is augmenting the "dnswl" result by providing additional
local data.  The zone itself is not part of the message, so it's not a
candidate for a dedicated ptype.


> > Iprev falls into policy specifically because (IMO) there is nothing
> > extracted from the message.  All the information is from the IP
> connection
> > (i.e. the address) and from DNS (the rdns lookup).
>
> It seems the concept of "policy" was stretched a bit in order to
> accommodate
> that fact.  Both ptype and property sound wrong in "policy.iprev".  That
> undoubtedly constitutes a precedent.  I agree it would be smoother to use
> "policy.zone" on that basis.
>

I disagree.  "policy" was used for "iprev" precisely because the IP address
isn't part of a message payload.  That wasn't a "stretch".  You could argue
that it should've been "policy.ip" or "policy.client_ip" or some such, but
no objection was raised when the document was in development.

To continue with the comparison with "iprev", however, note that it makes
no attempt to report from which nameserver the answer came.

> This is exactly the same situation as your DNSWL proposal, so I see no
> reason
> > to treat it differently.
>
> Iprev differs inasmuch as it doesn't require a reputation provider.  These
> three methods, SPF, iprev, and dnswl, all stem from the client IP and
> deliver
> results on the basis of DNS queries.  However, only dnswl presents a
> choice of
> provider, and only SPF is an authentication method.
>

I suggest that SPF is answering a different question: "Was use of <domain>
in this message authorized?"  The actual mechanism does take the IP address
as one of its inputs, of course, but it's not the datum in which a consumer
of this information is really interested.


> > Furthermore, I think that paragraph would need to be changed (and not via
> > errata) to broaden the ptype definition to do what you propose, so even
> if I
> > thought a dns ptype was appropriate, it couldn't just be added to the
> > registry.
>
> I'm unable to find a passage in RFC7601 that forbids adding "dns".


Please try again, starting with the first paragraph of Section 2.3 (cited
above).  It doesn't seem weak or ambiguous to me, especially given the
registrations that exist and the numerous examples present in production
and in the document.

I agree there are several indications, such as references to "part of the
> message",
> that may suggest "dns" is not a valid ptype.  But then the same is true for
> "policy", and it is not stated that the introduction of another special
> ptype
> requires the specs to be changed.
>

As I said above, and Scott also said, "policy" is defined as an exception
ptype.

It boils down to "ptypes are for reporting X, except for 'policy', which is
for reporting Y".  You can introduce as many ptypes as you like into the
registry that are for reporting things described as "X" without updating
the RFC.  To change "X" to accommodate your use case, however, there needs
to be an update to RFC7601, and thus a compelling reason to spin up that
effort.  Speaking for myself, I don't see that here given the absence of
demand, the availability of suggested alternatives that do fit within the
existing framework, and your concessions above that the suggestions would
indeed be smoother.

-MSK