Well, I am a state of disbelief.
After all the many years efforts to champion Policy, to keep it alive
after the focus was split from DKIM (an update and derivative of the
DomainKey with Policy RFC4870 historic standard), the long battles to
show DKIM has no signature security protection layer with a 2006 DSAP
(DKIM Sender Authorization Protocol) I-D,
http://tools.ietf.org/html/draft-santos-dkim-dsap
illustrating the security concerns:
http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-7
with a proposed DSAP verifier protection wrapper:
http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-9
with all that and then including all the background noise, off-list
discussions re-awakening of the POLICY concept, suggesting ASL, to get
Doug involved with TPA and even proposing a trimmed down merger,
proposing a new discussion group which Barry Leiba (DKIM WG chair)
showed interest, and even inviting you to participate, to proposed to
you to add API support of a trimmed down TPA or ASL concept, etc, etc,
etc, even with all that, I will never get any respect or
acknowledgments from you whatsoever.
Oy vey, whatever, I guess the only thing to say:
"Mission Accomplished"
Getting you to support the concept, adding it to your future version
of OpenDKIM is more important than anything else.
I will add exploratory support for ATPS today. I believe it was the
right thing to do for the future of DKIM.
Thank you for taking the time to writing a clear and concise ATPS I-D.
I have only one suggestion:
Iin your IETF way, add a statement that would update RFC 5617
definition for DKIM=ALL
from
all All mail from the domain is signed with an Author
Domain Signature.
to
all All mail from the domain is signed with an Author
Domain Signature or Authorized Third Party Signature
Or mention it a implementation (if it exist) may actually follow the
DKIM=ALL semantics to the letter and only allow the Author Domain to
be the signing party.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
-----Original Message-----
From: dkim-ops-bounces(_at_)mipassoc(_dot_)org
[mailto:dkim-ops-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Todd Lyons
Sent: Tuesday, September 21, 2010 8:07 PM
To: Hector Santos
Cc: dkim-ops(_at_)mipassoc(_dot_)org
Subject: Re: [dkim-ops] DKIM Testing Feedback Loops
The site DKIM Verifier implementation now has ADSP support with my R&D
on the ADSP extension ASL (Allow Signer List) idea. �We are now
Example ADSP record for winserver.com:
dkim=all; asl=mipassoc.org,megabytecoffee.com,
� � � � � � � mapurdy.com.au,santronics.com,isdg.net
I see very quickly the potential for scaling problems. What's your
expected max length? DNS TXT records can consist of 255 byte strings,
so if your length is more than 255 characters, you'll have to split it
into multiple strings (upper bound of any DNS record seems to be
65535). Personally, I subscribe to 43 different mailing lists. For
someone like me, I think you'll have to consider doing like spf where
you can include other txt records for the asl setting in order for it
to scale.
Splitting into multiple strings isn't a hindrance really. That's what we do
in DKIM with large public keys. You'd just need to stipulate that multiple
"character-strings" as DNS calls them are concatenated before parsing the
resulting payload.
I think this proposal and others like it sidestep the scaling problem with
the argument that this isn't intended for a large domain (gmail.com, for
example) to list all of the domains that host lists to which its users
subscribe, but only specific high-value phish domains like the popular
paypal.com example. In that case they're probably right that it's unlikely
such a domain would make an ASL that's very big or very dynamic and it would
probably continue to fit inside a UDP reply, but it also constrains that
approach to a very small slice of the signing population. (Then again,
that's who ADSP was for...)
Given the two, I prefer the TPA approach at least in terms of how to store
the data in the DNS so that it can be easily queried. It makes the
authorized third-party signer list much more extensible and furthermore
enables specification of policies or other details for each signer without
adding more payload to a single common record. However, TPA as currently
presented suffers a little from being overly complex without any data to
justify that complexity.
It's still not even clear that there will be a widespread need for this kind
of DKIM-related technology or that its value trumps that of other related
work like domain reputation and use of VBR, but nevertheless since so many
people are certain this is going to be necessary for long-term success of
DKIM, it seems that some real experimentation is warranted.
I've taken the liberty of producing a trimmed-down TPA concept called ATPS
which, if implemented, would be an ADSP extension. It's up for review here:
http://www.ietf.org/id/draft-kucherawy-dkim-atps-00.txt
I'll take a run at coding up an extension to OpenDKIM to do this for its next
major release after the current Beta wraps up. We can then use the
statistics portion of OpenDKIM to monitor deployment and gather some results,
though as I think I said before it could be many months before we know
anything. Other implementers are of course invited to collaborate on
implementations and the collection of data.
Comments welcome.
-MSK
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops