On 6/16/2014 4:17 PM, John Levine wrote:
Here's a draft that puts the forwarding thing into DKIM, with the
dread version bump. It defines a general syntax for conditional
signatures, with the forwarding signature the only condition defined
so far. (Since you asked, new conditions don't need another version
bump.)
R's,
John
-----------------------------------------------------------------
A new version of I-D, draft-levine-dkim-conditional-00.txt
has been successfully submitted by John Levine and posted to the
IETF repository.
Name: draft-levine-dkim-conditional
Revision: 00
Title: DKIM Conditional Signatures
Document date: 2014-06-16
Group: Individual Submission
Pages: 5
URL:
http://www.ietf.org/internet-drafts/draft-levine-dkim-conditional-00.txt
Status: https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/
Htmlized: http://tools.ietf.org/html/draft-levine-dkim-conditional-00
Abstract:
The DKIM protocol applies a cryptographic signature to an e-mail
message. This specification extends DKIM to allow the specification
of external conditions that must be satisfied for a signature to be
valid.
John,
There are many problems with this and any other complexed, additional
processing idea, like DKIM-Delegate, that tries to get around a DNS
Author Domain lookup -- namely, it doesn't address the main issue
policy verification systems want:
How to authorized a valid third party signature when
nothing else exist but the two parameters:
Author Domain <<--- 5322.From
Signer Domain <<--- 5322.DKIM-Signature
In addition, it doesn't solve what the resigner want:
Do be able to resign blindly without restriction.
In addition, it doesn't solve what the users want, to continue using
restrictive domains EXTERNALLY from outside the restrictive domain
mail machines for sending mail.
In other words, the only thing a list operation will see is NON-SIGNED
messages from these restrictive domains. If the MTA-receiver is not
checking for this, then the new distribution is only going to have one
signature. For example:
From: <[email protected]>
DKIM-Signature: d=ietf.org .....
There is no primary, delegate or conditional headers, tags, overhead
complexity.
Lets not make it any more complex for the DKIM/DMARC verifier when all
it needs to do is a simple single line DNS lookup:
YesNo = IsSignerAllowed(Author.Domain, Signer.Domain)
Simple.
I can see where you have an short circuit optimizer (not a
replacement) to help reduce the lookups, but it has to be only for
strong rejection policies and it can not trusted for generating pass
results purely on this basis. In other words, if an optimizer is
found, then it better be correct otherwise it MUST be a REJECT
condition because you don't want to force a situation where the
verifier will begin to not trust this optimizer and ignore it anyway
to do a lookup anyway. You will always need to do a lookup
regardless of this additional complexity proposed.
Note, I do see, that you also point out the uselessness of this
proposal in the security section. So if it was an futile exercise in
proving some technical point about BUMPing versions, fine, but it is
really a waste of engineering time for folks who are highly interested
in solving this problem, well that, you did have a major voice and
hand in creating with your lack of support in ADSP and now DMARC.
Ignoring the policy concept is no longer an option.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
