Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics
2008-01-15 17:39:56
On Jan 15, 2008, at 2:54 PM, Jim Fenton wrote:
The goal of SSP is to determine the practices of the (alleged)
author of the message.
SSP asserts the signing policy of the _domain_, and not that of the
"first author". SSP assertions are referenced from the domain of the
"first author" as the entity protected by SSP. When a domain signs
with an unrestricted key on-behalf-of entity other than the "first
author", and happens to include a 'first-author" address that is
within their domain, it MUST BE assumed to be compliant with the
domain's signing policy. In this case, there is no need to check
against the SSP assertions. In other words, the Sender or the third
From email-address could be signed on-behalf-of and yet be compliant
when the domains match that of the "first author".
The practices of the (alleged) agent responsible for the
transmission of the message aren't relevant; the agent could be the
author's secretary, or for that matter the author's (or authors')
attorney or PR firm.
Only practices of the signing domain are relevant. A corner case is
with respect to a message signed on-behalf-of the office administrator
that includes a "first author" within the same domain. Such a message
is compliant with an assertion that all messages from the domain are
signed, as in "dkim=all".
When the entity's address within the Sender's header being signed is
within a different domain from that of the "first author", the message
would not be complaint with "dkim=all". SSP policy is about _domains_
and not about _entities_. DKIM's charter excludes signatures being
about _entities_. DKIM is about _domains_.
According to RFC 2822 section 3.6.2, the Sender header field MUST
appear whenever the From field contains more than one mailbox
specification, and SHOULD appear whenever the message is transmitted
by other than the author. However, even when the From field
contains more than one mailbox specification, the Sender field still
represents the transmitting agent, not the author. Use of the
Sender field would therefore apply SSP incorrectly.
When the entity's address contained within the Sender header is being
signed, and the signature is within the same domain as that of the
"first author", then SSP policies apply to both the Sender and "first
author".
We then are left with the dilemma of what to do when there is more
than one author.
No. By definition, SSP policy is determined by the "first author"
domain. A requirement should be added for a signature using a g=
restricted key. For a restricted key, the signature is valid with
respect to policy compliance when on-behalf-of the "first author".
One option would be to look up the practices of all of the authors
and combine them.
No. This would result in more transactions and highly dubious results,
as an indication of a signature being valid means what? Which domain
is making the assurance? Policy assertions should stem from the
"first author", but signatures should be on-behalf-of the entity
responsible for their introduction.
An attacker could then potentially make up messages with many
alleged authors as a make-work attack on SSP.
It would be doubtful anyone could offer an understandable way of
conveying who did what as well. The recipient should only need to
look at the _domain_ of the "first author" to understand which
_domain_ originated the message when this domain's policies are either
"all" or "strict" and the message is marked as DKIM signed. DKIM is
not required to indicate _who_ sent the message.
When a large ISP signs all messages, they may wish to include an
opaque i= parameter within their signatures and use an SSP of
"dkim=all". This changed definition would allow their customers to
place their desired email-address as "first author" (perhaps even the
email-address offered by the provider) without the message being
deemed non-compliant. The opaque i= parameter thereby protects their
customer's privacy, while also offering a means for providers to curb
abuse.
Instead, by looking at the first From address only, we force an
attacker who wants to weaken SSP by inserting an extra address to
put the bogus address first, causing the message, most likely, to
look like it came from someone else entirely.
Only look to the "first author" for locating the _domain's_ policy.
Keep in mind that DKIM is not about identifying individuals, as you
appear to be implying. Ironically, by not restricting which entity a
signature can be on-behalf-of, enables domains to clarify who sent the
message. As SSP is currently defined, domains might be forced to
falsely identify who sent the message or make who sent the message
ambiguous. Placing unnecessary restrictions on the use of the i=
parameter is counter productive and is highly problematic.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [ietf-dkim] ISSUE 1525 -- Restriction to posting by first Author breaks email semantics, Dave Crocker
- [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics, Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics, Douglas Otis
- Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics, Jim Fenton
- Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics,
Douglas Otis <=
- [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthor breaks email semantics, Frank Ellermann
- 1:1 (was RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthorbreaks email semantics), J D Falk
- Re: 1:1 (was RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthorbreaks email semantics), Scott Kitterman
- Re: 1: 1 (was RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthorbreaks email semantics), John Levine
- Re: 1: 1 (was RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthorbreaks email semantics), Jim Fenton
- Re: 1: 1 (was RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthorbreaks email semantics), John L
- Re: 1: 1 (was RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthorbreaks email semantics), Jim Fenton
- Re: 1: 1 (was RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthorbreaks email semantics), John L
- Re: 1: 1 (was RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthorbreaks email semantics), Jim Fenton
- [ietf-dkim] Re: 1: 1 and assertions about third parties, John L
|
|
|