Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

[Hector Santos <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>