Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Jun 2014 23:11:05 -0700

Playing around with ideas here.  This one removes the "l=0" signature stuff
and instead makes DKIM-Delegate into a more self-contained thing, which I
believe was suggested (or at least inspired) by Stephen's comments.  There
is still the potential for abuse during the ephemeral relationship period
(i.e., prior to expiration), but it it is now an indirect attack on the
author domain rather than a direct one.  Perhaps that's more palatable in
this scenario.

Comments welcome.

-MSK

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Jun 19, 2014 at 11:08 PM
Subject: New Version Notification for draft-kucherawy-dkim-delegate-01.txt
To: "Murray S. Kucherawy" <[email-masked]>, Dave Crocker <
[email-masked]>

A new version of I-D, draft-kucherawy-dkim-delegate-01.txt
has been successfully submitted by Murray S. Kucherawy and posted to the
IETF repository.

Name:           draft-kucherawy-dkim-delegate
Revision:       01
Title:          Delegating DKIM Signing Authority
Document date:  2014-06-19
Group:          Individual Submission
Pages:          11
URL:
http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-01.txt
Status:
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-delegate/
Htmlized:       http://tools.ietf.org/html/draft-kucherawy-dkim-delegate-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-delegate-01

Abstract:
   DomainKeys Identified Mail (DKIM) permits a handling agent to affix a
   digital signature to an email message, associating a domain name with
   that message using cryptographic signing techniques.  The digital
   signature typically covers most of a message's original portions,
   although the specific choices for content hashing are at the
   discretion of the signer.  DKIM signatures survive simply email
   relaying but typically are invalidated by processing through
   Mediators, such as mailing lists.  For such cases, the signer needs a
   way to indicate that a valid signature from some third party was
   anticipated, and constitutes an acceptable handling of the message.
   This enables a receiver to conclude that the content is legitimately
   from that original signer, even though its original signature no
   longer validates.

   This document defines a mechanism for improving the ability to assess
   DKIM validity for such messages.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

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

>author domain rather than a direct one.  Perhaps that's more palatable in

This looks an awful lot like my draft-levine-cdkim-00 and
draft-levine-dkim-conditional-00 except that mine has more bits of
DKIM in the cdkim signature so it can sign To and From to limit the
range of spoofage.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jun 2014 13:07:31 -0700

> DKIM in the cdkim signature so it can sign To and From to limit the

The difference is that this proposal doesn't
change/extend/spin/fold/mutilate DKIM at all.  The semantics are outside
entirely.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2014 16:13:06 -0400

> change/extend/spin/fold/mutilate DKIM at all.  The semantics are outside

That's draft-levine-cdkim.  I changed the name of the header, so it's not 
a DKIM signature, just a signature that happens to have a lot of aspects 
that are similar to one.

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

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Jun 2014 14:04:05 +0900

> DKIM in the cdkim signature so it can sign To and From to limit the

I'm not sure about the plusses and minuses of signing To: (and Cc:),
but I agree that the new version (which I like a lot) would definitely
be more valuable to Author Domains if the signature covered From:.
It's not obvious to me that this couldn't be REQUIRED rather than an
option (with attendant complication of the protocol), since Mediators
that "take ownership" of From: (eg, anonymizers) will then be "first
parties".

Unless the Mediator chose to use a *different* mailbox in the Author
Domain, but I don't see why the Author Domain would want to permit
that unless the Mediator is controlled by the Author Domain.