Subject: [ietf-dkim] Responsibility concerns with Designated Signing Domains

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 14:48:57 -0700

While we aren't defining reputation or accreditation services in this
working group, it has been widely suggested that such services would use
the d= domain on the signature as the "lookup key" for retrieving
reputation or accreditation information.

There is a fundamental difference, then, between key delegation and
delegation via SSP.  In the former (key delegation) case, the party
applying the signature (delegatee) is merely acting as an agent of the
delegator to do the mechanics of signature application.   It is still
the delegator's signature, and the "buck stops" with the delegator in
terms of who has taken responsibility for the message.  In the latter
(SSP delegation) case, it is the delegatee's domain that takes
responsibility for the message.  Some have suggested the delegatee might
want to use subdomains in order to allow reputations to avoid
aggregating reputations from different delegators (or classes of
delegators).

Some implications of this change in responsibility:

1. Responsible domains using SSP delegation will not be able to change
signing providers (delegatees) without forfeiting any positive
reputation they have accumulated.  It should really be the delegator's
positive reputation, because they are the ones acting responsibly in
their mailing practices and/or the use of outside mailing providers.  It
should not be necessary to start over if you change ISPs or outbound
marketing providers.

2. Delegators are more likely to be diligent in the choice of delegatees
when it is their own reputation at stake.  When it is the delegatee's
reputation at stake, they can always employ an unreliable party, or in
the extreme a spammer, and when abuse is reported simply say "oh, sorry"
but not endure any impact on their reputation at all.

3. We are already aware of the potential for the use of throw-away
domain names by bad actors who otherwise might accrue a bad reputation. 
This opens a new possibility:  it isn't necessary to get a new domain,
just delegate signing to a new entity and "all is forgiven".

-Jim

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 25 Aug 2006 19:10:19 -0400

> reputation or accreditation information.

Yes and IIRC, in the discussions about DKIM-base it was largely assumed d= 
would point to the operator's domain.

> aggregating reputations from different delegators (or classes of

Yes, this is the opposite of what was figured for DKIM-base.

> should not be necessary to start over if you change ISPs or outbound

I can see this going either way.  In the end the operator controls what goes 
out and what doesn't.  Both the author domain and the operator domain can 
allow bad things to happen.  Only the operator is in  a  position to be 
assured of preventing them.

> but not endure any impact on their reputation at all.

And if the author's reputation, the operator has less incentive to ensure 
their customers are clean and have a positive impact on their reputation.

> just delegate signing to a new entity and "all is forgiven".

That's equally true for first party signatures if one picks a new subdomain or 
a new domain.  I don't think this is any different.

Personally, I've got no idea how the reputation stuff is going to work out.  I 
think it was smart to have it outside the scope of this WG.  From a 
reputation scoring perspective, I think it's a toss-up.  NS delegation versus 
DSD/third party authorized will definitely different.  I don't know which is 
better.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Fri, 25 Aug 2006 16:28:26 -0700

On Aug 25, 2006, at 2:48 PM, Jim Fenton wrote:

> While we aren't defining reputation or accreditation services in  
> this working group, it has been widely suggested that such services  
> would use the d= domain on the signature as the "lookup key" for  
> retrieving reputation or accreditation information.
>
> applying the signature (delegatee) is merely acting as an agent of  
> the delegator to do the mechanics of signature application.   It is  
> still the delegator's signature, and the "buck stops" with the  
> delegator in terms of who has taken responsibility for the  
> message.  In the latter (SSP delegation) case, it is the  
> delegatee's domain that takes responsibility for the message.  Some  
> have suggested the delegatee might want to use subdomains in order  
> to allow reputations to avoid aggregating reputations from  
> different delegators (or classes of delegators).
>
> 1. Responsible domains using SSP delegation will not be able to  
> change signing providers (delegatees) without forfeiting any  
> positive reputation they have accumulated.  It should really be the  
> delegator's positive reputation, because they are the ones acting  
> responsibly in their mailing practices and/or the use of outside  
> mailing providers.  It should not be necessary to start over if you  
> change ISPs or outbound marketing providers.

It MUST always be the provider offering outbound services, not the  
provider receiving messages held accountable.  The designators are  
the receivers of email.  Not the senders and signers.  Reputation is  
about watching for abuse when it is sent by your customer, even when  
they are using their email-address of the day.

> 2. Delegators are more likely to be diligent in the choice of  
> delegatees when it is their own reputation at stake.  When it is  
> the delegatee's reputation at stake, they can always employ an  
> unreliable party, or in the extreme a spammer, and when abuse is  
> reported simply say "oh, sorry" but not endure any impact on their  
> reputation at all.

Any provider should be able to disable an abusive account at any  
moment.  This problem is common and does not change with DKIM.

There is also the safety in numbers phenomenon and herd mentality.    
ISP.com now has a zillion customers designating them as their signing  
domain.  A true sign of trust.  An ISP that now requires that all  
2822.From addresses be validated prior to use should also find their  
abuse issues are reduced.  There is an upside.

> domain names by bad actors who otherwise might accrue a bad  
> reputation. This opens a new possibility:  it isn't necessary to  
> get a new domain, just delegate signing to a new entity and "all is  
> forgiven".

Just gaining access to a new provider also works.  This works 70% of  
the time through a compromised system as well.  Finding a way to  
encourage the use of a rather simple mechanism that fends off  
spoofing, irrespective of whether there is any designation being  
used, seems like a win-win for the provider and their customers.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 26 Aug 2006 01:08:37 +0100

Again, only a quibble, but maybe a more significant one.

Jim Fenton wrote:
> terms of who has taken responsibility for the message.  

 From the verifier point of view the buck stops with the delegator.

But if the delegator delegated its private key, or if the signer
supplied its public key to the delegator, then the buck might get
moved between them (from their, and not the verifier, perspective),
depending on the details of how the key delegation happened.

For example, if there is >1 copy of the private key, then, in
buck passing terms, we just don't know which signer signed.

Not an unsurmountable problem of course, and maybe the best
thing for some folks to do in any case. But yet again, each
form of delegation has its issues.

S.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 25 Aug 2006 18:42:58 -0700

> should not be necessary to start over if you change ISPs or outbound

This is how I'm thinking, as well...if senders try to piggyback on 
somebody else's reputation, I'm likely to ignore that and use other 
criteria to determine the overall reputation of the message.

The desire from some of the bulk senders & 3rd party reputation vendors 
appears to be to allow a sender to say "go ask [vendor], they'll tell 
you how good I am."  This is not, however, something that receivers of 
that mail would necessarily want.

And just from a general cleanliness perspective, I'd rather keep all 
reputation decisions out of the signing/verifying process.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Fri, 25 Aug 2006 23:31:18 -0400

DKIM has nothing to do with reputation, reputation providers may want to
use DKIM as part of their processing technologies but that is their
issue/point of failure. I want something that allows me to accurately
identify who decided to send me a piece of mail.
What I choose to do with that identification is internal to me as a
receiver. 
Any negative assertions by the DKIM signer may be helpful for me to
classify the material I have received.
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 J.D. Falk
Sent: Friday, August 25, 2006 9:43 PM
To: IETF-DKIM
Subject: Re: [ietf-dkim] Responsibility concerns with Designated
SigningDomains

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 22:02:40 -0700

> would point to the operator's domain.
I don't recall that at all.  Yes, signing would normally be done by the
operator (I think I have the terminology straight on this...) but I
believe we were referring to the operator of the domain that the author
belongs to (in the case of an origination signature).
> assured of preventing them.
I'm pretty sure I have the "operator" terminology messed up, then.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 22:10:21 -0700

Douglas Otis wrote:
> provider receiving messages held accountable.  The designators are the
> receivers of email.  Not the senders and signers.  Reputation is about
> watching for abuse when it is sent by your customer, even when they
> are using their email-address of the day.
In that case, you must believe that key delegation and NS delegation do
the wrong thing.

SSP Designated Signing Domains have been promoted as making it easier
for some domains, particularly small domains, to obtain a first-party
signature.  But that otherwise the end result is the same.  My point is
that it isn't:  the point of responsibility is different for SSP
Designated Signing Domains from the other forms of delegation.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Sat, 26 Aug 2006 04:15:19 -0700

On Fri, 2006-08-25 at 22:10 -0700, Jim Fenton wrote:
> > the receivers of email.  Not the senders and signers.  Reputation 
> > is about watching for abuse when it is sent by your customer, even
> > when they are using their email-address of the day.
>

A naive provider may hope a signature not bound in any way to the
message envelope will be used exclusively to block spam.  They will be
in for a rude awakening.  It does not matter who signed what, the IP
address WILL be blocked!

DKIM is excellent at identifying who sent the message based upon the
2822.From, where 2822.From policy name associations can be extremely
useful at better enabling this genuine benefit using inexpensive
autonomous administrative techniques.  A name association list is done
by one entity.  Key exchanges or zone delegations MUST be done by two.
Administration by one is far better than two when scaling is considered.

> signature.  But that otherwise the end result is the same.

2822.From policy is not graphing DNS name trees together, or in any way
affecting the integrity of the signature.  Attempting to exchange keys
on a large scale WILL affect the integrity of the signature.  2822.From
policy can list associated domains, and is extremely simple in
comparison.

With the delegation approach:

- A user must forgo being recognized when using an email-address
  outside of the signing domain. 

- Send their messages through one provider offering combined
  domain/email services.

- Run their own signing MTA and obtain relay services.

- Establish arrangements for routinely exchanging keys with several
  providers to ensure a robust service.

Exchanging keys with a several providers who in turn must recognize and
sign messages for millions of customers using different keys is not
without its own risks.

The alternative to this absurdity would be to sign with a common
signature, ensure only validated 2822.From addresses are signed within a
protected domain, and let the millions of customers make an effort on
their own when needed.  This effort would allow the recognition of any
email-address operated under a domain controlled by the users.  This
effort could ensure their business associates, friends and family by
allowing their messages to be properly annotated as being from them.

This annotation process first validates signatures for addresses found
within the address book, and then annotates messages where either the i=
syntax or the 2822.From policy has assured the 2822.From address.  The
i= syntax should already indicate the provider has restricted use of the
2822.Form address.

The next step is to allow customers a means to request the use of other
email-addresses, signed under the provider's common domain.  This would
be no different than subscribing to a mailing list or obtaining an
email-address certificate.  Market forces alone will likely see that
this happens.

> My point is it isn't:  the point of responsibility is different for SSP

No.  DKIM may allow being able to uniquely recognizing a source within a
domain.  DKIM offers no means to prevent replay abuse.  Reputation based
upon signatures or keys won't work either.  DKIM does not offer a means
to prevent spam.  It is as simple as that.

DKIM does not offer a practical means to hold an email provider
accountable based solely upon the signature.  Providers who think DKIM
fulfills a dream where they no longer need to concern themselves about
the content of their networks are sadly mistaken. 

DKIM is a practical tool for reporting abuse.  DKIM is an excellent tool
for conveying assurances about the 2822.From domain.  The signing and
address domains do not need to match for this to be done safely.  In
fact, allowing these to differ is likely the ONLY practical and safe
solution where DKIM offers significant value.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 26 Aug 2006 14:54:04 +0200

Stephen Farrell wrote:

> But yet again, each form of delegation has its issues.

Right, but those forms where the delegator can delegate
without prior and explicit consent of the delegatee are
beyond my no-nonsense limit.  Ideally "explicit" should
allow receivers to verify this.

If an ISP uses a "we sign everything" strategy, and many
customers belong to botnets, then a "bad actor" could
register eboy (with an "O"), delegate eboy-signing to this
ISP unilaterally, and phish using his zombies with accounts
at this ISP.  SSP shouldn't allow this by design.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Sat, 26 Aug 2006 08:35:41 -0700

> at this ISP.  SSP shouldn't allow this by design.

A bad actor can register look-alike domains and added their own DKIM
signature sent through any number of providers. Designation does not
make this problem worse.  With the entire email-address being
internationalized, a problem of visual recognition must be handled
through other strategies. 

Imagine the MUA has several types of annotations added to messages with
DKIM's wonderful valid 2822.From address:

- In Address Book
- Matching Address/Signature Domains
- Certified by

Look-alikes might be handled by annotating messages with valid addresses
found in the address book.  Adding this mechanism allows the MUA to
safely recognize correspondents, independently from the domain that was
used to sign the message and still avoid the look-alike issue.

There can be different annotations that indicate when the signing domain
and the email-address domain match.  An organizing finding themselves
the subject of phish attacks should take this extra precaution.  Perhaps
policy adds a certification vector as well.

Designations help the small outfit.  Why deal with the negotiations and
specialized services?  There can still be safe annotation. It might not
look as impressive as that seen with the bigger outfits.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 26 Aug 2006 08:45:01 -0700 (PDT)

> reputation or accreditation information.

Not necessarily only that. Its just that 'd' is a verified identity
and so is good for building up reputation. SSP provides ability to
build additional verified identities (currently only identity being
talkied about is 'From'), so those verified identities after that
can also start to be used for reputation and accreditation - I
predict even more so then signature's 'd' because they are more
easily related to actual users of the system.

In light of above you'll find that all 3 of your questions have an
answer in "From" identity reputation and it will in work properly.
On the other hand its pure 'd' identity that ma have problems
especially as you alluded to in the 3rd question.

> just delegate signing to a new entity and "all is forgiven".

How is that different then just default use of DKIM?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Sat, 26 Aug 2006 09:26:56 -0700

> buck passing terms, we just don't know which signer signed.

I hope that we're not getting wrapped around the axle about this.
As Dave mentioned from our conversation, enrollment of public
keys as an alternative method doesn't suffer from this problem, but
is otherwise the same. That is, s/private/public/g.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 26 Aug 2006 09:18:47 -0700

>classify the material I have received.
DKIM base provides the ability for you to determine who's handle a message
in transit just by the fact that it accrues signatures from the domains 
it's passed
through who choose to sign. You don't need anything more to achieve what
you're asking for.

SSP goes beyond that and informs the receiver about the signing domains 
practices
which also allows you to potentially correlate what to expect from the 
author's domain.
Maybe the overall problem here is that we're conflating the information 
service of
SSP and the correlation that a receiver might want educe from that. 
Maybe we should say that
SSP is *only* about the practices information service of the *actual* 
domain in
question. From that standpoint, it doesn't make much sense for that 
domain to speak
of the practices of other domains -- that's their SSP record's job.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Sat, 26 Aug 2006 11:34:18 -0700

On Sat, 2006-08-26 at 09:18 -0700, Michael Thomas wrote:
> SSP goes beyond that and informs the receiver about the signing
> domains practices which also allows you to potentially correlate what
> to expect from the author's domain. Maybe the overall problem here is
> that we're conflating the information service of SSP and the
> correlation that a receiver might want educe from that. Maybe we
> should say that SSP is *only* about the practices information service
> of the *actual* domain in question. From that standpoint, it doesn't
> make much sense for that domain to speak of the practices of other
> domains -- that's their SSP record's job.

When policy is referenced only from the 2822.From domain, it should be
called DKIM From Signing Policy, or DFSP.  Perhaps there could be
policies referenced from other message elements.  

Going through the trouble of verifying the DKIM signatures leaves few
questions about the signing domain not better conveyed within the keys.
The greatest benefit to be obtained from any policy would be about the
2822.From address.  The most important piece of information to be
conveyed is whether this 2822.From address is assured to be valid.

Clearly this information does not risk damage to the integrity of the
signature as some have suggested.  Also, a list of domains that sign on
behalf of this domain does not represent a relationship other domains
may have with respect to their 2822.From addresses either, as you appear
to suggest.  This 2822.From policy, whether or not it includes a list of
domains, is _only_ about this 2822.From address and no others.

It doesn't make sense to preclude an ability for millions of users from
having an option of being able to associate their 2822.From domain with
that of a specific signing domain with whom they trust.  This process is
safe, easily scales, does not involve a routine exchange of keys along
with incumbent unique handling of messages.  When their trust is
misplaced, then only this domain's 2822.From address is affected, and no
others.

Like it or not, DKIM is about trust and conveying an assurance only
acted upon when the 2822.From address is trusted.  This trust is
automatically conveyed to the signing domain when the domains match. The
2822.From policy offers a means for this trust to extend to other
domains.

Imagine that _dfsp._domainkey.true-blue.com returned a DFSP record
a=IRON-CLAD-DKIM.COM.  This record conveys to the recipient that they
should not be surprised to find this domain signing their messages, but
also their 2822.From address is also assured to be valid.  If you don't
trust IRON-CLAD-DKIM.COM or the 2822.From address, then your choice as a
recipient is to not accept the messages or place it in low esteem.  The
only damage that might occur would be to the 2822.From domain that may
have misplaced their trust.

IRON-CLAD-DKIM.COM will need to ensure only validated 2822.From
addresses are signed, and that their domain is not used to send spam.
These two tasks offer mutual benefits to IRON-CLAD-DKIM.COM, and this
type of assurance adds significant value to their customers then able to
freely associate this domain with theirs.  The recipient of the message
now has twice the information upon which to weigh their trust.  That of
the 2822.From address AND that of the signer.  More is better.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 26 Aug 2006 21:52:42 -0400

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

> through other strategies.

What Frank is saying is the ISP.COM has all power to control this and
protect his users from direct DKIM phish attacks in a very elegant and
graceful manner using SSP.

Example:

The phisher uses eboy.com and creates a SSP policy (using a DSAP syntax):

DNS TXT:  _policy._domainkeys.eboy.com

     op=never;
     3p=always;
     3PL=isp.com;

The phisher has harvested hundreds or even thousands of users at ISP.COM and
he knows ISP.COM always signs mail.

The phisher sends mail to the ISP local users.  No SMTP authorization is
required because it is local mail (not routed).  That's BCP.

In the bare bone DKIM-BASE ISP implementation:

The ISP signs the message and delivers it to local users.  DKIM PHISHING
LOOPHOLE!

In the "not so smart" SSP Ready ISP implementation:

The ISP signer will check the From address SSP policy and it will see that
it is designated as an authorized signer.  It continues to sign and delivers
the mail to its local users.  DKIM PHISHING LOOPHOLE!

In the "Smarter" SSP Ready ISP implementation:

The ISP.COM should have his own list of domains the ISP will sign for to
check against.  The ISP will check the From address SSP policy and it will
see that it is designated as an authorized signer.  However, if EBOY.COM is
not in the ISP list of domains he is signing for, then it should not accept
this message or see it as suspicious.  DKIM Phishing Problem Solved!!  The
ISP's users are protected and EBAY is indirectly protected too.

To maximize protection all 3rd party signers should check the originating
domain SSP policy to see if it is allowed to sign.

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

---

From: [email-masked] (Wietse Venema)
Date: Sat, 26 Aug 2006 22:29:37 -0400 (EDT)

> graceful manner using SSP.

None of these loopholes would exist if d= domains were required to
match rfc822.from domains (*). Third party signatures are part of
the problem. Making them "work right" requires additional complexity.
Complexity leads to error, vulnerability and exploitation.

	Wietse

(*) This is possible even when the signer is in a different domain.
    All they need is the private key that matches the public key
    in the d= DNS record. That record can, but does not have to,
    be CNAME delegated to the signer's DNS.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sat, 26 Aug 2006 20:07:50 -0700

On Sat, 2006-08-26 at 21:52 -0400, Hector Santos wrote:

> The phisher has harvested hundreds or even thousands of users at
> ISP.COM and he knows ISP.COM always signs mail.
> 
> The phisher sends mail to the ISP local users.  No SMTP authorization
> is required because it is local mail (not routed).  That's BCP.

Not when 2822.From i=syntax of the 2822.From being valid one would hope.
This would be a bad practice from the standpoint of security.

> The ISP signs the message and delivers it to local users.  DKIM
> PHISHING LOOPHOLE!

Unfortunately that "loophole" exists in many forms.

 - A signature added by the sender that should not be removed according
   to the base draft.

 - A message signed by ISP.com that still has the audacity to allow
   users a choice of 2822.From email-addresses.

 - A message sent directly from a compromised system somewhere.

DKIM offer no protection without annotations.  DKIM Designation should
be annotated differently than messages where the 2822.From address and
the signing domain match.  Add to that strategy an annotation when the
valid 2822.From addresses also seen in the address book.  These two
steps can comprehensively defeat most phishing attacks that use
look-alike domains.  The problem of look-alikes will only grow worse and
is not prevented by taking away everyone's freedom.

> The ISP.COM should have his own list of domains the ISP will sign for
> to check against.  The ISP will check the From address SSP policy and
> it will see that it is designated as an authorized signer.  However,
> if EBOY.COM is not in the ISP list of domains he is signing for, then
> it should not accept this message or see it as suspicious.  DKIM
> Phishing Problem Solved!!  The ISP's users are protected and EBAY is
> indirectly protected too.

An option should be added to DKIM aimed directly at conveying whether
the ISP has validated the 2822.From address. One might assume this
process also applies a block-list of known problem addresses as a best
practice.  Unfortunately this validation can not be conveyed when the
2822.From domain is not within that of the signing domain.  This is a
security flaw.  An assurance of having validated an address out of the
signing domain improves security.  It would also be useful at better
encouraging this desired mode of operation.  Good idea, but it needs a
way to indicate when this verification has happened.

> To maximize protection all 3rd party signers should check the
> originating domain SSP policy to see if it is allowed to sign.

Sorry, many ISPs may decide to ignore DKIM altogether. There are still
other modes where a look-alike attack with DKIM remains viable.  The
solution is to ensure the 2822.From _always_ offers an assurance of
being valid, and that this address is also found in the address book.
This could be strengthened by also indicating when the signing domain
has validated the 2822.From without reliance upon the self limited
i=syntax.

Perhaps the i= syntax should be revisited or something.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Sat, 26 Aug 2006 23:16:22 -0400 (EDT)

> > graceful manner using SSP.

Apologies. Let me phrase this better.

None of these loopholes would exist if signatures could vouch only
for rfc822.from domains that match the signature's d= domain (*).
Third party signatures are part of the problem. Making them "work
right" requires additional complexity.  Complexity leads to error,
vulnerability and exploitation.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Sat, 26 Aug 2006 20:23:12 -0700

> Complexity leads to error, vulnerability and exploitation.

No. Look-alike exploits exist without designated domains.

Any protection from a look-alike attack requires annotation that
indicates when the 2822.From address has been assured as being valid,
and when this address is also in the address book.  Increasing the
number of situation where 2822.From address validation is conveyed
improves the protections afforded by DKIM.

This is a specious argument against designated domains.  The MUA or the
ISP can decide not to offer any annotation related to 2822.From policy
related assurances when they think it is unsafe.  Seldom does less
information improve security however.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 27 Aug 2006 00:25:49 -0400

From: "Wietse Venema"

> vulnerability and exploitation.

Wietse, you won't find me arguing this point! :-) That's been my position
for the past 18+ months (*).

Now we just need convince everyone else who is bent on allowing open ended
3rd party signatures (2822.From != signing domain).  If we allow them, then
we just can't ignore the exploitation. We need would some "kind" of control.

The basic idea is that DKIM should first concentrate on protecting the
author domain owner of the message.  Nothing should alter this protection.

Acknowledging the extra integration design issues (but not necessarily
overly complex and impossible) to get it "right," I had proposed at the
beginning of this new round of SSP discussions a consideration to punt on
3rd party signatures and concentrate on the more important 1st party
signature concepts where the biggest benefits are achieved.  Then, if
possible, work in 3rd party signatures in the future.

    How to proceed with SSP
    http://mipassoc.org/pipermail/ietf-dkim/2006q3/004464.html

In my opinion, this will serve the techical selling and marketing of this
very promising DKIM technology.  We can not shoot of the gate with thorns on
our side. Ignoring the concerns now is not going to make it go away.

PS: Concentrating on 1st party signatures protection will massively improve
DKIM-BASE itself.  And this should not exclude the teriary "Black Box" DKIM
Appliance business market that is expected to emerge.  They just have to
assume more 1st party signing behavior.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 27 Aug 2006 08:20:46 +0200

Douglas Otis wrote:

> DKIM offer no protection without annotations.  DKIM
> Designation should be annotated differently than messages
> where the 2822.From address and the signing domain match.

Do we already have this in the requirements ?  At some point
you could probably say that it's "obvious", but documenting
it explicitly is clearer.

> The problem of look-alikes will only grow worse and is not
> prevented by taking away everyone's freedom.

Some of them are receivers, we want a common subset of DKIM
functions working similarly for receivers supporting SSP, and
others not supporting SSP.  Unilateral delegation is odd.

John's comparison with a Turing-complete path registration
scheme comes to mind:  Limited to at most 10 lookups it's in
practice harmless, and limited to CIDRs + mx (without colon)
+ a (without colon) + include + all it would be perfect.

But as soon as folks are forced to "emulate include" (because
the relevant ISP has no policy) things start to get messy as
far as that's possible within the overall limits.  "Emulate
include" (SPF) is very near to "unilateral delegation" (SSP).

 [...]
> One might assume this process also applies a block-list of
> known problem addresses as a best practice.

The dnsbl draft is in limbo at the moment, from an "IETF last
call" POV block-lists might not exist "officially".  Maybe we
could adopt the ASRG draft and publish it as DKIM document (?)

> Sorry, many ISPs may decide to ignore DKIM altogether.

No problem, a minor point in the security considerations of an
authentication header field RFC.  MUAs might need to know what
they get.

> Perhaps the i= syntax should be revisited or something.

The i= syntax is apparently fine, unless you want a mandatory
local-part with default postmaster (?).  The i= semantics is
less clear.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 27 Aug 2006 08:35:51 +0200

Douglas Otis wrote:

> Look-alike exploits exist without designated domains.

Sure, but they sail under their own look alike flag.  They can't
"steal" the reputation of an ISP with millions of zombies for
their criminal purposes.  Admittedly that reputation won't be
good, but still better than "eboy" = "unknown stranger".

> Seldom does less information improve security however.

Make sure that "eboy" is treated as the "unknown stranger" it
is, even if isp.example.com signed it, and there's no problem.
An eboy-SSP trying to change this should be ignored.

Frank

---

From: Damon <[email-masked]>
Date: Sun, 27 Aug 2006 06:50:11 -0400

> good, but still better than "eboy" = "unknown stranger".

How is this any different than what we are doing with reputation
systems based on IP right now?

> An eboy-SSP trying to change this should be ignored.
Basing reputation on key provider wouldn't be prudent. If I were a
less than honorable person, I would send all my spam using someone
with a good reputation (goodrep.com) as my DSD. My sig fails because I
purposely munged it, there is no policy saying that this should
definitely be rejected. Because goodrep.com can not publish all of the
domains that it signs for, it is helpless to do anything about this.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Sun, 27 Aug 2006 05:04:42 -0700

> others not supporting SSP.  Unilateral delegation is odd.

The word designation was used for a reason. This is not taking anything
away the authority of the signing domain, nor is this being done
unilaterally from the perspective of the 2822.From address domain.  A
domain designation does not impact the signature at all.  A designated
domain may affect the message's annotation or refusal when this permits
more aggressive exclusivity assertions.  In other words, the 2822.From
domain is better protected from fraud when they prefer for economic or
convenience considerations to allow someone else to sign their messages.

> + a (without colon) + include + all it would be perfect.

You should review a draft where this assumption was tested.
http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt

Unfortunately, many of the libraries neglect applying even the suggested
limitations, and a notable exception where a reduced limit causes
unpredictable results for some domains.

The straw-man proposal regarding the designation concept is at:

http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-dfsp-00.txt

You should note that of the three flags, only two will likely ever be
used at a point in time.  There are two categories of listed domains.

a= lists domains where the 2822.From address is assured.
d= lists domains where the 2822.From address is not assured.

Either of these lists could be infinitely extended by using a single
query in the form:

<signing-domain>._policy-labels.<from-domain>

The latter d= list might be used to to mitigate some of the damage
occurring from an assertion of all messages being signed where specific
exceptions are desired. 

> include" (SPF) is very near to "unilateral delegation" (SSP).

A far safer approach to emulate an SPF mechanism would be to use the
same approach as suggested for the designated domain.  The query would
be:

<ehlo-domain>._policy-labels.<mail_from-domain>

> could adopt the ASRG draft and publish it as DKIM document (?)

There is ongoing work to provide this service.

> local-part with default postmaster (?).  The i= semantics is

There are alternatives to using i=syntax.  This could be some added
parameter added to both the key and the signature field making a rather
simple assertion:

 2822.From address is assured valid.

This would provide clearer semantics and overcome i= syntax limitations
regarding outside domains.

Wietse's concerns with non-matching signatures is solved by treating the
a= list as a d= list member and thereby avoid resulting annotations.
Two distinct annotations would be the preferred solution, however.

Those advocating DKIM should not expect all 2822.From domains will be
signed by the same domain, whether from a mailing-list or a large ISP.
Allow designations to say "this is really still me".  Or perhaps "I use
this domain."  

The use of a d= list is not very ideal, where an a= list offers
information valuable to the recipient.  This removes the need to ask,
"Is this your new signing domain?" 

The issue of reputation is out of scope, but is getting reviewed as a
concern that by adding information, this makes assessing who the actors
are more difficult.  Only the signer identity can be verified, and only
the signer can safely be held accountable. Simple.  Just as a provider
may allow their users to use their own email-address going through their
service, a designated domain represents an exact analogy to this
freedom.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sun, 27 Aug 2006 05:18:09 -0700

> systems based on IP right now?

There seems to be some concern about accountability either shifting or
not shifting to the designated domain.  As this domain can not be
verified, this shift should not occur.  Any annotations being placed
upon a DKIM message should indicate two things at least.

- Signing/From Domains Match
- Valid Address is in Address Book

> domains that it signs for, it is helpless to do anything about this.

Only the signing domain can be safely held accountable. ISPs are being
used to send spam and DKIM does not change this problem.  A DKIM
signature does enable better noise-free reporting to help address the
issue.  The provider must still disable abusive accounts as they are
reported. Companies offer a free scrub for their customers when they are
infected.

The provider still must be diligent.  DKIM helps from the reporting
side.  The 2822.From can not be held accountable as it can not be
verified as being culpable.  A designated domain involves trusting the
signing domain.  Trust alone can not be defended with respect to
reputation.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 27 Aug 2006 14:16:49 +0200

Damon wrote:

> How is this any different than what we are doing with
> reputation systems based on IP right now?

Maybe I'm only confused.  But apparently we have two groups
here, some interested in "DKIM pure" without SSP, and others
interested in DKIM + SSP.

A "DKIM pure" signer talking with an "SSP aware" verifier (or
vice versa) should still work, no matter what the SSP of the
2822-From domain says.

> If I were a less than honorable person, I would send all my
> spam using someone with a good reputation (goodrep.com) as my
> DSD. My sig fails because I purposely munged it, there is no
> policy saying that this should definitely be rejected.
> Because goodrep.com can not publish all of the domains that
> it signs for, it is helpless to do anything about this.

Yes.  In theory goodrep can check your SSP, but a "DKIM pure"
signer might not like this.  Somebody proposed off list, that
goodrep should have a list of 2822-From domains it signs.  I'm
not sure about this, is it acceptable for "DKIM pure" signers ?

There is no procedure in 4409 for "check the 2822-From", it
only offers a "MAY add Sender" option.  Should signers "know"
what they are signing - beyond their "normal" authentication ?
The "MAY add Sender" option is already far from "normal", as
far as I can judge it (i.e. based on about five MSAs :-)

Frank

---

From: Damon <[email-masked]>
Date: Sun, 27 Aug 2006 08:27:59 -0400

> signing domain.  Trust alone can not be defended with respect to

Doug,

I am in agreement with you 99% of the time... here is my 1% :)
> "The provider still must be diligent."
IMO and extensive experience, some of the largest are not diligent at
all... not because they don't want to be... but because they are
understaffed, underfunded, and underpaid. If diligence is any sort of
hinge pin, I don't expect it to be successful.

Regards,
Damon Sauer

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 27 Aug 2006 16:51:19 +0200

> You should review a draft where this assumption was tested.

Yes, I looked briefly into it, as you might recall, working
under a "no original research" doctrine can be hilarious ;-)

> straw-man proposal regarding the designation concept is at:

What exactly means "strawman" ?  Looking shortly into it:  an
example or two with an a= vs. d= explanation would help.  I'm
no fan of n= constructs, nobody will read this.

Maybe use <ANY> instead of <WC>, a matter of taste, it didn't 
take me long to find out that it stands for "wildcard".  I've
some difficulties to parse 3.3 and 3.4, anything else is clear.

The A:O and N parts are fine, that's IMO a useful minimum of
flags, with Hector's proposal as maximum.  I can't tell if
anything critical is missing, you have the f=A a= d= case (if
that's how an empty list is supposed to be defined).

Hector proposed to focus on first party signatures.  That
reduces his 1+3*3 to 1+3 cases, and apparently you also have
1+3, where your "1" is the f=A a= d=.

With semicolon as separator I'd stay away from comma or colon
as secondary separator if plus is available, but probably you
want the same look and feel as in base.

> d= lists domains where the 2822.From address is not assured.

What's "assured" ?  With a mail 2822-From: [email-masked]
I'd try to get the DFSP of user.isp.example, and then what ?
Or is that already a bad idea for all PRA != 2822-From cases ?

BTW, I'd be surprised if IANA offers to reserve domain labels.
Actually I'd ask them if they're mad if they try to pull this.

You'd need a trick like 7.4 in "base", bind a IANA registry to
_dfsp TXT.  With that everybody is still free to use _dfsp for
other purposes (and if that doesn't work it's her/his problem).

The only reserved domain labels I'm aware of are noted in 2016,
three example SLDs under the cno TLDs, and four TLDs.  And of
course some syntactical classes like "--" as third and fourth
character.  You can't "reserve" _dfsp everywhere.

> <signing-domain>._policy-labels.<from-domain>

At some point you'd meet a critical 253, where you'd need some
compression / truncation tricks.

> <ehlo-domain>._policy-labels.<mail_from-domain>

Nice idea, where it fits into the 253 limit.  It would force
folks to organize their "include emulation" in a reasonable
way, and it limits unnecessary queries for an unrelated ehlo.

Unfortunately three years too late for the existing versions.
If ISPs offer an includable neutral record passing for their
infrastructure it's no issue, and if they don't do this and
their users try to guess they'll find out what happens next -
unhappy users getting their "include emulation" wrong, likely.

> There are alternatives to using i=syntax.  This could be some
> added parameter added to both the key and the signature field
> making a rather simple assertion:

> This would provide clearer semantics and overcome i= syntax 
> limitations regarding outside domains.

If that's the case make it so, I didn't follow all discussions
about i=.
 
> Those advocating DKIM should not expect all 2822.From domains
> will be signed by the same domain

For PRA != 2822-From cases that's anyway impossible, from the 
old Sender: secy@ example up to Resent-* cases, plus some more 
interesting gateway cases.
 
> Only the signer identity can be verified, and only the signer
> can safely be held accountable. Simple.

Well, folks wanting some kind of DFSP might also want that some
mails claiming to be 2822-From them are rejected.  I can't tell
how that's supposed to work for PRA != From, "not at all" would
be okay.

I've not yet got the essence of your proposal, the a= and d=
lists.  Add some examples please, if it gets too long shrink
chapters 1 and 2.

Frank

---

From: John Levine <[email-masked]>
Date: 27 Aug 2006 15:41:55 -0000

>Third party signatures are part of the problem.

Actually, I think the problem is that people want to read way too much
meaning into a DKIM signature.  If a message is signed by blah.com,
all that means is "if you don't like this message, blame blah.com."
That's it.  Despite quite a lot of loud wishful thinking from people
in my killfile, it doesn't mean anything about the accuracy or lack
thereof of various header lines, the path the message took, the
spamminness of the message, the worth of other signatures that might
be present, or anything else.  

This is an important deliberate design decision.  In my case, for
example, I expect to sign all the outgoing mail at my MTA with my main
domain, even though I have users who send mail in about 200 vanity and
small biz domains.  So long as my users behave, which they do, there
is no point to trying to match up signatures with From: lines and the
effort to do so would be so great that I wouldn't, anyway.  There is
enough info in the messages for me to tell who sent a particular
message (user names, time stamps, etc.), even though it might not be
possible for a random recipient to do so.  I think this is a microcosm
of the situation at most ISPs.

A topic we've been dancing around but never really faced is what extra
semantics if any there are if a signature's d= matches the From line.
I don't think there are any, but I see a lot of people who seem to
think that it means the entire From: address is correct, for some
definition of correct.

Finally, don't forget that recipients have great latitude in their
interpretation of DKIM signatures.  If you don't think that third
party signatures tell you anything useful, you can always ignore them.

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 27 Aug 2006 12:34:29 -0400

----- Original Message -----
From: "John Levine" <[email-masked]>
To: "Wietse Venema" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 27, 2006 11:41 AM
Subject: Re: [ietf-dkim] Re: Responsibility concerns with
DesignatedSigningDomains

> Actually, I think the problem is that people want to read
> way too much meaning into a DKIM signature.  If a message
> is signed by blah.com, all that means is "if you don't
> like this message, blame blah.com." That's it.  Despite
> quite a lot of loud wishful thinking from people in my killfile,
> ....

You know John, your mail would be so more delightful and interesting to
read, as was this one, with valid points, if such ignorant and nonsense
statements was kept to yourself.

> This is an important deliberate design decision.  In my case,
> for example, I expect to sign all the outgoing mail at my MTA
> with my main domain, even though I have users who send mail in
> about 200 vanity and small biz domains.  So long as my users
> behave, which they do, there is no point to trying to match
> up signatures with From: lines and the effort to do so would
> be so great that I wouldn't, anyway.

Fair enough.

But consider this:

The evolving bad actor will now know the existence of DKIM ready John.com
and like systems out there. They will know they have a way to blast mail
with a higher phishing confidence in attacks against other remote systems
around the world using your domains and user email addresses information.

Example: A phish/spoof to OTHER systems, not from your users or system.

  From: User @ ChezJohn.com
  To: PoorShmuck @ PhishingTarget.com
  Subject: Some enticing topic
  Sender: Joel @ TrustMe.com
  DKIM-Signature: d=John.com;    # fake/invalid 1st party
  DKIM-Signature: d=TrustMe.com  # valid 3rd party

So it is not just about *you* and how well behave your social network or
users are, but how bad actors very easilly begin to use *you* to exploit
others.

> Finally, don't forget that recipients have great latitude in
> their interpretation of DKIM signatures.  If you don't think
> that third party signatures tell you anything useful, you
> can always ignore them.

That's very true.  DKIM MUA Market will have a role. We have it planned to
update our Mail Readers to support DKIM too.

But so will the DKIM SMTP market have a major role too as the centralized
source for its user network.

The clear direction in the security market is to be more proactive in
preempting malicious behavior (default OFF).  Passing the buck to the user
has been shown to not work very well.  Of course, with smarter readers, it
will help.  But we can't assume the market of users, especially those
outside your own social network, will be using the required special DKIM
MUA.

---

From: [email-masked] (Wietse Venema)
Date: Sun, 27 Aug 2006 12:57:53 -0400 (EDT)

> we just can't ignore the exploitation. We need would some "kind" of control.

Thanks for the opportunity to explain my point more clearly.

By themselves, nothing is wrong with third-party (i.e.  2822.From
domain != d= domain) signatures.  The problem is the mistaken belief
that signatures make statements about 2822.From addresses.  This
leads to complexities such as "what domain can sign my mail".  Your
"control" is a solution for a problem that doesn't need not exist.

Even in the case of a first-party signature (2822.From matches d=
domain), the 2822.From is not of primary importance. It is the
signing domain that comes first; the signature is the basis of any
rating that one might assign to an email message.

I favor first-party signatures mainly because they avoid reputation
cross-talk: when an ISP uses the same shared signing domain for
multiple author domains, bad actors can negatively affect the email
reputation of innocent author domains. With first-party signatures
the damage would be more confined to the bad actor's author domains.

Both first-party and shared-party signature approaches present
scalability challenges.  With first-party signatures, there is a
technical problem of deciding what signing domain and key to use.
With shared-party signatures, there is a non-technical problem of
preventing bad actors from messing up everyone elses reputation.
As a technical person, I prefer to tackle the technical problem.

	Wietse

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 27 Aug 2006 11:55:13 -0400

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>

> interested in DKIM + SSP.

Yes, but I think overall it comes down to about unrestricted (uncontrolled)
vs. restricted (controlled) 3rd party signatures.  SSP would be the proposed
way to control them.

I believe this was one, if not the main, contention which started with the
terminology I used of "Exclusive" for the o=! SSP-01 in Section 5:

  !  All mail from the entity is signed; Third-Party signatures
     SHOULD NOT be accepted.

I called that "exclusive" policy and the debate and deep division started
over what that really means and the idea of allowing 3rd party signatures
EVEN if you ignore them.

My argument was that the "existence" of a 3PS, even if you ignore it,
possible represents "bad" events that was not expected by the domain.

One school of thought was that if the OA signed his mail, it shouldn't be a
security problem if there were hops who blindly signed as 3rd party
entities.  That was John's main point.

I agreed that as long there is a valid OA signature was present, it should
lower security concerns when you have 3rd party signatures.  But what if the
mail integrity was destroyed and the OA signature is no longer valid?  Is
this security still intact?

This is why I have a problem with the DKIM-BASE logic that says:

    Only one valid signature is required in a multiple
    signature message.

And when you couple this with the other DKIM-BASE mandate:

    Ignore failed signatures

you have a huge spectrum of potential issues when trying to make sense out
of all this.   This opened a security threat where phishers can throw in a
fake OA DKIM-Signature that he knows will fail, but then sign as an
unrestricted 3rd party:

    Subject: Check your account
    Date: Sun, 27 Aug 2006 05:04:42 -0700
    From: [email-masked]
    To:  [email-masked]
    Sender: [email-masked]
    DKIM-Signature: d=bank.com     # invalid 1st party
    DKIM-Signature: d=asp.com...   # valid 3rd party

According to DKIM-BASE, the valid 3PS signature would make this an valid
DKIM message, even if the 1st party signature failed.

Anyway, DKIM-BASE intentionally leaves much of this to local policy.

My point is that with SSP, bank.com can at very least should be allowed to
optional declare a signing policy indicated whether it allows or not asp.com
or anyone to sign mail on its behalf.

I think Mike, Dave and others do support or 'understand' the need for some a
few basic general policies like SIGN or NO SIGN, but it is the unrestricted
vs. restricted 3rd party signatures that we mostly differ at.  Atleast that
is how I see where the disagreement lies.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Aug 2006 10:27:06 -0700

Wietse Venema wrote:
> that signatures make statements about 2822.From addresses.  
...
> reputation of innocent author domains. 

We are not going to fix mistaken beliefs with technical constraints.

If d= != rfc2822.From domain, then assessment software needs to treat the d=
value on the assumption that -- big surprise -- the message was not signed by
the author's ADMD.  That does not make the d= value useless, merely different.

It is fine for an assessment engine to treat a case of both names being equal
(or directly related) in a special way, whatever that way might be.  However
this, really, is a decision to be made by the assessment engine.

If an ISP has mail from different sources that it might sign, it needs to
determine whether it wants a single reputation based on the aggregate mail from
all those sources, or whether it wants finer-grained reputation information
maintained.  The easiest way to do that is to use sub-domains that it signs for,
or to do no signing (or sign only for the domains it has vetted, or...).

Most of the various discussions about SSP choices seem to believe that this
realm is easily defined and controlled. It ain't.  In particular, statements
about how practices information is going to get used are seriously lacking in
basis. We need to refrain from adding features that have speculative benefit,
because it is expensive and risky to add features.

Once again:  We need to define a basic publishing mechanism and the smallest
number of practices to publish, for which there is very strong and very broad
agreement.  Anything that is controversial needs to be deferred.

I believe we have strong and broad agreement that it would be useful to publish
"I sign everything".  This is of basic benefit, when receiving a message that is
not signed.

I believe we do not have strong or broad agreement on any other features.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 27 Aug 2006 14:22:41 -0400

----- Original Message -----
From: "Wietse Venema" <[email-masked]>
To: <[email-masked]>

> The problem is the mistaken belief that signatures make
> statements about 2822.From addresses.

Wietse,

There a strong statement stated in the DKIM-BASE introductory goal:

   The ultimate goal of this framework is to permit a
   signing domain to assert responsibility for a message,
   thus  protecting message signer identity and the
   integrity of the messages they convey while retaining
   the functionality of Internet email as it is known today.
   Protection of email identity may assist in the global
   control of "spam" and "phishing".

An even more detail strong statement is stated in DKIM-BASE section 5.4
where it clearly mandates the hashing the 2822.From: header field:

   The From header field MUST be signed (that is, included in the h= tag
   of the resulting DKIM-Signature header field). Signers SHOULD NOT
   sign an existing header field likely to be legitimately modified or
   removed in transit.

In the real world, no one expects the 2822.FROM: to be modified in transit.
It would be considered a taboo to do so.

And in the same section, it provides informative insight as to what headers
should be considered and why. We can summized it as:

   - Persistent Headers
   - Best Practice for Presentation
   - Well known

In general, these are headers that typically common among all applications
and including across mail gateways.  You can't go wrong with a bare minimum:

    From:
    To:
    Subject:
    Date:
    [body]

So I am not sure why it is a mistaken belief to view DKIM as a Digital
Message Signature technology and protocol that attempts to make a strong
statement of assuring mail integrity by protecting the originating mail
author, its domain, its mail content from potential harm and abuse.

After all, what is the purpose of DKIM?

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Aug 2006 13:31:14 -0700

offlist.

Wietse Venema wrote:
> Thanks for asking. The purpose of DKIM is to trace back signed mail
> to signing parties.
> 
> For example, suppose that you have confidence in your bank's DKIM
> signature.  Then you can use it to distinguish between mail from
> the bank, and phishing mail that pretends to be.  Note that it does
> not matter what their rfc822.from says.  It's the bank's DKIM
> signature that forms the primary basis for trust.
> 
> Another example: suppose that I receive mail from a mailing list.
> I trust the list server's DKIM signature, so I can distinguish
> between mail from the list server and mail that pretends to be.
> Again, note that it does not matter what their rfc822.from says.
> It's the list server's DKIM signature that forms the primary basis
> for trust.
> 
> With first-party signatures, things simplify conceptually and
> technically to the point of elegance. This is one reason why I
> express preference for first-party signatures. But even in this
> special case, it is the DKIM signature that forms the primary 
> basis for trust. The rfc822.from is secondary.

Nicely stated.

d/

-- 

  Dave Crocker

---

From: [email-masked] (Wietse Venema)
Date: Sun, 27 Aug 2006 15:24:13 -0400 (EDT)

...
> author, its domain, its mail content from potential harm and abuse.

First, I trimmed a log of your reply, because I would not limit a
discussion of DKIM usefulness to just the popular email exploit of
the day (phishing).

Allow me to get back to basics. Stated in simple terms, if a DKIM
signature verifies, then the verifier knows two things:

 1) The hash was signed by the purported signing party. This means
    that the verifier can trace the message back to the signing party.

 2) The inputs to the hash were not modified. Specifically, some
    malicious or non-malicious party didn't modify the inputs at
    some later point in time.

If mail doesn't have a valid signature, then the none of the above
assurances exist. The mail may be authentic but some munging broke
the DKIM seal, or it may be non-authentic (phishing etc). The
verifier can not make a definitive statement about this. SSPs
notwithstanding, because SSPs don't handle email munging.

	Wietse

---

From: <[email-masked]>
Date: Sun, 27 Aug 2006 18:14:25 -0400

Onlist +1

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 Dave Crocker
Sent: Sunday, August 27, 2006 4:31 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Re: Responsibilityconcerns
withDesignatedSigningDomains

offlist.

Nicely stated.

d/

-- 

  Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 28 Aug 2006 00:25:50 +0200

[...]
> According to DKIM-BASE, the valid 3PS signature would make
> this an valid DKIM message, even if the 1st party signature
> failed.

As far as asp.com is concerned it is valid, no hops between you
and them manipulated the mail.  Maybe one of their users got a
legit mail from bank.com and forwarded it to his mailbox behind
your MX - but then I'd expect to see a Resent-From or similar.

So from your POV it's invalid if the bank.com SSP says so, and
if you didn't forget to mention an important header field.  But
your user might have arranged his forwarding via a munger, then
it's the known SPF problem.

> it is the unrestricted vs. restricted 3rd party signatures
> that we mostly differ at.  Atleast that is how I see where
> the disagreement lies.

It can be both correct:  Let's take a realistic example, GMail
starts to offer forwarding, but adds some ads plus their own
signature, destroying the signature of bank.com.  If we have
a couple of "MUST reject" and implementations actually doing
this they might give up.  Something has to give, bank.com, the
munger, the verifier, or the user.

With mail I expect the worst, the crap is dumped with a big
red "fishy" icon into the mailbox of the unhappy user.  The
user will delete it unread, bank.com will give up its SSP,
the verifier gives up to use DKIM... tell me why I'm wrong.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Sun, 27 Aug 2006 17:44:42 -0700

> the verifier gives up to use DKIM... tell me why I'm wrong.

I agree with you on this point. A message signed by Gmail can't be
accepted on the basis their signature.  Gmail has the same problems
plaguing any large domain.  Some other acceptance criteria must be used
which makes DKIM fairly useless should a limited assurance of a
signature via policy be the only benefit. 

Dave Crocker suggests policy be limited to "I sign everything" without
any other clarification.  Is this domain a phishing target where they
are willing to forgo services and suffer delivery issues?  Otherwise
this assertion allows bad actors to simulate situations causing
signature damage to gain acceptance.

This limited policy does not offer a piece of information related to the
handling of their signature.  "I do not utilize non-complaint services
that damage the signature."  With that piece of information, a solution
for an extremely small percentage of domains seeking protection from a
phishing problem is promised.  But this is a false promise.

As other have pointed out, look-alike and cousin domains breeze past
this mechanism as if it were not there.  Delivery problems continue and
phishing will become even more convincing.  Hardly a good choice for
anyone under attack to have made.  : (

There is a different strategy that should work without suffering the
same delivery issues and yet defeat look-alike attempts.  While
accountability starts at the DKIM signature, trust starts at the
2822.From address.  The DKIM signature MUST provide extremely clear
semantics regarding an assurance of the 2822.From address being valid.
After all, people will not even see the signature in most cases, and it
could be a look-alike even if they did.

Before an MUA even attempts to ascertain the validity of the signature,
the signature MUST provide an assurance the 2822.From address is valid.
Otherwise, the recipient should ignore the signature as completely
meaningless.  When the 2822.Form address is assured valid by the signing
domain AND this address is also in the address book, then verify the
validity of the signature.  There is no reason these assurances need to
be limited to just email-addresses within the same domain.  The DKIM
signature can easily play the role of an email-certificate.

Trust starts at the 2822.From address where the signing domain must be
associated with the 2822.From address for the signing domain to be
trusted.  There MUST be an assurance that the 2822.From is valid as well
before anything can be trusted at all.  With this strategy, there is no
need to indicate whether all messages are signed for the sender and the
recipient to obtain a safe and tangible benefit.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Sun, 27 Aug 2006 21:39:36 -0400 (EDT)

> munger, the verifier, or the user.

When mail has a valid bank DKIM signature we have assurance that
it was sent by the bank. The rfc2822.from is of minor relevance,
because we already know from the DKIM signature that it was sent
by the bank.

When mail has a valid gmail.com DKIM signature, but no valid bank
signature, then all we know is that it came via gmail. Whatever is
in rfc2822.from is merely hearsay and should be treated as such.
There is no reason to delete the mail.

The problem that you refer to is due to the mistaken belief that
DKIM signatures imply anything about rfc2822.from addresses. We
can eliminate the problem by simply taking DKIM signatures for what
they actually are: proof about the identity of the signing party,
not proof about the identity of the author.        =============

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Sun, 27 Aug 2006 21:31:39 -0700

> because we already know from the DKIM signature that it was sent

Without an assurance of the 2822.From, one does not know who within the
signing domain authored the message.  This would be true for any domain,
where one must not assume an entire signing domain represents a
trustworthy entity.  Very few will.  Therefore DKIM should develop a
strategy that provides a benefit when not everyone in the domain is
trustworthy.  Trust therefore MUST start at the 2822.From address.  The
signature MUST also convey whether the 2822.From address has been
validated.  Without this assurance, the DKIM signature is practically
worthless.

> There is no reason to delete the mail.

There is no reason to verify the DKIM signature when the 2822.From
address is not assured. When the 2822.From address is not assured, there
is no assurance who sent the message. The recipient should not assume
this signature offers any protection, nor should there be any annotation
that indicates the signature is valid.  Annotation should only indicate
the 2822.From address is assured valid AND the signature verifies. 

> not proof about the identity of the author.

If someone decides they can trust the 2822.From address, this trust can
be extended to that of signature, but only when the signature itself
indicates the 2822.From address has been validated.  Otherwise, there is
no way any trust can extend to the signature, and there would be no
significant value obtained verifying the signature.  If anything, this
would be wasted cycles that could leak information and ultimately
mislead the recipient.

Any DKIM message can be replayed, there are look-alike signing domains,
and not everyone within a signing domain should be considered
trustworthy.  Also the To header is often an alias of some bulk list.
The factors needed for security are:

 - a signature assured 2822.From address
 - the DKIM signature associated with the 2822.From address
   (by being within the 2822.From domain or via policy)
 - presences of the valid 2822.From address in the address book

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Aug 2006 06:10:49 -0400

----- Original Message -----

> DKIM signatures imply anything about rfc2822.from addresses.

You keep saying that its a mistaken belief.  Yet, DKIM-BASE is filled with
sorts of implications about the x822.From address.  See section 5.4.

> We can eliminate the problem by simply taking DKIM signatures for what

Now that is a mistaken belief that the problem will go away. :-)

It is an implied proof about the identity of the author via the validation
of the signature.  What you are basically suggestion is that you shouldn't
TRUST the From field.  That's a difference mindset that will required
special batteries!

However, I think the overall mistake is not seriously taken into account
failure analysis.  I think it is also a mistake to presume all receivers are
going take on unnecessary overhead where there is little payoff.  And I
think it is a HUGE mistake to believe the general public is just going to
accept your (and Dave's) vague explanation of what DKIM is really all about.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Aug 2006 06:35:21 -0400

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>

> it's the known SPF problem.

Correct. How the verifier will address it can be various ways, including
SPF.

In the general sense Frank, in a DKIM only would, it is failure analysis and
protocol consistency.

Sherlock Holmes now has more evidence to work with when there is a DKIM
"fingerprints" and DNA available.  Checking SSP concept would easily solve
this for bank.com simply because it may not be expecting 3rd party
signatures - very simple or asp.com to be the signer.

Hmmmm, maybe we have a compromise here with a special policy?

    "I don't care if 3rd party exist, I don't want them, but
     if they DO exist, it BETTER not destroy my 1st party
     signature."

Its about keeping the *purpose* of the Digital Message Signature Alive - the
survivability.  If a domain does not have control of the transport hops and
who can sign, can it atleast say:

    "If you going to stick your fingers into this, then you better
     do it right.  Don't destroy my signature."

Sounds like we are heading into the same RELAXED issues of SPF and the
debates of needed SRS and the arguments of who (forwaring mta) is at fault.
The problem with SRS (in my view) is that it required a change to the SMTP
process.

With SSP for DKIM, I think it is natural part of the protocol - Signature
Authorization.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Aug 2006 11:56:27 +0100

> sorts of implications about the x822.From address.  See section 5.4.

I'd have to agree with Wietse's interpretation here. Anything you
infer about the rfc2822.from is something you're doing after (or
in parallel with, whatever) DKIM-base processing.

And I don't accept that this means there are batteries missing
or any other negative analogy.

And I further believe that the position as stated by Wietse
does represent the consensus of the WG, so I don't think we
should continue to argue the merits or otherwise of various
possibilities for DKIM-base signature semantics.

S.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Aug 2006 07:08:48 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> possibilities for DKIM-base signature semantics.

Excuse me?

Then are we going to change the DKIM-BASE document?

It is not a mistake to suggest there is no statement or implication of the
MUST has 2822.From mandate.  Section 5.4 clearly goes into what headers
should be considered for specific reasons.  There is a strong reason for
that.

Nevertheless, I don't dispute the common sense, already known, semantics as
Wietse puts it.  He said nothing new.  For that I could easily say +1 too.

But it doesn't solve the problem that is being addressed.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Aug 2006 12:04:56 +0100

Folks,

I think we've done the delegation debate sufficiently that we
can, and should, sit back and think about it for a while (i.e.
stop typing for a bit:-). For now, maybe best would be for Mike
to ensure that the -01 requirements draft has sufficient mention
of the issue, that we don't forget to come back and resolve it in
a bit.

If there are other things Mike should be doing with reqs-01 that
haven't been said on the list, now is probably a good time to
raise them (in a new thread).

Mike has suggested that after he produces the reqs-01 that we might
want to go back to the jabber/issue-tracker modus operandi to close
out the ssp requirements work. That sounds like a reasonable plan to
me, but if you've any concerns do let Barry and I know. (I guess
that reqs-01 will take a week or so to pop out given the amount of
list traffic that Mike will have to process, so a bit of patience
is required from us all btw.)

Cheers,
S.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Aug 2006 06:58:14 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>

> We are not going to fix mistaken beliefs with technical constraints.

However, I am afaid to say, that is exactly whats going to happen when
receivers and the world begin to see an avalanche of DKIM-BASE failures, a
high potential chaos condition evolving from the mistaken beliefs of how
DKIM-BASE only advocates think it should be used based on WORDS only.

> I believe we have strong and broad agreement that it would be
> useful to publish "I sign everything".  This is of basic benefit,
> when receiving a message that is not signed.
>

Dave, I think if you want this to move forward you are going to have to read
and make the attempt to *understand* about what people are saying and be
more compromising.

You need to include migration and deployments considerations where there
will be many domains who will add a POLICY but not necessarily yet directly
support DKIM/SSP.

This is exactly what happen with SPF.  SPF began to take off when AOL
announced SPF support by adding a POLICY but had yet to directly support it
yet.   That is when we jumped on board. Before that, we were still on the
fence if it was worth the effort.  Same with most of the big ISP domains.
My personal DSL account, bellsouth.net has a SPF policy, but has yet to
support it directly. Same is true with thousands of big domains.

The same will most likely happen with DKIM and you should be very happy if
they do because it will help with your promotion.

Therefore, two more policies should be part of the 1st party signature only
direction:

  - I never send mail with this domain
  - I never sign with this domain

Dave, this is GOOD, not BAD and it will help with the technical sales of
DKIM.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Aug 2006 04:17:52 -0700

> But it doesn't solve the problem that is being addressed.

Agreed.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Aug 2006 09:53:52 -0400

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: <[email-masked]>

> raise them (in a new thread).

I'm taking your off list advice and posting this here:

[Offlist]

Hector wrote:

My only concern about all this is that the process has been hijacked 
by those who believe a REPUTATION LAYER is the only solution to be 
used with DKIM-BASE.   I'm afraid the requirements will be written in a 
way to water down any strong SSP consideration. Evidence of that is req 
#10 and the provisional considerations that the authors themselves 
don't believe in.

Stephen replied:

That is a valid concern. I encourage you to keep defending your
position.

---

From: Damon <[email-masked]>
Date: Mon, 28 Aug 2006 10:03:02 -0400

>     if they DO exist, it BETTER not destroy my 1st party

I will agree to this, as long as the 1st party can say "I always sign
and I have the expectation that an unsigned message from me will be
treated with extreme prejudice."

Regards,
Damon Sauer

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Aug 2006 15:24:01 +0100

Hector Santos wrote:
> That is a valid concern. 

The valid concern to which I refer, is your wish for a "strong SSP".

As I also intimated in that off-list message (and I wouldn't quote you
back to the list without asking first btw), I do not care what the
WG participants think of one another's motives. So in case anyone is
confused I in no sense agree with Hector's "hijacked" remark, and nor
do I think such remarks are useful in a list message. Not that Hector
is the only one who uses such purely pejorative terms of course.
(Sometimes this list reminds me of nothing more than a bad coaching
session with the under-12 footballers.)

Lastly, the text above is hardly informative in terms of what should
be in reqs-01 (that has not been stated already), so this appears to
be a content-free thread at the moment.

Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Aug 2006 07:34:07 -0700

>not proof about the identity of the author.        =============
If you take the real life example of Yahoo!, I believe that they 
annotate the
mail when the message contains a valid first party signature (ie from 
the author
domain). I'm not certain whether they annotate it if it contains only a 
third party
signature, but there's a lot of reason to believe that that would be 
very confusing
to their users if they did. Annotation of the third parties might 
inadvertently lend
credibility not deserved. Human factors are tricky things.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Aug 2006 08:25:07 -0700

> of the issue, that we don't forget to come back and resolve it in

Rather than calling a solitary policy flag "I sign everything", this
flag would be better described as "I am being phished".  The use of this
flag will come to represent a dire situation as it will also likely
induce a myriad of delivery issues.  As such, this policy might be
published by only a small portion of the overall domains.

A rare policy will expend greater efforts searching each 2822.From for
policies up name trees that in the end are unlikely to exist.  Even if
DKIM were being used, the suitable default is implied when nothing is
published.  A repository listing phished domains would likely gain
greater adoption and consistent use by DKIM verifiers.  This repository
could identify those being phished as well as their look-alikes.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Aug 2006 16:35:19 +0100

Doug,

> could identify those being phished as well as their look-alikes.

So I ask that we sit back and not prolong the thread and you respond
with this...I don't know what it is actually, since I can't extract
anything meaningful from the above.

If you have a new, relevant, SSP-requirements related issue, that *you
can state in a way that we can understand*, then go ahead and start a
new thread. Otherwise, please say nothing for a bit.

Stephen.

---

From: Damon <[email-masked]>
Date: Mon, 28 Aug 2006 11:37:27 -0400

> could identify those being phished as well as their look-alikes.

In reality, I don't think that heavily phished domains would have very
deep trees.
So assuming this to be true, "I sign everything because I am at risk"
would still have a benefit.

Regards,
Damon Sauer

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Aug 2006 16:40:33 +0100

Hi Damon,

> would still have a benefit.

Allowing the WG progress by terminating this thread has a benefit.

Can we do that now?

Thanks,
Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Aug 2006 08:52:41 -0700

> is required from us all btw.)

My processor is a pretty vintage one (circa car's and cdr's), so yes this
is going to take me a bit. My intention is to document all of the commentary
of these threads on third party signing so that we can look at the larger
picture surrounding the provisional requirement and ultimately make the
decision.

One note: rehashing the same topic endlessly doesn't help me, and makes
it less likely that I'll be able to see any new angle or twist, 
especially if
it's buried in a familiar looking tome.

          Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Aug 2006 09:16:30 -0700

>>this an valid DKIM message, even if the 1st party signature

I'm afraid that this is a pretty fundamental misunderstanding of what 
dkim-base
does and does not provide. DKIM-base does not say whether a given message is
valid: that is not something that it can say with any accuracy. It does 
provide a
mechanism for a receiver to determine whether one or more dkim signatures
are valid. How those (in)valid signatures are evaluated by the receiver 
is out of
scope of the protocol.

I'm afraid that his may be one of the unintentional results
of the previous -base drafts having the Authentication-Results: header 
in it.
Authentication-Results -- which may or may not lead to message level 
evaluation
is most definitely not in scope though. It should be noted that even if 
it were,
it is a receiver-side annotation which may or may not have things to say 
about
DKIM-base, SSP, SPF and all kinds of other things.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Aug 2006 09:49:36 -0700

>#10 and the provisional considerations that the authors themselves 
Speaking as all of the authors in question:

  10.  [PROVISIONAL] A domain holder MUST be able to publish a Practice
        which enumerates the acceptable cryptographic algorithms for
        signatures purportedly from that domain.

           [INFORMATIVE NOTE: this is to counter a bid down attack; some
           comments indicated that this need only be done if the
           algorithm was considered suspect by the receiver; I'm not
           sure that I've captured that nuance correctly]

I'm sure that I have no clue as to what nefarious intentions um, we,
had in mind here. As always, it would be helpful to be specific about
actual wording changes and/or showing wide support for new requirements.

		Mike

---

From: Damon <[email-masked]>
Date: Mon, 28 Aug 2006 13:01:00 -0400

On 8/28/06, Michael Thomas <[email-masked]> wrote:
> provide a mechanism for a receiver to determine whether one or more dkim
> signatures are valid. How those (in)valid signatures are evaluated by the receiver
> is out of scope of the protocol.

IMO that the contention that remains is how this "mechanism" is to be
used and interpreted and a particular signing level. Providing a level
of valuation is not a dictation how that valuation is used.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Mon, 28 Aug 2006 13:02:31 -0400

Correction to my previous:

> used and interpreted at a particular signing level. Providing a level

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Aug 2006 13:29:05 -0400

----- Original Message ----- 
From: "Michael Thomas" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>         signatures purportedly from that domain.

I referred to the wrong req #. I should of been #9.

   9.   The Protocol MUST NOT be required to be invoked if a 
        valid first party signatures is found.

Concerns were already discussed. No need to go over it again.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Aug 2006 14:10:42 -0400

----- Original Message -----

> I'm afraid that this is a pretty fundamental misunderstanding
> of what dkim-base does and does not provide. DKIM-base does
> not say whether a given message is valid: that is not
> something that it can say with any accuracy. It does
> provide a mechanism for a receiver to determine whether one
> or more dkim signatures are valid. How those (in)valid
> signatures are evaluated by the receiver is out of
> scope of the protocol.

Sorry Mike,

I prefer not to rehash all of this because it is already obvious people will
read only what they want to read, twisting or turning the way they want it,
filtering out the rest, etc.

I'll wait until the next draft leaving you with this:

By far, the industry direction for security is to preempt failure and
problems before passing the buck to the user.  There is no question this is
the direction across the board in the security market simply before we have
a long history to know the other ways did not work very well.  You can try
to force an one-sided meaning into what you think DKIM-BASE should be but
rest assured if its doesn't SOLVE a problem it won't be used and if it
creates problems, people will take matters into their hands.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Aug 2006 11:34:59 -0700

Sorry Stephen, I'll try to be clearer.  When stepping back, perhaps  
one should also question whether a policy record is the best solution.

A Policy that can indicate only a solitary state of the 2822.From  
being within the signing-domain will be problematic.  There are  
legitimate causes for a once compliant message to later become non- 
compliant.  When policy can only reflect adoption of this solitary  
provision, non-compliant messages are more likely rejected or placed  
into the never read spam folder.  The prevalence of delivery related  
problems may lead to a general assumption that this policy is only  
suitable for dire situations, such as being the subject of a phishing  
attack.  This solitary state therefore represents a significant step- 
function in non-complaint messages being acceptable, to not being  
acceptable.  This step-function is also likely to become steeper or  
more severe over time.

When a solitary state policy ends up providing benefit to an  
extremely narrow scope of domains, the overhead searching label-trees  
for a policy intent on blocking non-compliant messages may actually  
discourage its adoption.  There is little incentive to publish a  
policy that does not alter the assumed default.  Look-alike domains  
being able to thwart even the most severe handling based upon this  
policy.  This raises the general question whether all emails should  
invoke a search for a narrowly applicable policy found somewhere in  
the DNS hierarchy.  It would be better to adopt a solution that  
limits the number of queries to one.  In addition, it would be better  
to adopt a solution that also thwarts look-alike exploits.

There are two possible solutions:

  - A repository of domain names that desire the severe
    handling of non-complaint messages.

  - An annotation scheme based upon the presences of the
    2822.From address being found in the Address book.

Both of these strategies can be done in parallel.  Neither scheme  
requires a DKIM specific policy.  The only essential element needed  
to secure annotations based upon 2822.From address would be for  
signature semantics to clearly indicate whether the signing domain  
assures the validity of this address.

The repository of domain names could be a zone dedicated to this use  
under the DKIM.ORG zone, for example.  This zone could return a  
record indicating that the domain being queried has requested the  
severe handling of non-compliant messages, or whether this domain has  
been used in criminal fraud as reported by various enforcement agencies.

Both of these solutions do not need policy, and both can thwart a  
look-alike attack.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Aug 2006 21:57:42 +0100

Dave Crocker wrote:
> The buck stops with the d= string.
> 
> How that string is administered is not a matter for public analysis.
> 
> You appear to be introducing an expectation that a validator is supposed to be
> able to know exactly which entity, within the ADMD of the signing domain,
> actually performed the signing action.
> 
> Since that is not something DKIM is designed to provide, per se, where does this
> expectation come from?

I was responding to something in context. Feel free to go back
and look at that. I've more-or-less forgotten 100 message back;-)

S.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 28 Aug 2006 12:52:08 -0700

d/
-- 

  Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 29 Aug 2006 08:20:04 +0200

Wietse Venema wrote:

> The problem that you refer to is due to the mistaken belief
> that DKIM signatures imply anything about rfc2822.from
> addresses. We can eliminate the problem by simply taking DKIM
> signatures for what they actually are: proof about the
> identity of the signing party, not proof about the identity
> of the author.  =============

Okay, that's the "crypto timestamp" model, and apparently some
big players want precisely this and no additional nonsense.

It would be consequent to take the timestamp line instead of
the 2822-From as "MUST" in base (5.4).  The EAI / IMA folks
just discuss a situation where the 2822-From is removed or
empty after some UTF8SMTP magic hitting a legacy mailbox.

If the whole point is a better timestamp line, why not include
it in the signature ?  An MSA could _also_ sign the 2822-From
if it knows that it makes sense (From = Mail From ) and is ok.

And a MUA could sign the (Resent-) Message-ID instead of the
timestamp line.  But actually I don't think that MUAs trying
to sign mail are relevant at the moment.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 29 Aug 2006 09:27:43 +0200

Douglas Otis wrote:

> Without this assurance, the DKIM signature is practically
> worthless.

Some months ago you were firmly in the "crypto timestamp" camp,
what happened ?

> only when the signature itself indicates the 2822.From
> address has been validated.

Okay, we can update 5.4 in base if necessary, e.g. add a flag
where that's the case.

>  - presences of the valid 2822.From address in the address

I'd prefer PRA where you say 2822.From, but otherwise ACK.

That's not yet covered in base, how can the MSA say that the
2822-From is okay ?  Even where the domains match it's not
necessarily okay.  The MSA has to know who submits the mail,
which PRA can be used by that authenticated user, and the
case PRA != 2822.From has to be documented, the procedure in
that case would be different.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Aug 2006 01:28:52 -0700

> > of the author.  =============

Signature verification is always silent on the nature of content.
Nevertheless, when the author's address associated with the signing
party is trusted, then assertions of the signing party are also
trustworthy by extension.

> big players want precisely this and no additional nonsense.

This scheme would be coupled with a call-back to verify whether the
message is still considered valid, eliminating public crypto and
providing a pay per verification model.

> empty after some UTF8SMTP magic hitting a legacy mailbox.

Perhaps a header copy saves the day in this case.

> if it knows that it makes sense (From = Mail From ) and is ok.

The MSA can also qualify the From based upon the account and prior
receipt verification. 

> to sign mail are relevant at the moment.

MUAs can sign with DKIM.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Aug 2006 10:13:52 +0100

> Okay, we can update 5.4 in base if necessary, e.g. add a flag

Eh - except we're done with WGLC on base. So making that change
would require a whole lot of +1's before being on the table.
In other words: not at this time.

I'm sure you're aware of this of course, but let's not bother
with extending this thread even further for no reason. (In fact
I this thread is well beyond its use-by date already.)

Cheers,
Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Aug 2006 02:20:43 -0700

> Some months ago you were firmly in the "crypto timestamp" camp,

DKIM does not assure the signature is unique and lacks any practical
revocation mechanism.  Tracking and controlling replay activity will be
extremely difficult and expensive.  DKIM still has value when used to
assure the author.  At least this should lessen phishing incentives when
it becomes less practical.  DKIM also provides a reasonable reporting
mechanism.  

> Okay, we can update 5.4 in base if necessary, e.g. add a flag

This could be done as an independent option.

> I'd prefer PRA where you say 2822.From, but otherwise ACK.

I suspect the reasons for sticking with the From are specifically to
avoid the PRA issues and to better tackle the phishing problem?  I have
labeled the policy DFSP.  A DPRAP could be published as well.

I am working on solving the issues you raised on the DNS limitations
when combining domain names, which should work in regard to other forms
of policies as well.  I hope to have a version tomorrow.  Ahh today.

> That's not yet covered in base, how can the MSA say that the 2822-From
> is okay ?

To incrementally enable this mode of operation, an assertion of the
identity validity must apply to any possible domain.  A premium service
could be provided where the the account holders would access their
account page and request to use a validated address.  They would verify
its receipt, and thereafter for some extended period of time, the
address for that account would be marked as valid when using a verified
address.  See below. 

> Even where the domains match it's not necessarily okay.

Agreed.

> The MSA has to know who submits the mail, which PRA can be used by
> that authenticated user, and the case PRA != 2822.From has to be
> documented, the procedure in that case would be different.

The general concept was that the i=<local-part>@<domain> allowed
semantics to convey an assertion "this address is valid."  i=@<domain>
or i=, or no i= at all would be Don't Know.  This address can be
discovered in any header.  It would have been nice had the domain
restrictions regarding this assertion did not exist.  This would have
enabled associations to be made in the DxxxP policy records as a way to
easily extend DKIM capabilities.

If this mode of use were to become popular and used by default, then
this will likely have the biggest impact on spam.  These account
verification tables could readily detect unusual activity.   

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 30 Aug 2006 05:33:39 +0200

Stephen Farrell wrote:
 
> I'm sure you're aware of this of course

Actually I'm not, I missed the WGLC and read only about 10%
of the 1800 unread DKIM mails some weeks ago.  Base-05 was
published last week, apparently reflecting WGLC issues.  

Is that now intended to go to an IETF last call, or is it
frozen waiting for whatever pops up in the SSP discussions ?

> (In fact I this thread is well beyond its use-by date
> already.)

The proposed "compromise" that additional signatures are okay
as long as the first signature is still valid was new.  I'd
say it's only consequent (instead of a "compromise"), but it's
a step forward.  We could note it as requirement:  If signers
don't munge mails they can sign everything they send without
looking at any SSP.

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Aug 2006 09:56:04 +0100

Frank Ellermann wrote:
> of the 1800 unread DKIM mails some weeks ago.  

http://mipassoc.org/pipermail/ietf-dkim/2006q3/004108.html
was posted on July 5th, before the current storm.

 > Base-05 was

Yep.

> frozen waiting for whatever pops up in the SSP discussions ?

Next is that it goes to the AD and then IETF LC.

Stephen.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 31 Aug 2006 00:57:54 +0200

Stephen Farrell wrote:

 [about 10% of the 1800 unread DKIM mails]
> was posted on July 5th, before the current storm.

ACK, that was in my 10%, I went through it thread by thread.

> Next is that it goes to the AD and then IETF LC.

Thanks for info.  The tracker only said "I-D exists, shepherd
not yet assigned" - this will be more interesting after Barry,
Russ, or you pushed its [GO] button.

Frank