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

Alessandro Vesely <> Tue, 19 April 2016 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA27012E1D7 for <>; Tue, 19 Apr 2016 09:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.298
X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t04YSoSLGLtO for <>; Tue, 19 Apr 2016 09:50:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82C1012E1D2 for <>; Tue, 19 Apr 2016 09:50:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; t=1461084622; bh=Gxq3gNmLMSRtf/cP/8odnwXD+W7AzjWW4LMKH2M0dRs=; l=3067; h=To:References:From:Date:In-Reply-To; b=WCtjQUYsB+LIfK5n5JJ5rklf1kWaBW/aAwmkZk9uWYGXPY98J9okYQn/pbiVlLUpe YuqyJShy7/9I/D8Y5ovFUTS3Nxvgp7iYpEhAHV0iNlV4j0AvdhYUYoiCccP9t6GM3c mpp/AWKFBUHbdiFsW9uTlzI4ru3ba8fXPdIo8ymY=
Authentication-Results:; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA; Tue, 19 Apr 2016 18:50:22 +0200 id 00000000005DC033.00000000571661CE.00002B7D
To: Scott Kitterman <>, AppsAWG <>
References: <> <> <> <1549185.XWxuN1SgMG@kitterma-e6430>
From: Alessandro Vesely <>
Message-ID: <>
Date: Tue, 19 Apr 2016 18:50:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0
MIME-Version: 1.0
In-Reply-To: <1549185.XWxuN1SgMG@kitterma-e6430>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Apr 2016 16:50:30 -0000

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