Subject: [ietf-dkim] Fenton-DKIM-Threat-02 3.1. Use of Arbitrary Identities (and SSP)

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jan 2006 11:13:00 -0800

Perhaps this can help with context.

On Nov 2, 2005, at 10:32 AM, Scott Kitterman wrote:
> On 11/02/2005 13:19, Douglas Otis wrote:
>> On Nov 2, 2005, at 9:47 AM, Hector Santos wrote:
>> >
>> > Table 1.0 - DKIM Verification States illustrates all possible
>> >             outcomes for signature verification against SSP.
>> >
>> >              
>> +------------------------------------------------------+
>> >             |            Sender Signing Policy  
>> Result              |
>> > +-----------+---------------------------------------------- 
>> +-------|
>> > | result    |  WEAK  | NEUTRAL | STRONG  | EXCLU  | NEVER  |  
>> NONE  |
>> > | verify    |   OPT  | OPT/3PS | REQ/3PS |  REQ   |         
>> |       |
>> > +-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | NONE      | accept | accept  | reject  | reject | reject |  
>> accept|
>> > |-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | PASS      | accept | accept  | accept  | accept | reject |  
>> warn  |
>> > |-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | PASS 3PS  | reject | warn    | accept  | reject | reject |  
>> warn  |
>> > |-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | FAIL      | warn   | warn    | warn    | warn   | reject |  
>> warn  |
>> > |-----------+--------+---------+---------+--------+-------- 
>> +-------|
>> > | FAIL 3PS  | reject | warn    | warn    | reject | reject |  
>> warn  |
>> >  
>> +------------------------------------------------------------------+
>>
>> This chart represents multi-level ratings added together with  
>> email-address reputations to determine whether a message is to be  
>> accepted.  As with any reputation scheme, a negative reputation is  
>> bad.  All columns that permit third-party signing should be  
>> considered NOT RECOMMENDED to protect the reputation of the email- 
>> address.
>>
>> It is interesting that an invalid signature is offered greater  
>> access than no signature.  The invalid signature is even granted  
>> greater acceptance than a valid third-party signature.  Where  
>> there is no policy, a third-party signature is given reduced  
>> acceptance to that of no signature?
>>
>> This seems force the use of SSP and completely ignore the  
>> reputation of the signing-domain, does it not?
>
> That's a feature, not a bug.

This chart is not finalized, but the direction raises serious  
concerns.  This chart appears to be an attempt to hold the email- 
address domain owner culpable.  It is also disheartening to see the  
email-address domain owner offers a reporting address, but not the  
signer.  There are alternatives to SSP, but following this direction...

When reputation of the email-address domain owner takes precedence  
over that of the signer, this could coerce  the authorization into  
becoming "closed" ('!').  To lessen disruption caused by the "closed"  
authorization, the PRA algorithm could be used.  With Jim suggesting  
Sender-ID may solve the replay issue, this algorithm will need to be  
licensed anyway.  Any "open" authorization offers no protection for  
either the email-address domain owner or the recipient whatsoever  
anyway.  (It would seem the protection being sought is for the  
provider.)  Being culpable for authorization takes the burden of  
reputation the provider would normally carry and places the  
reputation burden onto the hapless email-address domain owner,  
perhaps in the form of user-feedback.

Fenton-DKIM-Threat-02

3.1.  Use of Arbitrary Identities
...
  DKIM is effective in mitigating against the use of addresses not
  controlled by bad actors, but is not effective against the use of
  addresses they control.

----

This effectiveness would be dependent upon the use of '!' (EXCLU)  
authorization.  Such setting however would be incompatible with  
several practices.  To be compatible with today's common practices,  
authorizations would need to be '~' (NEUTRAL) or "open-ended."

It would seem the statement "is effective" should be changed to "may  
be effective only when the '!' authorization is being employed.  This  
'!' authorization is not compatible with many possible uses."

-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Jim Fenton <[email-masked]>
Date: Thu, 05 Jan 2006 15:41:39 -0800

> Perhaps this can help with context.
[very good chart removed for brevity]

> signer.  There are alternatives to SSP, but following this direction...

The chart does not hold anyone culpable.  When a message is received
with a valid signature, the signer is acknowledging that the message
came from or through them. [We should really work out the wording on
this:  do they "take responsibility"?  Are they "accountable"?  But I
digress.]  What SSP does is to strengthen what can be said of a message
without a valid signature:  it gives the email-address domain owner (to
use your term) or originating-address domain owner (to use mine) the
ability to assert that they didn't send the message.  So it makes them
less culpable, not more.

It's true that there is no reporting address associated with the signer
(there is the n= (notes) field in the key record, but no guidance about
putting a reporting address there).  That is perhaps something that
should be added; do you think it belongs in the key record or in the
signature itself?'

> perhaps in the form of user-feedback.

The coercion you describe depends on how the reputation system
operates.  It's unwise to assume that it operates under any particular
set of rules.

With respect to the replay issue, I only want to point out that DKIM
does not need to operate in a vacuum.  I do not want to tie it to any
other message authentication technology.

The "hapless" email-address domain owner has the option of not
publishing a contact address (r= in the SSP is optional).

> '!' authorization is not compatible with many possible uses."

This paragraph is talking about addresses controlled by bad actors.  The
point is that bad actors that own particular domains can sign messages
(i.e., you can't use the presence of a signature to say that a bad actor
didn't originate it).  It has nothing to do with SSP.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jan 2006 17:10:45 -0800

> [very good chart removed for brevity]

This chart also needs to be updated to remove the '?' qualifier I  
believe.  As I indicated, the chart still raises concerns.  Having a  
signature without a policy is provided a lower rating than not having  
a signature.  The same is true for 3rd-party signatures.  This is  
dunning those without policies and discounting the signer.  That is  
being coercive.  This is bad as publishing the SSP record also  
increases the exposure to those administrators willing to equivocate  
about source identifiers.  Having an "open" authorization increases  
risks in those cases.  The chart should assume the sender is  
intelligent and publishes nothing in these cases.  There should be  
only two policies possible '!' and '.'.   Anything other policy is  
foolish.  The rating scheme should emphasize the signer over the SSP  
record, but when paired down to just these two policies, that  
situation is resolved.

> The chart does not hold anyone culpable.

Spend a bit more time studying the matrix.  Why demerits for not  
having a policy or for using third-party signatures?  Why is the  
email-address domain owner (I don't want to assume they are actually  
the originator) the entity publishing a contact?  There has been at  
least a solid two years of arguing (not with you) that authorization  
is not authentication, but this chart seems to be based once again  
upon this false assumption. : (

> When a message is received with a valid signature, the signer is  
> acknowledging that the message came from or through them.

The terminology should be specific.  "Only the signing-domain is  
accountable for the message."

> [We should really work out the wording on this:  do they "take  
> responsibility"?  Are they "accountable"?  But I digress.]  What  
> SSP does is to strengthen what can be said of a message without a  
> valid signature:  it gives the email-address domain owner (to use  
> your term) or originating-address domain owner (to use mine) the  
> ability to assert that they didn't send the message.  So it makes  
> them less culpable, not more.

This statement assumes the authorization is '!' which breaks the way  
email works.  Messages to this list would be lost for example.  For  
normal uses, SSP does not offer one iota of protection.  Of course,  
when the DKIM signature is used as a basis for recognition, no  
authorization is needed and yet protection is still be afforded. : )

> It's true that there is no reporting address associated with the  
> signer (there is the n= (notes) field in the key record, but no  
> guidance about putting a reporting address there).  That is perhaps  
> something that should be added; do you think it belongs in the key  
> record or in the signature itself?'

Perhaps it would make sense to establish a convention, DKIM- 
POSTMASTER@ perhaps.  If this seems too rigid, perhaps an entry in  
the key, but this makes the key even larger.  Adding the reporting  
address within the header could be problematic for delegated keys.

> operates.  It's unwise to assume that it operates under any  
> particular set of rules.

After the last few years, I too agree that it would be unwise to  
assume how reputation is applied.  This is why it would be less than  
intelligent to publish any policy other than '!' or '.'.

> With respect to the replay issue, I only want to point out that  
> DKIM does not need to operate in a vacuum.  I do not want to tie it  
> to any other message authentication technology.

Keep in mind there is a header selection conflict between DKIM and  
Sender-ID.  The conclusion reached more than a year ago, "open-ended"  
authorizations are worthless.  As the only safe policy to publish is  
"closed," this suggests the PRA algorithm should be re-examined,  
especially if Sender-ID is considered a means to offer replay  
protections.  There is also an alternative to the authorization  
scheme that offers better protections.  CSV and In-Channel checks  
could be yet another alternative for message replay abuse.  Leave the  
email-address domain owner harmless.  Only the administrator knows  
who is using the email-address.

> publishing a contact address (r= in the SSP is optional).

But the hapless email-address domain owner can not control those  
administrators willing to equivocate about source identifiers.   The  
'r=' suggests this is the entity that is seen as accountable.  Not  
publishing the SSP record offers more protection than not publishing  
an 'r=' parameter.

> This paragraph is talking about addresses controlled by bad  
> actors.  The point is that bad actors that own particular domains  
> can sign messages (i.e., you can't use the presence of a signature  
> to say that a bad actor didn't originate it).  It has nothing to do  
> with SSP.

>> "DKIM is effective in mitigating against the use of addresses not  
>> controlled by bad actors,..."

This is the portion of the statement that is highly misleading.  DKIM  
is not effective at mitigating the use of addresses not controlled by  
bad actors unless a "closed" authorization is used such as '!' or  
'.'.   A clarification that a "closed" authorization is not  
compatible with many common uses of email would also ensure that  
someone reading this would not be dramatically mislead.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 05 Jan 2006 22:34:32 -0800

Douglas Otis wrote:

> This chart also needs to be updated...

I'm trying not to have the SSP design discussion yet.  While I like the
chart in general, I'm not sure I agree with all of the entries in it
either.  I don't think it's necessary to correct it in order to have the
threat analysis discussion.

> address within the header could be problematic for delegated keys.

Good point here:  If it's important that the domain owner control the
reporting address so that the user of a delegated key can't specify any
reporting address they want, then it needs to be in the key record
rather than the signature.  But let's defer that decision until we're
actively discussing the -base document.  I have asked that this be
tracked as an open issue so that we don't forget.

>> does not need to operate in a vacuum.  I do not want to tie it  to
>> any other message authentication technology.
>
>

Let's have this discussion when we're actively discussing SSP.

> publishing the SSP record offers more protection than not publishing 

There are no semantics defined for the r= tag; it is just a "reporting
address" and might not even be a person, so I wouldn't call it accountable.

> someone reading this would not be dramatically mislead.

I guess it depends on what you consider to be a "mitigation".  Note that
it does not say that it prevents the use.

-Jim

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 06 Jan 2006 09:09:32 +0100

Jim Fenton wrote:

> When a message is received with a valid signature, the signer
> is acknowledging that the message came from or through them.
> responsibility"?  Are they "accountable"?  But I digress.]

No, it's a good point.  They might claim that it's not their
fault if their user is in fact a zombie.  From the receiver's
POV they are still "accountable".

> the email-address domain owner (to use your term) or
> originating-address domain owner (to use mine)

Doug's vaguer term might be better until I know precisely what
you're talking about, "originator", "author", "sender", "PRA",
or what else.  It's not the Return-Path and no "opaque-ID", so
far I'm still on your track.

If you transform it into draft-dkim-threats-00 I hope you'll
add more to appendix A:  "Typically the 2822-From" is a trivial
case, if you really want that say "author" instead of "origin",
this would also exclude Resent-From.

What's ADMD ?  Some kind of MTA either DKIM-signing messages,
or checking the signature, that point is clear.  Your diagram
apparently suggests that the "signer policy" is only checked
for a "verified domain".  Is that intentional, and how is it
supposed to work for unsigned mails ?

| Placeholder for some discussion of 2821 vs. 2822 solutions

Say that DKIM is by design independent of the transport, and
that has obvious advantages and disadvantages.  Nothing in the
existing 2821 solutions is incompatible with DKIM.  No need to
go into details, anybody who cares knows where to find tons of
Caveats for PRA, it's also simple to test it.

| These tools may or may not falsify the origin address

s/may or may not/typically allow to/  It's draft about threats,
not CAN SPAM compliant spam novices.

| and possibly networks of compromised computers ("zombies")

s/possibly//  No doubt about that.

| Access to significant computing resources, perhaps through
| the conscription of worm-infected "zombie" computers.

s/perhaps/normally/ or similar, there's no doubt about this...

| Ability to "wiretap" some existing traffic

...OTOH that's rather special, isn't it ?  No problem with
listing it as possibility, of course, if it later turns out
to be related to DKIM in some way.

| Certain attacks are possible primarily within the
| administrative unit of the claimed originator

This AU stuff invariably turns into a mouthful, why not use
Keith's term MON (mail originating network).  It's perfectly
clear that a "zombie" can pick any route also available to
its former owner including any MSAs signing mail with DKIM.

| and/or recipient domain

"AU of the recipient domain" is also tricky, but Keith's MRN
is clear, who cares how they adminster or outsource their MXs
and AV, and in what adminstrative relationship they are with
the domain part of the original or replaced RCPT TO.

| DKIM focuses primarily on bad actors located outside of the
| administrative units of the claimed originator and the
| recipient.

That would be the "MON of the purported author(s)" if you're
talking about the 2822-From, and the MRN on the side of the
final RCPT TO.  I skip further "AU" issues.  Essentially it's
a matter of taste which terms you use, but with "AU" it tends
to get pretty verbose.  In your short form "AU of the claimed
originator" it makes IMHO no sense.

 [Internal bad actors on the MON side]
| DKIM is not directly effective against these bad actors.

Of course not.  It might make it worse if the bad actors get a
DKIM PASS, isn't that the main threat ?

| DKIM is effective in mitigating against the use of addresses
| not controlled by bad actors

That's unclear, which addresses, author(s) / sender / PRA ?
Nit or my DEnglish, shouldn't that be "against the abuse of" ?

| In other words, the presence of a valid DKIM signature does
| not guarantee that the signer is not a bad actor.

ACK, same as SPF PASS.  Even if it's no stranger, it could be
somebody we know turned into a zombie.

| It also does not guarantee the accountability of the signer,

What do they sign it for if they're not accountable ?  That's
different from SPF PASS.  For the latter you can at least send
bounces and auto replies without hitting innocent bystanders -
incl. any SPF PASS of bad actors.  JFTR, nothing you need to
mention in your draft.

| accreditation and reputation systems can be used to enhance
| the accountability of DKIM-verified addresses and/or the
| likelihood that signed messages are desirable.

Better add "white or black listing" as example / explanation,

3.2 is about "eBoy", how about s/specific/look-alike/ or a
similar term ?  IMHO DKIM will be not completely ineffective:

If I'm used to see a PASS for paypal.com, and get a NEUTRAL
for mail.paypal.com.au, then it's "suspicious".  Creating a
funny thread on the spamcop list for that fresh and real case.

| Compromised system within originator's | Medium | Medium |
| network                                |        |        |

That could be "high + low" for a phish.  Or for a mail worm
installing a keylogger it could be "high + medium".  It's the
case I most worry about:  White listed address with DKIM PASS
turned into a zombie.

It's no "DKIM bug" or something, but it's a real danger, where
any scheme offering some kind of PASS could make it worse, if
receivers aren't educated to stay vigilant.

| It may also help locate the compromised system that is the
| source of the messages more quickly.

Yes, that "may" help.  No much progress with that, blocking
port 25 is a cheap snake oil.

| Look-alike domain names                |  High  |  High  |

Oops, yes, you're right, I forgot that they will get a PASS for
their look-alike domain.  IMHO you can delete I18N as special
"high : medium" case, soon nothing will be special with IDNA.

 [multiple authors]
| This is an area in need of further study.

Yes, but "pick the first" sounds like a good idea.  Even very
stupid MUAs should somehow manage to display at least the first
author (in all scenarios with bad actors).

All in all no serious problem, if we can agree on talking about
author(s) for the 2822-From.  Not "origiator", PRA, or "sender"
unless you seriously want it after you have precisely defined
it, RFC, section, paragraph, sentence.  That's burnt territory.

Maybe a stupid metaphor, AU is like NFKD, MON + MRN like NFKC,
both are fine, but you need the latter for your threats draft.

                            Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jan 2006 13:18:40 -0800

On Jan 5, 2006, at 10:34 PM, Jim Fenton wrote:

> I'm trying not to have the SSP design discussion yet.  While I like  
> the chart in general, I'm not sure I agree with all of the entries  
> in it either.  I don't think it's necessary to correct it in order  
> to have the threat analysis discussion.

While any type of chart can be recommended, it does not change how  
"open-authorizations" can be misused.  The misuse of authorizations  
is a _real_ threat.

>> administrators willing to equivocate about source identifiers.    
>> The 'r=' suggests this is the entity that is seen as accountable.   
>> Not publishing the SSP record offers more protection than not  
>> publishing an 'r=' parameter.
>
> There are no semantics defined for the r= tag; it is just a  
> "reporting address" and might not even be a person, so I wouldn't  
> call it accountable.

Being hammered with complaints would suggest otherwise.  Placing any  
"reporting" address at an authorization is simply wrong.  The is a  
hold-over from the equivocation that has occurred in the past.  In  
cases where there has been an exclusive policy such as '!' or '.'  
then the signing domain remains just as unique.  Only the signing- 
domain should have a "report" link, never the authorization record.

>>>> "DKIM is effective in mitigating against the use of addresses  
>>>> not controlled by bad actors,..."
>>
>> This is the portion of the statement that is highly misleading.   
>> DKIM is not effective at mitigating the use of addresses not  
>> controlled by bad actors unless a "closed" authorization is used  
>> such as '!' or '.'.   A clarification that a "closed"  
>> authorization is not compatible with many common uses of email  
>> would also ensure that someone reading this would not be  
>> dramatically mislead.
>
> I guess it depends on what you consider to be a "mitigation".  Note  
> that it does not say that it prevents the use.

For normal use, an authorization scheme used in conjunction with DKIM  
does not offer an ability to mitigate the misuse of one's email- 
addresses.  There should be an admission that only in an exceptional  
and highly restrictive case, can DKIM offer this protection in  
conjunction with authorization.  This then wanders down the road of  
multiple from addresses, but again this depends upon how SSP is  
resolved.   There are some safe generalizations that can be made  
about an authorization scheme, but the caveats regarding the use of  
authorization should not be overlooked.  Try to keep an open mind  
about how DKIM offers protection.  I would not be concerned by an  
authorization scheme that only include the '!' and '.' policies.    
Anything else invites equivocation and coercion with respect to what  
is authentication, and who ultimately is held accountable.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Jan 2006 14:25:16 -0800

> domain should have a "report" link, never the authorization record.

This is beyond the scope of the threats document.  Feel free to bring it
up again when we're discussing SSP.

>>> such as '!' or '.'.   A clarification that a "closed"  authorization
>>> is not compatible with many common uses of email  would also ensure
>>> that someone reading this would not be  dramatically mislead.
>>
>>

Goind back to the original statement, this has nothing to do with SSP. 
It simply says that bad actors can sign their own messages from their
own domains, and I think we all agree with that.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Jan 2006 15:14:33 -0800

>this would also exclude Resent-From.
I'm sure I don't mean "author".  Repeating a bit of what I said
elsewhere, what I'm trying to convey is "who it's from", as defined by
what a typical email user would say when they look at a message.  It's
that address that really matters to them.  The reason I say "Typically
the 2822-From" is that it's my belief that most users will point to it
and say "It's from [whomever]".  I looked at your message and said to
myself "it's from  Frank Ellermann", not "it's from ietf-dkim-bounces".

>supposed to work for unsigned mails ?
Dave Crocker contributed the diagram, which I appreciate because I'm not
good at creating diagrams.  I assume it means "administrative domain". 
Dave?

>Caveats for PRA, it's also simple to test it.
That's a good thing to say.

>s/perhaps/normally/ or similar, there's no doubt about this...
I like the more straightforward wordings.

>to be related to DKIM in some way.
I don't see it as being much more special, or difficult, than
manipulating IP routing.

>its former owner including any MSAs signing mail with DKIM.
I'm happy to use any term that fits but I want to be consistent.  Is
there a definition of MON somewhere that I can read and refer to?

>the domain part of the original or replaced RCPT TO.
There's one vote for Keith's terminology.  Any other opinions, anyone?

>That's unclear, which addresses, author(s) / sender / PRA ?
If you consider SSP, probably "originating address".

>Nit or my DEnglish, shouldn't that be "against the abuse of" ?
If it's a bad actor, it's almost certainly "abuse".

>incl. any SPF PASS of bad actors.  JFTR, nothing you need to
This is that paragraph I need to rewrite, because I was thinking about
the individual that is the administrator of the domain, but of course
DKIM doesn't trace accountability to individuals who are domain owners,
only to the domains.

>Better add "white or black listing" as example / explanation,
Good point.

>similar term ?  IMHO DKIM will be not completely ineffective:
We aren't really getting into the specifics of the attacks at this point
in the document.  The attacker has a specific target in mind that they
want to attack.  The use of look-alike domains is a means to that end.

>funny thread on the spamcop list for that fresh and real case.
I tend to think of that as a (mental) reputation: it's not something we
can depend on.

>case I most worry about:  White listed address with DKIM PASS
Whether it's high or medium impact (based on my definitions) depends on
how strictly the originating domain restricts access to message
signing.  But since that's outside the scope of DKIM, I'm inclined to
raise the impact to High.

>author (in all scenarios with bad actors).
That was our inclination.

>both are fine, but you need the latter for your threats draft.
You lost me on the metaphor.  I assume you mean the Unicode acronyms
NFKD and NFKC?

Thanks for your comments!

-Jim

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 10 Jan 2006 19:20:49 +0100

Jim Fenton wrote:

> I'm sure I don't mean "author".  Repeating a bit of what I
> said elsewhere, what I'm trying to convey is "who it's from"

Addresses in the From header field are only "guaranteed" to be
authors.  Or rather "supposed", a guarantee is a job for DKIM.

That MAY be also the sender / originator / PRA / poster, but
that depends, maybe not.

Your "informative references" include draft-crocker-email-arch.
The version I have is -04, and it says:

| RFC2822.From
|
|  Set by: Originator
|
|  Names and addresses for author(s) of the message content are
|  listed in the From field
[...]
| 2.1.1  Originator
|
| Also called "Author", this is the user-level participant
| responsible for creating original content and requesting its
| transmission.  The MHS operates to send and deliver mail
| among Originators and Recipients.  As described below, the
| MHS has a "Source" role, that correlates with the Author
| role.

This is highly controversial.  E.g. if I take your message and
send it to another list / newsgroup / recipient, then I'm the
originator, but you're still the author.  And that's nothing
unusual, moderated newsgroups might be one example, another is
the Resent-* case, last but not least with news or UUCP before
a gateway to SMTP you could get various kinds of "originator".

Better stay away from email-arch unless you can back up what
you need with (2)822.  Bruce posted several (!) huge (!) lists
of objections wrt draft-crocker-mail-arch on the rfc822 list,

(And I also wasn't pleased by its "bounces-to" POV, but that's
 fortunately irrelevant for DKIM as long as you dance around
 all "originator" issues.)

> as defined by what a typical email user would say when they
> look at a message.  It's that address that really matters to
> them.

Maybe, it depends on their UA, some display "on behalf of" for
an explicit Sender, and some might do something for PRA in the
future.  UAs supporting List header fields probably exist, and
UAs not supporting the Return-Path at all would never be able
to do anything remotely related to RfC 3834.

> The reason I say "Typically the 2822-From" is that it's my
> belief that most users will point to it and say "It's from
> [whomever]".  I looked at your message and said to myself
> "it's from  Frank Ellermann", not "it's from
> ietf-dkim-bounces".

Yes, I've written it, or rather somebody claiming to be me
behind the list or behind GMaNe.  I'm the "purported author".

The "originator" was GMaNe because that's where I (or somebody
claiming to be me) posted it in a newsgroup.  At that time it
was author = 1036-From = poster.  GMaNe treats almost all its
newsgroups as "moderated" NGs, because they are mailing-lists.

For that purpose it sends the article to a "moderator", in this
case the DKIM list address.  So the list got it with MAIL FROM
GMaNe (originator, SPF PASS), AFAIK also with a Sender GMaNe,
and with author = 2822-From = me.

Finally the list redistributed it to among others you and back
to GMaNe, and only after that step it appeared in the GMaNe NG
corresponding to this list.  Some news idiosyncrasies left out.

That's the "normal" magic done by gateways and their operators,
desperately trying to figure out what some IETF documents talk
about.  Here's the version enshrined in STD 11 (822):

| source      = [  trace ]                    ; net traversals
|                  originator                 ; original mail
|               [  resent ]                   ; forwarded

| trace       =    return                     ; path to sender
|                1*received                   ; receipt tags

| return      =  "Return-path" ":" route-addr ; return address
[...]
| originator  =   authentic                   ; authenticated addr
|               [ "Reply-To"   ":" 1#address] )

| authentic   =   "From"       ":"   mailbox  ; Single author
|             / ( "Sender"     ":"   mailbox  ; Actual submittor
|                 "From"       ":" 1#mailbox) ; Multiple authors
|                                             ;  or not sender

|     resent      =   resent-authentic
[... etc., received and resent-authentic omitted ...]

Change a single word in this semantics and the bloodshed hits
the fan.

> I don't see it as being much more special, or difficult, than

ACK.  It's something I also didn't like for SPF.  There are of
course ways to attack something in the lower layers, and there
should be pointers to relevant documents like RFC 3552 and 3833
in the security considerations, the former maybe replaced by
draft-klensin-rfc2821-security later.

But I'm more interested in threats and security considerations
for DKIM itself, not stuff like IP-spoofing, DNS poisoning, or
DDoS attacks on DNS.  Not our job to secure DNS, you only have
to make clear that DKIM depends on a working and reliable DNS,
otherwise it's "ex falso quodlibet".

 [AU vs. MON / MRN]
> I'm happy to use any term that fits but I want to be
> consistent.  Is there a definition of MON somewhere that I
> can read and refer to?

Yes, Keith published it on the SMTP list in conjunction with
the IETF last call for the old draft-hutzler-spamops-04:

http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html

You could read a thread about it using GMaNe:

http://news.gmane.org/group/gmane.ietf.smtp/thread=4383/force_load=t

You'd be forced to copy what you like for a definition of the
terms MON and MRN.  It was also discussed on the general list:

<http://article.gmane.org/gmane.ietf.general/17506> (Sam)
<http://article.gmane.org/gmane.ietf.general/17506> (Bill)

  [3.1 DKIM "mitigating against the use of addreses" <g>]
> If you consider SSP, probably "originating address".

Yes, but _which_ address, From / Sender / Reply-To / PRA ?

For STD 11 see above:  "originator" is the part of "source"
without the "Return-Path" or Resent-*, so that would remove
PRA from the equation leaving From / Sender / Reply-To.

Keith uses "return address" for the set 2822-From / Reply-To /
2821-From (Return-Path), you don't want the latter, so that's
no alternative.  Draft-ietf-usefor-usefor-06 offers "poster"
if you don't like "author" (maybe not a good idea for DKIM):

| A "poster" is the person or software that composes and submits
| a possibly compliant article to a "user agent".  The poster is
| analogous to [RFC2822]'s author.

>> What do they sign it for if they're not accountable ?
[...]
> This is that paragraph I need to rewrite, because I was
> thinking about the individual that is the administrator of
> the domain, but of course DKIM doesn't trace accountability
> to individuals who are domain owners, only to the domains.

Okay.  It's odd to work on the "security considerations" before
the protocols (base + SSP) are clear.  Are you supposed to do
this _three_ times, once to get the WG chartered (ready), again
because the charter says so as some kind of input feedback loop
back into the WG to get base + SSP right, and for a third time
after base + SSP are ready, or integrated into their "security
considerations" ?

>> Maybe a stupid metaphor, AU is like NFKD, MON + MRN like
>> NFKC, both are fine, but you need the latter for your
>> threats draft.

> You lost me on the metaphor.  I assume you mean the Unicode
> acronyms NFKD and NFKC?

Yes.  Dave's mail-arch decomposes the mail architecture into
AU pieces with various roles, an AU for any given role is a
bit like a NFKD (set of compatible decomposed charaters).

OTOH Keith aggregates various AUs and what else on the side
of the originator (MON) or receiver (MRN) resp.  Dave's term
"mediator" is also some kind of aggregation / composition, any
middle man not belonging to the initial MON and the final MRN,
like a mailing list.
                            Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 10 Jan 2006 20:02:33 +0100

> <http://article.gmane.org/gmane.ietf.general/17506> (Bill)
  <http://article.gmane.org/gmane.ietf.general/17476>    Sorry

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 15 Jan 2006 09:25:29 +0100

Jim Fenton wrote:

>> the use of multiple terms creates an architectural
>> separation of authority that is not reflected in real life.

> I was reacting to what limited consensus I saw, rather than
> to the architectural issue.  If there is support for the use
> of AdMD instead, I'm happy to use that.

Divining rough consensus from less than five opinions is white
or black magic for the Chairs... ;-)  On the MON side we have
the domain owner, one of his AUs or AdMDs is his registrar or
Web hoster or his own box, whereever the name servers for his
domain are.  Another AU or AdMD is responsible for his MSA, he
could use more than one MSA, or he has his own mailer.

The "MSA of the ISP" can be relevant for some aspects of the
threat drafts.  E.g. [email-masked] is a relevant case if
ISP.example picks a "closed" signing policy.

Otherwise [email-masked] is interesting, if all
mails sent via the MSA of ISP.example get a signature, no
matter what the my.homepage.example domain owner might wish.

With the term MON you'd cover these different cases.  On the
other side (receiver) you have essentially  *(mediator) MRN,
zero or more "mediators" before the final MRN.

That final MRN may contain MXs at a third party or not, or
AV-software at a 3rd party or not, as long as it contains
the final MDA you're ready and don't care about the details.

It can be also a gateway to something else (4356 SMTP to MMS
is an example), and in that case it will please check DKIM
signatures before it modifies 2822 header fields for MMS.

The cases with one or more mediators are essentially mailing
lists, that's an "MRN plus MON" redistributing the mail, or
251-style "user not local" forwarders, in that case they're
logically a part of the final MRN.

For DKIM all SMTP subtleties of keeping the old MAIL FROM or
not while changing the RCPT TO are irrelevant.  Only if the
2822 header fields are modified by a "mediator" (e.g. for PRA,
by mailing lists, in conjunction with moderated newsgroups,
etc.) we're very interested, because then that's a potential
point of failure for DKIM.
                             Bye, Frank

---

From: Jim Fenton <[email-masked]>
Date: Sat, 14 Jan 2006 09:55:33 -0800

Dave Crocker wrote:
> Jim,
>
>
>> Thanks.  It's looking like MON and MRN are the terms to use.
>
> Probably not, since the use of multiple terms creates an architectural
I was reacting to what limited consensus I saw, rather than to the
architectural issue.  If there is support for the use of AdMD instead,
I'm happy to use that.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 Jan 2006 22:37:42 -0800

Jim,

An administrative authority is cohesive, whether it only sends, only received, 
or both sends and receives.  The purpose of the construct is to focus on the 
administrative cohesiveness, not to case-analyze various sub-type of "services" 
that can be performed by different, cohesive services.

The functional components (eg, MSA, mediator, MTA, etc.) reflect the role 
differences just fine.  There is no need to try to propagate those functional 
distinctions onto the authority construct.

The ultimate example of the problem in trying to define two terms for the 
authority construct arises with a mailing list, which both sends and receives.

After further discussions, I'm leaning towards the term Administrative 
Management Domain (AdMD), deriving it from X.400, but with some differences in 
the definition.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Jim Fenton <[email-masked]>
Date: Fri, 13 Jan 2006 22:11:02 -0800

> That MAY be also the sender / originator / PRA / poster, but
I stand corrected.  I see in RFC 2822 that the address(es) in the From
header are, by definition, authors (or alleged authors, at least).  I'm
learning to be very careful about words these days; I remember a little
while back we had quite a discussion about the word "forgery" and
whether DKIM did anything about it.  I wanted to avoid falling into that
trap with the word "author".
>  all "originator" issues.)
I intend to remove the reference to draft-crocker-mail-arch, and define
the terms I need in this document.
> to do anything remotely related to RfC 3834.
Indeed.  Even with "on behalf of" I think most people will still pick
the From address (the part that comes after the "on behalf of").

Incidentally, I upgraded to Thunderbird 1.5 today and I see that it now
shows the Sender address by default.
> Change a single word in this semantics and the bloodshed hits
I agree with your description but I don't see where it affects the
Threats document.  If you're just explaining something, that's fine, but
let me know if I missed a point.
> otherwise it's "ex falso quodlibet".
Where did that Latin dictionary go...
> | analogous to [RFC2822]'s author.
Author is fine since it's defined that way in 2822.
> after base + SSP are ready, or integrated into their "security
Hopefully not, but we'll see.
> middle man not belonging to the initial MON and the final MRN,
Thanks.

-Jim