Re: [ietf-822] WSJ/gmail/ML, was a permission to...

[Hector Santos <[e-mail]>]

On 5/3/2014 8:35 PM, Michael Richardson wrote:

> So, how in the world does this scale to having thousands of "trusted" mailing
> lists?  Seriously.

We won't know if we don't try it.  Of course, there is a management 
issue, but its doable. Simple but new DNS tools are needed. Surely, 
DNS is robust enough it.

>      > and there would be 30,000 ATPS records for all the purported list that
>      > yahoo says their users are members of.
>
> okay, but how would they have fit into that _adsp record?

It would not fit within a "asl=" tag list of course, but ATPS records 
would be used for a larger scale.   For example, for isdg.net I have 
the following records:

_adsp._domainkey        TXT	( "dkim=all; atps=y; 
asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecoffee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;" 

e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT   ( "v=atps01; 
d=megabytecoffee.com;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT   ( "v=atps01; 
d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT   ( "v=atps01; d=gmail.com;" )
n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT   ( "v=atps01; 
d=mipassoc.org;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT   ( "v=atps01; d=ietf.org;" )
q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT   ( "v=atps01; d=isdg.net;" )
rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT   ( "v=atps01; 
d=mapurdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT   ( "v=atps01; 
d=santronics.com;" )

Can DNS handle 30,000 for a zone file?  No problem.

> I sure support the concept, but it seems to me that we need to do this
> differently.

I agree we should review all the work, the explorations for optimizing 
and scaling DNS lookup methods, maybe there is better new DNS 
expectations for "wild cards."  I don't think we are ready to switch 
to a non-DNS lookup solution, but it should be considered if only as a 
blackbox I/O function.

Also, there is also the DKIM signature i= tag value or AUID "Agent or 
User Identity" which may play a role in DKIM-LIST environments. See 
comments below about AUID.

> I was thinking that a (list) machine, receiving a signed message with
> p=reject, would respond with some new 3xx code that would say, "great, I'd
> love to help you, but you didn't delegate to me....", and then include
> some transactional part that would help the right authorization occur.
> Perhaps going back to the *user* to confirm.

Yes, it would be one deployment option.

The IETF should be documenting the practical possible deployment 
options for a SMTP REJECT protocol semantic without the lost of 
security. The alternative options provide the same security protection 
to the end-user -- no harm, which I think includes:

   [X] Honor DMARC p=reject by:
       (o) 550 Reject
       (_) 250 Accept and Discard
       (_) 250 Accept and Keep
       (_) 250 Accept and Quarantine (user junk bin)
       (_) 250 Accept and Bounce/DSN
       (_) 250 Accept and Non-Bounce Notification

Of course, a restrictive domain could quarantine DMARC failed mail and 
present it to the user (in a safe way) to get his acknowledgment 
and/or authorization, thus "learning" a whitelist of resigners.  Yahoo 
decided not to implement or deploy the DMARC p=quarantine mode of 
operations.

> After all, just because [e-mail] is a subscriber to ietf.org lists,
> doesn't mean that [e-mail] wants his email redistributed by ietf.org.

The real question is whether there is a security hole with yahoo.com 
opening up its
DMARC policy with trusted 3rd party resigners.  Can a bad guy use the 
trusted ietf.org site to send bad mail purportedly from an 
uncompromised [e-mail]?

User-based policies or user-level granularity designs was always left 
on the back burner for its obvious design overhead and complexity. It 
was all very vague how we can use some of those options, and if any, 
at some local level only.

The AUID "Agent or User Identity" DKIM-Signature i= tag value is an 
example.  In DKIM RFC6376 theory, we have two parameters for lookups:

    DKIM-Signature: ... d=SDID i=AUID

where SDID is the signing domain and AUID is the optional sub-domain 
of the signer domain.

This strict SDID/AUID alignment has always been a problem.  It could 
be used for user granularity authorization at some level but it lacked 
flexibility for a 3rd party policy semantic unless the implementation 
added the author address as part of the AUID.  I have an example of 
that with our DKIM implementation signer configuration option shown below.

The problem was the lost of an "Author Domain Identity" (ADID) in the 
DKIM equation:

    From: user.id@ADID
    DKIM-Signature: ... d=SDID i=AUID

And we also now have a possible mail List-ID to consider:

    List-ID: MLID

What are all the relationships between these ADID, SDID, AUID and MLID 
identities?

Maybe that is the abstract question DKIM alludes to by separating SDID 
and ADID, but we now know the DMARC industry is not wanting to 
separate the two.  Here is what DKIM says about SDID and AUID:

     3.11.  Relationship between SDID and AUID
     http://tools.ietf.org/html/rfc6376#section-3.11

How do we scale an authorization system for a 3rd party SDID signer 
who MAY be related to the ADID, AUID and/or MLID?

How do we separate the SDID and AUID to add the ADID?  What we did 
with our DKIM implementation was to offer the following DKIM signer 
configuration option for setting the i= tag:

# USER DEFINED TAGS:
#
# The UserTags are experimental. They are additional signed "tag=value;"
# information added to the signed signature.  The tag MUST NOT conflict
# with an DKIM standard tag.
#
# IDENTITY (i=)
#
# The optional i= tag allows you to add any valid formatted "email 
address"
# (but it doesn't have to exist).  It must be the same domain as the 
signer
# or a sub-domain of the signer.  Some macros are available:
#
#   {AUTHOR}           replace the Author (From:) address
#   {AUTHOR.DOMAIN}    replace the Author (From:) address domain
#   {SIGNER}           replace the signer domain
#
#   example: i= {AUTHOR}.{SIGNER}

So as you can see, this was one way to get the ADID into the DKIM 
equation:

    DKIM-Signature: ... d=SDID i=ADID.AUID

There are a lot of ideas considered, included some CallBack methods 
where a Message ID (MSGID) can be checked at the source. IBM even has 
a MSGID call back patent.

Whatever the DKIM-LIST resigner solution is, the receiver's DKIM Check 
Signing Practice (CSP) module process model could be:

       RESULT = DKIM_CSP(SDID, ADID, AUID, MLID, MSGID)

and ultimately, it is the ADID Author Domain that should have the 
final mail policy say in what is expected and honored for any of this 
to have a chance to work.

-- 
HLS