Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.
2007-06-11 04:33:23
Jim Fenton wrote:
I'm just saying that there's way to accomplish very much the same thing
as is being requested by expressing the policy in a way that is (IMO)
in-scope for the DKIM working group.
Hi Jim,
I appreciate your comments.
Thats the thing, it is not the same thing. I will explain how below.
> I am not trying to dictate receiver design. Receivers can continue to
> do whatever they want.
No, not really. With NOMAIL eliminated under the incorrect theory that
it is redundant policy and be emulated or "accomplished very much the
same thing", you have inadvertently dictated a specific receiver design.
Here's how:
NOMAIL BASELINE:
For the sake of illustration, lets assume that NOMAIL was part of the
requirement, as it was part of the original SSP specification. This was
allow us to establish the BASELINE GOAL for comparison.
The goal here is to declare the strong policy with a clear and
definitive, zero false positive, declaration by a domain to eliminate
the random and indirect abuse of their unauthorized domain. This is one
of the highest abusive currently going on. Random exploitation of domains.
In short, the RECEIVER, who has a high interest in eliminate abuse as
well, has a clear and definitely signal from the DOMAIN that the usage
of the domain for electronic mail was illegal and not expected,
therefore the receiver has a strong opportunity to eliminate the
"suspicious" unauthorized message.
What is critical important here is that the NOMAIL policy can be
considered regardless if the mail is signed or not. Hence this has
optimization considerations for receivers and clear and definitive
declarations by the domain.
NOMAIL EMULATION:
Now, we eliminate this NOMAIL policy that 100% blocks and protects
domain from unauthorized usage from the SSP requirements because some
feel it is redundant and the same goal can be accomplished by other means.
So what are these other means that "emulate" the same the NO-MAIL policy?
Regardless of the methods are used that satisfies the current as written
requirements, it must handle the following two possible scenarios:
- Incoming message is signed
- Incoming message is not signed
Again, the GOAL here is to end up with a NO-MAIL emulation.
1) Handling Signed Mail:
In this case, we have a signature header selector and we have the
From domain:
1.1) DKIM-Signature selector returns NXDOMAIN
1.2) DKIM-Signature selector returns NULL KEY (intentionally bogus)
1.3) From domain returns a SSP record with NEVER SIGN
2) Handling Unsigned Mail:
In this case, we only have the From domain:
2.1) From domain returns a SSP record with ALWAYS SIGN
As you can see, there is a From domain SSP policy conflict with mail
that is either signed or not signed.
If the email was signed, you have enforced the receiver design to
always do the DKIM verification first. There is more overhead which can
only by reduced by creating a design that does a PUBLIC KEY lookup first
to see if there is a public key (1.1, 1.2)
If the receiver did 1.3 first (check SSP), then it conflicts with the
NON-SIGNED mail scenario 2.1 where you will need a "ALWAYS SIGN" policy
to handle the non-signed mail scenario.
So you now dictated a receiver design where it MUST do a DKIM
verification first if the message is signed and if it wants to reduced
overhead, it will need to check for the PUBLIC KEY first and perform the
HASHING only if the key is not NXDOMAIN or not NULL.
If the message is not signed, then the only POLICY you can have here is
a "ALWAYS SIGN" policy.
But as I indicated, you can not create a "ALWAYS SIGN" if you want to
cover the signed mail situation where you will need instead a "NEVER
SIGN" policy.
If the domain did declare a "ALWAYS SIGN", then you dictated a Receiver
Design that an only work one way.
Did that make sense to you?
In summary, to have a NOMAIL policy, you have dictated the following in
order to satisfy the as written requirements:
o KEY and SSP records setup for a NOMAIL emulation
- DKIM: Bogus Public NULL Key
- SSP: Never Sign Policy
o Verification Logic:
1) If the mail is not signed, check SSP for "NEVER SIGN" policy
2) If the mail is signed, check Public KEY for "Bogus Null Key"
- Do not perform HASH first - this will create overhead
2.1) if the key is not bogus, perform the hashing, verify
with key.
2.2) if the signature is invalid, check SSP for "NEVER SIGN"
2.3) if the signature is VALID, no check for SSP
- POSSIBLE SECURITY LOOPHOLE
And this is great Jim, but you can't do it any other way. The loophole
in 2.3 is theoretically possible, low chance, but possible.
Overall, I have determined that a SSP check should be done first at ALL
times. This goes against the requirements. Otherwise may disagree with
my determination, and thats fine. But I am even given the chance to
optimize the DKIM/SSP implementation in our system.
You may say that I'm not restricted from doing a SSP check first, and
you would be correct.
If I did SSP first:
If the message is not signed, a SSP "ALWAYS SIGN" policy will work
ideally here.
If the message is signed, a SSP "ALWAYS SIGN" policy will not work
ideally here, because it will break step 2.2 above..
So now you have create a high overhead potential by forcing me to only
do it your way to minimize the possible "NO MAIL" scenarios and you
removed the ability to close the possible security hole.
If a system is getting hit hard with SPAM, and most are, the odds are
very good that as DKIM is adopted, that it will be included high among
this group of unwanted failures.
A NOMAIL policy is clear, definitive, no-overhead situation. It doesn't
go against any design any one wishes to do.
Just think about this:
Do you considered a message that is not DKIM signed has a presumption
of invalidity? Thus promoting a SSP check?
There is no presumption of invalidity, any more than there is a
presumption that messages being content filtered are spam. If SSP says
that the messages should have a valid signature and they don't, then
there might be a presumption of invalidity (although I would prefer to
call it "suspicious") but that a result of the SSP check, not a
presumption of an unsigned message by itself.
As I shown above, you can't use a "ALWAYS SIGN" policy to cover the
unsigned mail transactions because this will conflict the failed signed
message condition.
The receiver is left in limbo.
The design is very complex, and I avoid the 3rd party issues above. But
if you begin to throw that in, it really gets messy, when all along, the
domain simply was trying to say "I DO NOT SEND MAIL" - a condition that
an direct and straight SSP policy would satisfy without any specific
design or overhead issue.
Again, if an implementator has reduced options to get the job done as
they think fits the bill for them system, then the current requirements
without NOMAIL is dictating a receiver design.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] lets add one more shall we?, (continued)
- RE: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Patrick Peterson
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Jim Fenton
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Jim Fenton
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.,
Hector Santos <=
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., John Levine
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Jeff Macdonald
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., John L
- Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope., Hector Santos
|
|
|