Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
2007-03-15 08:32:32
Eliot Lear wrote:
Hi,
Given two sets of RECEIVERS:
RECEIVER-A: Legacy DKIM-BASE system. Supports DKIM-BASE only
RECEIVER-B: Updated to support DKIM-BASE+SSP
and given a DOMAIN that has determined that it "better" to use SSP
than not use SSP, therefore it uses a strong SSP policy for signing.
then who do you think the BAD GUY will target?
Simple: RECEIVER-A
RECEIVER-A will bare the blunt of the premature decisions. The DOMAIN
reputation will be harmed because there exist a legacy of DKIM-BASE
only systems that bad guys will target.
First, I'm not sure how DOMAIN comes into this equation. I suspect that
RECEIVER-A will maintain a list of domains, either manually or out of
band, that it knows signs messages, and may then weight messages from
those domains with invalid signatures somewhat toward spam. The only
issue is that RECEIVER-A may not be able to make an easy decision about
a message with an invalid signature from a domain that has no SSP
record. Perhaps it doesn't sign any mail.
Right, or the DOMAIN signs all mail and Bad Guys (BG) target legacy
systems, including RECEIVER-A DKIM-BASE only systems with no signature
mail purportedly from this DOMAIN BGs will stay away from RECEIVER-B
type systems.
So using the word "break" is not a term I would use. But I would say
that the promotion and recommendation that it is SAFE to use DKIM-BASE
without any helper technology is in my strong opinion, a very poor
engineering decision because it HARM receivers and domains.
I just don't see this.
Fair enough, it is just a consequence of the above which is not much
different than today with BGs targetting legacy systems. Receiver-A,
including non-DKIM ready system will feel the blunt of the exploitation.
The unsuspecting domains, who unbeknowst to them, their domain is
being used in vain at these sites (spoofed, phished), are harmed. No
different than it is today. I'm just hoping that we don't begin march
into a new era with the same mistakes of opening new holes due to
incomplete considerations.
Of course, RECEIVER-A would have to upgrade and I believe that is
question Mr. Lear was poising to Mr. Powers. Will systems upgrade at
a later point?
No, my question was directed at Dave Crocker and Tony Hansen about
whether they would be willing to revise the overview document.
My apology. Rereading your message, I misread it to mean you were asking
Mr Powers if they would upgrade (software) since he showed an urgency
to get an operation going now. My bad, I read you wrong. Sorry.
--
HLS
_______________________________________________
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] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, (continued)
- Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Hector Santos
- Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Steve Atkins
- Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Hector Santos
- Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Eliot Lear
- Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt,
Hector Santos <=
- Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Eric Allman
- Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Powers, Jot
- Message not available
- Fwd: Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Charles Lindsey
- Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Tony Hansen
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Hector Santos
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt, Wietse Venema
|
|
|