ietf-dkim
[Top] [All Lists]

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

2006-01-10 11:44:05
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.

| 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.

I don't see it as being much more special, or difficult, than
manipulating IP routing.

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>]
That's unclear, which addresses, author(s) / sender / PRA ?
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


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