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

From: Alessandro Vesely <[email-masked]>
Date: Wed, 13 Apr 2016 20:01:41 +0200

On Mon 04/Apr/2016 23:11:22 +0200 Murray S. Kucherawy wrote:
> On Mon, Apr 4, 2016 at 9:20 AM, Alessandro Vesely <[email-masked]> wrote:
> 
>> Can people subscribe to iana-prot-param-comment's?
> 
> Not without just starting to Cc: them (i.e., it's not a list or UI I can
> access), but I'm also not sure it's a good idea to burden their ticketing
> system with a lot of traffic; they don't need to be involved at this phase.

The traffic is not so much.  The problem is it doesn't seem to be publicly
accessible.

> If you want to discuss this in a public forum, [email-masked] is
> certainly a valid choice.  If you want to seek publication via the IETF
> stream (which seems a legitimate thing to do), I would eventually move it
> to [email-masked].

Hm... adding CC AppsAWG.  Let's see if anybody is interested.

I still don't think it is worth publishing the I-D, but maybe IETF's list
archives can be considered permanent documents, which can be referenced by
items added after Expert Review, no?

> I had a look at your -04.  Thank you for addressing most of my comments and
> suggestions; it's certainly better.  A few non-editorial issues remain:
> 
> - The original ptype.property list has not been updated as discussed, so
> the main problem remains.

The "dns" ptype has its own table there.  Added a more text.  I don't think
this is a useless ptype, since so much stuff is DNS-based...

> - You might want to include an example of use, perhaps in an appendix or in
> a new Section 2.1, so people can see what's going on.

A bare example was there already.  Fully expanded.

<pissed off>
So delighted of the new text, I managed to screw up policy.txt, which is
exactly what was to be exemplified :-/

It should read:

  Authentication-Results: mta.example.org;
      dnswl=pass dns.zone=list.dnswl.example
      policy.ip=127.0.10.1
      policy.txt="fwd.example http://fwd.example/s?s=100"

</pissed off>

> - You mention the need to "determine the color of x".  Doesn't an MTA
> making a query to a DNSxL know what the color of "x" is already?

Yes.  This is detailed in the last paragraph of the example (A.1).

> - Section 2 changed "fail" to "none", but Table 3 in Section 3 did not.

Thanks.

> - There is now a reference to RFC7719, but no use of that reference
> anywhere in the body of the document.

Dropped.

Ale

-------- Forwarded Message --------
Subject: New Version Notification for draft-vesely-authmethod-dnswl-05.txt
Date: Wed, 13 Apr 2016 10:19:28 -0700
From: [email-masked]
To: Alessandro Vesely <[email-masked]>

A new version of I-D, draft-vesely-authmethod-dnswl-05.txt
has been successfully submitted by Alessandro Vesely and posted to the
IETF repository.

Name:		draft-vesely-authmethod-dnswl
Revision:	05
Title:		DNSWL Email Authentication Method Extension
Document date:	2016-04-13
Group:		Individual Submission
Pages:		7
URL:
https://www.ietf.org/internet-drafts/draft-vesely-authmethod-dnswl-05.txt
Status:         https://datatracker.ietf.org/doc/draft-vesely-authmethod-dnswl/
Htmlized:       https://tools.ietf.org/html/draft-vesely-authmethod-dnswl-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-vesely-authmethod-dnswl-05

Abstract:
   This document describes an additional Email Authentication Method
   compliant with RFC 7601.  The method consists in looking up the
   sender'IP in a DNS whitelist.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Apr 2016 11:15:04 -0700

> items added after Expert Review, no?

That seems... unconventional at least.  I would rather see something
published.  Going via the ISE, if you're worried about the slog through the
IETF Stream, seems like a perfectly viable option.

> this is a useless ptype, since so much stuff is DNS-based...

I explained in my previous replies why I don't think "dns" is a viable
choice for a ptype.  I never said it was "useless", but it doesn't fit
within the framework described by RFC7601 or its antecedents.  I proposed
an alternative that I claim does fit.  Have you rejected it?

> A bare example was there already.  Fully expanded.

It looks great, modulo the issue above.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 16 Apr 2016 17:20:52 +0200

> IETF Stream, seems like a perfectly viable option.

I think that is called RFC Required, not Expert Review.

>>> I had a look at your -04.  Thank you for addressing most of my comments 
>>> and suggestions; it's certainly better.  A few non-editorial issues
>>> remain:
>>>
>>> - The original ptype.property list has not been updated as discussed,
>>> so the main problem remains.
>>

Yes, I rejected your proposal to use policy.zone=lists.dnswl.example, because
it disagrees with the only existing implementation.  When that was discussed,
the syntax dns.zone=lists.dnswl.example was chosen because a DNSxL is a zone in
the DNS, according to, say, RFC5782.  Nobody realized that "dns" is not a valid
RFC7601 ptype (and I still don't understand why).

Since I'm neither the maintainer of the existing implementation, nor the only
user of that feature, I cannot change the syntax arbitrarily.  Making a
registration that disagrees with the terrain seems pointless to me.

Ale

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 16 Apr 2016 08:38:24 -0700

[dropping the IANA address because it keeps creating tickets in their
system]

> I think that is called RFC Required, not Expert Review.

It would if I had asserted that you have to publish an RFC, but that's not
what I said.  I was making a suggestion about one way to publish it, and
since you already have a draft, you're part way there.

Yes, I rejected your proposal to use policy.zone=lists.dnswl.example,
> because

I've gone over the "why" with you at some length both at the Berlin meeting
and now on a thread subsequent to your request to IANA.

While I'm sympathetic to some degree with the "installed base" argument, I
don't think it's reasonable to accept a registration that doesn't fit
within the defining RFC merely because there's a single existing incorrect
implementation.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 16 Apr 2016 12:10:47 -0400

On April 16, 2016 11:38:24 AM EDT, "Murray S. Kucherawy" <[email-masked]> wrote:
>> > On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely
><[email-masked]>
>> wrote:
>> >
>> >> I still don't think it is worth publishing the I-D, but maybe
>IETF's
>> list
>> >> archives can be considered permanent documents, which can be
>referenced
>> by
>> > published.  Going via the ISE, if you're worried about the slog
>through
>> the
>> the syntax dns.zone=lists.dnswl.example was chosen because a DNSxL is
>a
>> zone in
>> the DNS, according to, say, RFC5782.  Nobody realized that "dns" is
>not a
>> valid

While I normally give pragmatic arguments (like alignment to existing practice) a lot of weight, in this case I agree with Murray that it would be a mistake.

If you look at the discussion of iprev in http://tools.ietf.org/html/rfc7601#section-2.7.3 it covers the exact same ground as this proposal with regards to ptype selection.  I believe it's clear that policy is the correct choice.

In order to add the proposed new ptype, I think the ptype definition in http://tools.ietf.org/html/rfc7601#section-2.3 would have to be changed and that would require a standards track update to RFC 7601.  I don't think you want to go down that path.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Apr 2016 13:21:16 +0200

On Sat 16/Apr/2016 18:10:47 +0200 Scott Kitterman wrote:
>>> because it disagrees with the only existing implementation.  When that
>>> was discussed, the syntax dns.zone=lists.dnswl.example was chosen
>>> because a DNSxL is a zone in the DNS, according to, say, RFC5782.
>>> Nobody realized that "dns" is not a valid RFC7601 ptype (and I still
>>> don't understand why).
>>
>> I've gone over the "why" with you at some length both at the Berlin 
>> meeting and now on a thread subsequent to your request to IANA.
>>
>> While I'm sympathetic to some degree with the "installed base" argument,
>> I don't think it's reasonable to accept a registration that doesn't fit 
>> within the defining RFC merely because there's a single existing 
>> incorrect implementation.
> 
> While I normally give pragmatic arguments (like alignment to existing
> practice) a lot of weight, in this case I agree with Murray that it would be
> a mistake.
> 
> If you look at the discussion of iprev in
> http://tools.ietf.org/html/rfc7601#section-2.7.3 it covers the exact same
> ground as this proposal with regards to ptype selection.  I believe it's
> clear that policy is the correct choice.

I guess you mean the paragraph:

   The result is reported using a ptype of "policy" (as this is not part
   of any established protocol) and a property of "iprev".

That looks like an explanation of the naming, it doesn't seem to mandate that
every ptype must be "policy" unless the related property belongs to an
established protocol.  The definition of "policy" in Section 2.4 differs.

Would a name like, say, client.ip=192.0.2.1 have been an equally valid choice?

> In order to add the proposed new ptype, I think the ptype definition in
> http://tools.ietf.org/html/rfc7601#section-2.3 would have to be changed and
> that would require a standards track update to RFC 7601.  I don't think you
> want to go down that path.

>From that definition it is not clear if or why a method is bound to use at most
one ptype.

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?

Ale

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Apr 2016 06:58:48 -0700

> established protocol.  The definition of "policy" in Section 2.4 differs.

In what way?

> Would a name like, say, client.ip=192.0.2.1 have been an equally valid

I think it would.

> From that definition it is not clear if or why a method is bound to use at

There is no such restriction.

> envisage what kind of change would be required in order to call A DNS zone

There would have to be a property of the message derived from the DNS.  The
property you're trying to report, i.e. the name of the DNSWL you queried,
is a local configuration choice rather than something extracted from either
SMTP or the message itself, so it falls squarely within the definition of
"policy".

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 18 Apr 2016 12:36:54 -0400

On Monday, April 18, 2016 01:21:16 PM Alessandro Vesely wrote:
> > practice) a lot of weight, in this case I agree with Murray that it would
> > be a mistake.
> > 
> That looks like an explanation of the naming, it doesn't seem to mandate
> that every ptype must be "policy" unless the related property belongs to an
> From that definition it is not clear if or why a method is bound to use at
> most one ptype.
> 
> 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.  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).  

This is exactly the same situation as your DNSWL proposal, so I see no reason 
to treat it differently.  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.

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

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Apr 2016 18:50:22 +0200

On Mon 18/Apr/2016 18:36:54 +0200 Scott Kitterman wrote:
> 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.

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

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Apr 2016 13:42:50 -0700

> highlights the possibility to alter the result of established protocols,

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.

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

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

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

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