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 mcr(_at_)yahoo(_dot_)com is a subscriber to ietf.org
lists,
doesn't mean that frank(_at_)yahoo(_dot_)com 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 frank(_at_)yahoo(_dot_)com?
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
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822