Fairly simple? I'm not sure about that.
1) The signer engine needs to do two signatures now. This will be a
major code change, more outbound signing overhead. There is still that
so called scalability, "big data" problem. How will the "YAHOOs"
scale this? A database is still needed of which domains will have an
outbound mail stream with two signatures. Some how the list domains
will still need to register with the Yahoos and tell the Yahoos,
"Please send us two signatures authorizing out list domain." I
would like to call this a "registration" problem because thats seems
to be the area of disagreement as a real problem.
2) Two (actually all) receivers now have to comply; the MLM MDA
receiver (middle ware) and the final User MDA receivers. All middle
ware MUST NOT strip the weak 1st party signature.
All this is not fairly simple changes. The idea has the same end
result for 3rd party authorization with more complex calculations at
all points; signers, middle ware and receivers. This is far more
complex than a simple DNS lookup of the ADID/SDID at the receivers
satisfying the same end result question -- "Does the ADID authorize
the SDID as a signer?"
Are we trying to skip the DNS part from the solution of all this? I
would like to ask the chairs, if the Indirect Mail Interop report
including further explorations into ATPS and TPA, then why is that not
happening, and who will do it? Obviously, Murray is showing his
disinterest in completing the DKIM ATPS work.
The IETF should present all the solutions in this complicated project.
Compared to what being proposed with this idea and Murray's other two
ideas, the DNS lookup method is still a viable option, if only, to be
included in the total solution pack:
DKIM+DMARC+ATPS as a faster, optimized, least change approach,
more proven in the
market place with APIs already set to do the ADID lookup.
DKIM+DMARC "In-band" method, such as Levine's @FS= idea for, I
guess, for
the customers out there that, for some reason, want a more
complex DKIM
engine in signing and verifying in order to do the same thing,
perhaps
because they have problems interacting with their DNS administration
requirements?
Even if this dual signature @FS= approach goes forward, the software
change requirements will allow for an optimized DNS authorization
lookup method to be included.
--
HLS
On 4/9/2015 12:52 AM, Murray S. Kucherawy wrote:
On Wed, Apr 8, 2015 at 7:06 PM, John Levine <jo...@taugh.com> wrote:
I updated my conditional signature draft, which is now (thanks to a
suggestion from Ned Freed) the mandatory tag draft.
https://tools.ietf.org/html/draft-levine-dkim-conditional-01
[...]
Well, I'm game to try. Adjustments to the parsing engine should be fairly
simple, and a couple of extra steps to notice and resolve the forward
reference will be needed. And maybe some extra return codes. I'd use "!"
instead of "@", I think, as an indication of their importance when observed
visually, but that's rather a minor point.
The first thing that hits me: Do we have to be specific about what's meant
by "weak"? How does the verifier decide if it's "weak enough" or perhaps
"too weak"?
-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
