Subject: Re: [ietf-dkim] alternate proposal to draft-ietf-dkim-rfc4871-errata

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Feb 2009 01:50:41 -0800 (PST)

Eliot,

Your proposal would satisfy me (as an implementor, anyway) in terms of the 
opacity of the local-part value in "i=".

What it doesn't do is address the question about whether or not RFC4871 
presents a single identity as its output, and if so, which one that is.

Or, alternately, perhaps you're suggesting that's not an issue that really 
needs to be solved?  (That's not sarcastic; I don't have experience yet to 
suggest this is a fire that needs to be put out, so I'm genuinely 
wondering.)

-MSK
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Feb 2009 12:03:40 +0100

On 2/11/09 10:50 AM, Murray S. Kucherawy wrote:
> Or, alternately, perhaps you're suggesting that's not an issue that really needs to be solved?  (That's not sarcastic; I don't have experience yet to suggest this is a fire that needs to be put out, so I'm genuinely
> wondering.)
>    

Murray,

I do not think this problem should be solved by the errata.  I do not 
see an actual interoperability problem stemming from this issue, beyond 
the clarification of i=, and even there I don't actually know of any 
implementations that have run into problems (some references to such 
would be very nice).

More importantly, I am concerned about the readability of the 
specification, when combined with the errata.  Dave and his co-authors 
may be extremely precise in their language, but there is a lot of it, 
and new terms make the reading harder, and make discussion less 
intuitive, requiring constant translation. I see harm with that much 
text, and for what *concrete *tradeoff?  As engineers we must always ask 
ourselves that question.  Show me actual reported interoperability 
problems between implementations beyond i= and I could at least have a 
positive value on the other side of the equation.

All the best,

Eliot

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 11 Feb 2009 10:06:08 -0500

On Wed, Feb 11, 2009 at 12:03:40PM +0100, Eliot Lear wrote:
> Or, alternately, perhaps you're suggesting that's not an issue that
> really needs to be solved?  (That's not sarcastic; I don't have
> experience yet to suggest this is a fire that needs to be put out, so
> I'm genuinely wondering.)
>
>
>   Murray,
>
>   I do not think this problem should be solved by the errata.  I do not see
>   an actual interoperability problem stemming from this issue, beyond the
>   clarification of i=, and even there I don't actually know of any
>   implementations that have run into problems (some references to such would
>   be very nice).

As a signer, I may want to do this:

i=@transaction.company.com d=company.com for transactional messages and
d=company.com for everything else (yes, there is no i=, but i= defaults
to @d). This is done to emulate separate IP streams by using a DKIM
identifier. ISPs have said 'separate your streams', so this is a
continuation of that.

Assume the messages pass DKIM authentication. Next the "output of DKIM"
is passed to some reputation module. Receiver A decides that is i= and
treats the two types of DKIM messages as the signer intended. Receiver
B decides to use d= and treat the two types of messages as the same.
One day a machine is compromised causing the signer to send spam but
only for those messages with no i=. Receiver A throttles those but not
the messages with i=. Receiver B throttles all the messages.

The errata doesn't actually fix this issue. It can still happen. What
it does try to prevent is the decomposition (if that is the right word)
of any value of d or i. For example:

fqdn=output_of_dkim();
(subdomain,domain)=find_domain(fqdn); # the million dollar function! :)
reputation=dkim_rep(domain);

it does hopefully* allow this:

(identifier_i,identifier_d)=output_of_dkim();
reputation=dkim_rep(identifier_d,identifier_i);

is certainly allows this:
(identifier_d)=output_of_dkim();
reputation=dkim_rep(identifier_d);

* I say hopefully because I haven't read the latest errata.

-- 
Jeff Macdonald
[email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Feb 2009 09:01:39 -0800

> identifier. ISPs have said 'separate your streams', so this is a

Does your use of the (pseudo-)subdomain "transaction" have any literal
meaning, or would you accomplish the same thing using the
pseudo-subdomain dfhjkhkjh?  If verifier is supposed to take meaning
from some specific pseudo-subdomain name, that would make it decidedly
non-opaque (or words to that effect :-) ) which would run contrary to
what many are suggesting.

> the messages with i=. Receiver B throttles all the messages.

How does Receiver A know the signer's intent?  It would be equally valid
for a signer to apply a different pseudo-subdomain on each message,
perhaps for tracking purposes.  If the value is really intended to be
opaque, the verifier shouldn't even group together like
pseudo-subdomains for reputation purposes, in the absence of out-of-band
information describing what the signer does.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Feb 2009 11:16:01 -0800

On Feb 11, 2009, at 9:01 AM, Jim Fenton wrote:

> If the value is really intended to be opaque, the verifier shouldn't  
> even group together like pseudo-subdomains for reputation purposes,  
> in the absence of out-of-band information describing what the signer  
> does.

Jim,

When mitigating replay abuse, a reputation service will likely need to  
assign negative reputations against i= values (opaque or otherwise) to  
deal with problematic domains.  Without the i= value,  the alternative  
might be to block domains, which is not likely a good solution for  
either the sender or recipient.  When a domain decides to use random  
local-parts and fictitious domains within the i= value that bad actors  
can access, it may become impractical for an abuse service to track  
all the i= values associated with abuse.  In addition, use of an  
i=transactional.example.com may prove problematic when a bad actor  
decides to flood mail-boxes with one of these messages.  This may have  
been done to ensnare users with a variety of exploits that might range  
from DNS poisoning to hacked web sites, or might be aimed at causing a  
DoS.  Disruptions could be limited by encoding the i= value with  
something like i=[email-masked] where the local- 
part relates to specific transactions or is randomly generated.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 11 Feb 2009 14:27:40 -0500

On Wed, Feb 11, 2009 at 09:01:39AM -0800, Jim Fenton wrote:
>pseudo-subdomain dfhjkhkjh?

yes, using dfhjkhkh would accomplish the same thing.

>If verifier is supposed to take meaning from some specific
>pseudo-subdomain name, that would make it decidedly non-opaque (or
>words to that effect :-) ) which would run contrary to what many are
>suggesting.

transaction was chosen for illustrative purposes.

>How does Receiver A know the signer's intent?

I don't see why the receiver would have to know the signers intent, if
by intent you mean what do the various values of i= a signer may
present means. It doesn't matter. All a signer wants is a guarentee of
what identifier (or identifiers) would be used as in input into a DKIM
reputation algorithm.

>It would be equally valid for a signer to apply a different
>pseudo-subdomain on each message, perhaps for tracking purposes.

I think that is actually a mis-use of DKIM. The message-id field covers
that nicely.

>even group together like pseudo-subdomains for reputation purposes, in
>the absence of out-of-band information describing what the signer
>does.

My understanding of opaque allows identical opaque values to identify
the same "something".

-- 
Jeff Macdonald
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Feb 2009 11:46:14 -0800 (PST)

> I think that is actually a mis-use of DKIM. The message-id field covers 

But Message-ID:'s semantics are defined in a different layer.  As things 
are currently defined, the DKIM module at either end can only make use of 
what's in the signature itself.

> My understanding of opaque allows identical opaque values to identify 

Then you're arguing for something stronger than what the draft proposes. 
The draft uses SHOULD, where to match your understanding, it would need a 
MUST.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 11 Feb 2009 16:36:31 -0500

> what's in the signature itself.

right, message tracking is covered by a different layer.

> The draft uses SHOULD, where to match your understanding, it would need a 

Could you post the section you are referring to?

-- 
Jeff Macdonald
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Feb 2009 13:44:32 -0800 (PST)

On Wed, 11 Feb 2009, Jeff Macdonald wrote:
>> Then you're arguing for something stronger than what the draft 
>> proposes. The draft uses SHOULD, where to match your understanding, it 
>> would need a MUST.
>

Sure, section 10 of the errata draft:

"... The Signer MAY choose to use the same namespace for its UAIDs as its 
users' email addresses, or MAY choose other means of representing its 
users. However, the signer SHOULD use the same UAID for each message 
intended to be evaluated as being within the same sphere of 
responsibility, if it wishes to offer receivers the option of using the 
UAID as a finer grained, stable identifier than the SDID."

I believe you're talking about increasing the strength of that SHOULD.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Feb 2009 15:51:56 -0800

> what identifier (or identifiers) would be used as in input into a DKIM

I don't know how a signer would obtain such a guarantee.  Different
recipients will probably use different reputation algorithms (or
services), and there's no requirement for them to publish the way that
they work.
> I think that is actually a mis-use of DKIM. The message-id field covers

I see nothing in 4871 that prohibits or advises against that usage, and
I have heard others discuss that usage on this list.
> My understanding of opaque allows identical opaque values to identify

That might be.  I seem to be opacity-challenged.

-Jim

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 12 Feb 2009 09:33:33 -0500

On Wed, Feb 11, 2009 at 01:44:32PM -0800, Murray S. Kucherawy wrote:
>>>> My understanding of opaque allows identical opaque values to 
>>>> identify the same "something".
>>>
>>> proposes. The draft uses SHOULD, where to match your understanding, 
>>> it would need a MUST.
>>

Yes, I suppose I am. But I hadn't realized that SHOULD meant that
identical UAIDs could mean they are not identical.

-- 
Jeff Macdonald
[email-masked]

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 12 Feb 2009 17:38:34 -0500

> identical UAIDs could mean they are not identical.

Hmm. I think a number of us were assuming that it would be obvious that message using the same UAID were intended to be evaluated as being within the same sphere of responsibility. That is distinct from saying that messages within the same sphere of responsibility MUST use the same UAID.

In other words, I think the intent is that messages using the same UAID MUST be intended to be evaluated as sharing the same sphere of responsibility (this is a mandate on the sender's usage, not on the receiver's interpretation); senders SHOULD thus label messages intended to be evaluated as being within that sphere with the same UAID (but aren't required to). I don't think that's a contradiction....

The question is whether this introduces enough confusion that we need to either 1) clarify the missing side of the coin, as above and/or 2) strengthen the existing requirement so that the other part just falls out.

Ellen

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 13 Feb 2009 11:33:09 -0500

On Thu, Feb 12, 2009 at 05:38:34PM -0500, Siegel, Ellen wrote:
>Hmm. I think a number of us were assuming that it would be obvious
>that message using the same UAID were intended to be evaluated as
>being within the same sphere of responsibility. That is distinct from
>saying that messages within the same sphere of responsibility MUST use
>the same UAID.
>
>In other words, I think the intent is that messages using the same
>UAID MUST be intended to be evaluated as sharing the same sphere of
>responsibility (this is a mandate on the sender's usage, not on the
>receiver's interpretation); senders SHOULD thus label messages
>intended to be evaluated as being within that sphere with the same
>UAID (but aren't required to). I don't think that's a
>contradiction....
>
>The question is whether this introduces enough confusion that we need
>to either 1) clarify the missing side of the coin, as above and/or 2)
>strengthen the existing requirement so that the other part just falls
>out.
>
>Ellen

Nicely put Ellen. Murray, I'm curious what you think now after reading
Ellen's message.

-- 
Jeff Macdonald
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Feb 2009 10:52:28 -0800 (PST)

> Nicely put Ellen. Murray, I'm curious what you think now after reading

I think I'd be fine with the draft saying that (or not, since both are 
workable and defensible), but that isn't what the draft currently says.

This would obviate the need for Jim's proposed extension.  On the other 
hand, it would make it impossible for a signer to use "i=" in any kind of 
arbitrary way.

If it were up to me to make the call, I'd say leave it the way it is, and 
go with Jim's extension (or something equivalent), so the signer can 
choose.  But it's currently not a very strong opinion.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ellen Siegel <[email-masked]>
Date: Fri, 13 Feb 2009 18:33:23 -0500

> hand, it would make it impossible for a signer to use "i=" in any kind of

Can you explain why you think this makes it impossible to use i= in an
arbitrary way? I don't see that that usage is excluded. If it's not intended
to be stable, there is no constraint at all except that it can't use an
identical identifier for unrelated groupings. And even if it is intended to
be stable, there is only a SHOULD for using the same identifier.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Feb 2009 15:58:13 -0800 (PST)

> be stable, there is only a SHOULD for using the same identifier.

I think your analysis contains the answer.  The minute you say "except 
that", it's no longer able to be arbitrary.  I can no longer use the 
local-part of the UAID to encode the sending date, or a count of viruses 
found in the message outbound, or a random number from one to 1000, if I 
want to do any of those for some reason.

A normative SHOULD means "have to unless you have a really good reason not 
to".  It leaves less wiggle room than I'm comfortable with here.

I prefer the option of a DKIM extension by which a signer announces that 
the UAID is stable.  It imposes no new semantics on the base spec and 
doesn't mess with any existing implementations that might do something 
funky with "i=", but also makes it possible for a signer to restrict 
itself in that way if it deems such to be appropriate or useful.

We SHOULD NOT (in 2119 terms) make any changes to the base spec, which is 
followed by a growing deployed base, via erratum or a full revision in a 
way which establishes any new constraints.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Feb 2009 16:30:27 -0800

On Feb 13, 2009, at 3:33 PM, Ellen Siegel wrote:

> Can you explain why you think this makes it impossible to use i= in  
> an arbitrary way? I don't see that that usage is excluded. If it's  
> not intended to be stable, there is no constraint at all except that  
> it can't use an identical identifier for unrelated groupings. And  
> even if it is intended to be stable, there is only a SHOULD for  
> using the same identifier.

There are likely two important constraints in the use of the i=  
parameter.

1) A domain's token versus real namespace should not overlap within  
the same message.

2) Whenever there is risk that a bad actor might be granted access,  
the i= values assigned to these risky sources should be stable for a  
period measured in hours and ideally days.

Otherwise, the i= value may become deceptive in the first case, and  
may not serve to reduce replay abuse in the second.

Without a practical means to limit the abuse from a larger domain,  
DKIM will not provide much value for most of Today's email.   Many  
domains emit hundreds of millions of messages daily.  Tracking abuse  
by message-ID or by signature will always be reactive and not respond  
fast enough to mitigate abuse.

The typical malware lifespan is now measured in hours in the war  
against polymorphic malware.  Bad actors have well demonstrated their  
effectiveness at leveraging the time it takes to flood the Internet  
with the details of their bad deeds.  DKIM should strive to limit the  
amount of protective information disseminated.  When a source  
represents a transactional operation from a well controlled database,  
a need for i= value stability is not likely.  For larger domains,  
offering an i= value will likely gain greater importance, especially  
when IPv6 becomes a factor.  Time will tell.

-Doug

---

From: SM <[email-masked]>
Date: Fri, 13 Feb 2009 17:07:54 -0800

>way which establishes any new constraints.

A base specification generally takes a minimalist approach so that 
people can build upon it.  From there, we can have ADSP or DKIM 
extensions.  Part of the discussion over the last weeks have been 
about RFC 4871bis.  Thinking aloud, it would be premature to get into 
that unless we have a good understanding of the implementation and 
deployment problems.  DKIM is still young by most standards.

If we can't agree on what RFC 4871 meant, then we will face the same 
situation with RFC 4871bis.

Regards,
-sm