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

[Alessandro Vesely <[e-mail]>]

On Mon 18/Apr/2016 18:36:54 +0200 Scott Kitterman wrote:
> On Monday, April 18, 2016 01:21:16 PM Alessandro Vesely wrote:
>
>> My understanding was that RFC7410 allowed to add new ptypes as needed
>> without having to update the A-R header field name definition each time. 
>> Can you envisage what kind of change would be required in order to call A
>> DNS zone dns.zone?
> 
> 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.

> 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.

> 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.

> 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".  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.

> Iprev is connect IP plus DNS lookup.  Perhaps if you could explain why you 
> think your DNSWL proposal is something else, it would help?

A reputation provider is a globally identifiable entity.  That trait is usually
expressed referring to DNS.  By introducing the "dns" ptype, we pave the way
for storing reputation results in A-R fields.  For example, it can be reused
for a prospective "dns.rater" (RFC7071).  I think this can be done by
consensus; it doesn't seem to require that the field name be changed to, say,
Authentication-And-Reputation-Results.

Ale