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

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jun 2014 12:43:57 +0200

Folks,

I've been stewing on this idea for awhile and Murray pressed to get it
into writing, adding his usual, significant enhancements to the original
concept.  We've gone a couple of rounds before releasing it, but it's
still nascent enough to warrant gentle-but-firm handling.  In other
words, comments eagerly solicited.

d/

-------- Original Message --------

Name:		draft-kucherawy-dkim-delegate
Revision:	00
Title:		Delegating DKIM Signing Authority
Document date:	2014-06-07
Group:		Individual Submission
Pages:		10
URL:
http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-00.txt
Status:
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-delegate/
Htmlized:       http://tools.ietf.org/html/draft-kucherawy-dkim-delegate-00

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.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Jun 2014 09:31:39 -0400

This idea is repeating the same thing again.

What would "DKIM-Delegate compliant" systems do when the "new 
information" is missing? What do you do when there are protocol 
faults? What are the protocol faults?

Mr Crocker, you have been leading the DKIM project since day one.  You 
have always been opposed to policy mail handling concepts that 
includes rejection.  Either you keep missing these essential finer 
protocol faults points or just don't believe they are important and 
nothing gets resolved for the resigner market. Your perspective for 
the DKIM model has only been on the GOOD side of things. The honor 
system when things are run perfect.

But the market has long been telling us there were other 
functionalities to this.  DKIM has also been about eliminating the bad 
using a verifiable mechanism and thus allows us to stream the 
potential good where you can do a "TRUST" assessment with the signer 
domain. But there wasn't an IETF endorsed answer in how to filter the 
bad.  I really wish you would finally get that "Ah Ha" so that the 
entire DKIM project can finally get completed.  We can't keep doing 
this half way wasting so much time.

The DKIM-delegate idea is asking for "change" again, yet the change is 
unwilling to except the simplest change which is to simply lookup the 
originating site policy.

So what is the problem?  The idea of a lookup?  A scalability issue? 
A management issue?

The DKIM-delegate idea appears only to try to avoid doing a lookup, 
but conceptually it the same idea of authorizing 3rd party resigners.

At best, it can serve as an optimizer, but only if the originator is 
aware of the potential resigner which the receiver will need to do 
more additional overhead to verify anyway.  You are now asking for 
additional receiver complex overhead when the simplest one has already 
been available; a straight forward query based on the Author Domain 
Identity (ADID) and Signer Domain Identity (SDID):

     YesNo  = IsSignerAllowed(ADID, SDID)

If you are finally telling us to begin thinking this way, well good. I 
support it, but I don't see how DKIM-Delegate is going to address all 
the key protocol faults that has always plagued the DKIM project.

--
HLS

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 08 Jun 2014 03:08:26 +0900

> http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-00.txt

Merry Christmas for mailing lists!  Mailman at least already
recommends that sites hosting lists DKIM sign, so we have nothing new
to do!

Two nits to pick.  First, I'd like a whole (sub)section (containing
approximately one sentence :-) for Mediator responsibilities, even if
it's redundant with step 4 of the specification.  Maybe a subsection
of section 5 (Discussion)?

Second, from the draft:

    The expiration time on the Secondary signature needs to be long
    enough to permit evaluation by receivers of the re-submitted
    message, yet short enough to limit the potential for unauthorized
    replay attacks.  A good choice is a small number of days or even
    hours.

Due to greylisting (I've seen a message that got greylisted twice,
once at the mailing list and once at the recipient), I'd recommend
that the absolute minimum for expiration time be 12 hours, and that at
least 24 hours be recommended.

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 7 Jun 2014 21:09:45 +0200

On Saturday, June 07, 2014 12:43 PM [GMT+1=CET], Dave Crocker wrote:

> into writing, adding his usual, significant enhancements to the
> original concept.  We've gone a couple of rounds before releasing it,
> but it's still nascent enough to warrant gentle-but-firm handling. 
> In other 

Hello, I have this comment: What do you think are the probabilities that YAHOO/AOL, etc, would go through the trouble of identifying and declaring the many third parties needed to be allowed to DKIM re-sign their messages, so that YAHOO/AOL users could painlessly post to mailing lists in a world where DMARC happened to be widely deployed?

Regards,
J.Gomez

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jun 2014 21:14:32 +0200

> Hello, I have this comment: What do you think are the probabilities that YAHOO/AOL, etc, would go through the trouble of identifying and declaring the many third parties needed to be allowed to DKI…

The spec imposes no such requirement.

So I've no idea how your comment applies to the document.

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 08 Jun 2014 06:57:24 +0900

J. Gomez writes:

 > Hello, I have this comment: What do you think are the probabilities
 > that YAHOO/AOL, etc, would go through the trouble of identifying
 > and declaring the many third parties needed to be allowed to DKIM
 > re-sign their messages, so that YAHOO/AOL users could painlessly
 > post to mailing lists in a world where DMARC happened to be widely
 > deployed?

First, in the usual case the mailing list is explicitly mentioned in
the addressee list at the time it reaches the destination domain, so
it automatically becomes a delegate.  So there would be no need to
specify "t=" in those cases.  Nor do I see a serious risk of
exploitation, since the implicit list is restricted to the explicit
(non-bcc) addressees.  DKIM sign To and Cc and replay attacks become
quite difficult, I should think.  I guess these considerations are
what Dave meant by "the protocol doesn't require that", but you'd have
to ask him.

Do you have a specific reason to think explicit delegate lists would
commonly be needed?

For your actual question, I can't speak to probability, but I think
that it would be reasonably easy to delegate the identification task
to the users.  Just as many webmail services allow you to "whitelist"
senders such as your bank, they could have a separate "delegate" list
(probably labeled "mailing lists").  Then the MUA module would
generate the "t=" parameter of the DKIM-Delegate header based on the
user's whitelist and the addressee fields.  I don't see a problem with
this from the mailbox provider's point of view, and it would be
greatly appreciated by many mailbox users.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 08 Jun 2014 22:37:28 +0200

Stephen,

Thanks for the comments...

> of section 5 (Discussion)?

Uhh... why?

> least 24 hours be recommended.

Long ago, the usual email minimum timer was 72 hours, to deal with a
long weekend...

I'll suggest that rather than using precise number, perhaps the spec
should indicate what the functional requirement or goal is, to guide the
choice of actual timer value(s).

Text suggesting how to accomplish this in the draft would not be met
with hostility...

d/

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Jun 2014 01:52:11 -0500 (CDT)

This is interesting, however it seems to me that DMARC should be more aware of it if used. 

I would suggest to sign with a sub domain. This would keep alignement, but would allow you to see which DKIM signature worked. Once both DKIM signature work, you would not need the delegated one.

I think DMARC should be made aware, so that it apply some constraints on when this signature is used/valid. May be only when there is a List-ID or List-Post header present, and the list has DKIM signed the whole message with its domain.

It would require MLM to not drop DKIM headers... Still some configuration on MLM side, but less in the way messages are modified

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: [email-masked]
Sent: Saturday, June 7, 2014 12:43:57 PM
Subject: [dmarc-ietf] Fwd: New Version Notification for	draft-kucherawy-dkim-delegate-00.txt

Folks,

d/

-------- Original Message --------

Abstract:

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

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 00:23:53 -0700 (PDT)

DKIM-Delegate suffers from replay attacks, and when not,
introduces whitelisting which, kind of, breaks its premise.

also, we need a solution that doesn't risk of being modified
by any middle man on message path. DKIM can't offer that,
and will never be able to.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 06:47:56 -0700

> This is interesting, however it seems to me that DMARC should be more

Why?  This is a way of satisfying the alignment requirement on the DKIM
side.  DMARC doesn't need to know it's there.  The same is true of ATPS,
for example.

> I would suggest to sign with a sub domain. This would keep alignement, but
> would allow you to see which DKIM signature worked. Once both DKIM
> signature work, you would not need the delegated one.
>

What would make both start working again?  The problem we're trying to
solve here is that the originator signature is broken by the list, and
that's a (theoretically) immutable condition.

> I think DMARC should be made aware, so that it apply some constraints on
> when this signature is used/valid. May be only when there is a List-ID or
> List-Post header present, and the list has DKIM signed the whole message
> with its domain.
>

Anyone can add a List-ID or List-Post header field, so I don't think that
adds any additional security.

> It would require MLM to not drop DKIM headers... Still some configuration
> on MLM side, but less in the way messages are modified
>

That's a much less visible and thus probably more tolerable change for MLM
operators.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 06:49:53 -0700

> introduces whitelisting which, kind of, breaks its premise.

DKIM is already replayable.

I don't see how this introduces whitelisting requirements.

> and will never be able to.

Yes, that is a risk.  That's why a short-lived signature is used with other
tight requirements.  The risk might be a tolerable one for this application.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Jun 2014 08:58:18 -0500 (CDT)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: "Dave Crocker" <[email-masked]>, [email-masked]
> Sent: Tuesday, June 10, 2014 3:47:56 PM
> Subject: Re: [dmarc-ietf] Fwd: New Version Notification for
> draft-kucherawy-dkim-delegate-00.txt

> On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin < [email-masked] >
> wrote:

> Why? This is a way of satisfying the alignment requirement on the DKIM side.
> DMARC doesn't need to know it's there. The same is true of ATPS, for
> example.

Sure but you have a strong DKIM signature and a weak DKIM signature, using about the same domain, it is like the strong DKIM signature did not exist...

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Jun 2014 15:02:13 +0100

On Jun 10, 2014, at 2:47 PM, Murray S. Kucherawy <[email-masked]> wrote:

> On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin <[email-masked]> wrote:
> Why?  This is a way of satisfying the alignment requirement on the DKIM side.  DMARC doesn't need to know it's there.  The same is true of ATPS, for example.
>  
> What would make both start working again?  The problem we're trying to solve here is that the originator signature is broken by the list, and that's a (theoretically) immutable condition.
>  
> Anyone can add a List-ID or List-Post header field, so I don't think that adds any additional security.
>  
> That's a much less visible and thus probably more tolerable change for MLM operators.

Dear Murray,

It would be helpful to reference TPA-Label instead of ATPS.  ATPS can never be deployed.  While List-ID will not in itself confirm the message source, when used as condition for authorization will help ensure recipients can use this header to sort messages.  I am about to update this draft to help clarify why the TPA-Label approach is still better than several of the other quick fixes being suggested.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 07:03:16 -0700

On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin <[email-masked]>
wrote:

> ------------------------------
>
> Sure but you have a strong DKIM signature and a weak DKIM signature, using
> about the same domain, it is like the strong DKIM signature did not
> exist...
>

Assuming by "strong DKIM signature" you mean the originator signature that
covers the whole message, then given the MLM is going to invalidate it, it
basically doesn't exist.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jun 2014 16:06:13 +0200

On 6/10/2014 4:03 PM, Murray S. Kucherawy wrote:
> Assuming by "strong DKIM signature" you mean the originator signature
> that covers the whole message, then given the MLM is going to invalidate
> it, it basically doesn't exist.

If it happens to survive (such as to recpients of the original message
who are not on a mailing list, so they get a direct copy) then their
DKIM evaluation engine ought to pay attention to the 'strength' of the
different signatures.

Also note that the weaker signature is enabled by the DKIM-Delegate
field, which specifies what intermediaries are tolerated.

d/

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Jun 2014 09:13:19 -0500 (CDT)

----- Original Message -----

> Sent: Tuesday, June 10, 2014 4:03:16 PM

> On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin < [email-masked] >
> wrote:

> > > > This is interesting, however it seems to me that DMARC should be more
> > > > aware
> > > > of it if used.
> > > 
> > 
> 

> > > side.

> covers the whole message, then given the MLM is going to invalidate it, it

Yes but are you assuming you only put the weak DKIM signature, when you specifically know you are emailing a mailing list? 

Or what about a receiver which is not a mailing list? You are just allowing better replay of the message, if you put any weak DKIM signature in the message... Unless the weak DKIM signature is constrained to a specific usage.

---

From: Franck Martin <[email-masked]>
Date: Tue, 10 Jun 2014 09:16:44 -0500 (CDT)

----- Original Message -----
> To: "Murray S. Kucherawy" <[email-masked]>, "Franck Martin" <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, June 10, 2014 4:06:13 PM
> Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt
> 

Yes, but it requires change in the deployed DKIM base, may be best to put these changes within DMARC, while there are still some motivated coordinated developers.

> field, which specifies what intermediaries are tolerated.
ah, yes...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 07:19:17 -0700

On Tue, Jun 10, 2014 at 7:13 AM, Franck Martin <[email-masked]>
wrote:

>>> aware of it if used.
>> Sure but you have a strong DKIM signature and a weak DKIM signature,
>> using about the same domain, it is like the strong DKIM signature did not
>> exist...
>>
>
> Yes but are you assuming you only put the weak DKIM signature, when you
> specifically know you are emailing a mailing list?
>
> Or what about a receiver which is not a mailing list? You are just
> allowing better replay of the message, if you put any weak DKIM signature
> in the message... Unless the weak DKIM signature is constrained to a
> specific usage.
>

You're constraining it to use by a specific, very small set of domains, and
only for a limited time.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jun 2014 16:25:51 +0200

On 6/10/2014 4:19 PM, Murray S. Kucherawy wrote:
>     Yes but are you assuming you only put the weak DKIM signature, when
>     you specifically know you are emailing a mailing list?
> 
>     allowing better replay of the message, if you put any weak DKIM
>     signature in the message... Unless the weak DKIM signature is
>     constrained to a specific usage.
> 
> 
> You're constraining it to use by a specific, very small set of domains,
> and only for a limited time.

Then again, let's note that this double-signed mail is going to show up
at some receivers that don't know about DKIM-delegate.

The underlying point needs to be that a receiver that is faced with
multiple signatures for the same domain needs some assessment of which
is the 'strongest' and to give that one the preference.

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 23:32:17 +0900

Franck Martin writes:

 > Sure but you have a strong DKIM signature and a weak DKIM
 > signature, using about the same domain, it is like the strong DKIM
 > signature did not exist...

Of course, the strong signature exists for the forwarding third party.

What the destination should do, is a question of how paranoid it is
about MITM attacks etc, and how much it trusts the list (and whether
the list re-signs).

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 23:59:03 +0900

Murray S. Kucherawy writes:

 > > It would require MLM to not drop DKIM headers... Still some
 > > configuration on MLM side, but less in the way messages are
 > > modified
 > 

Mailman added an *optional* capability to drop DKIM signatures at the
request of list operators who believed that DKIM failures were being
used to reject or discard messages (contrary to protocol, of course).
It drops all such fields.  I don't know whether other MLMs implement
it.  I don't know how commonly the capability is used or whether the
list operators still want it.  If this idea goes further, we can ask
the -developers and -users lists.

AFAIK otherwise Mailman doesn't delete fields.  Nor does it alter
fields except for:

(1) Personalization (list is replaced by subscriber in To: and Cc:).
(2) Anonymous lists (From: is replaced by list).
(3) Subject (optionally tag is added).
(4) Reply-To (traditional munging; as part of p=reject mitigation).

This is probably typical of most MLMs.

Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Jun 2014 17:14:58 +0200

> words, comments eagerly solicited.

Some comments:

First, weak signatures which are not part of a chain should be ignored
by verifiers.  An authentication chain can be defined as a set of
valid DKIM signatures and possibly an SPF authentication of delegated
domains ("D" set), ordered such that:

* the first one is an author domain signature,
* each signature covers more header fields than the preceding one,
* the last authentication is a full (i.e. not weak) DKIM signature, or
  an SPF "pass" authentication.

That way, by adding DKIM-Delegate: and/or Resent-To: as needed, it is
possible to have a mailing list send to another one.

The sentence starting this point is stronger than the wording in the
document.  The latter talks about satisfying "this profile", which may
sound like allowing those verifiers who used to validate weak
signatures to continue their practices so long as other profiles are
concerned.  Instead, since we encourage signers to produce weak
signatures, we ought to tell verifiers to ignore them unless they are
part of a chain.

Second, Section 3 and its subsections overstate the meaning of adding
a DKIM-Delegate: field.  AIUI, it serves when the To:/Cc: fields
contain more domains than those which are meant to be delegated.
Bullet 2 of Section 3.2 could characterize that better.  Bullets 3 and
7 should not assume the field is always there.  I suggest to define
weak signatures and then characterize the method independently of the
presence of any DKIM-Delegate: field.

Third, weakly signing should be limited to messages destined to known
mediators of trusted domains.  This point is just implied in the
document.  A discussion about the correspondence between envelope
recipients and signed destination addresses may be appropriate too.

Fourth, a full author domain signature seems to be useless if the only
recipient is a ML.

As a fifth and last point, I'd mention quotation marks (RFC 2045 token
vs quoted-string) among the uses of z= in Section 5.1.

Using z= is easier and probably more effective than trying to specify
a list of admissible, innocuous message alterations, but looks ugly.
Anyway, it may help having MLMs publish a how-to-sign DNS record.  The
record says what subject-tag the MLM adds, for which fields it wants
z=, in which cases it applies which encoding transformation, and the
like.  By itself, the existence of such record will confirm that a
given recipient expects weak signatures.  Just mumbling.

Ale

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 10 Jun 2014 08:41:51 -0700 (PDT)

> DKIM is already replayable.

i'm not talking about DKIM, i'm talking about DKIM-D.

i'm still waiting for u to address the spoofing hole
u left wide open with this approach.

no, i won't accept "short-lived" as a solution, cause that's
easy to circumvent.

> I don't see how this introduces whitelisting requirements.

===
section 3, DKIM-Delegate

[...] it asserts an ephemeral relationship between an original
message signing domain and a later intermediary (Mediator).
===

this is, ESSENTIALLY, a whitelisting approach.

and we have much better whitelisting solutions already.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 10:44:03 -0700

> no, i won't accept "short-lived" as a solution, cause that's
It means you have a limited time to reuse a delegation signature.  Also, as
defined, you have to be able to impersonate one of the domains in the To:
and/or Cc: field because one of those domains has to DKIM-sign the altered
content, and that signature has to pass for the receiver.  If you can do
both of those things, then yes, the attacker "wins".

Not everything has to be bulletproof to be useful as either an experiment
or a starting point for further discussion.  The document already calls
this out as a known risk; that's specifically what Security Considerations
is for.  The fact that there are risks doesn't automatically mean this
proposal fails.  If people aren't prepared to accept the risk, then they
don't have to do what's described here, and maybe it quietly fades into
history.  Otherwise, if this solves a problem for them and the risk is
palatable, then it might be useful to them.

> and we have much better whitelisting solutions already.

You must be using a different definition of "whitelisting" than I am.  To
me, a whitelist is something you have to query to provide elevated status
to some identifier that might be on that list.  There's no query happening
here, unless you consider that DKIM-Delegate is carrying the whitelist with
it implicitly for every message.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jun 2014 10:56:30 -0700

Hi Alessandro,

>   an SPF "pass" authentication.

The first one might fail.  In fact, for the use case of interest, we might
as well assume it always does.

Why the second requirement?

We already have the third requirement, minus the SPF tie-in.  I'm not sure
I see the benefit of the latter, since DKIM and SPF evaluate different
things in the first place.

> possible to have a mailing list send to another one.

Isn't that already possible?

> signatures, we ought to tell verifiers to ignore them unless they are

The "profile" language comes from an earlier version of the draft.  I'll
clean it up in the next version.

I agree, there should be language warning about the delegation signature on
its own.  However, we also have to realize that if that happens and a
receiver doesn't even know about this proposal, such text isn't going to
help any either.

> contain more domains than those which are meant to be delegated.

That's not correct.  DKIM-Delegate serves when there's a desire to delegate
to one or more of the domains listed in To:/Cc:, and not beyond that.  The
"t=" tag is provided in case there's a need to further expand that list,
such as when there's a Mediator in the envelope recipients but not in the
recipient fields.  (That, actually, needs to be called out in Security
Considerations; the "t=" tag reveals envelope information that might not be
intended to go anywhere.)

> presence of any DKIM-Delegate: field.

Doesn't RFC6376 already talk at some length about what should be considered
when deciding what content should get hashed?  I'm also worried about using
languages like "weak" and "strong" as it relates to signatures, because
those are pretty subjective terms.

> recipients and signed destination addresses may be appropriate too.

By "weak" I think you're referring to the delegation signature.  Yes,
that's a good suggestion, though it still imposes a requirement on the
originator to know what domains contain trusted Mediators, which is
something that has been a stalling point for things like ATPS.  The Yahoo!s
of the world would have to create some process by which they either
determine what those domains are by observing their own traffic, or have a
registration process for them.

What correspondence are you referring to?  DKIM has always been completely
independent of the envelope, and it should remain so.

> Fourth, a full author domain signature seems to be useless if the only

Why?

> given recipient expects weak signatures.  Just mumbling.

We're specifically hoping to avoid adding still more lookups here.  I'm
also not much of a fan of the proposed "z=" hacks, for the same reasons
that we abandoned that idea during the DKIM working group years.  "z="
should be used to identify what got modified, but not to report a different
result.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2014 14:15:29 -0000

This looks like a cleaner version of my forwarding token proposal.

>at some receivers that don't know about DKIM-delegate.

Right.  So if you don't want people using unforwarded weak signatures
for reputation management, you need to put something into them so that
old clients don't accept them as signatures and ignore the t= tag.
Either call them something other than DKIM-Signature, or do a version
bump to v=2.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Jun 2014 16:44:08 +0200

On 6/11/2014 4:15 PM, John Levine wrote:
> So if you don't want people using unforwarded weak signatures

If a receiver cares about 'strength' (or perhaps robustness) of
signatures, they should pay attention to that.

This does not require changes to DKIM.  Rather, it requires receivers
being diligent.

The issue has nothing to do with DKIM-Delegate.  That is, -Delegate is
not creating the issue.  Signers have always been free to hash less or
more of the message.

So while -Delegate might be making the issue more salient, by making
everyone more aware of it, the issue already existed.

d/

---

From: "John R Levine" <[email-masked]>
Date: 11 Jun 2014 16:56:42 +0200

> signatures, they should pay attention to that.

It is my impression that the idea here is that a signature with t= isn't 
interesting unless there's a matching signature with d=.  Or did I 
misunderstand that.

You are of course correct that senders have always been allowed to create 
weak signatures, but until now there has been little incentive to do so.

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Jun 2014 17:00:52 +0200

> interesting unless there's a matching signature with d=.  Or did I

It is provided because there is a -Delegate enabled, yes.  On the other
hand, the concern that the token signature will get used when it
shouldn't essentially means it is interpreted without awareness of
-Delegate.

Hence this is merely the case of two, competing signatures and deciding
which to choose.

That's a generic DKIM issue, and its resolution depends on the DKIM
evaluation.

> You are of course correct that senders have always been allowed to
> create weak signatures, but until now there has been little incentive to
> do so.

Hence my citing 'salience'.

d/

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Jun 2014 11:09:48 -0400

Preference should be given to the author domain explicitly authorized resigners, how ever that black box functionality is achieved. Currently, there are three DNS-based authorization proposals on the table.  From Murray's follow-up comments,  the DKIM-delegate is basically an optimizer to avoid doing a lookup.  If this can address the basic protocol fault failures the DNS lookup proposals addresses, the I would like see how that is done. I plan to study the draft more.

The most basic protocol fault is when no signatures, no extra new headers are available -- the legacy operation. Here the lookup is required.  If not, the bad guy loophole is simply to remain in legacy mode.  They don't need to think about trying to find a fake signature.

--
Hectorb Santos
http://www.santronics.com

> On Jun 10, 2014, at 10:25 AM, Dave Crocker <[email-masked]> wrote:
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jun 2014 13:58:40 -0700

On Wed, Jun 11, 2014 at 8:09 AM, Hector Santos <[email-masked]> wrote:

> Preference should be given to the author domain explicitly authorized
> resigners, how ever that black box functionality is achieved. Currently,
> there are three DNS-based authorization proposals on the table.  From
> Murray's follow-up comments,  the DKIM-delegate is basically an optimizer
> to avoid doing a lookup.  If this can address the basic protocol fault
> failures the DNS lookup proposals addresses, the I would like see how that
> is done. I plan to study the draft more.
>

One thing that is missing (and there's a placeholder for it) is examples so
you can see how it works.  I'll make sure that's there for -01.

> The most basic protocol fault is when no signatures, no extra new headers
> are available -- the legacy operation. Here the lookup is required.  If
> not, the bad guy loophole is simply to remain in legacy mode.  They don't
> need to think about trying to find a fake signature.
>

A lookup for what, and where?

But you're right, there's a risk of a legacy DKIM verifier getting only the
delegation signature for some reason.  The exposure is supposedly
time-limited, and we're assuming verifiers all pay attention to "x=", but
it should also be documented.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jun 2014 14:03:05 -0700

> Either call them something other than DKIM-Signature, or do a version

I'm not clear on the case you're describing.  Can you mock up an example?

Also, isn't it "x=" that's interesting here, not "t="?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2014 22:22:07 -0000

>Also, isn't it "x=" that's interesting here, not "t="?

Someone sends off a message to a mailing list with the two DKIM
signatures and DKIM-Delegate.  Someone else, perhaps a list
subscriber, notes that the weaker signature doesn't cover the body, so
he replaces the body with nose enlargement spam and blasts it out.
Recipient MTAs which haven't been updated since 2014 and don't know
about DKIM-Delegate see the weak but valid signature and since the
signer has a generally good reputation, delivers it.  Ugh.

This hasn't been a problem before.  Although you've always been
allowed to use weak signatures, there's been no advantage to doing so,
so nobody did.  Now you do, but with new semantics that you shouldn't
pay much (any?) attention to that signature unless it's paired with
the forwarder's.  One could make an argument that it's not technically
a semantic change to DKIM (indeed, Dave just did), but in practical
terms, it is likely to interact poorly with existing unupgraded
software, so I'd want a version bump so that the old software ignores
the special purpose signature.

Bonus question: why put the author domain and target domain fields in
a new header rather than just addding ddd=<author> and
ddt=<forwarders> to the signature header?

R's,
John

---

From: Vlatko Salaj <[email-masked]>
Date: Wed, 11 Jun 2014 14:52:03 -0700 (PDT)

On Wednesday, June 11, 2014 6:33 PM, Alessandro Vesely <[email-masked]> wrote:

> Or am I missing something?

delegated domain inclusion in DKIM-D header is optional,
and considering it requires some kind of whitelist from which
its to draw a list of domain it should include, compared 2 those
it should not, it is most probably not gonna be used.

not to speak that creation of such a whitelist is whole
another problem.

if u instead, make it automatic, for example, putting
To: domain into DKIM-D header automatically while message is
signed, then u have an open hole of spoofing such message by
any user of, for example, ESP which was in original To:.

so, u again need 2 fall back to whitelist.

now comes the question of why r we doing whitelisting in headers,
solving only a small portion of the DMARC-excluded email, when
we could do whitelisting in ASL, and deal with the problem
in a much broader way?

if we r doing whitelisting, it should be done properly, not
with aidband like DKIM-D.

> Beg your pardon, but I don't think you mean age/sex/location.  What is ASL?

Aligned Sender List... or Allowed Sender List, we r still debating
about the name. Hector Santos introduced it some time ago, as a 3rd party
solution for DMARC. it is still being worked on, but it's much more
promising than DKIM-D.

i simply prefer it over any header mumbo jumbo:
1. has no spoofing elements like DKIM-D,
2. can always survive message path, unlike anything header based,
3. provides much wider support for 3rd party than just ML.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jun 2014 15:47:50 -0700

> signer has a generally good reputation, delivers it.  Ugh.

Right, that's the "considerable latitude" that's already mentioned in the
draft.  The "x=" is the current protection against that sort of abuse.
It's not much, but it's what we've thought of so far.  The alternative is
to use an "l=" that is the length of the original rather than 0, which
constrains the abuse considerably but might reduce the likelihood of this
working.

> the special purpose signature.

I see your point, though it seems strange to do a version bump when that's
really the only change to the bits on the wire, and the only real change
then is how the signatures are interpreted; syntax vs. semantics.

> ddt=<forwarders> to the signature header?

Originally it was done as a separate tag, but that meant changing DKIM in
some way even if it means registering a new tag that some/most will just
ignore.  Using a separate header field keeps DKIM itself pristine, and just
builds on top of it.  Would reverting to a tag method obviate the need for
a version bump?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jun 2014 16:25:32 -0700

> then is how the signatures are interpreted; syntax vs. semantics.

Hmm:

DKIM-Signature: v=1; d=example.com; ...
DKIM-Signature: v=2; l=0; d=example.com; rsf=to,cc,trusted-lists.example.org;
...

"rsf" = "require signature from", with "to" and "cc" being special case
keywords with the obvious meaning.

You have something like that in mind?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Jun 2014 22:49:36 -0400

On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote:
>
> One thing that is missing (and there's a placeholder for it) is
> examples so you can see how it works.  I'll make sure that's there for
> -01.

Examples are good. Can we work it out here, a "software" walkthru? 
Save some drafting time.

>     The most basic protocol fault is when no signatures, no extra new
>     headers are available -- the legacy operation. Here the lookup is
>     required.  If not, the bad guy loophole is simply to remain in
>     legacy mode.  They don't need to think about trying to find a fake
>     signature.
>
>

The "Checking Signing Practice" (CSP) module in the DKIM architectural 
overview (RFC5585), the "Sender Signing Practices Query" in the DKIM 
Threat Analysis (RFC4686).   In this case, DMARC.

In general, the market is finally doing a DNS lookup for policy and we 
need to leverage that call for 3rd party semantics. In my view, that 
is the problem we are facing.

So if the proposed DKIM-Delegate header or DKIM-Signature 2.0 tags 
offer a lower overhead, shortcut to addressing all the threats, then 
we need to see how that is done.  I don't think it does cover the 
basic use cases unless there is something else in the logic I am not 
catching. More below on this.

> But you're right, there's a risk of a legacy DKIM verifier getting
> only the delegation signature for some reason.  The exposure is
> supposedly time-limited, and we're assuming verifiers all pay
> attention to "x=", but it should also be documented.

Good idea to use the x= more.

Yes, the risk with the existing base DKIM verifiers, but I speak of 
the more primitive, basic protocol faults "holes", "use cases" that is 
central to all this:

   Restrictive 1st Party (Author Domain) Signing Policies

   - No Mail Expected
   - Signature Required, Exclusive 1st party only.
   - Signature Required, Any 3rd party allowed.
   - Signature Required, Authorized 3rd party allowed only.

How will DKIM-Delegate address the above conditions?

The "No Mail" policy can be folded with the others. Previous proposals 
SSP, DSAP I-D included "No Mail" policies. ADSP with a 
"dkim=discardable" policy and a null public singer key. I suppose the 
same can be done for DMARC "p=reject" policy and a null public signer 
key. I just wanted to outline it above since it is also part of the 
modern mail processing logic to check for.

The goal is to detect the faults in the above policies.

If DKIM-Delegate does address the above, then its becomes a good 
optimizer. However, there still need to be an "IF ELSE" DNS lookup 
when the DKIM-Delegate or advanced 2.0 DKIM signature is missing.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jun 2014 20:07:21 -0700

On Wed, Jun 11, 2014 at 7:49 PM, Hector Santos <[email-masked]> wrote:

> Examples are good. Can we work it out here, a "software" walkthru? Save
> some drafting time.

The draft already does that in Section 3.2.  What's missing is an example
message showing the semantics.

Yes, the risk with the existing base DKIM verifiers, but I speak of the
> more primitive, basic protocol faults "holes", "use cases" that is central
> to all this:
>

That's not in scope here.  You could use draft-ietf-appsawg-nullmx for that
if you really want.

>   - Signature Required, Exclusive 1st party only.

You would simply not use DKIM-Delegate if that's your policy.

>   - Signature Required, Any 3rd party allowed.

I don't think we're interested in that case here.  Why would you want to
allow arbitrary third parties to sign on your behalf and have that be
meaningful?  That would mean I can sign something that came from you and
everyone would believe you approved it.

>   - Signature Required, Authorized 3rd party allowed only.

That's the exact use case for DKIM-Delegate.

> optimizer. However, there still need to be an "IF ELSE" DNS lookup when the
> DKIM-Delegate or advanced 2.0 DKIM signature is missing.
>

It only addresses one of those cases, but that's the only one we need to
solve here.  And since one of the big benefits of this mechanism is that
the policy becomes part of the message, there's no need to bring DNS (or a
published whitelist of any kind) into this at all.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Jun 2014 00:21:36 -0400

> That's not in scope here.  You could use draft-ietf-appsawg-nullmx for
> that if you really want.

The NULLMX proposal only applies on the SMTP client, sending, callout 
side. This one can be folded with the others, but again, its an 
optimizer.

> You would simply not use DKIM-Delegate if that's your policy.

Again, the fault. The policy is X, but Y is seen.  The payload can be 
DKIM-Delegate compliant but the actual policy is exclusive and doesn't 
allow it.  You need the lookup for this or prove the assertion it will 
satisfy the threat analysis for this use case.

> I don't think we're interested in that case here.  Why would you want
> to allow arbitrary third parties to sign on your behalf and have that
> be meaningful?  That would mean I can sign something that came from
> you and everyone would believe you approved it.

Yes, it is a more relaxed policy that does require a signer trust and 
this was the where we last left SSP because we were trying to figure 
out the scaled authorized signer model. In the mean time, it helps for 
the resigners to exist.  But again, its the fault we are detecting. 
The policy allow for any signer, but there meant be no valid 
signatures.  You are probably right that DKIM-Delegate can't resolve 
this, but what we want is for DMARC to have the language to say:

           "I'm ok with any trusted valid signer"

For the trust attribute, this is where either VBR comes into play or 
the DKIM_Trust_Assessment(SDID [,AUID) algorithm is applied, when its 
finally available.

> That's the exact use case for DKIM-Delegate.

Right, You want the fault of this case. In others, a domain may not 
expect the DKIM-Delegate header, but that is what you see or there is 
no header, and the domain expects it.

> It only addresses one of those cases, but that's the only one we need
> to solve here.

But it also has to address the others too at the same time, otherwise, 
there have loop holes.

> And since one of the big benefits of this mechanism is
> that the policy becomes part of the message, there's no need to bring
> DNS (or a published whitelist of any kind) into this at all.

I agree. Passing the policy via 5322 was talked about in 2005/2006 
between Jim Fenton and I.  But if the signature and/or policy 
information in the payload is missing, you have to do the lookup 
anyway.  And also, how are you going to show the the payload policy 
actually matches the DNS published policy?  In theory, they have to be 
the same because you are going to need a migration path.

We can do the same with the public key, piggy-back off the 5322 
payload too, saving even more DNS calls.  In theory, a compliant 
domain isn't going to commit suicide by providing faulty information. 
  By if you don't enforce it, then it does not solve anything.

Overall, the problem is the DMARC verifiers are indeed enforcing the 
strong policies.  If you have a DKIM-Delegate to address only 3rd 
party resigners, then you will need a matching backward compatible DNS 
version of this.

In this vain, I think there is a lost focus on working on 
dkim-delegate unless its overall functional goals comes in two 
flavors; a DNS and a NON-DNS version.  In this case, it is an optimizer.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jun 2014 21:45:07 -0700

> satisfy the threat analysis for this use case.

No, there are two possibilities in the face of DMARC "p=reject":

(1) There's no DKIM delegation, and therefore the From: domain's policy is
automatically what you call first-party only.

(2) There is DKIM delegation, and therefore the From: domain's policy is
either first-party or authorized third-party, where the list of authorized
third-parties is in the message (either DKIM-Delegate's "t=" field, or the
To/Cc fields).

> For the trust attribute, this is where either VBR comes into play or the
> DKIM_Trust_Assessment(SDID [,AUID) algorithm is applied, when its finally
> available.

"Any trusted valid signer" is not the same as "Any third party allowed"
(which is the first thing you said).  The minute you introduce the need to
know if X trusts Y, you're basically back to a whitelist and scaling
problems again.

We really don't want (or need) to deal with this use case.  We're only
interested in specific third parties.

> Right, You want the fault of this case. In others, a domain may not expect
> the DKIM-Delegate header, but that is what you see or there is no header,
> and the domain expects it.

It's never expected.  It's used at the discretion of the From: domain to
select one of two possible modes of verifying, described above.

> But it also has to address the others too at the same time, otherwise,

I disagree, I claim those others are out of scope.  We don't need them to
solve this problem.

> I agree. Passing the policy via 5322 was talked about in 2005/2006 between
> Jim Fenton and I.  But if the signature and/or policy information in the
> payload is missing, you have to do the lookup anyway.

I don't agree; the policy is implicit in DMARC (if that's what you're
using).

> And also, how are you going to show the the payload policy actually
> matches the DNS published policy?  In theory, they have to be the same
> because you are going to need a migration path.
>

In theory, DMARC would be amended to either allow for DKIM delegation
always, or offer it as a flag in the DNS record.  But ignoring DMARC for
the moment, no additional lookup is needed here.

> We can do the same with the public key, piggy-back off the 5322 payload
> too, saving even more DNS calls.  In theory, a compliant domain isn't going
> to commit suicide by providing faulty information.  By if you don't enforce
> it, then it does not solve anything.
>

This seems to go off in the weeds a bit.  Carrying the public key in the
message adds a bunch of bulk to the message and then adds the requirement
that the key be tied back to the domain somehow, otherwise you could use
any old key and claim to be anyone.  I don't think there's a need to drag
DANE into this.

> strong policies.  If you have a DKIM-Delegate to address only 3rd party
> resigners, then you will need a matching backward compatible DNS version of
> this.
>

I fail to see how DNS is a requirement for this beyond what DKIM already
requires.  The policy is implicit in the way the message is built with DKIM
and DKIM-Delegate.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 07:33:11 +0200

> delegated domain inclusion in DKIM-D header is optional,

This is a reading of the draft specification that appears to be
incorrect:  the DKIM-Delegate proposal always specifies target domain
names for delegated operation.

What is optional is the method of specifying them.  They can be
specified overtly, in the DKIM-Delegate header field, or they can
default to the set of domain names in recipient header fields, such as
To and CC:

     3.2. Specification

     2.   ...  It can also identify the specific
        domain(s) with which it wishes to claim an ephemeral
        relationship; absent this indication, the list of candidate
        domains is implicit from elsewhere in the message header (see
        below).

and

   3.3. Syntax
   ...
   t= Delegation target (plain-text; OPTIONAL).  This value is a comma-
      separated list of domain names to which the authority to sign on
      behalf of the Author domain is being delegated.  When not present,
      this list is inferred from the domain names present in the
      recipient fields (To, Cc) of the header.

> it should not, it is most probably not gonna be used.

DKIM-Delegate does not need or use any externally-maintained list.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 07:39:44 +0200

On 6/12/2014 12:22 AM, John Levine wrote:
>       One could make an argument that it's not technically

The irony of your suggestion is that it requires having 'unupgraded'
software reliably use the version number, given that they haven't needed
to do that before either...

> ddt=<forwarders> to the signature header?

1. Because DKIM isn't being modified.

2. Because there is non-DKIM information that needs to be permitted,
namely the list of delegated domains

3. Because layering is our friend.

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 12 Jun 2014 15:37:54 +0900

> Hence this is merely the case of two, competing signatures and deciding

An invalid DKIM signature should not be treated differently from the
absence of that signature.  I'm not sure about the intended precise
technical interpretation of that clause, but I suspect that some (many?)
verifiers will simply drop it from further consideration.

In spoofed messages either the content-covering DKIM signature will be
invalid, or it will be missing.

So the valid signature matching -Delegate is indeed weak
(authenticates little content), but *there is no competing signature*.

I don't know if that matters to your argument.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jun 2014 23:40:43 -0700

> to do that before either...

Section 6.1.1 of DKIM makes it a MUST that unknown versions result in an
error.  Are you assuming here that some/many/most implementations will have
ignored that?  You might be right; I'm just trying to be clear.  For that
matter, can we assume "x=" was properly implemented?

It would indeed be ideal to find a way to ensure that the delegation
signature is disregarded by legacy DKIM implementations, and only used when
coupled with a passing Mediator signature.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 08:52:48 +0200

On 6/12/2014 8:37 AM, Stephen J. Turnbull wrote:
> absence of that signature. 

I wasn't referring to any 'invalid' signatures.

When DKIM-Delegate is used, there are two, valid signatures for the same
domain.  One is 'stronger'.

The scenario being discussed is for a recipient who gets both signatures
when they are valid, but who does not know about DKIM-Delegate.  They
only know about DKIM.

Folks who are receiving this email they are reading, via the
[email-masked], would get only one valid signature, since the 'stronger'
one would be broken.  On the other hand you, Stephen, are a direct
recipient and ought to get two valid signatures.  One stronger, one
weaker.

So your system needs to decide which one to prefer.

It ought to prefer the 'stronger' one, but the point being raised is
that this is not an issue that has been at issue until now.  (Or, at
least, not much of an issue until now.)

My own response is that implementations of security-related software
that do not attend to factors that make the security weaker have deeper
problems than the one we are discussing now...

 I'm not sure about the intended precise
> invalid, or it will be missing.

The concern is that the weaker signature (that I call a token, given how
little of the message it is likely to cover) is more easily re-used for
a replay attack.

> (authenticates little content), but *there is no competing signature*.

except for direct recipients (and mailing list recipients for lists that
don't break the 'stronger' signature...)

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 08:55:31 +0200

On 6/12/2014 8:40 AM, Murray S. Kucherawy wrote:
> On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> error.  Are you assuming here that some/many/most implementations will
> have ignored that?  You might be right; I'm just trying to be clear. 
> For that matter, can we assume "x=" was properly implemented?

It's the kind of issue that needs field verification, because it is the
kind of spec detail that developers often treat casually or ignore.  If
they don't have to pay attention to it, to get things running, they
often don't.

Not YOU, of course, but lots of other developers...

It's one of the reasons that version numbers tend to have little real
utility.

> signature is disregarded by legacy DKIM implementations, and only used
> when coupled with a passing Mediator signature.

Well, remember that we need this to be useful even when there is no
mediator signature, if the receiver can validate the identity of the
mediator through other means...

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 12 Jun 2014 16:25:34 +0900

Hector Santos writes:

 > Again, the fault.

Please define "fault".  Also "lookup".  I doubt I'm the only one who
doesn't understand what you mean by these words.

 > The policy is X, but Y is seen.  The payload can be 
 > allow it.

You're thinking about a case where one or more unprivileged users at
the first party have been cracked, and mail that dkim-delegate
authenticates is being sent through 3rd parties but shouldn't be?

If there's no inside threat I don't see how this can happen (stolen
keys are an inside threat, breaking the crypto is outside of scope).

 >            "I'm ok with any trusted valid signer"

Why?  "Trusted" by whom?  If it's verifier trust, no problem.  They
know who they trust.  If it's Author Domain trust, use dkim-delegate
t= and put the intersection of your whitelist and visible and
invisible addressees in there (AFAICS this handles Bcc correctly,
modulo concerns with revealing Bcc addresses -- but that is something
for the originator to determine).

Note that AFAICS this is not subject to the "mail-privileges-only user
gets cracked" issue, as presumbly the whitelist is maintained by a
privileged user.  If it's not, this is effectively an "any signature
will do" policy.

 > party resigners, then you will need a matching backward compatible DNS 

Not really.  The unfortunate semantics of "p=reject" will in practice
be worked around by refusing to respect it when respecting it is a
socially destructive thing to do (eg, if the Author Domain is Yahoo! 
or AOL and there's "strong enough" evidence that the message is
legitimate).  That's a loss of face for DMARC, of course, but no more,
since it's already practiced by at least one "billion message" class
mailbox provider.  I suspect Yahoo! and AOL would be willing to
cooperate.[1]

I agree that the various issues with *absence* of DKIM-Delegate and
verifiers that don't implement DKIM-Delegate need to be considered,
and we need to consider the implication of cracking users limited to
mail-sending privilege as described above (in which case a policy
lookup by DNS would give different information).

However, we can, and perhaps should, "handle" this by saying "so don't
let your users get cracked if you have a 1st-party-only or no-mail
policy."

Footnotes: 
[1]  Note that even if a mailbox provider allows the users to populate
the whitelist, and an abuser discovers a way to exploit this, the
provider can shut them down very quickly by turning off -Delegate
headers in their MTA.

---

From: "John R Levine" <[email-masked]>
Date: 12 Jun 2014 10:12:48 +0200

> constrains the abuse considerably but might reduce the likelihood of this

For this application I don't see x= as much protection.  If a bad guy
subscribes to the list or gets messages via something like gmane, he
can do the mutate and spam in close to real time.

> keywords with the obvious meaning.

Right.  This seems to me a DKIM signature with a different semantics,
only pay attention to this one if there's a matching forwarding
signature (give or take your inexcusable assumption that nobody at the
registries in Tonga or the Cocos islands will ever use this.)

Adding new tags to DKIM signatures should be no big deal.  The spec has 
always been very clear that verifiers ignore tags that they don't 
understand and I know that works, since I've been adding private tags ever 
since the argument about what, if anything, the i= tag means.

Adding a new tag doesn't need a version bump so long as it's OK for 
verifiers that don't understand the tag to ignore it.  This needs a 
version bump since the intention is that the signature isn't interesting 
unless it's paired with a forwarder's signature so you have to undersand 
rsf=.

You could get the same effect by defining a new signature header with
the same syntax and meaning as DKIM-Signature except that the rsf= tag
is mandatory and you ignore it without the second signature:

DKIM-Forwarding-Signature: v=1; l=0; d=example.com; rsf=to,cc,trusted-lists.example.org;

I don't see any reason to prefer this, but whatever.

Re Dave's concern that DKIM verifiers don't look at the version number, 
that's easy enough to check since there aren't many widely used verifier 
libraries, and most large MSPs add A-R headers so you can send mail to 
your test account and see how it liked the signature.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 10:29:37 +0200

> unless it's paired with a forwarder's signature so you have to undersand

Sorry I wasn't clear about my core point:  Changes to a protocol should
involve changes to the protocol.

There is nothing about DKIM-Delegate that changes DKIM.

So, changing DKIM to accommodate -Delegate is artificial and merely adds
complexity to the engine unnecessarily.

d/

---

From: "John R Levine" <[email-masked]>
Date: 12 Jun 2014 10:32:42 +0200

> There is nothing about DKIM-Delegate that changes DKIM.

We disagree.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 11:01:52 +0200

> We disagree.

Yup.  But I don't mind your being wrong...

And humor aside, please state the technical changes to the existing DKIM
specification that are being made with DKIM-Delegate.

Keep in mind the fact that TCP uses IP, and does not change it.

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 12 Jun 2014 18:58:22 +0900

Dave Crocker writes:

 > when they are valid, but who does not know about DKIM-Delegate.

I didn't understand that from previous posts.  At least Hector seems
to be concerned (though not exclusively so) with the case I presented.
I suspect John as well.  And I think that case is important.

 > It ought to prefer the 'stronger' one, but the point being raised
 > is that this is not an issue that has been at issue until now.
 > (Or, at least, not much of an issue until now.)

If they're both valid, isn't this "no blood, no foul"?

Is there a concern is that having seen a token signature, it will
ignore the valid signature, and treat the message as high-risk?  I
think that that is a quality-of-implementation-issue that the
DKIM-Delegate document itself need not worry about, except maybe a
mention in the discussion section.

 > little of the message it is likely to cover) is more easily re-used for

I don't understand what attack you have in mind, if that attack
involves two valid signatures from the Author Domain, the content-
covering signature has a "good" selection of headers, and doesn't use
the l= tag.  (The latter two conditions are consonant with current
common practice, I believe, but I mention them for completeness in
describing the scenario I think is relevant.)

If the attack doesn't have two valid signatures from the Author
Domain, then aren't we in the scenario I describedin my previous
post?

Steve

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 12:04:34 +0200

> I suspect John as well.  And I think that case is important.

Now it's my turn to not understand.  Really, what scenario is involved here?

> If they're both valid, isn't this "no blood, no foul"?

The concern is a a write-down attack, where the weaker signature is
effectively an exploit.

> mention in the discussion section.

Sounds like a generic issue with receiver use of DKIM.  A worthy
question, but not inherent to -Delegate.

> describing the scenario I think is relevant.)

The premise is that the weaker nature of the token signature (needed to
get it to survive through the mailing list) will make it more subject to
some form of replay attack that includes bad content.

I've no idea how serious the threat is, but it's certainly a
mathematically legitimate concern.

> Domain, then aren't we in the scenario I describedin my previous

Probably.

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 12 Jun 2014 19:10:37 +0900

> can do the mutate and spam in close to real time.

Is this a practical concern, though?  The levels of spam etc that
drove Yahoo! and AOL to "p=reject" were *huge*, and have persisted
(according to Elizabeth Zwicky of Yahoo!) for several weeks after
imposition of "p=reject".  The "retail" spams you describe are still
going to have to run the obstacle course of content filtering, I would
suppose, and x= means they have to use substantial resources to
continually harvest new signatures.  Do-able, of course, but how much
of a threat?

---

From: "John R Levine" <[email-masked]>
Date: 12 Jun 2014 13:29:58 +0200

> specification that are being made with DKIM-Delegate.

If a signature has an rsf= tag, verifiers ignore it unless there's a 
matching signature from a domain the rsf= points to.

This is not backward compatible, since verifiers that don't understand 
rsf= will often get the wrong answer, so it needs a version bump.

R's,
John

---

From: Elizabeth Zwicky <[email-masked]>
Date: Thu, 12 Jun 2014 11:29:55 +0000

>continually harvest new signatures.  Do-able, of course, but how much

I did not say that the levels were the same; I said the attackers have
not gone away. They are not at high volume, but they're sure sitting
there checking to see whether or not it's working.

x= is a weak protection here; spammers can and do move millions of
messages a minute to us. Then again we are well placed to implement
special handling here, as are most if not all sites receiving mail
at this kind of scale. So the problem is at small and intermediate
sites.

	Elizabeth

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 12 Jun 2014 13:51:05 +0200

Hi Murray,

> as well assume it always does.

Well, a chain is valid only if all of its signatures are valid.

> Why the second requirement?

The chain gets extracted from the available signatures.  They need to be
ordered.  In an A->B->C->D scenario, where B and C are mediators, the
receiver D has to extract A, B, C, in that order.

The set of signatures is not totally ordered, just partially.  That
formulation of the second rule is handy to code a comparison function
for sorting.

> things in the first place.

The doc says "if the receiver can otherwise determine that the message
was handled through a delegated domain".  I just clarified it, adding
that only the last authentication in a chain can be handled that way.

> Isn't that already possible?

No, the doc doesn't mention multiple instances of DKIM-Delegate:.  BTW,
you should probably specify it has to be treated as a trace field.

> receiver doesn't even know about this proposal, such text isn't going to

You're right.  It is both an advantage and a disadvantage.  At first,
such DMARC receivers will "magically" accept mailing list traffic by
verifying only the first (weak) signature in a chain.  Then they'll
learn --the hard way, if they're out of luck-- how verifications should
be carried out.

> intended to go anywhere.)

The spec allows using t= to both contract or expand the delegation list
(as well as to leave it as is, redundantly).  Author's domains who don't
expand that list are more respectful of that principle of header field
visibility which inspired DMARC.

In the multi-intermediary scenario above, A->B->C->D, B knows that C is
an intermediary and trusts it.  Most likely, B must extend the original
delegation list.  It can do so by adding a Resend-To:, a DKIM-Delegate:,
or both; neither is visible.

> Doesn't RFC6376 already talk at some length about what should be
> considered when deciding what content should get hashed?  I'm also
> worried about using languages like "weak" and "strong" as it relates
> to signatures, because those are pretty subjective terms.

How about "partial" and "full"?  The problem with "primary" and
"secondary" is that they are not so obvious.

> registration process for them.

Alternatively, mediators can be the first movers, flanked by their
users.  I proposed an online demonstration.

> independent of the envelope, and it should remain so.

Formally, yes.  In practice, users trust the header addresses.  If a
message is authenticated, that trust ought to be warranted, up to
acceptable changes, or the authenticated entity must be willing to give
explanations in case questions arise.  Isn't that what authentication is
all about?

>> Fourth, a full author domain signature seems to be useless if the only

If it's gonna get broken, it can only be useful for the MLM itself.  Now
that you put the question, I realize that it is a clever idea for a MLM
to use it, but I think none do.  MLMs who want the full author domain
signature could ask for it in their how-to-sign record (oh, well...)

> We're specifically hoping to avoid adding still more lookups here.

This one would occur on sending, only when the recipient is one of those
trusted intermediaries.  And can also be used to gauge how this proposal
is doing...

> I'm also not much of a fan of the proposed "z=" hacks, for the same
> reasons that we abandoned that idea during the DKIM working group
> years.  "z=" should be used to identify what got modified, but not to
> report a different result.

Agreed.  If it serves just the few cases mentioned above, case-specific
workarounds are much better.

Ale

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Jun 2014 13:09:33 -0400

> doesn't understand what you mean by these words.

A lookup is a callout, a shim, a hook, a "blackbox" query, a "function 
generator" and so on. In this case, the lookup is a DNS-based query. 
We can today offer a practical functional process model as so:

     Result  = CheckSigningPractice(ADID [, SDID])

where

     ADID is the required Author Domain Identity, and
     SDID is the optional Signer Domain Identity.

Note, I used the optional parameter prologue definition since that is 
what we have today and we are trying to get SDID back into the lookup 
algorithm which MAY be a non-DNS algorithm as well.  That is what you 
are trying to do. I am saying you need a fallback with the 
DKIM-Delegate idea, so at best, it a short circuiting optimization 
concept.

The functional concepts are described and outlined in various 
documents developed over the years, including the RFC documents 
referenced in DKIM RFC6376 section 1.1:

    1.1.  DKIM Architecture Documents

    Readers are advised to be familiar with the material in [RFC4686],
    [RFC5585], and [RFC5863], which provide the background for the
    development of DKIM, an overview of the service, and deployment and
    operations guidance and advice, respectively.

The three documents are:

    RFC4686  Analysis of Threats Motivating DKIM
    RFC5585  DKIM Service Overview
    RFC5863  DKIM Development, Deployment, and Operations

Review the documents to get a functional understanding of the entire 
DKIM layered framework. Fundamentally, the lookup in RFC4686 was 
conceptualized as "Sender Signing Practices Query" (SSP):

                       +---------------------------------+
                       |       SIGNATURE CREATION        |
                       |  (Originating or Relaying AU)   |
                       |                                 |
                       |   Sign (Message, Domain, Key)   |
                       |                                 |
                       +---------------------------------+
                                        | - Message (Domain, Key)
                                        |
                                    [Internet]
                                        |
                                        V
                       +---------------------------------+
      +-----------+    |     SIGNATURE VERIFICATION      |
      |           |    |  (Relaying or Delivering AU)    |
      |    KEY    |    |                                 |
      |   QUERY   +--->|  Verify (Message, Domain, Key)  |
      |           |    |                                 |
      +-----------+    +----------------+----------------+
                                        |  - Verified Domain
      +-----------+                     V  - [Report]
      |  SENDER   |    +----------------+----------------+
      |  SIGNING  |    |                                 |
      | PRACTICES +--->|        SIGNER EVALUATION        |
      |   QUERY   |    |                                 |
      |           |    +---------------------------------+
      +-----------+

This model still applies as well as the model in RFC5585 where it was 
conceptualized as a "Check Signing Practices" (CSP) module, component, 
"blackbox" concept:

                     |- RFC5322 Message
                     V
      +--------------------------------+
      |  Message Signed?               |
      +-----+--------------------+-----+
            |yes                  |no
            |                     |
            |                     |
            |                     |
            V                     |
      +-------------+             |
      |  Verify     +---------+   |
      |  Signature  |         |   |
      +------+------+         |   |
         pass|            fail|   |
             V                |   |
      +-------------+         |   |
      | Assessments |         |   |
      |             |         V   V
      +-----+--+----+      +-------+
          |    |          / Check   \
          |    +-------->/  Signing  \
          |             /   Practices \
          |            +-------+-------+
          |                    |
          V                    V

For describing "fault," it is semantically more complex since its a 
system level security concept but also a well understood concept among 
industry peers across various technical and communications fields 
including automated process control concepts, artificial intelligence 
concepts like expert systems, fuzzy logic, neural networking, robotics 
and yes IETF protocol client/server engineering.

If you have a "series of steps" for an operation, you look for faults, 
holes, inconsistencies, "errors" in that operation -- in short, 
protocol faults would be threat entry points.  They become threat 
entry points if you don't watch for these basic conditions:

    - no mail expected,
    - only 1st party signature expected,
    - any valid signature is expected,
    - only 1st party or authorized 3rd party.

At best, DKIM-Delegate allows a reduction for lookups, but not 
eliminating them.  This mean that verifiers must now have fallback and 
migration complexities, more coding.  It might be worth to explore as 
an optimizer. Definitely, not a replacement.

>> DKIM-Delegate compliant but the actual policy is exclusive
>> and doesn't allow it.
>

Its below all that. The logic is detecting a fault in the domain 
policy declaration and mail operation expectation compared to what is 
actually detected. A condition expected did not happen. What will be 
done about it?

The power of the DKIM+POLICY framework since its invention comes from 
the detection of these enforceable failure points and taking 
enforcement action when the domain has declared such enforcement. If 
not enforced, then we have reduced payoff, increase security problems, 
high processing wastes.

-- 
HLS

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 12 Jun 2014 00:53:57 -0700 (PDT)

> DKIM-Delegate does not need or use any externally-maintained list.

please, solve this spoofing example:

1. so, a sender sends DKIM-D with every email, regardless whether
   it is meant for a mailing list or not, cause they maintain no
   whitelist to make a difference,

2. sender sends an email to me. mind u, i'm not a mailing list.
   sender added me in DKIM-D "t=" tag [there's no whitelist,
   so any receiver is a candidate, whether defined by "t=" or
   implicitly],

3. i see there's DKIM-D in ur email, i copy it for my message, sign
   that message using my DKIM [i AM a delegated entity], and
   send away an email satisfying DKIM-D profile, caring whatever
   i'm interested transmitting to my victims.

or am i missing something?
a whitelist, perhaps?

this is a common issue with any weak DKIM.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Jun 2014 11:50:04 -0700

> please, solve this spoofing example:

Asked and answered already, here (and elsewhere):
http://www.ietf.org/mail-archive/web/dmarc/current/msg01250.html

There's no need to beat a dead horse.  We're discussing what we could do
about this, because we know it's a weakness with the current proposal.  One
good suggestion was made later in the same thread.

> or am i missing something?

Is there some reason a queryable whitelist is better than an implicit (and
very small) one, which is the design here?  It seems like there's quite a
lot of overhead in making that work.

Obviously.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 13 Jun 2014 07:19:21 +0900

> Now it's my turn to not understand.  Really, what scenario is involved here?

Any situation where the token signature is the only valid signature
from the Author Domain.

 > The concern is a a write-down attack, where the weaker signature is

We're talking about verification by the destination MTA (no mention of
mediators anywhere.  If there *is* an attack involving two valid
signatures from the Author Domain, I don't see how either DKIM or
DKIM-delegate can do anything about it.

 > > ignore the valid signature, and treat the message as high-risk?
 > 

That's part of what I meant by "quality-of-implementation issue".
Sorry it wasn't clear.

 > >  > The concern is that the weaker signature (that I call a token,
 > >  > given how little of the message it is likely to cover) is more
 > >  > easily re-used for a replay attack.
 > > 
 > > involves two valid signatures from the Author Domain, the
 > > content-covering signature has a "good" selection of headers,
 > > and doesn't use the l= tag.
 > 

Yes, I understand that, but I don't see mathematical legitimacy
without an invalid/missing content-coveting signature in the picture
(unless users at the Author Domain have been suborned by the abusers).
So I don't understand why your analysis is limited to the two-valid-
signatures case, which doesn't have an "interesting" failure mode as
far as I can see.

Mathematically, a crappy implementation could indeed choose to reject
because of the presence of a token signature, despite the presence of
a valid content-covering signature.  But the answer is "Well, if that
hurts, don't do it."

---

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

Elizabeth Zwicky writes:

 > I did not say that the levels were the same; I said the attackers
 > have not gone away. They are not at high volume, but they're sure
 > sitting there checking to see whether or not it's working.

What you said, exactly, is

   But I do, in fact, have data, and that data tells me that the
   attackers forging our users based on stolen addressbooks have never
   stopped; we are still blocking them now.

What they were doing was sending millions, perhaps billions, of spoofed
messages.  "Never stopped" implies they are still sending millions,
perhaps billions, of spoofed messages.  As does "we are still."
Do you really mean to invoke "plausible deniability"?

N.B. I've already embarrassed myself twice by citing your message as
support for my belief (expressed in my own words, not a quote or
paraphrase) that the spammers are still attacking Yahoo! (in volume,
vs. probing for weaknesses).  I resent that.

 > at this kind of scale. So the problem is at small and intermediate

Implementation of DKIM-Delegate is a site-by-site decision.  I don't
see why you would know better than the site admins for other sites.
If you're worried about them, document the issues and let them decide.

In any case, filtering by 3rd parties has to be presumed weak, and
lists are obvious targets for spammers (as amplification devices).
Anybody who doesn't check incoming list traffic for spam should fold
up shop and send their users to Yahoo! IMO.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 13 Jun 2014 08:05:15 +0900

> rsf= will often get the wrong answer, so it needs a version bump.

Can't both the version bump issue and the token signature issue be
ameliorated by incorporating the token signature in the DKIM-Delegate
field?

There's a protocol collision on the t= tag which would need to be
addressed, but otherwise I don't see a problem.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Jun 2014 16:47:52 -0700

> addressed, but otherwise I don't see a problem.
Interesting.  So DKIM-Delegate is syntactically the same as DKIM-Signature,
but with augmented semantics?  Or did you have something else in mind?

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 13 Jun 2014 09:34:35 +0900

> but with augmented semantics?  Or did you have something else in mind?

That's what I had in mind.  But the semantics are not merely
augmented, they're conceptually different.  DKIM-Delegate attests only
to the authenticity of the delegate list, not to the content of the
message.

It occurs to me that that means that in the case of use of an explicit
delegate list, the DKIM-Delegate field needs to contain a signature
for itself.  Not a conceptual problem AFAIK, but the creation and
verification of the field get fussy.

I think that in general use of an explicit delegate list should be
recommended, and that where the Originator can identify lists with
good reputations, it should restrict to them rather than allow random
mailboxes.  I'm not sure how to make precise enough to go into the
I-D, though.

---

From: Elizabeth Zwicky <[email-masked]>
Date: Fri, 13 Jun 2014 04:24:03 +0000

>Do you really mean to invoke "plausible deniability"?

No, I mean to say that "never stopped" does not mean "never slowed down",
it means
"never stopped". And we are still blocking them now, every day, possibly
every minute.
The volumes are for the most part down to the levels they were after this
attack started
being used but before the onslaught began, although they go up
considerably from time to time.

Your argument was that we should turn off blocking to see what would
happen.
That only makes sense if the attackers have actually fully gone away. If
you
are still blocking them every day, at any level, there's really no need to
find
out what will happen if you stop blocking them. You don't unlock the door
when somebody
is still standing outside it rattling it to see if it will open.

	Elizabeth
	[email-masked]

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 13 Jun 2014 15:18:34 +0900

Elizabeth Zwicky writes:

 > No, I mean to say that "never stopped" does not mean "never slowed
 > down", it means "never stopped".

OK.  I'll remember that.

In any case, now I wonder what they're really trying to do.  They can
check for "p=reject" without sending *any* mail.  (I know, you're not
in a position to speculate publicly.)

 > Your argument was that we should turn off blocking to see what
 > would happen.  That only makes sense if the attackers have actually
 > fully gone away.

Getting to that conclusion requires a lot of assumptions, all implicit.

The way I see it, the attackers are doing this as a business.  If they
think they can make enough money in 1 minute (or however long it takes
the defense to react, 2X DNS resource TTL I'd guess), they will come
back in force, and soon.  On the other hand, suppose they do and you
shut them down in one minute.  How does that look to *their clients*?

AOL's graph showed more than a week of the torrent.  If you cut that
off in 1 minute, the fraction that gets through is 1/(7x24x3600) =
0.00000165, and presumably their revenues will be reduced in that
proportion.  Heck, they might even consider getting a real job!

Is that argument a justification for Yahoo! experimenting?  I doubt
it, and of course you know a lot more than I do.  But it's not the
"beyond obvious" conclusion that your phrasing makes it appear.

---

From: John Sweet <[email-masked]>
Date: Fri, 13 Jun 2014 07:47:36 +0100

On Jun 13, 2014, at 7:18 AM, "Stephen J. Turnbull" <[email-masked]> wrote:
> check for "p=reject" without sending *any* mail. 

That's not an integration test. It's all automated. The answer you want is, "Can I make money now?" This is how you get the answer. The DMARC record is only part of the story, whether recipients act on it or not is just as important.

The source code for spamming tools isn't hard to find, or to read. There are tutorials. It's a competitive market.

Every single AS technology we've written over the years to block an exploit sees constant, low-traffic probing continue indefinitely. It works.

> The way I see it, the attackers are doing this as a business.

And not a small one. 

J

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 13 Jun 2014 16:46:54 +0900

John Sweet writes:

 > That's not an integration test. It's all automated. The answer you
 > want is, "Can I make money now?" This is how you get the
 > answer. The DMARC record is only part of the story, whether
 > recipients act on it or not is just as important.

Well, for Author Domains publishing "p=reject", we can certainly
confuse the issue dramatically.  Change the protocol to advocate
"silent discard" instead of "return to sender", and then probing gives
spammers no idea whether domains are discarding or delivering, and
they have no data on their conversion rate for spams received.  They
don't want to report what they see (victims/sent, much lower than
victims/(sent - rejected)), and any numbers they have to support
higher estimates are for other domains or growing stale.

Author Domains receive a report, they can see if their users are
losing mail and let them know.  Keep a copy for a few hours until the
report gets back if they don't trust their users to do so.

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2014 18:46:11 -0000

>when they are valid, but who does not know about DKIM-Delegate.  They

That's not a problem -- if it has both signatures it is presumably the
real message and it doesn't matter which one the recipient uses.

The problem is when the message arrives with only the weak signature.
If the recipient doesn't know that the weak signature is supposed to
be paired with a strong signature from the forwarder, it will treat
the weak signature as a regular signature, which is, as I understand
it, undesirable, since that likely means that the message has had its
body replaced by a bad guy.

Perhaps there are DKIM validators that look at the signature to decide
how strong it is, but I don't think I've ever seen one.  Either they
pass or they fail.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2014 18:47:31 -0000

>ameliorated by incorporating the token signature in the DKIM-Delegate

Yes, you could do the equivalent of the version bump by changing the
name of the header, but I don't see the point.

---

From: [email-masked]
Date: Sat, 14 Jun 2014 12:35:24 -0700 (PDT)

> name of the header, but I don't see the point.

If you're going to bump the version, you need to use the opportunity to
solve the more general underlying problem.

I'm not sure I can completely characterize that problem, but it's something
along the times of there need to be some way to state the intention behind this
particular signature. Is this a signature tied to use by third parties?
Whitelisting? Something else?

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 14 Jun 2014 16:10:45 -0400

>>>> matching signature from a domain the rsf= points to. ...

> Whitelisting? Something else?

That's what the rsf is supposed to mean.

I suppose we could factor it out and do a version bump and add a new 
"conditional signature" cs= field, which means that a verifier only uses 
this signature if the conditions are met.  There's a registry of cs field 
values, and if there is a cs field whose condition isn't satisfied, or 
that the verifier doesn't know about, the verification fails.

So it'd be something like this:

  DKIM-Signature: v=2; ... cs=fwd; ... ft=t,c,foo.example

That is, the condition is that it's also signed by one of the targets in 
the forwarding target "ft=" field.  ("t" and "c" are the to and cc 
headers, on the perhaps overoptimistic theory that there will never be 
single letter TLDs.)

You can safely add new cs values without a version bump, since the 
verifiers will fail until they've been upgraded to understand them.

Regards,

---

From: [email-masked]
Date: Sat, 14 Jun 2014 13:12:39 -0700 (PDT)

> That's what the rsf is supposed to mean.

I understand that. The question is what happens when another, similar
proposal comes along. Unless I'm missing something, rsf is quite specific
to this delegation proposal.

> that the verifier doesn't know about, the verification fails.

That's one of the axes we could proceed along. The other would be
to focus instead on the purpose of the signature, and make the conditions
part of that.

I don't know which is better. There's a serious design decision to make here.

> verifiers will fail until they've been upgraded to understand them.

Yes, that's the general idea. But I'm not sure this is the right way to do it.

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 Jun 2014 16:34:19 -0400

> solve the more general underlying problem.

+1 ... And then some. 

> Whitelisting? Something else?

The theoretical solution is a DNS-based lookup with an in-band optimizer, like a DKIM-Delegate.  I say it is the only practical and most cost effective solution based on implementation experience (minus the optimizer).  The problem I sense is learning who to whitelist automatically out of the box and the management for the whitelist.  Yahoo says they need 30k whitelist records.  I don't see why that is a problem for them. They got the money to manage it. No? It's not going to be problem for me, you and most domains. Most domains are not going to need such scale or expect to be authorizing anyone else but themselves. Besides, we are talking software -- let it do the work.   

Personally, it's getting ridiculous. So much time being wasted.

--
Hector Santos

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 Jun 2014 19:03:02 -0700

> how strong it is, but I don't think I've ever seen one.  Either they

OpenDKIM has all sorts of hooks for doing that kind of thing, but I don't
know if anyone actually uses them.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 Jun 2014 19:08:20 -0700

> Whitelisting? Something else?

What about a new canonicalization, which is largely the same as the
existing ones but carries with it the additional semantic that "This can
only pass when accompanied by a Mediator signature"?

Current verifiers don't know what this is and thus wouldn't know what to do
with it, so unless they do something abysmally stupid like "I don't know
what this canonicalization is, so let's just call it a 'pass' to be on the
safe side", this might be a path forward without a version bump.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 14 Jun 2014 22:12:19 -0400

>> along the times of there need to be some way to state the intention behind
>> this particular signature. Is this a signature tied to use by third parties?

That would work, but it seems more kludgy than usual to tie the new loose 
canonicalization to the second signature.  Those are both features that 
seem like they could be useful on their own.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 15 Jun 2014 05:57:21 +0200

On 6/15/2014 4:08 AM, Murray S. Kucherawy wrote:
> Current verifiers don't know what this is and thus wouldn't know what to
> do with it, so unless they do something abysmally stupid like "I don't
> know what this canonicalization is, so let's just call it a 'pass' to be
> on the safe side", this might be a path forward without a version bump.

The suggestion I made in an offlist discussion was a new header
canonicalization, but it hadn't occurred to me to include the
contingency of a mediator signature.

It's an interesting idea, but does seem like some sort of layer
violation.  (i wanted some phrase other than 'kludgy' just so i didn't
echo john...)

Surely there are enough details we could vary in a header
canonicalization that are legitimate so that we don't need to toss in
odd 'policy' characteristics to the of the algorithm?

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 Jun 2014 23:01:01 -0700

> odd 'policy' characteristics to the of the algorithm?

Hmm.

How about a new tag, "shf=" (special header fields).  Ignored by legacy
verifiers, as required; otherwise, contains a colon-separated list of
fields that get special handling by verifiers.  "Special handling" depends
on the header field and would need to be documented in each case.  For
DKIM-Delegate, for example, it is always canonicalized in a special way
that would cause the signature never to validate for a legacy verifier.

Or maybe "shf=" header fields are only canonicalized by verifiers that know
that they're special and why; they're a separate list than "h=".

Somewhat less bogus than a new canonicalization that imparts new semantics;
a new tag would, one would think, always impart new semantics in the first
place.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 15 Jun 2014 08:15:18 +0200

On 6/15/2014 8:01 AM, Murray S. Kucherawy wrote:
> fields that get special handling by verifiers.  "Special handling"
> depends on the header field and would need to be documented in each
> case.  For DKIM-Delegate, for example, it is always canonicalized in a
> special way that would cause the signature never to validate for a
> legacy verifier.
> 
> Or maybe "shf=" header fields are only canonicalized by verifiers that
> know that they're special and why; they're a separate list than "h=".
> 
> Somewhat less bogus than a new canonicalization that imparts new
> semantics; a new tag would, one would think, always impart new semantics
> in the first place.

I do not understand this predilection for trying to change the DKIM base
engine.  It doesn't need it.

I also don't understand the construct of 'special handling', nevermind
not liking the idea of it, especially since it explicitly creates the
complexity of "depends on the header field".

What I was suggesting was merely registering a new canonicalization
algorithm.  Legacy DKIM implementations won't understand it.  New ones
(presumably also modified to know about DMARC) will.

The new canonicalization should have actual differences from the current
ones that are deemed worthy for general use.

For example, how about 'very-relaxed' which is like relaxed but
eliminates all WSP from the calculation rather than just compressing it?

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 15 Jun 2014 15:45:16 +0900

> name of the header, but I don't see the point.

There are two points.  First, all the new semantics ends up supported
by the new header; it gets completely ignored by existing MUAs, which
means that there's no reason at all for a version bump.

Second, a version bump means screwing with your existing, presumably
working DKIM code because you need to produce a backward compatible v1
signature where possible, and a new v2 signature for the token
signature and any other new semantics that gets piggy-backed on it.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 15 Jun 2014 15:53:45 +0900

> that would cause the signature never to validate for a legacy

This seems to have it backwards though, because it's the presence of
the DKIM-Delegate field that means one or more of the DKIM-Signature
fields require special handling.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 15 Jun 2014 12:06:10 +0200

> eliminates all WSP from the calculation rather than just compressing it?

Let's take the occasion to also have it eliminate quotation marks.
See http://mipassoc.org/pipermail/ietf-dkim/2011q2/016518.html and
following discussions.

Ale

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 15 Jun 2014 09:43:48 -0700

> eliminates all WSP from the calculation rather than just compressing it?
The reason I don't like this approach -- assuming I am not missing
something from this idea -- is because then we are, directly or not, tying
verification semantics outside of DKIM to a canonicalization.  In essence
the change is to add this new canonicalization and at the same time teach
verifiers that the token signature, in the absence of DKIM-Delegate and a
passing Mediator signature, is to be ignored.  I would much rather it be
more explicit than that.

Adding a new tag that introduces this is fully backward compatible with the
installed base, and isn't piggybacked on a new header canonicalization that
(as far as I know) we don't actually need.  I'm happy to be corrected on
that if there's actual data about it, of course.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 15 Jun 2014 09:47:17 -0700

On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull <[email-masked]>
wrote:

> depends
True, but I think that small bit of weirdness is fine in the face of the
token signature that would be misinterpreted and possibly abused by legacy
DKIM installations that don't know about new tags or header fields.

-MSK

---

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

>engine.  It doesn't need it.

Actually, I claim that a version bump is the approach least likely to
break existing clients.

>I also don't understand the construct of 'special handling', never mind

I think we agree that the goal here is to have a weak signature that
verifiers disregard unless it's associated with a delegated signature.
Your plan, as I understand it, was that verifiers will ignore a
signature that is too weak.  One might argue clients that accept weak
signatures are already broken, but in that case there are an awful lot
of broken clients, starting with spamassassin.  (I just checked.)

Until now there's been no reason other than playing games to use weak
signatures, so in practice it hasn't mattered.  Now it does, so
clients have to change their code to check for "too weak", probably in
inconsistent ways, to check for l= and what headers are signed and so
forth.

Murray's trick, add a new canonicalization that's only valid if
there's a paired signature, many not require a version bump, but to be
useful it does require a change to the verifier library interfaces.
Libraries and clients are not upgraded in sync, so there will be old
clients calling upgraded libraries.  The libraries can't just accept
the new canon and return "valid", since old clients won't know to look
for the paired signature.  They can't return "conditionally valid",
since clients won't know what to do with it.  So the libraries will
need a new entry point, or at least a new option, for the client to
say that it understands a conditionally valid result.  A few moments
thought should confirm that's semantically the same as an option for a
client to say it understands v2 signatures, just kludgier.

With respect to Stephen's concern about libraries knowing when to
construct v1 or v2 signatures, really, that's no big deal.  We've been
doing that sort of stuff for version bumps since approximately
forever, and it's a nit compared to the other stuff it'll have to do
to interpret the conditional signatures.

It also occurs to me that there are all sorts of ways that a
conditionally valid signature would be useful.  For example:

* valid if this DNS lookup resolves, for per-signature revocation

* valid if the body has this S/MIME signature, to allow for list
software that reformats the message but keeps the signed body part
(mailman and mj2, for example) or that resigns with its own S/MIME
signature (sympa)

* valid if the body has this PGP signature (mailman's working on it)

Some of these can be done with kludges, but most can't.

R's,
John

---

From: [email-masked]
Date: Sun, 15 Jun 2014 11:58:42 -0700 (PDT)

> of broken clients, starting with spamassassin.  (I just checked.)

Out of curiousity, did you try having two signatures in various different
orders and combinations of validity?

Mind you, even if this leads to a way of structuring these things
that "works" for the current crop of clients, I would not be inclined to
trust it. I'm just curious.

> inconsistent ways, to check for l= and what headers are signed and so

Agreed. Like it or not, this calls for, let's call it a "clarification"
of existing DKIM semantics. And to do that you either bump the version
or overload some other existing field in the protocol.

> useful it does require a change to the verifier library interfaces.

Six of one, half a dozen of the other.

> client to say it understands v2 signatures, just kludgier.

Exactly.

> Some of these can be done with kludges, but most can't.

Exactly why I think that as long as we're bumping the version, building in some
additional extensibility seems like a really good idea. The only question
is how much and in what form.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 15 Jun 2014 15:24:48 -0400

> orders and combinations of validity?

No, but from looking at the code, I don't think that would matter.  It
makes a table of the signatures (just the valid ones, I believe) and then 
applies various rules about signers and pseudo-ADSP.

> is how much and in what form.

Suggestions welcome.

Regards,

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 16 Jun 2014 09:25:04 +0900

> Actually, I claim that a version bump is the approach least likely to

The point is to avoid breaking the anti-spam *system*.  If the system
continues to work (in some appropriate sense) in the presence of
clients "broken" in some sense, that's a win.

 > of broken clients, starting with spamassassin.  (I just checked.)

Spamassassin does not pretend to be a DKIM (or DMARC) policy engine,
so of course it "accepts" weak signatures.  It accepts invalid and
nonexistent signatures, too.  By this I suppose you mean that
spamassassin does not distinguish among levels of content coverage of
signatures it detects and verifies, so different spamminess
coefficients can't be assigned?

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 16 Jun 2014 09:37:09 +0900

> 
 > >  > How about a new tag, "shf=" (special header fields).  Ignored
 > >  > by legacy verifiers, as required; otherwise, contains a
 > >  > colon-separated list of fields that get special handling by
 > >  > verifiers.  "Special handling" depends on the header field and
 > >  > would need to be documented in each case.  For DKIM-Delegate,
 > >  > for example, it is always canonicalized in a special way that
 > >  > would cause the signature never to validate for a legacy
 > >  > verifier.

 > True, but I think that small bit of weirdness is fine in the face
 > of the token signature that would be misinterpreted and possibly
 > abused by legacy DKIM installations that don't know about new tags
 > or header fields.

I don't understand.  My point is that in the case of a token signature
and one or more content-covering signatures, it is a nonempty proper
subset of fields of the same DKIM-Signature type that need "special"
treatment.  How do you reliably distinguish a subset of fields with
the same tag?  Am I missing something?

The DKIM-Delegate field is a different type.  Of course its handling
is special.

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2014 01:02:37 -0000

>nonexistent signatures, too.

No, it doesn't.  It calls Mail::DKIM to validate the signatures.

R's,
John

---

From: Matt Simerson <[email-masked]>
Date: Sun, 15 Jun 2014 18:58:42 -0700

On Jun 15, 2014, at 6:02 PM, John Levine <[email-masked]> wrote:

> No, it doesn't.

Yes, SpamAssassin does "accept" weak, invalid, and nonexistent signatures. 

> It calls Mail::DKIM to validate the signatures.

Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM failure is frequently not a sufficient basis for rejection.

http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Plugin_DKIM.html

Matt

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 16 Jun 2014 11:58:10 +0900

> No, it doesn't.  It calls Mail::DKIM to validate the signatures.

Indeed, it validates the signatures.  I should have written "'accept'
and 'reject' are not appropriate for use in discussing SpamAssassin's
processing at the level of message features".

The question I'd like to ask is "how hard would it be to get
SpamAssassin to evaluate the features it knows about (eg, 'valid DKIM
signature') in conformance with each of the proposals?"

That is, is it possible for SpamAssassin to independently assign a
score (presumably a fairly large negative one) to the specific feature

  - This field is DKIM-Delegate to example.com, AND
  - there is a valid DKIM signature from example.com for the whole
    message body and appropriate headers, AND
  - the DKIM-Delegate field is signed with a valid signature, AND
  - RFC5322.From is aligned with the valid signature on DKIM-Delegate

and other such (complex) features?  Is it more straightforward if
DKIM-Delegate is self-signed as I proposed?  Etc.

---

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

>sufficient basis for rejection.

I should hope not.  The DKIM spec is crystal clear that an invalid
signature is equivalent to no signature.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Sun, 15 Jun 2014 23:35:00 -0700

On Sat, Jun 14, 2014 at 1:34 PM, Hector Santos <[email-masked]> wrote:

> The theoretical solution is a DNS-based lookup with an in-band optimizer,
> like a DKIM-Delegate.  I say it is the only practical and most cost
> effective solution based on implementation experience (minus the
> optimizer).  The problem I sense is learning who to whitelist automatically
> out of the box and the management for the whitelist.  Yahoo says they need
> 30k whitelist records.  I don't see why that is a problem for them. They
> got the money to manage it. No? It's not going to be problem for me, you
> and most domains. Most domains are not going to need such scale or expect
> to be authorizing anyone else but themselves. Besides, we are talking
> software -- let it do the work.
>

If its your personal domain, sure, there are maybe 5 domains you need to
whitelist, you know them well, its all good and easy.

If I have to whitelist 30k domains, what am I doing it based on?  The DMARC
reject report combined with maybe some reputation and proof that those
domains actually perform accurate authentication (ie, existence of an AR or
OAR header that's signed) and that those domains auth themselves.  And do
we really think all 30k domains are going to remain pure?  If I list a
single domain for a handful of users, I'm exposing xxxM users to that
domain... more when I'm whitelisting those third parties to mimic my
domains to anyone else, so its the xB users around the world who normally
interact with my xxxM users.

Managing the whitelist through DNS also has its issues, just how short of a
TTL am I willing to live with, would anyone else actually like it if I
published one with a 30s TTL?

I'm sure we can come up with a mechanism for producing a whitelist, and it
would be "reasonable" until something on it was compromised, and we could
have mechanisms to update that whitelist in real time based on reputation
and other features.  I'm sure our dns team would be thrilled to delegate
the sub-domain to us so we can let the world query us... but it ends up
looking like a pretty leaky boat to me.

I like the "in-band optimizer" since it gives me more confidence... but
maybe that's being naive as well, if they compromise a domain to get on our
whitelist, are they really going to be deterred in working around a weak
signature?

Brandon

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 17 Jun 2014 19:29:21 +0900

Brandon Long writes:

 > I like the "in-band optimizer" since it gives me more
 > confidence... but maybe that's being naive as well, if they
 > compromise a domain to get on our whitelist, are they really going
 > to be deterred in working around a weak signature?

Once they've compromised a domain on your whitelist, they can send as
much spam as they like to pretty much anywhere as long as they don't
care if the actual recipient is a visible addressee (they can't change
To: or Cc: without breaking the signature).  They can, of course, send
to any visible recipient as well.  You could sign From: in the token
signature, which would restrict them to a specific author as well.

If you're worried about that (and I think compromise of delegate
domains is a genuine worry), there are a number of mitigations you
could apply as a mailbox provider.

1.  Sign From: in the token signature so that the abuser can't spoof
    arbitrary users in your domain.  This may break some mailing
    lists, but all of the use cases I know of put a mailbox not in
    your domain in there anyway.

2.  Make your users register the addresses they want to delegate to.
    (You'll actually delegate to the domain, of course, but you'll
    only sign for those addresses, not others at that domain.)  Always
    use explicit delegate lists, containing only registered addresses.

3.  Check that those addresses are mailing lists (you can do this in
    the guise of helping users register by checking for List-Post in
    their incoming traffic, then offering those lists at registration
    time).  As Hector points out in a different thread, mailing lists
    are probably the main use case for DKIM-Delegate, since it's not
    possible to have a valid DKIM-Delegate field in an "on behalf of"
    message originating at a third party.

4.  Restrict to one addressee (total) for delegated mail, to avoid
    providing any acquaintance information in the addressees except
    the list itself.

Of course, this doesn't restrict abusers from spamming/phishing anybody
they want (they only need one copy of message signed at the delegate
domain to arrive at their botnet, then they can send it verbatim), but
(1) it appears to be a specific list's post, which makes it easy for
victims (or their mailbox providers) to filter in the future (To and
Cc should be signed, of course), (2) for almost all recipients (ie,
anybody who didn't subscribe to the list) they won't recognize any
recipients, so the probability of content-based filtering becomes
*much* higher, (3) the user in From: is also almost certainly unknown
to anybody who isn't a genuine subscriber to the list, bumping the
probability of filtering again, I would think, and (4) although your
user appears in "From:", the security breach is clearly at the list
domain, not your fault (this last is purely PR, of course, it doesn't
make anybody who gets spam that spoofs your user feel better).

Also, the token signature expires fairly quickly, so the spammers will
need to be continuously harvesting list domains.  But the 30,000
list-providing domains are probably much harder targets than the
3,000,000,000 user contact lists.

Taken altogether, I think this raises spammer costs a lot, and
probably weakens the contact-list-based attack dramatically.

Steve

---

From: S Moonesamy <[email-masked]>
Date: Thu, 19 Jun 2014 09:49:37 -0700

Hi Matt,
At 18:58 15-06-2014, Matt Simerson wrote:
>Yes, it does. But SA uses the results of Mail::DKIM heuristically 
>and a DKIM failure is frequently not a sufficient basis for rejection.

During the (old) DKIM discussions there was a view that the result of 
a DKIM verification was to be used as input for policy 
decisions.  That is similar to the above.  This was also discussed on 
a SMTP mailing list [1].  There is the following recommendation in RFC 6376:

   "Therefore, a Verifier SHOULD NOT treat a message that has one or more
    bad signatures and no good signatures differently from a message with
    no signature at all."

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg01487.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Jun 2014 14:15:09 -0400

Let us remember that DKIM+Policy were separated into two protocols;  a DKIM-BASE layer and a secondary domain signing practice layer (SSP which evolved to ADSP).  Making an invalid signature equal to a missing signature concept was a security logic which allowed for the exclusive or strict signing domain policies to exist and work with one single short circuiting policy handling state/event condition:

   If policy.strict and signature.missing or invalid then negatively classify;

You must make invalid be the same as missing from a rejection or functional equivalent negative classification standpoint otherwise you have a security loophole.

While DKIM-BASE tried to clean up this separation of the author domain policy, it could not because of all the past existing ADSP or SSP references in the many DKIM related RFCs, see RFC6376, section 1.1.   But conceptually, it didn't matter what you called it.  It was an author domain signing policy protocol and today, it's called DMARC.   DKIM has no payoff with just base signing analysis . It was separated but with all the intentions of sticking secondary author policy and signer trust layers on it before a payoff was realized.  

> On Jun 19, 2014, at 12:49 PM, S Moonesamy <[email-masked]> wrote:
> 
> Hi Matt,
> During the (old) DKIM discussions there was a view that the result of a DKIM verification was to be used as input for policy decisions.  That is similar to the above.  This was also discussed on a SMTP mailing list [1].  There is the following recommendation in RFC 6376:
>

---

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

On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos <[email-masked]> wrote:

> While DKIM-BASE tried to clean up this separation of the author domain
> policy, it could not because of all the past existing ADSP or SSP
> references in the many DKIM related RFCs, see RFC6376, section 1.1.   But
> conceptually, it didn't matter what you called it.  It was an author domain
> signing policy protocol and today, it's called DMARC.   DKIM has no payoff
> with just base signing analysis . It was separated but with all the
> intentions of sticking secondary author policy and signer trust layers on
> it before a payoff was realized.
>

There are reputation systems -- I built one, and I know others exist --
that use DKIM as the identifier on which reputation is built, and they've
been effective in experimental environments at identifying what's good and
what's outside of "good".

The difference here is between active and passive determination of what's
good and what's not good.  If you want active, I agree that DKIM by itself
isn't enough.  But I disagree, with evidence, that DKIM "has no payoff with
just base signing analysis".

If that's not convincing enough, consider that IP reputation has been
largely successful, and the input to such systems is a verified identifier,
which is the same class of output DKIM provides.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Jun 2014 12:36:21 -0700

On Jun 19, 2014, at 11:45 AM, Murray S. Kucherawy <[email-masked]> wrote:

> There are reputation systems -- I built one, and I know others exist -- that use DKIM as the identifier on which reputation is built, and they've been effective in experimental environments at identifying what's good and what's outside of "good".
> 
> The difference here is between active and passive determination of what's good and what's not good.  If you want active, I agree that DKIM by itself isn't enough.  But I disagree, with evidence, that DKIM "has no payoff with just base signing analysis".
> 
> If that's not convincing enough, consider that IP reputation has been largely successful, and the input to such systems is a verified identifier, which is the same class of output DKIM provides.

Dear Murray,

Our company has had extensive experience dealing with email spoofing.  While reputation is able to deal with bulk spamming, it is ineffective at dealing with a phishing problem, the intent behind DMARC.  It is a basic information issue.  Those offering a reputation for a domain have no way to judge which of their identifiers are being spoofed for messages handled by third-parties.  Only the spoofed domain can be considered authoritative.  To suggest otherwise implies the sharing of PII, which is not acceptable in many regions.

Regards,
Douglas Otis

---

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

On Thu, Jun 19, 2014 at 12:36 PM, Douglas Otis <[email-masked]>
wrote:

> Our company has had extensive experience dealing with email spoofing.
>  While reputation is able to deal with bulk spamming, it is ineffective at
> dealing with a phishing problem, the intent behind DMARC.  It is a basic
> information issue.  Those offering a reputation for a domain have no way to
> judge which of their identifiers are being spoofed for messages handled by
> third-parties.  Only the spoofed domain can be considered authoritative.
>  To suggest otherwise implies the sharing of PII, which is not acceptable
> in many regions.
>

DKIM coupled with reputation can only tell you if a given message was
handled by a source with a good reputation.  It doesn't evaluate any
visible identifiers.  I don't really understand the rest of what you're
talking about here.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Jun 2014 16:04:01 -0400

Let me clarify it. 

From a deterministic protocol standpoint,  depending only on base signing analysis has no payoff, i.e. no filtering is legitimately possible with high confidence and zero/low false positive.  

What is left is non-deterministic, heuristic, classification Bayesian scoring,  learning,  "fuzzy, neural net, expert system" and similar AI-like logic methods, including SA like methods.  Sure, you can learn from weighting indeterminate results.  But it's not deterministic, not 1 nor 0, but in between. Not yes/no, but maybe. 

I agree this method were always possible, and expected it in order to deal with these unknowns "in-between" results, the ones that result from relaxed or no policies.  The only real issue with this method is that it's not shareable.  It could not be a network persistent and consistent protocol method unless there was a centralized repository concept/service everyone can check with similar results.  If a site depends on such a method, then the sites that do no sign up for this central reputation lookup service will become targets.   It has long been shown that bad guys do target "weaker" sites especially when it's well known a common reputation method doesn't exist in practice for everyone to use.  The DNS-based author domain defined policy is the only common approach we have now. 

> On Jun 19, 2014, at 2:45 PM, "Murray S. Kucherawy" <[email-masked]> wrote:
>

---

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

Hector Santos writes:

 > The DNS-based author domain defined policy is the only common
 > approach we have now.

"To a man with a hammer, every problem looks like a nail."

But unfortunately, use of strict policy in the current environment can
be antisocial behavior, and therefore it is going to be ignored (as a
policy) by socially responsible recipients.  Viz, GMail.[1]  And it
leads to avoidance behavior (From-corruption, encapsulation) by third
parties (at least mailing lists).  "Avoidance" is also anti-social
IMO, even though it's my constituency that's doing it.

Those same socially responsible recipients will, of course, use it as
an (important) input into their *heuristic, reputation-based*
decisions about filtering.  Viz. again, GMail.

Third-party authorization just pushes the heuristic, reputation-based
decision-making off onto the third parties you want to authorize, and
doesn't scale to precisely the large mailbox providers who can cause
widespread consternation by publishing "p=reject" policies.

Footnotes: 
[1]  While I have my reservations about the CSR of all billion-dollar
companies, including Google, GMail's handling of p=reject is socially
responsible behavior.  IMHO YMMV.

---

From: Hector Santos <[email-masked]>
Date: Fri, 20 Jun 2014 11:14:42 -0400

> "To a man with a hammer, every problem looks like a nail."

Yes, indeed, in this case, it is that simple -- Occam's razor.  Quite 
often, a hammer is all this is needed.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Jun 2014 10:51:52 -0700

Folks,

G'day.

I've now caught up on the list activity and am sending my combined
comments in a single posting, especially since I think there's really a
single organizing issue that's being missed...

On 6/13/2014 12:46 AM, Stephen J. Turnbull wrote:
> "silent discard"

Question to the group:  Does silent discard help?  Or rather, do we have
any indication that noisy "p=reject" does or can hurt?

On 6/15/2014 9:43 AM, Murray S. Kucherawy wrote:
> On Sat, Jun 14, 2014 at 11:15 PM, Dave Crocker <[email-masked]>:
> algorithm.  Legacy DKIM implementations won't understand it.  New
> ones (presumably also modified to know about DMARC) will.
...
> something from this idea -- is because then we are, directly or not, 
> tying verification semantics outside of DKIM to a canonicalization.

One way or the other, the different approaches are trying to trick
legacy receivers into being unable to process the weaker signature. As
the cliche goes, we are merely haggling price.

However price matters; we should have a good reason for choosing one
trick over another.  Still I think we shouldn't trick ourselves into
believing this game is anything other than producing a hack.

On 6/15/2014 10:00 AM, John Levine wrote:
>> I do not understand this predilection for trying to change the DKIM
>> base engine.  It doesn't need it.
>

The premise is that a version number change will be noticed by a legacy
DKIM engine.

While of course it ought to be noticed, do we have evidence that it
reliably is?

There's some history with version numbers not working for Internet
protocols.  (I get some perverse enjoyment out of noticing that IPv6
requires a different ethertype value, rather than just relying on the IP
version field...)

>> I also don't understand the construct of 'special handling', never
>> mind not liking the idea of it, especially since it explicitly
>> creates the complexity of "depends on the header field".
> 

That does not make the issue any less fundamental.

The DKIM specification leaves it to the receive-side evaluator to decide
whether "enough" of a message was covered and whether the signature was
"sufficiently" strong.  If engines are currently ignoring this issue, we
have a deeper problem, IMO, and should focus on fixing that, rather than
treating it as an acceptable given.

> signatures, so in practice it hasn't mattered.

Right.  Some problems don't surface right away.  That does not mean we
should ignore these sorts of underlying problems and just work around them.

> useful it does require a change to the verifier library interfaces.

It's definitely a paradigm change.

Arguably the change is 'above' DKIM, in the sense that the core DKIM
engine remains unchanged, but rather it is the interpretation of the
result for a DKIM evaluation that can be different.

Merely validating a signature is /never/ supposed to give a message an
automatic pass.  Rather, the validation is supposed to be fed into an
analysis engine that considers a variety of factors.

Adding a requirement that one validation needs to be accompanied by a
particular other valid signature is just such an additional factor.

     In other words, the changes being discussed here are really
     in DKIM usage policy and not DKIM signing/validating.

> to interpret the conditional signatures.

Please point to details on the long history of successfully doing
version bumps in Internet protocols.  I'm not aware of it.

I see that http has done it, though I don't know how it is used or how
useful it has been.  But I haven't noticed the construct being generally
useful for other protocols.  Certainly not for IP...  And note that the
rest of the email specs haven't used them.

> conditionally valid signature would be useful.  For example:

The signature is not "conditionally valid".  The signature validates or
it doesn't.  Binary choice.  That a signature is what we are calling
weak does not make it more or less valid.

What is conditional is the /use/ of the validation, just as is supposed
to already apply for validated DKIM d= values.

     So the enhancement here concerns a new layer that
     specifies DKIM usage policies, not changes to the
     existing signing/validating engine.

This does invite the basic and continuing need to worry about how things
will be processed by legacy engines that don't know about the
enhancements.  However we need to be careful in making assumptions about
this rather than empirical information.

On 6/15/2014 11:58 AM, [email-masked] wrote:
>> Until now there's been no reason other than playing games to use
>> weak signatures, so in practice it hasn't mattered. Now it does,
>> so clients have to change their code to check for "too weak",
>> probably in inconsistent ways, to check for l= and what headers are
>> signed and so forth.
> 
> Agreed. Like it or not, this calls for, let's call it a
> "clarification" of existing DKIM semantics. And to do that you either
> bump the version or overload some other existing field in the
> protocol.

I understand the premise here, and agree it's reasonable.  What I don't
know is whether it is valid.  That is, we have a presumption of a
problem but I haven't noticed documentation that the problem is real and
serious, to justify making a change to the basic DKIM platform.

More generally, the IETF has often done BCP-ish documents that clarify
usage issues -- such as "watch out  for 'weak' signatures" without
changing protocol version numbers.

> Exactly why I think that as long as we're bumping the version, 
> building in some additional extensibility seems like a really good
> idea. The only question is how much and in what form.

Which is why I'm classing this as adding a policy engine on top of the
(stable and unchanging) DKIM signing and validation engine.

For reference, I note that some other postings on the list have been
making a similar distinction between validation and policy.  However
they do not seem to have gotten traction.

On 6/20/2014 7:42 AM, John R Levine wrote:>>> 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?
>
> That seems likely,

And this underscores just how strange the current discussions are, since
a list like that doesn't scale.

On 6/19/2014 2:46 PM, Ned Freed wrote:
> 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?
...
> Why don't we fix the extensibility problem instead?

+1

Anyhow and FWIW...

As we worry about 'suddenly' having to worry about getting receivers to
be careful if they receive a 'weak' signature, let's consider the
suddenness in the context of the literally overnight, rapid expansion of
DMARC use into generalized mass-market scenarios.

By comparison, anything we are talking about doing here is at glacial
speeds.

That is, it is arguably quite easy to get DKIM receivers to start paying
attention to signature strength, without anything other than a public
awareness campaign, and certainly not needing anything as extreme as a
version number change to an engine that is not actually changing...

d/

---

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

>any indication that noisy "p=reject" does or can hurt?

ADSP had silent discard.  It avoided the problem of people bouncing
off lists, but made the "where did my mail go" problem even worse.

DMARC has p=quarantine.  In discussions with people running large mail
systems, they said they thought about it and decided it would not be
an improvement.

>treating it as an acceptable given. ...

I don't know anyone who's checked whether DKIM validators verify the
version number, but if it's an issue, there aren't that many widely
used DKIM engines so it wouldn't be hard to check.  It seems to me
it's a lot easier to verify a specific check for a version number than
an ill defined acceptance of "too weak" signatures.

It's also not clear to me that there is any reason for a verifier to
care about the strength of a signature.  If a signer wants to put weak
signatures on mail and take the risk that his reputation will be
sullied by heavily mutated messages, that's not the verifier's
problem.  (Note that this is not the same as what I'm proposing, a
weak signature that is valid only if there is an additional signature
from a second signer that I trust to put on a reasonable signature.)

>particular other valid signature is just such an additional factor.

I don't see it that way.  In my version, at least, the second
signature is part of what makes the signature valid, just like a body
hash that matches the body or an expiration date that hasn't passed.
It's not a matter of opinion, it's either there or not.

>version bumps in Internet protocols.  I'm not aware of it.

ssh seems to work OK with versions 1 and 2 both in use
NFS moved from 4.0 (RFC 3530) to 4.1 (RFC 5661)

>weak does not make it more or less valid.

By "conditionally valid" I mean more conditions the verifier uses to
make the binary choice.  Better wording always welcome.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Jun 2014 13:10:47 -0700

On 6/20/2014 11:43 AM, John Levine wrote:
> ADSP had silent discard. 

Sorry, I meant to indicate an interest in usage that was, well, you
know, actually used...

> systems, they said they thought about it and decided it would not be

That could be worth getting some consensus documentation on.

> an ill defined acceptance of "too weak" signatures.

Once you've classed the task as touching existing engines, then we
should touch them strategically and not merely with a tactical hack.

> problem. 

Actually, it is, since it is the verifier's system that will let the
mail get delivered, or not, to an associated mailbox.  It is /their/
users who will be most directly affected.

Or, at least, I have assumed that is why folks are so concerned about
the increased ability to do a replay attack if the signature is 'weak'
(mostly meaning, doesn't cover the body.)

> (Note that this is not the same as what I'm proposing, a

Right.  Adding a Policy layer.

> I don't see it that way.  

Try harder.

>> In my version, at least, the second

One can always define things in a way that conflates issues that should
be layered.  That doesn't make it the right architectural choice.  TCP
and IP used to be a single entity.

Adding architectural structure and modularity is a discipline.
Subroutines aren't "required" but they certainly make code a lot
cleaner. The same holds for protocol specification.

So on the question of conflating usage of a validated signature with the
validation process, I'll offer my usual quote from my favorite engineer:
 "We can do that, but it would be wrong."[1]

> It's not a matter of opinion, it's either there or not.

How did you come up with 'opinion' as relevant to the discussion here?

> ssh seems to work OK with versions 1 and 2 both in use

There is some irony in citing ssh, given things like:

     Prevent SSH from advertising its version number

http://serverfault.com/questions/216801/prevent-ssh-from-advertising-its-version-number

But yeah, this sounds like version numbers work /really/ well:

   RFC 4253:

   "5.2. New Client, Old Server

   Since the new client MAY immediately send additional data after its
   identification string (before receiving the server's identification
   string), the old protocol may already be corrupt when the client
   learns that the server is old.  When this happens, the client SHOULD
   close the connection to the server, and reconnect using the old
   protocol."

> NFS moved from 4.0 (RFC 3530) to 4.1 (RFC 5661)

Except that the usage model is more like SMTP options, or completely
independent dual stack:

   RFC 5661

   "NFS version 4 minor version 1
   has no dependencies on NFS version 4 minor version 0, and it is
   considered a separate protocol.  Thus, this document neither updates
   nor obsoletes RFC 3530."

Wow...

> make the binary choice.  Better wording always welcome.

Having an added layer of policy-related /usage/ of a validated signature
is quite different from the question of whether the signature validates.

d/

[1] Nixon, R.  Watergate tapes. March 21, 1973.

http://www.huffingtonpost.com/mitch-rofsky/history-reexamined-waterg_b_838716.html

---

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

> (mostly meaning, doesn't cover the body.)

Since we have, as far as I can tell, never seen weak signatures, nor am I 
aware of any actualy attacks that attempt to turn messages into spam while 
preserving the signature, at this point it's entirely hypothetical.

It feels like some people (not you I hope) are assuming that if a message 
has a valid signature, it's good and you deliver it, which is of course 
wrong.  If the signature is valid *and* the signer has a good reputation, 
then a delivery agent might do something nice to the message.  If it sees 
a lot of cruddy mail with my signature, I'm going to have a bad 
reputation, and it doesn't matter whether I'm signing spam, or I'm putting 
on weak signatures that third parties are turning into spam.  Indeed, it's 
hard to see how a verifier could even tell the difference.

R's,
John

PS: If we're going to tell people what's a sufficiently strong signature, 
could we start by deciding whether it's sufficient to put one "from" in 
the h= tag ?

---

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

>>> particular other valid signature is just such an additional factor.

Still not having much success here, so please help me out.

It is presumably permitted to check an external clock to find out what 
time it is to validate the x= or t= tags.  How come that's OK, but 
checking the message for the presence of a signature with d=whatever 
isn't?

R's,
John

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 20 Jun 2014 15:47:39 -0500

> used DKIM engines so it wouldn't be hard to check.

Just FYI, libdkim which all our products use does check the v= and if 
it's not "v=1" verification "fails" with an "invalid v=" error which we 
then document in the authentication-results header.

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Jun 2014 13:51:14 -0700

On 6/20/2014 1:40 PM, John R Levine wrote:
> It feels like some people (not you I hope) are assuming that if a
> message has a valid signature, it's good and you deliver it, which is of
> course wrong.  

Since I haven't seen anyone suggest this, during this or frankly any
other, discussion, nor have I seen any text that even hinted at that
attitude, I've no idea what you are referring to.

> If the signature is valid *and* the signer has a good
> reputation, then a delivery agent might do something nice to the
> message.  If it sees a lot of cruddy mail with my signature,

The issue is not your 'signature' but your d= domain name.  That's where
the reputation assessment is supposed to lie.

It's one of the problems with language that loosely refers to what DKIM
does as 'signing' the message.  It's not really doing that.

Since your Subject text nicely invokes the question of real DKIM
semantics, let's be explicit:

     DKIM is "affixing" the d= name to the message.  The 'signature' is
the glue.

If we think and talk in those terms, then the question of how strong the
glue needs to be needs to be made in the context of real or likely
efforts at pulling the name off of a legitimate message and affixing it
to an illegitimate one.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Jun 2014 13:53:08 -0700

On 6/20/2014 1:45 PM, John R Levine wrote:
> checking the message for the presence of a signature with d=whatever isn't?

That has not appeared (to me) to be the nature of what you have been
espousing.

Rather you appear to be espousing the benefits of mixing policy with
mechanism, by placing requirements for combinatorials (one sig in the
presence of another) into the middle of a signing/validating spec.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jun 2014 14:05:12 -0700

On Fri, Jun 20, 2014 at 1:47 PM, Arvel Hathcock <[email-masked]>
wrote:

> Just FYI, libdkim which all our products use does check the v= and if it's
> not "v=1" verification "fails" with an "invalid v=" error which we then
> document in the authentication-results header.

OpenDKIM as well.

-MSK

---

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

>the reputation assessment is supposed to lie.

If anyone else found this obvious point confusing, I apologize.

>efforts at pulling the name off of a legitimate message and affixing it

Why would that be the verifier's concern rather than the signer's?  If
for some (perhaps good, perhaps bad) reason I decide to use weak
signatures, why wouldn't the hit to my reputation be an adequate
remedy?

R's,
John

---

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

>That has not appeared (to me) to be the nature of what you have been

Hmmn.  That is exactly what I describe in
draft-levine-dkim-conditional-00.  If it seems to be saying something
else, could you give me some suggestions about where I need to make it
clearer?

R's,
John

---

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

>then document in the authentication-results header.

I looked at the code in Mail::DKIM which is what spamassassin and
probably every other perl DKIM application uses.  It checks the
version number, and for some reason accepts "0.5" as well as "1", but
nothing else.

The most widely used python module is Scott's dkimpy, which checks
that the version is "1".

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jun 2014 15:19:45 -0700

> version number, and for some reason accepts "0.5" as well as "1", but

"0.5" was used during early DKIM evolution within the IETF, such as:

http://tools.ietf.org/id/draft-ietf-dkim-base-05.txt

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Jun 2014 13:08:54 +0900

> any indication that noisy "p=reject" does or can hurt?

We have the latter: mailing list deactivations and unsubscriptions.
This effect can be mitigated but not eliminated because the same
domains that agree to use "p=reject" refuse to provide informative
DSNs, or even consistent status codes.

That said, the more I think about this, the less I'm inclined to think
it's important.  There are multiple mitigations (ie, both heuristic
recognition of "p=reject" bounces and mitigations based on avoiding
DMARC rejects in the first place).  These mitigations will be largely
effective in newer versions of Mailman (and I assume other MLMs), and
for older versions non-delivery is probably much the bigger problem,
now that MLM developers and support understand why the deactivations
and unsubscriptions occurred.

I withdraw the suggestion of recommending silent discard for the
purpose of protecting mailing list subscribers.

Steve

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Jun 2014 13:40:41 +0900

John R Levine writes:

 > message has a valid signature, it's good and you deliver it, which
 > is of course wrong.

As far as I can tell this notion was injected by your use of the terms
"accept" and "reject" in your discussion of SpamAssassin's DKIM plugin.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 21 Jun 2014 01:07:24 -0400

>The most widely used python module is Scott's dkimpy, which checks

It currently raises an error if the version is not 1.  That was probably a mistake. It'd have been better just to treat versions !1 as no signature present. 

I think I'll change that. 

Scott K