On 5/29/2014 4:28 PM, J. Gomez wrote:
On Wednesday, May 28, 2014 10:13 PM [GMT+1=CET], Tim Draegen wrote:
I don't believe TPA-Label hits the mark between "solving a big hurt"
and "simple". IOW, it's too complicated for the amount of pain it
would resolve. Just my opinion, take care,
I'm of the same opinion as above.
In my own words, I would say the TPA-label draft Otis posted reads like
perfectly polished Klingon to me.
Id est, overly too complex for very little gain.
Mr. Gomez,
TPA has a wider scope and an overly described functional specification.
But the main idea should not be thrown away due to lack of
fundamentally understanding the long time problem and proposed solutions.
In its simplest terms, the idea is to lookup a 3rd party domain for
authorization to sign or resign originating author domain mail.
The earliest suggestions like in the 2006 DSAP proposal used an
Allowed Signer List (ASL) "asl=" tag in the policy records. So
applying this simpler idea to DMARC, an example policy for your
domain, seryrich.com, might be
_dmarc.seryrich.com TXT ("v=dmarc1; p=reject; asl=ietf.org; ...")
This would expose to the world the policy that says:
Only domains seryrich.com and ietf.org are
authorized to sign mail for seryrich.com.
If you see anything else, reject it.
Simple idea. No extra lookup beyond the DMARC lookup. The problem
with ASL is that it works for the shorter list domains. It would not
scale for the larger domains, i.e. can't fit Yahoo's 30K potential
authorization list. I think its an optimization idea for the majority
of domains who are smaller than YAHOO.
This is where Doug's TPA (Third Party Authorization) and Murray's
simpler version of TPA called ATPS (Authorized Third Party Signer,
RFC6541) comes into play.
TPA and ATPS is basically the same when it comes to the lookup
formula, which is to combine the signer domain as a subdomain zone of
the author domain. I have implemented ATPS but its basically the
same as TPA with a query formula of:
BASE64(SHA1(signer-domain))+"."+author-domain
So for you, your DMARC and ATPS subdomain records for seryrich.com
zone would be:
_dmarc TXT ("v=dmarc1; p=reject; atps=y;")
PQ6XADOZSI47RLUIQ5YOHG2HY3MVJYOO._atps TXT ("v=atps01; d=ietf.org;")
So the ideas has been worked out. The problem has been to get the
IETF List Operators and Administrators to support this.
So why not? Note, we also develop list software, so I have no problem
doing what is necessary to get it all to work right.
The main problem is that list operators prefer to use a TRUST model by
looking up the signer domain. Not the author domain.
They currently do neither, but they prefer to use the signer domain
and this was the DKIM standard suggestion. Use the SIGNER domain.
Forget about the author domain. Again, I am just looking for a total
mail integrated solution between all parts. So lets go ahead and
lookup the signer domain.
What's the problem then?
Well, what happens when any of these simple use cases occur:
a) The signature does not exist in the message. Its missing.
b) Signature exist, but it doesn't hash verify. Its broken.
c) Signature exist and its valid, but its not your signature.
Its some unknown signer that wants to tell the world its
signing on your behalf.
So the basic argument against depending on a signer domain only is
that may not exist nor be valid. It can be completely fake. Now,
Levine's VBR was a step in the right direction with the "combo" author
and signer lookup but again, what happens when the signature is
missing or invalid so that there is no signer domain to lookup? The
trust advocates don't have an answer for these simple first level
security issues that are easily detectable as failure.
In summary, this has been examine all ways and the best and original
idea was looking up the author domain because its the single identity
that MUST exist in the message. It is the most important header of
them all, the 5322.From header. This is the reason it is also the
only header that MUST be hash bound to the signature. No other header
is required to be hashed to the signature.
But the resigners don't want to look it up. They want the freedom to
resign mail. The policy advocates wants a more flexible 1st and 3rd
party resigner framework, but one with options to lock down the 3rd
party signers.
I believe the latter is the more protocol strong solution. Its require
more wider support and it will clamp down on the laissez-faire
resigners who want to resign and don't wish to even check to see if
its valid.
Yes, there is the problem of the legacy users that has long used
public, but also highly spam polluted big email brand domain. The
Yahoos are not the only one who domains are polluted and they wish to
finally take control and increase its security quality value.
The IETF need to stop trying to make policy itself on what parts of
the mail market it wishes to support. Its not just about resigners.
Hope the above makes sense.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
