Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.

Jim,

I'm sorry, in my vain attempt to reduce the complexity of the problem 
and my past post to you, I had removed complex 3rd party analysis and 
incorrectly changed a few conclusions.
The final conclusion is the same:

   As a implementator, with NOMAIL removed, my design options are
   reduced, the design is predetermined and more complex in order
   to help protect domains from unauthorized domain usage and
   to help reduce incoming mail system abuse.

Let me summarize it this way:

A NOMAIL "Emulation" must cover the basic mail scenarios:

  - Unsigned Messages,
  - Signed Messages,

For unsigned mail, you can only used a "I ALWAYS SIGN" policy because 
there would be no DKIM-Signature header to check the selector for a 
possible bogus null public key.
Thats a given.  You must use a "I ALWAYS SIGN" policy to cover the 
unsigned mail scenario.
For the signed mail scenario, using a bogus key can be used.

In short, to duplicate this NOMAIL emulation, you have:

  o Domain Public Key and SSP records for a NOMAIL emulation

    - DKIM: return Bogus Public NULL Key
    - SSP:  return "I ALWAYS SIGN" Policy

The problem, which included  3rd party conditions that I incorrectly 
removed and changed the wording, is when:
  - the DKIM-Signature header selected produces a NXDOMAIN, and
  - the signed message is by a 3rd party.

If the selector lookup returns NXDOMAIN, DKIM-BASE allows a 451 response 
code to occur under dynamic SMTP implementations (checking is done at 
SMTP) conditions.   For POST SMTP (message is accepted first) 
implementations, this conflicts with protection against ACCEPT/BOUNCE 
abusive operations.
If the selector lookup returns 3rd party conditions and the signature is 
valid but the domain did not expect mail from this FROM domain, 
requirement 5.3 item 8 creates a conflict:
   8.   There is no requirement that SSP publish a Practices of any/all
        third parties that MUST NOT sign on the domain holder's behalf.
        This should be considered out of scope.

So in summary:

1) Is not possible to fully emulate the NOMAIL scenario using other 
means using the current requirements.
2) The lack of a NOMAIL enforces a specific design that requires us to 
do key and hash checking which creates unnecessary possible overhead.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com



Hector Santos wrote:
> 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.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html