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: [email protected] [mailto:[email protected]]
>> On Behalf Of Todd Lyons
>> Sent: Tuesday, September 21, 2010 8:07 PM
>> To: Hector Santos
>> Cc: [email protected]
>> 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
> [email protected]
> http://mipassoc.org/mailman/listinfo/dkim-ops
>
>
_______________________________________________
dkim-ops mailing list
[email protected]
http://mipassoc.org/mailman/listinfo/dkim-ops
