Subject: [dmarc-ietf] So if you don't want a DKIM version bump ...

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

Here's the exact same proposal, except done with a new header
CDKIM-Signature rather than a DKIM version bump.

A new version of I-D, draft-levine-cdkim-00.txt
has been successfully submitted by John Levine and posted to the
IETF repository.

Name:		draft-levine-cdkim
Revision:	00
Title:		CDKIM Signatures
Document date:	2014-06-19
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-levine-cdkim-00.txt
Status:         https://datatracker.ietf.org/doc/draft-levine-cdkim/
Htmlized:       http://tools.ietf.org/html/draft-levine-cdkim-00

Abstract:
   The DKIM protocol applies a cryptographic signature to an e-mail
   message.  This specification defines a DKIM-like signature that
   includes the specification of external conditions that must be
   satisfied for a signature to be valid.

---

From: Terry Zink <[email-masked]>
Date: Thu, 19 Jun 2014 20:28:51 +0000

It would be nice to have some concrete examples in the draft, I find those easier to follow than descriptions. So, maybe something like:

From: [email-masked]
To: [email-masked]
CDKIM-Signature: cs=?; fs=?;

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of John Levine
Sent: Thursday, June 19, 2014 1:03 PM
To: [email-masked]
Subject: [dmarc-ietf] So if you don't want a DKIM version bump ...

Name:		draft-levine-cdkim
Revision:	00
Title:		CDKIM Signatures

Abstract:

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

---

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

So, are we going to create a new header field every time we come up with
some new required semantic we want to attach to a DKIM signature?

Admittedly this hasn't happened previously, but predicting the future has
never been our strong suit.

Why don't we fix the extensibility problem instead?

				Ned

---

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

> Why don't we fix the extensibility problem instead?

+1

     Tony Hansen

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2014 00:38:15 -0000

Here's an example.  The top signature is from the list, the second and
third signatures were applied by the sender. The second is the normal
signature and the third a weak conditional signature.  The third has
cs=fs which means it's only valid with an additional (forwarder)
signature, and fs=t means that signature has to be from the domain on
the To: line.

When the list does its thing, it invalidates the strong signature from
the original sender, but it adds its own signature which satisfies the
weak signature's condition, so the weak signature becomes valid.

From: [email-masked]
To: [email-masked]
Subject: [discussion-l] cat videos lol

blah blah

--
This is the discussion-l list, with a beautiful message footer.

---

From: Terry Zink <[email-masked]>
Date: Fri, 20 Jun 2014 00:45:36 +0000

Thanks for this, it makes sense. Some questions (may or may not have been discussed already or in your Internet draft):

1. The DKIM-Signature v=2 is only in the headers in the email, correct? Or, would a DKIM DNS record also have v=dkim2;  ?
2. If there are multiple To: addresses, the verifier just checks to see d= in any DKIM-Signature that validates matches any domain in the 5322.To: header?
3. Should we think about how this interacts with Authentication-Results stamping?
4. How does the sending MTA know when to stamp this v=2 DKIM header? Presumably, it would need to have a list of known forwarders stored somewhere?

-- Terry

-----Original Message-----
From: John Levine [mailto:[email-masked]] 
Sent: Thursday, June 19, 2014 5:38 PM
To: [email-masked]
Cc: Terry Zink
Subject: Re: [dmarc-ietf] signature sample, was So if you don't want

blah blah

---

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2014 21:40:47 -0400

> 1. The DKIM-Signature v=2 is only in the headers in the email, correct? Or, would a DKIM DNS record also have v=dkim2;  ?

No need to change the keys, since the hashing and signing hasn't changed. 
Also see my later note about why the key records don't need version 
numbers.

> 2. If there are multiple To: addresses, the verifier just checks to see 
> d= in any DKIM-Signature that validates matches any domain in the 
> 5322.To: header?

Yes.  The draft says the fs= can be a specific domain, or abbreviation "t" 
or "c" which should make the signing marginally easier since the signer 
could use the same template for many signatures without having to pick the 
domain out of the To: header.

> 3. Should we think about how this interacts with Authentication-Results stamping?

I don't see offhand how A-R would be affected.  It's still a DKIM 
signature, the A-R report would be the same.

> 4. How does the sending MTA know when to stamp this v=2 DKIM header? Presumably, it would need to have a list of known forwarders stored somewhere?

When there's a cs= tag.  It's in the draft.

R's,
John

---

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

Terry Zink writes:

 > 4. How does the sending MTA know when to stamp this v=2 DKIM
 >    header? Presumably, it would need to have a list of known
 >    forwarders stored somewhere?

Maybe John's answer in his parallel post is what you're looking for,
but my interpretation is that this is a matter of local policy (and
MTA implementation).

Eg, I'm responsible for lists etc at a couple of domains, and I have
several different answers!  Maybe I trust the user (eg, me).  Maybe I
trust a particular addressee (because it's on your "list of known
forwarders").  And maybe I don't really care as long as downstream is
willing to sign and put *their* reputation on the line (they are
signing the whole message, I'm just making a token).

Oops, there's a real question.  Should these forwarding signatures be
RECOMMENDED or (REQUIRED) to have "full coverage" of message contents?
Or maybe that doesn't matter as "responsible" 3rd parties will want to
provide full coverage, and it's no trouble for abusers to do so?  If
REQUIRED, should there be a way for the Author Domain to specify the
meaning of "full coverage," or should the RFC do so?

---

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

>>    forwarders stored somewhere?

That seems likely, or else the DMARC group could hire someone to publish a 
list of known forwarders.  Based on Yahoo's statements and Gmail's 
aggregate reports, they have a pretty good idea of who the forwarders are.

> RECOMMENDED or (REQUIRED) to have "full coverage" of message contents?

They're ordinary signatures.  I don't think we need to invent new rules 
for them.

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