Subject: Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

From: Scott Kitterman <[email-masked]>
Date: Wed, 16 Aug 2006 21:20 -0400

On Wed, 16 Aug 2006 17:41:35 -0700 Michael Thomas <[email-masked]> wrote:
>Jim Fenton wrote:
>
>>Douglas Otis wrote:
>>  
>>
>>>This seems like a minor change for the better.  What weakness can't be
>>>fixed by the proper procedures followed by a signing domain?
>>>    
>>>
>>The one I described:  the inability for a verifier to distinguish an
>>author signature generated by the delegate from a third-party signature
>>generated by the delegate operating in a different context.
>>  
>>
>What would be useful is for people who are neutral about this issue to
>look at the attack vector Jim describes. It sure seems real to me, but some
>independent verification would be helpful as well. In particular what would
>be nice is to place requirement constraints on the protocol such that this
>attack must be able to be mitigated by the delegated third party. If that's
>possible at all.

It seems to me that bringing a mailing list into the scenario changes the 
scenario slightly, but not in a significant way.  I would envision two 
basic modes of operation for a signer:

1.  Uncontrolled - Sign mail submitted by authorized users of the MTA 
without extra regard for identities used in the message (I say extra regard 
since many mailing lists only accept mail sent by subscribers).

2.  Controlled - Sign mail submitted by authorized users whose authority to 
use the requisite identity (2822.From) has been verified.  

Shifting from uncontrolled operation to controlled operation is, in my 
opinion, a pre-requisite for being a safe delegated first party signer.  I 
can see that doing this for a mailing list could be problematic.  I expect 
that this is the next step in the evolution of MSA operational constraints 
- a next logical step analagous to closing open relays.

In summary, I think the concern is valid, but not one the protocol can 
solve.  I view it as an operational issue for MSA operators.

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Aug 2006 08:26:06 -0700

>basic modes of operation for a signer:
[]

I think people are missing the subtlties of the attack; the basic 
problem is that there's
nothing that the signer can do to stop its subscribers from being gamed:

Suppose there is an ISP who signs for two customers: company.com and 
mailinglist.com
using this third party delegation mechanism that it being touted. 
company.com and
mailinglist.com make a SSP records that says that ISP.com is their 
signer. Now lets
construct some messages:

// normal from company.com

From: [email-masked]
Dkim-Signature: d=isp.com;

// what is the dkim-signature asserting here:

From: [email-masked]
Sender: mailinglist.com
Dkim-Signature: d=isp.com

How does the recevier know who isp.com is signing on behalf of? The answer
is that it doesn't.

So let's send this from mailinglist.com through their authorized 
submission server:

From: [email-masked]
Sender: mailinglist.com
DKIM-signature: d=isp.com;

Is mailinglist.com allowed to assert [email-masked]? No. Does the
signer have any way to allow the receiver to tell which address it's signing
on behalf of? No. Is this a threat to company.com? Yes. Does ISP.com have
any way to police this? No: it doesn't know whether [email-masked]
is subscribed to a mailing list at mailinglist.com or not.

This is a *much* bigger security hole than just a submission 
authentication problem.
It's allowing companies whose only common business link is their 
provider to freely
spoof each other in a way that the ISP can't control. That's a problem.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 17 Aug 2006 11:41:08 -0400

On Thursday 17 August 2006 11:26, Michael Thomas wrote:
> signer have any way to allow the receiver to tell which address it's
> signing on behalf of? No. Is this a threat to company.com? Yes. Does
> ISP.com have any way to police this? No: it doesn't know whether
> [email-masked] is subscribed to a mailing list at mailinglist.com or
> not.
>

Maybe I am missing something here, but it seems to me much like the old story 
about the man who goes to the doctor and says, "Doctor, when I raise my arm 
like this, it hurts".  The doctor then says, "Then don't raise your arm like 
that".

If you consider the controlled/uncontrolled perspective I mentioned last 

> use the requisite identity (2822.From) has been verified.

The way I read what you are saying is that mailing lists are inherently 
uncontrolled in this context.  I agree with that.  I think it's true of any 
mail received from an MTA and not locally authenticated and controlled via an 
MSA.  Delegating signing authority to a forwarder that re-signs messages 
would have similar problems.

The signing domain (d=) needs to be different for controlled/uncontrolled 
traffic.  Since d= is not visible to the user, there aren't any user 
interface issues.  If isp.com signs as d=msa.isp.com for locally submitted 
controlled traffice and signs as d=lists.isp.com for mailing list traffic, I 
don't think there's a problem.  I do think we need to mention in security 
considerations of the final specification, but I don't think it's a major 
issue that impacts requirements or protocol design.

What am I missing?

Scott K

---

From: <[email-masked]>
Date: Thu, 17 Aug 2006 11:44:37 -0400

Big gaping hole, I may assume that isp.com can determine the
author/originator but how to differentiate or not sign a spoof?
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Thomas
Sent: Thursday, August 17, 2006 11:26 AM
To: Scott Kitterman
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] SSP Responsibility Delegation - Security
Concerns

[]

From: [email-masked]

From: [email-masked]
Sender: mailinglist.com

How does the recevier know who isp.com is signing on behalf of? The
answer
is that it doesn't.

Is mailinglist.com allowed to assert [email-masked]? No. Does the
signer have any way to allow the receiver to tell which address it's
signing
on behalf of? No. Is this a threat to company.com? Yes. Does ISP.com
have
any way to police this? No: it doesn't know whether
[email-masked]
is subscribed to a mailing list at mailinglist.com or not.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 17 Aug 2006 12:18:10 -0400

> author/originator but how to differentiate or not sign a spoof?

It gets back to is the signer controlled or uncontrolled.  Only a controlled 
signer is suitable for SSP delegation (this would be a contractual matter 
between the ISP and their customers).

Typically, today, ISPs that allow foreign mail identities operate 
uncontrolled.  That is, any user authorized to use the MSA is allowed to use 
arbitrary identities.  This would have to change.  I expect that for large 
ISPs it would be impractical to go back an validate their entire userbase and 
so this might be offered as a premium service for the class of customers that 
would care.

Operationally for an MSA this is trivial (at least based on my experience with 
Postfix, my MTA software of choice), the major challenge is the 
administrative effort needed to verify authorization to use an address. 

When we get to writing the internet draft with the SSP specification, I will 
volunteer now to write the words explaining all this so people have no excuse 
if they screw it up.  I will keep writing until there is agreement that the 
issue and how to mitigate it is described accurately.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Aug 2006 09:33:47 -0700

On Aug 17, 2006, at 8:44 AM, <[email-masked]>  
<[email-masked]> wrote:

> Big gaping hole, I may assume that isp.com can determine the author/ 
> originator but how to differentiate or not sign a spoof?

To achieve full isolation, sign all sources with a subdomain  
signature or set the t=s flag at the parent domain key.  Make only  
the signing domain for the sources confirming or constraining the  
2822.From address as a designated domain. A structure something like  
this can be used:

- relay-accounts signed with d=relay.example.com.
- mailing-lists signed with d=lists.example.com.
- user accounts signed with d=example.com.
- example.com is the designated domain for example.com.

There is no gaping hole.  Filter relay.example and lists.example from  
appearing in example.com or set the t=s flag.  There can not be any  
protection in any arrangement unless the 2822.From addresses are  
constrained or validated prior to use.  One method that might be used  
is to validate each 2822.From per account could be much like that  
done for a mail-list subscription.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Aug 2006 11:30:39 -0700

Douglas Otis wrote:
>
> On Aug 17, 2006, at 8:44 AM, <[email-masked]> <[email-masked]>
> wrote:
>
> To achieve full isolation, sign all sources with a subdomain signature
> or set the t=s flag at the parent domain key.  Make only the signing
> domain for the sources confirming or constraining the 2822.From
> address as a designated domain. A structure something like this can be
> used:
>
> is to validate each 2822.From per account could be much like that done
> for a mail-list subscription.
I really don't think you want to go there.  Effectively this would
require "relay" and "lists" to be reserved subdomain names requiring
IANA registration.  There's no way that will ever happen.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Aug 2006 11:33:23 -0700

I rather like Mike's example of the hole better than my own, since it
shows how a single SSP-delegated signer can be affected by the actions
of its customers, and not by its own actions.

Thanks, Mike.

-Jim

[email-masked] wrote:
>> It seems to me that bringing a mailing list into the scenario changes
>>     
> the 
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Aug 2006 11:44:00 -0700

> done for a mail-list subscription.

I thought that the entire point of all of this was that it was an easier 
delegation
mechanism. At the point that you have to do all sorts of unnatural acts 
-- like
these -- I think the entire argument unravels. The cure here seems much 
worse
than the disease.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Aug 2006 11:47:14 -0700

>between the ISP and their customers).
If that's really the case, I'm not sure why this idea has any merit at 
all because
we already have the means to do controlled delegation using NS records, and
it doesn't tickle any of these problems.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Aug 2006 12:37:27 -0700

On Aug 17, 2006, at 11:30 AM, Jim Fenton wrote:

>> 2822.From address as a designated domain. A structure something  
>> like this can be used:
>>
>> There is no gaping hole.  Filter relay.example and lists.example  
>> from appearing in example.com or set the t=s flag.  There can not  
>> be any protection in any arrangement unless the 2822.From  
>> addresses are constrained or validated prior to use.  One method  
>> that might be used is to validate each 2822.From per account  
>> (could be much like that done for a mail-list subscription).
>
> require "relay" and "lists" to be reserved subdomain names  
> requiring IANA registration.  There's no way that will ever happen.

This type of strategy is required even when a domain designation  
tactic is not used.  There is no need to reserve a subdomain with an  
IANA registration.  I don't see how one could reach that conclusion.   
There could be [email-masked] placed in a header  
within the list messages, even when the list address is some- 
[email-masked].  It is important to _not_ have 2822.From addresses  
seen as validated when issued from an invalidated source such as the  
mailing list.  Sources where 2822.From are not validated should not  
receive a signature what will have the 2822.From seen as being  
validated by the signature.  A different domain is required.  One  
simple solution would be to use a subdomain, any subdomain.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Aug 2006 18:50:05 -0700

On Aug 17, 2006, at 11:47 AM, Michael Thomas wrote:

> Scott Kitterman wrote:
>
>> It gets back to is the signer controlled or uncontrolled.  Only a  
>> controlled signer is suitable for SSP delegation (this would be a  
>> contractual matter between the ISP and their customers).
>
> If that's really the case, I'm not sure why this idea has any merit  
> at all because we already have the means to do controlled  
> delegation using NS records, and it doesn't tickle any of these  
> problems.

Without the means to ensure _only_ valid 2822.From address are signed  
by the domain, not being suitable as a designated domain is of lesser  
importance.  The untrustworthy 2822.From address would be a far  
greater issue.  This is not a hole that must be filled for a  
designated domain list to be viable.  A policy that lists the  
authoritative domains can accurately convey whether assurances are  
made with respect to the validity of the 2822.From address.  No  
domains listed, then there is no assurance of the 2822.From's  
validity.  Perhaps there needs to be a separate assertion regarding  
the validity of the 2822.From address.

A large ISP may wish to take the steps needed to validate a 2822.From  
address that is not within their domain.  One can obtain an email- 
certificate in roughly the same manner.  This extra step would allow  
this signing domain to be certified as suitable for DKIM domain  
designation.  It would also allow their customers greater freedom to  
use desired email-addresses while knowing they are still protected  
from being spoofed.  Their recipients would also obtain assurances  
made by a certified DKIM signing domain that the 2822.From address is  
valid.  When the domain of the 2822.From address designates this  
signing domain, both parties reap the benefits afforded by the  
greatly simplified administration.

If there is a choice offered, bet dollars to doughnuts that domain  
designation within the 2822.From policy will be the preferred method  
over DNS zone delegation for the majority of smaller outfits.  This  
approach should induce fewer support calls, require less back-office  
overhead, and attract greater demand for the service provider  
offering the simpler service.  Without question, a larger outfit will  
opt for the zone delegation approach.  At the same time, it seems  
many smaller outfits will find the ability to designate a signing  
domain fairly attractive.  This will likely afford smaller outfits  
lower associated costs, and increased acceptance of their messages.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 17 Aug 2006 22:18:48 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Scott Kitterman" <[email-masked]>

> Suppose there is an ISP who signs for two customers: company.com
> and  mailinglist.com using this third party delegation
> mechanism that it being touted.  company.com and mailinglist.com
> make a SSP records that says that ISP.com is their signer.

So lets assume the declation as proposed in DSAP

company.com

     OP=NEVER or OPTIONAL;
     3P=ALWAYS;
     3PL=ISP.COM

mailinglist.com

     OP=NEVER or OPTIONAL;
     3P=ALWAYS;
     3PL=ISP.COM

> Now lets construct some messages:
>

Ahhh, but it doesn't care because the customers don't care, via the above
consistent policy declaration.

> DKIM-signature: d=isp.com;

First, the presumption here is that [email-masked] has subscribed to
some mailing list where he should now be very aware the door is wide open to
exploitations.

Second, the presumption here is that the mail is that we have a single
source signing domain network, and that the mailinglist.com server is
outside the signing domain network.

        COMPANY.COM     ---->
                                ISP.COM
        MAILINGLIST.COM ---->

So far the policies are consistent. But what is more important is the
SUBMISSION process.  Don't forget that.  The ISP does have control here.

> Is mailinglist.com allowed to assert [email-masked]? No.

Yes, because [email-masked] has subscribed to mailinglist.com it has
opened the door to exploitations.  Its like you giving your driver's license
to your teenage son so he can go drinking or to some night club.   You are
taking chances.

> Does the signer have any way to allow the receiver to tell which
> address it's signing on behalf of? No.

It doesn't care.

> Is this a threat to company.com? Yes.

Absolutely, but the boss should of known that by using his company.com
domain promisculously on other systems.

> Does ISP.com have any way to police this? No: it doesn't know
> whether [email-masked] is subscribed to a mailing
> list at mailinglist.com or not.

The ISP.COM does have a way to policy it if the DOMAIN declared it in its
policy or there is a contractual policy between the ISP.COM and DOMAIN not
mix apples and oranges.

Also, the ISP.COM has control thru the SUBMISSION process.  It sees mail
coming in from the mailinglist.com, not company.com.  Thats a major piece of
the protection here.

> authentication problem.  It's allowing companies whose only
> common business link is their provider to freely spoof each
> other in a way that the ISP can't control. That's a problem.

I don't agree, Mike.

This issue is no more, no less an implementation issue. The ISP.COM can
control the process, but also the domains themselves can't have all the cake
and eat it too.  If it wants protection, against external abuse then he will
need to be less promiscuous about his domain usage.  What if the
mailinglist.com does other things to the mail, such as destroy the integrity
so that DKIM-BASE will fail anyway?   At the very least, if the domain
wanted to do this right, it would have a policy such as:

company.com

     OP=NEVER or OPTIONAL;
     3P=ALWAYS;
     3PL=ISP.COM; MAILINGLIST.COM

This allows for the mailinglist.com to maybe RESIGN his mail, the policies
would be consistent for the verifier and its all good.

But if the domain didn't care at all by subscribing to this and other
mailinglist.com services, then why even have a policy at all?  He doesn't
need one.

If anything come outs of this discussion is to show the DKIM-BASE is less
safe without email signature policies because anyone (ISP.COMs and his
uplink, and his uplink, and so on) can sign without restrictions.

It also saws that ISP.COM need to be more in control of what they sign once
DOMAINS want it to be used, either directly themselves and they are using
the ISP.COM to route mail, or indirectly with the ISP.COM taking on some
duties or offering DKIM services.

The idea of an ISP.COM just blindly signing mail as a 3rd party is going to
create some major problems without some level of controls.

I can understand how we want to allow this to happen, but we also need to
understand that there will be domains that do not expect this to happen, not
if they are going to invest in DKIM.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 01:40:19 -0400

Just small point here, if it wasn't obvious:

The possible arrangement we have in this scenario is:

    COMPANY.COM     ---->
        |
        |                  ISP.COM  ---> 3P signed mail
        V
    MAILINGLIST.COM ---->

Where the domains company.com and mailinglist.com both have their ISP
signing on their behalf as a 3rd party.  Both have delegated the ISP in
thier SSP policy, and company.com is also a subscribed member of
mailinglist.com.

The question is why would COMPANY.COM continue to use other services which
may or may not use DKIM?  If he is going to go thru this trouble with
ISP.COM, why would it avoid the protection by also using other services?

What if MAILINGLIST.COM decides it no longer wants the ISP.COM to sign mail?

What if MAILINGLIST.COM decides to go else where with a different ISP?

In short, the problem is not the concept, but how COMPANY.COM uses his
domain promiscuously.

Does he use this mailinglist.com because he knows it also uses ISP.COM?

Does he know mailinglist.com will never sign? or that it will also use
ISP.COM?

So its all basically how company.com expect his domain to be used by others.

It could also be possible that ISP.COM is designed with some smarts and sees
that company.com is using mailinglist.com (Sender: mailinglist.com)?

In this case, it is mailinglist.com who is SUBMITTING the message, so the
ISP.COM will have some state information ahout whether it should allow this
or not because it might be considered suspicious the mail is not coming
directly from COMPANY.COM.

Maybe the company.com is also using SPF and he knows the ISP using SPF, so
in company.com SPF record, he authorize the mailinglist.com machine to send
mail to ISP.COM on its behalf.

So the concept is not flawed.  It all a matter on how the domain prepare its
policy.

As a VERIFIER, I don't see a problem here as long as it is all consistent.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Aug 2006 00:24:03 -0700

On Thu, 2006-08-17 at 08:26 -0700, Michael Thomas wrote:
> problem is that there's nothing that the signer can do to stop its
> subscribers from being gamed:
> 
> mailinglist.com using this third party delegation mechanism that it
> being touted. 

For a DKIM domain to offer a service safely listed as a designated
domain, the 2822.From is valid or it is not signed.  In the case of a
mailing-list, this would abuse an account. The 2822.From addresses will
not have been validated and a validation process should be rather
limited on a per account basis.  A slew of non-validated 2822.From
addresses should cause the account to become disabled without permitting
this messages to be sent.

In the case of a company, arrangements through an account could avoid
each local-part of the company's domain being validated.  Perhaps just
postmaster@ validation would suffice.  This account should still be
restricted in the addresses within the domain permitted by the account.

> // what is the dkim-signature asserting here:

[email-masked] represents a valid use of this address.

> Dkim-Signature: d=isp.com

Account disable due to frequent attempts to send messages where the
2822.From had not been validated.  Perhaps isp.com offers special
accounts for mailing lists signed using:

From: [email-masked]
Sender: mailinglist.com
Dkim-Signature: d=lists.isp.com

lists.isp.com should not be a designated domain as this would not be
representative of validated 2822.From addresses.  This domain should not
be certified as a DKIM signing domain suitable for designation.

> How does the receiver know who isp.com is signing on behalf of? The
> answer is that it doesn't.

Either the signing domain ensures the 2822.From addresses are valid, or
the signing domain should not be certified as a DKIM signing domain
suitable for being designated.  If the domain is suitable, then it can
be assumed the 2822.From is valid in every case.

> Is mailinglist.com allowed to assert [email-masked]? No.

Again, this account should be disabled when the 2822.From addresses have
not been permitted.  Permissions should only occur after a validation on
a limited basis per account. 

> address it's signing on behalf of? No.

No. Messages where the 2822.From has not been verified are not signed.
Setting up a DKIM signing domain suitable for being a designated domain
will requiring tracking what is permitted on a per account basis. This
may also require a means to validate the receipt of the 2822.From
address by the account.   

>  Is this a threat to company.com? Yes.

No. Either this is prevented or a different signing domain is used. When
there is no designated domain, there is no expectation the 2822.From is
valid.

It would seem Hector would advocate a separate flag indicating whether
the 2822.From is valid as a separate assertion from by whom it should be
signed.  My view differs in this case.  Either the 2822.From is valid or
don't list a designated (authoritative) domain in the policy.  A flag
that signals a required signature without an assertion the 2822.From is
valid offers little protective value.

> Does ISP.com have any way to police this? No: it doesn't know whether
> [email-masked] is subscribed to a mailing list at
> mailinglist.com or not.

ISP.com should limit the use of the 2822.From addresses to those
pre-arranged and validated.  A mailing list should be trapped and
disabled as an abusive account.  This should also curtail many of the
bot-net abuses. 

> authentication problem. It's allowing companies whose only common
> business link is their provider to freely spoof each other in a way
> that the ISP can't control. That's a problem.

If ISP has not validated the use of a 2822.From address, it should not
be permitted.  Again, this can work in much the same way as is done to
validate an email-certificate, or to subscribe to a mailing-list. To
accommodate the use of a mailing-list a different type of account would
be used and signed using a different domain such as lists.isp.com.

The goal that Hector is seeking represents a desire to list who should
sign without making any assertion regarding the validity of the
2822.From.  While not agreeing with that use, a policy could be
structured to accommodate that use as well.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 06:27:20 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>

> No. Either this is prevented or a different signing domain is
> used. When there is no designated domain, there is no
> expectation the 2822.From is valid.
>
> It would seem Hector would advocate a separate flag indicating
> whether the 2822.From is valid as a separate assertion from by
> whom it should be signed.  My view differs in this case.  Either
> the 2822.From is valid or don't list a designated (authoritative)
> domain in the policy.  A flag that signals a required signature
> without an assertion the 2822.From is valid offers little
> protective value.

I'm not sure what this means, but we still have the DKIM-BASE hashing of
2822.From.  Thats a great assertion for validity.

I argue only that it is unsafe for company.com to be using his domain
promisculously after it has arranged for his mail to be signed by anyone or
himself.  If he wants to do that, fine.  But he should atleast declare such
a relaxed policy.

He doesn't know what will happen at mailinglist.com.  Maybe tomorrow
mailinglist.com will find a different ISP.  Who knows?

But if domain wants to allow that, I don't see it as any different than
other relaxed domain policy.

> The goal that Hector is seeking represents a desire to list
> who should sign without making any assertion regarding the
> validity of the 2822.From.  While not agreeing with that use,
> a policy could be structured to accommodate that use as well.

Lets not forget there is still DKIM-BASE.  The tie in would be the hashing
of the 2822.From: header.  The signature still needs to verify.

All we are doing here is a simple policy concept to says the signature was
expected to be signed by either the OA or some 3rd party.

If the domain doesn't care and doesn't designate a 3rd party signer or will
be using his domain loosely, then there is nothing the verifier can do.  But
is the domain protecting itself?  I don't think and its not doing one any
favors.

All the verifier can do is do some upfront checks for consistency.

After that, its up to the local policy what they want to do. They want to
buy some DAC batteries, excuse the pun <g>, thats fine.  But I am not going
to spent an investment on DKIM solely on membership only DAC batteries.

I think this is simply to just eliminate the most obvious of potential
loopholes:

- Is domain being used for mail when it should not?

   This can happen now. Bad guys blindly using a domain.
   DKIM domains will benefit to protect domains that not
   used for mail. Very simple to eliminate.

- Was it suppose to be signed?

   Did some bad guy who knew nothing about DKIM blindly
   harvested some domains began to spoof the domain without
   a signature?  This is what I call an "Indirect Attack."
   Very simple to eliminate.

- Was it support to be unsigned?

   Did some bad guy try to fool the system somehow, and
   began to sign mail - valid or not?  This is what I
   call a "Direct attack."  Very simple to eliminate.

- Was it really strict with only the first party?

   Did some bad guy try to use a 3rd party party to
   fool randomly targeted systems?  Again, very simple
   to eliminate and help protect these "High Value"
   domains.

- Is a 3rd party signinature ok?
- And if they want to be more strict, which 3rd party?

   if a 3rd party was found, did the domain
   allow it?  and if so, was there a specific domain
   allowed? Very simple to eliminate.

Very basic stuff.

After that, in my opinion, there is nothing the verifier can do.  The policy
was checked and if they is a signature, run it by DKIM-BASE.  That's it.
Simple.

If we want to remove the delegation, then in my view, we are either going to
make it more strict with a no 3rd party flag or completely openness where
anyone can sign.

So the delegation is a middle ground for those people who don't want to be
100% strict with OA only signatures and yet do not just want anyone signing.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Aug 2006 08:28:12 -0700

On Fri, 2006-08-18 at 06:27 -0400, Hector Santos wrote:
> I'm not sure what this means, but we still have the DKIM-BASE hashing
> of 2822.From.  Thats a great assertion for validity.

You appear less concerned about whether the signature implies the
2822.From is valid from the perspective of being used by the correct
entity.  Without a 2822.From policy, there is little real reason to
assume the correct entity is using the 2822.From address.  It has been
suggested in the base draft, correct use is implied only when the i=
parameter contains the full email-address.  When a designated domain has
signed on behalf of the 2822.From address, this syntax is not possible
where it should be assumed that this designation only occurs when the
2822.From address is _absolutely_ restricted to being used by the
correct user.    

> promisculously after it has arranged for his mail to be signed by
> anyone or himself.  If he wants to do that, fine.  But he should at
> least declare such a relaxed policy.

I assume you mean that by "relaxed" the 2822.From is not valid but here
are the domains who should be signing for this 2822.From domain.  Here
is where a flag might be needed to indicate this state.  This would
create the need for:

 - "All" All initially signed.

 - "Only" Only these signing domains used.

 - "Invalid" 2822.From is not assured to be valid.  

> mailinglist.com will find a different ISP.  Who knows?

In my view, a domain that permits a mailing list unrestricted use of the
2822.From addresses should never be a designated domain, and should not
be certified as being suitable for this purpose.  You, on the other
hand, wish to limit the set of valid signers for the 2822.From address
even when anyone is still able to spoof this address who also has access
to this domain.  This removes the protection expected of a 2822.From
policy.  As long as there is a flag that indicates the 2822.From address
should not be considered valid, then damage is mitigated to some extent.
This message might not be filtered, but then it should not be annotated
as having an assured address in any manner.

> But if domain wants to allow that, I don't see it as any different
> than other relaxed domain policy.
> 
> Lets not forget there is still DKIM-BASE.  The tie in would be the
> hashing of the 2822.From: header.  The signature still needs to
> verify.

Signed by a domain that does not restrict the use of the 2822.From will
not protect the use of the 2822.From, whether or not the signature
verifies.  You should admit that this mode of operation offers little
value to the 2822.From address holder and to the recipient.

> So the delegation is a middle ground for those people who don't want
> to be 100% strict with OA only signatures and yet do not just want
> anyone signing.

Here we do not agree.  A designated or delegated domain should only
occur when the 2822.From address is expected to be protected.  For large
ISPs, some organization like DAC could certify which DKIM domains offer
this form of protection.  Without that assurance, either through a
contract or third-party indication of compliance, designation or
delegation should not occur.  Not having a designated domain for the
2822.From address should indicate this address domain should never be
trusted as being used by a specific entity.  Acceptance, if there is
any, would be based solely upon the signing domain and the IP address of
the sender.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Sat, 19 Aug 2006 16:11:00 -0700

>some mailing list where he should now be very aware the door is wide open to
Does anybody else agree with this statement? I'm fairly certain that my 
president
(or even the Resident for that matter) is decidedly unaware, and I can't 
imagine
a universe in which mine or any other would be aware of such a threat. 
Since this
threat does not exist with the NS delegation method, my president could 
remain
in unaware bliss which seems like as it should be.

       Mike