[ietf-dkim] Terminology

[Jim Fenton]

Frank Ellermann wrote:
> 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.
>   
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".
> 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.)
>   
I intend to remove the reference to draft-crocker-mail-arch, and define
the terms I need in this document.
>   
>> 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.
>   
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.
>   
>> 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 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.
>   
>>> | 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".
>   
Where did that Latin dictionary go...
>  [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)
>   
Thanks.  It's looking like MON and MRN are the terms to use.
>   [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.
>   
Author is fine since it's defined that way in 2822.
>   
>>> 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" ?
>   
Hopefully not, but we'll see.
>   
>>> 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
>   
Thanks.

-Jim