Subject: [dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC

From: Vlatko Salaj <[email-masked]>
Date: Sun, 8 Jun 2014 02:13:09 -0700 (PDT)

i consider my 3rd party alignment support for DMARC
easy to understand, trivial enough to deploy and
useful enough to cover many use cases, so i would
like to move it to IETF as a, probably, independent
RFC.

does anybody here see interest in helping me out
with this procedure? u should have good english skills,
and at least some xp with RFCs.

be free to contact me if u do.

btw, mr. Hector, would u be so kind to include my
version of the proposal on ur test-page at:
http://www.winserver.com/public/wcDMARC/default.wct

my proposal is quite similar to what u call ASL and
if we agree to merge our two proposals together to at
least some degree, i may actually adopt ASL as a
name for new version, but rename it to
Aligned Sender List.

since ur ASL logic and my ASL logic r similar enough
to merge, it could be beneficial to both proposals,
adding some traction to other, more, advanced 3rd
party support, for cases where ASL is insufficient.

also, that may be a start of a working cooperation
for a true, full-fledged 3rd party DMARC standard,
assimilating* ASL or in addition to ASL.

[*] borg anybody? :D

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Vlatko Salaj <[email-masked]>
Date: Sun, 8 Jun 2014 02:16:35 -0700 (PDT)

> like to move it to IETF as a, probably, independent

if u missed it, it's here, more or less, defined:

http://www.ietf.org/mail-archive/web/dmarc/current/msg01079.html

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 Jun 2014 10:03:01 -0400

> assimilating* ASL or in addition to ASL.

Hi Vlatko,

Overall, the problem is backward compatibility. When we try to extend 
an existing protocol,  we need to consider the basic implementation 
"ignorance" of any new extended logic.

This is why "asl=" and the "atps=" tags are separate from existing 
tags.  With the proposed idea to extend "adkim=" and "aspf=", it (the 
syntax parsing) can fail with existing systems.

Such situations are suppose to be ok for such protocols language; 
unknown tags are to be ignored, not a failure, otherwise the whole 
extension concept allowed by the specification is a wash. Won't work 
well at all.  But this is different from attempting to use a syntax 
error as an extended logic.

Doing a quick search for "unknown" in the dmarc draft rev4...

    5.2 General Record Format

    DMARC records follow the extensible "tag-value" syntax for DNS-based
    key records defined in DKIM [DKIM]].

    Section 16 creates a registry for known DMARC tags and registers the
    initial set defined in this memo.  Only tags defined in this memo or
    in later extensions, and thus added to that registry, are to be
    processed; unknown tags MUST be ignored.

    ...

    A DMARC policy record MUST comply with the formal specification found
    in Section 5.3 in that the "v" and "p" tags MUST be present and MUST
    appear in that order.  Unknown tags MUST be ignored.  Syntax errors
    in the remainder of the record SHOULD be discarded in favor of
    default values (if any) or ignored outright.

So in DMARC protocol theory:

   o unknown tags MUST be skipped, ignored,
   o syntax errors SHOULD be ignored in favor of its defaults.

This is ok software logic, but you have to watch the latter one.  In 
practice, syntax errors can be a problem. It also has security 
implications, i.e. DoS-like attacks, overwhelming you with invalid 
syntax processing overhead that the operator is forced to turn off the 
DMARC processor.

But extending an existing tag is almost guaranteed to be a parsing 
problem to be expected at some processor.  It depends on the 
sophistication of the implementation, can't assume everyone is using 
the same "DMARC library."

Generally for an extension of an existing tag=value, this is where you 
would change the v=DMARC1 version number to something else, i.e. 
v=dmarc1.1, v=dmarc2, etc.

To provide an example, here is a general outline for simple token base 
parser for something like this:

  string rec = GetDMARCRecord(Author.Domain)

  do while rec has something
     string value = GetNextTag(rec,";") // rec has remaining string
     string tag   = Split(value,"=")    // value has remaining string
     case lowercase(tag) of
      "v"       : process_v(value)     // check version
      "adkim"   : process_adkim(value)
      "aspf"    : process_aspf(value)
      "fo"      : process_fo(value)
      "rua"     : process_ruf(value)
      "ruf"     : process_ruf(value)
      "pct"     : process_pct(value)
      "p"       : process_p(value)
      ....
     end case
  end do

The process_adkim(value) logic will MOST LIKELY only have the logic 
that has been specified in the DMARC draft which is check a value of:

     "r"
     "s"

and nothing more.

If DMARC developers had envisioned such extended value needs, it would 
allowed for such things as your idea.  But in general, its not typical 
to see this for many reasons, and within the IETF, it will be pointed 
out that simple string parsing is better.

On the other hand, one may also suggest that since we are doing this 
more and more with this format for many new DNS based single line 
command tag-based language applications,  maybe we should have a 
formal IETF language syntax for such protocols so intelligent advanced 
tag-based parsers can be written.

But it would be more complex and since the same functionality can be 
accomplished with the advanced reader required anyway, you might was 
well just propose a new tag, like:

    "adkimx="

Finally, you would need to do feasibility test to make sure there is 
no compatibility problem.  I have not seen a problem with the various 
domains using "atps=y" or "asl=y" yet but who knows if there are some 
DMARC sites with software parsers that see the unknown tags and well, 
skip the entire record, do nothing in the name of avoid the possible 
"DoS" overhead processing attacks.  It would be a 'violation' of the 
spec but there still needs to be a feasibility test because if most of 
the sites are violating the spec in this regard, then we have a 
protocol specification implementation "bug" and generally, in cases 
like this, we begin to consider "codifying" the actual industry 
behavior in the updated DMARC draft to whats actually seen.

    - SHOULD|MAY ignore unknown tags
    - MAY throw an exception (abort processor)

Then we will get into debates on what it means to throw an exception 
and do we need to control it, limit it, track it, report it, block 
abusers, etc.

Can we use a different tag for your proposal?

-- 
HLS

---

From: Vlatko Salaj <[email-masked]>
Date: Mon, 9 Jun 2014 01:04:44 -0700 (PDT)

> Can we use a different tag for your proposal?

Hector, i'll give u one thing for sure: u do like to
make ur replies as detailed as possible.

i do respect that actually, cause it shows that u
give a damn, and that u r a perfectionist, both
traits that r actually somewhat of a requirement
in development of things such a standards.

but u may, especially if u r pressed with time,
make it as shirt as much u like, and hope my brain
is developed enough to fill all the blanks on its own.

and i'll do my best to surprise u.

that said, i understand all the technical burden
of possible incompatibility, which u were kind enough
to cover in ur reply. but i hope DMARC implementers
followed DMARCv1 specs and r making version checks
before they actually process aspf and adkim tags,
the way spec requires them to.

i do not want to lower my ambitions cause of fear of
bad DMARC implementation out there. bugs r to be
addressed by their developers.

so, the question, imo, is what is better:

1. to be as much compatible as possible with v1,
   essentially making as little disruption as possible,
   but risking to be ignored on long run, and

2. to be blunt and request a version replacement,
   hoping for overall approval, thus moving v1 to
   legacy.

imo, changing the way alignment works, ESSENTIALLY
changes the basic logic, based on a SINGLE domain
virtue.

by extending it to cover whatever domain-owner wants
covering, alignment now becomes a TRUST logic, and,
imo, that is a sufficient reason to actually go
bluntly forward and make space for DMARCv2,
possibly as a 1st step for any future IETF WG to base
its work on.

yeah, i know this is ambitious. and may as well be
ignored as SPF2 was. but i hope we learned from
past mistakes, and instead i choose to be positivist
about it and hope ppl will find DMARCv2 an upgrade
in right direction.

beside those clearly political motives, imo, there
r technical ones:
1. adding "none" to alignment logic requires changes
   in aspf/adkim tags, and i think "none" is valued
   enough to warrant it for domain-owner too,
   not just 3rd party,
2. there's a need to treat ASL domains separately for
   SPF and DKIM, cause some domains may need something
   like "aspf=n:urdomain.com adkim=s:urdomain.com",
3. adding new tags is less optimized than using old tags,
   essentially cause it uses more characters, in a limited
   DNS record space.

all that being said, we can do both:

1. make a DMARC version 1.1, which would use
   aspfx and adkimx, and won't introduce "none" for
   domain-owner; merely to have a test online, and
   to see if there's something we miss in the concept space,
   but also as a fallback if v2 is completely dismissed
   by community,

2. make a DMARC version 2 draft, which would go my
   original proposal for aspf and adkim, and which
   we would advertise as a more optimized, stable
   solution, working towards inclusion of a more complex
   and scalable 3rd party support [i'm considering TPA-Label],
   in addition to ASL, thus adding more weight to
   the proposed version upgrade.

be free to reply as detailed as u like. i'm happy we r
moving on this, anyhow.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Vlatko Salaj <[email-masked]>
Date: Mon, 9 Jun 2014 23:42:11 -0700 (PDT)

On Monday, June 9, 2014 10:04 AM, Vlatko Salaj <[email-masked]> wrote:

> more complex and scalable 3rd party support
> [i'm considering TPA-Label],

i would like to know if anybody on this
list was persistent enough to reread TPA-Label
draft as many times as needed to fully grasp
its operational logic?

it's here:
https://datatracker.ietf.org/doc/draft-otis-tpa-label

-- 
Vlatko Salaj aka goodone
http://goodone.tk