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

"Murray S. Kucherawy" <> Tue, 19 April 2016 20:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6ECCD12D8B0 for <>; Tue, 19 Apr 2016 13:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ddGoN7o5EwTV for <>; Tue, 19 Apr 2016 13:42:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C450C12D543 for <>; Tue, 19 Apr 2016 13:42:51 -0700 (PDT)
Received: by with SMTP id e185so34924727vkb.1 for <>; Tue, 19 Apr 2016 13:42:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rHotYzoLklvbH/ZKoW6gnNjHJSX5EaVOsPCCL4A0u0s=; b=mJCFEGsnMdL6zWOlA/6IJyRbMJqc3eym+5LS6jchEEehR0wOYabo6eNu+CnYylGInB gul6Bb+iz8PXlii7jOmnKjdYTaHdj0ZwqKJM4reqtSCr7t3osf5oxGnd5ickWPxIpbnE A2nS3VtDSxWSos0UoaTj3zJJbFLOkTDnv3scEw0Gx1E7QCfBfEe2BvaYEFfSqeqZF4pq hfQQH5K/PbXH85y1C4DOMmddGAnDnXmIJqfDKgABHWC+CIjMHlgm5pBuhKz46akx7uR3 OcTiJeattn0QmZqfcE/YJ8EYVaJNv2NhHzOKwLzf5LPn+Z8W0YtM3L7UaQvCmNlehORX IKog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rHotYzoLklvbH/ZKoW6gnNjHJSX5EaVOsPCCL4A0u0s=; b=Edq4YOvLAw4bIiUFURwFm41ta4MY7c5Olnh+aAmEbowVzl/3uoYYTfhXxVfNInleHh 5wjnkPS5dqt8VDqib+TrGNOsoTLPwnywmrwrHuJbKQGWQifEvScilL2PlYQH2fesNZlx R0UdxERh+y1vzxNfCmFZ8eQZdlXsV+liLpfhm9mt+EHYTKjJoVx1rrbNga2u5VYSmFG8 E/5NQNTcsfkut9CTvxx8ejp3nH6EZpJcODImGO7iPwyNqr6G9D1IXWr6FdlSP9J1Aogg TH1EqUPnszWe0nFxq7eVLD04ZX35pHxY95EQwU65UkPrCEC4CLzaf50J2NSm7jRuSIBR vd7w==
X-Gm-Message-State: AOPr4FWZKpke29k4ABmRRIYH3kQ8ltA63LMZ0u3V7huRjSM9vf4eiIS7Cpj5EeXK9y3l1O0obSchplVlhlUq1w==
MIME-Version: 1.0
X-Received: by with SMTP id z11mr2810893vkd.131.1461098570813; Tue, 19 Apr 2016 13:42:50 -0700 (PDT)
Received: by with HTTP; Tue, 19 Apr 2016 13:42:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <1549185.XWxuN1SgMG@kitterma-e6430> <>
Date: Tue, 19 Apr 2016 13:42:50 -0700
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: Alessandro Vesely <>
Content-Type: multipart/alternative; boundary=001a1140f86a4b99360530dc85ea
Archived-At: <>
Cc: Scott Kitterman <>, AppsAWG <>
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 20:42:54 -0000

On Tue, Apr 19, 2016 at 9:50 AM, Alessandro Vesely <> 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}{}

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

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.