Re: A permission to re-sign header

John,

Sounds reasonable so far, but the main issue is making the MLM honor 
such or any strict protocol logic.

What happens if the policy is strict and does not allow for 3rd party 
resigning, i.e. no M-R header is provided by the originated and 
doesn't create them as well?   Will the MLM honor the policy?

Once the HARD FAILURE handling is a acceptable consideration , then we 
can have the energy again to revisit the already discussed possible 
solutions, including looking at why YAHOO did not do what DKIM wanted 
by looking up the SDID (d= tag value) against any existing whitelist 
or trust database to lead the way, in additional as to why not using 
the AUID (i= tag) for user level unique signing.

The only real change for DMARC is to correctly lay out the 1st and 3rd 
party handling semantics given all the possible DMARC tag values between:

    p=none|quarantine|reject
    adkim==r|s
    aspf=r|s

Is this sufficient?  Why can't this M-R be described via the policy 
record?  I think it would be with the p=reject and relaxed adkim=r and 
aspf=r alignment defaults. Unless I my (quick) reading the DMARC spec 
is wrong, the YAHOO policy currently has:

    p=reject
    adkim==r  (not set, default)
    aspf=r    (not set, default)

As I understand DMARC, this means mail must be signed but it can be 
either a 1st and 3rd party signature.  This would be the same as a 
ADSP DKIM=ALL policy.  If so, maybe YAHOO is handling the logic wrong? 
  I don't see the "alignment" requirement with the implicit default 
relax alignment adkim=r, aspf=r defined for their record.  Maybe 
someone can explain where the "strict" alignment (5322.From.domain 
must equal the signer domain) is defined via yahoo's DMARC record and 
in the specification.

Anyway, I think the basic problem is to first revisit the wider, 
practical POLICY SEMANTICS for 1st party and 3rd party operations and 
make the expected protocol handling draft corrections and/or 
clarifications.  This is really about the MLM honoring STRICT 
policies, and also given the author domain the benefit of all doubt 
that their publicly exposed DMARC policy was well considered and 
published for a reason.   We should treat all domains equally with the 
protocol, including yahoo.com.

Thanks

-- 
HLS


On 4/18/2014 8:37 AM, John Levine wrote:
>> Even with the local part (marissam) an M-R is not really hard to
>> forge, otherwise DKIM-Signature wouldn't have had to include all the
>> other tags.  If we worry about replay attacks, we can enhance M-R so
>> that it includes them too.  For example, we could make M-R exactly
>> like a regular DKIM-Signature, except that it would be a very very
>> weak one, something that the MLM won't break.
>
> BTDT.  If we could invent a weak signature that the MLM won't break,
> we wouldn't have this problem.  The M-R token is signed so it should
> be impossible to forge, and we don't expect anyone to change it in
> transit.
>
> I also note that this hack, with or without Ale's changes, does
> nothing to solve the send from gmail and WSJ article problems.
>
> R's,
> John
>
> _______________________________________________
> ietf-822 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-822
>
>


_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822