Subject: [dmarc-ietf] draft-levine-dkim-conditional-00

From: "John Levine" <[email-masked]>
Date: 16 Jun 2014 20:17:59 -0000

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Jun 2014 13:45:48 -0700

> so far.  (Since you asked, new conditions don't need another version

I'm uneasy with an increase in version that isn't done in a complete
replacement for RFC6376.  We're not just registering a couple of new
extension tags here.  I would prefer that, if we do go decide to go down
this route, we crack it open and do a proper revision document rather than
just describing v2 in terms of "changes since v1".

I also wonder where/how/if this would fit inside a potential DMARC charter,
or if we're looking at a second WG for this, or what.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 Jun 2014 17:12:36 -0400

> so far.  (Since you asked, new conditions don't need another version

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-masked]>
    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

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 17 Jun 2014 12:06:01 +0900

John Levine writes:

 > dread version bump.

I agree that this proposal needs a version bump, for the reasons given
in Section 5 of the document.  I still think that these semantics are
better put into the -Delegate header because it's simpler and requires
no version bump[1], but the version bump approach seems tenable, and is
more general, I suppose.

I think the requirement that To and Cc "SHOULD" be signed when "t" and
"c" are present in the fs parameter should be promoted to a "MUST".
It's easy to satisfy the requirement at the signing stage, adds more
complexity to the verifying stage, and the flexibility is redundant.
(If desired the same semantics can be achieved by specifying the
addresses in To: and/or Cc: explicitly, and not signing the
corresponding field.)

Footnotes: 
[1]  I don't "dread" it, I just don't think it's necessary or useful.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Jun 2014 15:14:46 -0700

On Thu, Jun 19, 2014 at 2:51 PM, Ned Freed <[email-masked]> wrote:

> There's a problem in front of us that needs solving. Part of that seems to
> call
> for a limited semantic extension to DKIM. Let's by all means make that one
> extension in way that generalizes as much as possible.
>
> But using this as justification to crack open the entire specification?
> That is not a good idea.

I agree, mostly.  I wasn't advocating for cracking open the entire
specification.  Assuming we go this path (rather than bolting down
DKIM-Delegate's problems somehow), I would much rather publish RFC6376
again, with the "v=2" and the two new tags and maybe a paragraph about
backward compatibility, but absolutely no other changes.  I don't want to
spend time reviewing and tweaking the whole damned thing again.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Jun 2014 14:51:10 -0700 (PDT)

> just describing v2 in terms of "changes since v1".

Behold the main problem with version numbers in protocols - people invariably
attach more significance to such values that they really deserve. This
is especially true when the number is "2" - they call it *second*
system syndrome for a reason.

Nathaniel and I have long since agreed that the MIME-Version field is one of
the biggest, if not the biggest, fuckups in MIME. And yet it's a mistake we
keep on making in protocol design. Sigh.

There's a problem in front of us that needs solving. Part of that seems to call
for a limited semantic extension to DKIM. Let's by all means make that one
extension in way that generalizes as much as possible.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Thu, 19 Jun 2014 20:46:12 -0400

On 6/19/14, 6:14 PM, Murray S. Kucherawy wrote:
> On Thu, Jun 19, 2014 at 2:51 PM, Ned Freed <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> backward compatibility, but absolutely no other changes. I don't want 
> to spend time reviewing and tweaking the whole damned thing again.

As one of the co-editors of the last version, I agree whole-heartedly.

     Tony Hansen

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 20 Jun 2014 14:13:37 +0900

Murray S. Kucherawy writes:

 > DKIM-Delegate's problems somehow),

Once you put the token signature in the DKIM-Delegate field itself (a
process we already do for DKIM-Signature, which implicitly MUST sign
itself), I don't see any problems that don't apply equally to this
proposal.

Except lack of generality, if you consider that a problem.  John's
proposal is more general, but generality is a two-edged sword.

This particular generality worries me.  As I understand it, conditions
become a registry matter, not an RFC matter.  I fear the proliferation
of conditions that nobody will implement, or worse similar conditions
with slightly different semantics that somebody prefers to existing
registered conditions.

So I'm firmly in favor of a new specialized header field.  I realize
that means support in verifiers will probably need to be maintained
for decades, but I'd rather seen the need for generality before
opening Pandora's Box.

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2014 10:50:49 -0400

> with slightly different semantics that somebody prefers to existing

That doesn't strike me as a problem.  We have lots of protocols with 
registries full of little used or unused optional extensions.  SMTP is a 
good example, and it interoperates pretty well.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.