Subject: [ietf-dkim] requrements-01 available

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Sep 2006 14:22:38 -0700

until it hits the drafts repository:

http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-01.txt
or
http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-01.html

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Sep 2006 16:12:36 -0700

,---
|5.3.1.  Negative Commentary
|...
|4. Concerns about conflation of responsibility and/or reputation:
|   there are concerns of adding to the confusion about who is
|   taking responsibility for what. Is it the d= domain in the
|   DKIM-signature? Is it the domain in the From: address? Is it
|   both? Is it neither? Keeping this simple by using the NS
|   delegation mechanism would not raise these interesting, if not
|   thorny questions.
'---

Perhaps the most basic requirement for any accrual is properly  
attributing actions to the correct entity.  What this means with  
regard to DKIM must be kept clear.  This statement indicates there is  
confusion?

1- The recipient of the message (2821.Rcpt To:) is independent of the  
entity defined in the To: or CC: headers.

Perhaps policy could change this assumption, but without being able  
to associate these fields, the recipient can not hold the signer  
accountable for having actually sent the message.  For those domains  
setting up trip-wire or honey-pots to identify bad actors, they need  
to fully understand this limitation.  Otherwise, a bad actor is able  
cause serious harm to innocent signing domains.

2- Only the signing domain is verified when the signature itself is  
verified.

While there might be external associations found in policy records  
binding the email-addresses with that of the signing domain, only the  
signing domain can be verified as being accountable.  Only the  
signing domain can be held accountable for any abusive content such  
as malware or phishing attempts irrespective of any email-address  
contained.  When a signing domain is a bad actor, why trust them to  
pass accountability onto someone else via an email-address?

3- Who Should sign?

DKIM should be allowed to naturally associate with that of the  
sending domain.  The contained email-address found in the  
2822.Sender: or 2822.From: header fields or the 2821.Mail_From  
parameters may be different.  To facilitate the activity at the MTA,  
the 2821.Mail_From offers the greatest advantage.

Any domain found in an email-address can expressed as SHA-256 hash  
and listed by the email-address domain as a base32 52 character  
label.  Any association of an unlimited number of signing domains  
would require only _one_ lookup to resolve.

  <base32 SHA-256 signing domain hash>._x-policy.<email-address-domain>.

3- Reputation of the sender will likely resolve to their IP address  
in most cases.

This means DKIM feedback reports needs to be directed to the actual  
sender.  This is not necessarily the owner of the email-address.   
Using a key published in a foreign domain as achieved through the use  
of DNS delegation prevents essential reporting information from being  
sent to the party held accountable by way of IP address.

For the sender's protection, DNS delegation is a bad practice.  The  
email-address should never be held accountable for a message.  Ever!   
There is no risk or danger created by allowing email-address policies  
for the 2822.From, 2822.Sender, or the 2821.Mail_From from simply  
listing an association with some signing domain.  This allows the  
signing domain to best protect outbound services, and also allow the  
email-addresses to be safely annotated by the recipient's MUA or  
safely used in a DSN.

This section seems to be profoundly confused about who is most likely  
to be held accountable, and what advantages are afforded by having a  
DKIM domain be associated with the sending domain.  From the MTA  
operations standpoint, an association with the 2822.From offers the  
least protection.  Policy allow associations to be made in a very  
simple fashion.  The MTA should be more concerned about abuse  
reporting and issuing DSNs.

Let the MUAs worry about email-address annotations via policy  
associations.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 16 Sep 2006 03:18:44 +0200

Michael Thomas wrote:
 
> until it hits the drafts repository

Thanks.  5.3.1 (2): s/which well/with well/  or /and well/
               (3) s/The seems/There seems/
               (6) s/abilitiy/ability to distinguish/

5.3  (9):  s/publish a Practices/supports to publish Practices/
5.3 (11): s/; I'm not sure .* correctly/./ (I think ;-)
5.3 (12): s/receiver./receiver or 2822-compliant resender./ (?)

5.4:      Are (1) and (3) in conflict ?  Maybe join (1)+(3).
          I dont's see the MUST in (4), it's a "nice to have".

5.3  (2): IIRC we've identified "never send mail" as a special
          case of "strict", and then just not sending mail, let
          alone signing it.  IMO you can delete this point.

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Sep 2006 16:56:22 +0100

Good job Mike.

So as we said before we want to move to close out these requirements
and so we'll start using the issue tracker and jabber sessions again.

If you have an issue to raise about what's in, or missing from,
ssp-reqs-01 then please start a new thread with the subject like
"New issue: <<whatever>>" and Eliot will pick it up for inclusion
in the tracker.

Eliot will not go back over the list archive to try pick out issues
already raised (since Mike has already done that, and there's a crazy
amount of mail;-), so if something's slipped under the radar you
should generate a new issue. And if you don't highlight your message
with "New issue:" then its quite likely that it'll get missed.

Please also consider all of the putative requirements in ssp-reqs-01
as "issues" in that they'll each be covered in jabber sessions to see
if we have rough consensus. So if you just want to say "+1" or
whatever, there's no need to raise a new issue.

I earlier asked you to pencil in a jabber session at 1500 UTC (1600
in Dublin) on the 21st and now that we have reqs-01 to hand we should
have that session. The agenda will be to go over each of the putative
requirements and issues from the tracker (in some order that Barry
and I will try figure out). We can discuss future jabber session
logistics then also. As before, the jabber sessions are like
interim meetings in that everything agreed there is subject to
confirmation on this list. I'll send a better agenda to the list
in a few days.

Our goal now is to try to achieve rough consensus on these requirements
before San Diego, where I suppose we'll want to start working on (or
adopt, whatever), a protocol meeting those requirements. (I've asked
for one 2.5 hour slot in San Diego btw.)

Regards,
Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Sep 2006 06:44:36 -0700

This document raises concerns regarding the security of designations  
rather than delegations.  A designation approach does not relinquish  
control of domain signing, or imperil the sending agent or the email- 
address domain with having administered the signing of messages by a  
different domain.  The domain actually sending the messages using  
another domain's keys is imperiled by not seeing abuse reports sent  
to the foreign signing domain.

As DKIM is unrelated to the message envelope, has no controls on  
message replay or practical message revocation schemes, the use of  
the signing domain as a basis for acceptance or rejection remains  
highly problematic in the general case.  Requiring the 2821.Rcpt To  
to match a 2822.To or CC header field email-address is not practical.

A receiving domain might caution a signing domain, but without  
knowing the source of a message has no ability to verify corrective  
actions, or know when it might be safe to once again to use the  
signing domain as a basis for acceptance.  This problem is true for  
nearly any large domain.  Conversely, corrective actions may have  
been taken and yet problems may persist due to the lack of source  
information and the potential replay issues.

Any assumption that a DKIM signature can be used as a basis for  
acceptance or rejection introduces very serious denial of service  
issues.  The primary goal of email-address policies should be aimed  
at safely leveraging DKIM signatures.  The DKIM signature does safely  
permit the following when a signing domain has been designated by an  
email-address:

  - Annotation of a recognized email-address based upon recipient  
retentions.

  - Safe DSNs based upon 2821.Mail Froms.

  - Reporting of abuse based upon the signing domain directed to  
actionable and ultimately accountable entities.

There should be a general understanding of the futility and perils  
using a DKIM signature as a sole basis of acceptance or rejection.   
Some policies may identify suspicious messages, however reliance upon  
identifying recognized messages offers greater protections without  
potentially causing disruptions in email delivery.  Abuse MUST be  
handled by identifiers tracking the actual sending agent.

The requirements draft appears to overlook and misconstrue rather  
serious security concerns.  As this is a requirements document,  
perhaps fundamental security concerns need to be understood and  
agreed upon.  What are the underlying security concerns related to  
some email-address policy and how can security be generally improved  
upon by this policy?

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Sep 2006 14:53:46 +0100

Doug,

Is this meant to be recorded in the tracker? If so, then you
forgot to say "New issue" and so Eliot will likely skip over it.

Also, I should of course have said that the WG can only really
decide things that are decidable. So issues in the tracker really
need to have a proposed resolution or else I confidently expect
that they won't achieve rough consensus. We no longer want to
have open-ended discussions on ssp-reqs, its now time to start
making decisions.

This mail falls on both hurdles IMO.

So, if you do want these points considered, send a new mail that
Eliot will notice and if at all possible include a proposed
resolution (or else say why you cannot).

Stephen.

Douglas Otis wrote:
> control of domain signing, or imperil the sending agent or the 
> email-address domain with having administered the signing of messages by 
> a different domain.  The domain actually sending the messages using 
> another domain's keys is imperiled by not seeing abuse reports sent to 
> the foreign signing domain.
> 
> As DKIM is unrelated to the message envelope, has no controls on message 
> replay or practical message revocation schemes, the use of the signing 
> domain as a basis for acceptance or rejection remains highly problematic 
> in the general case.  Requiring the 2821.Rcpt To to match a 2822.To or 
> CC header field email-address is not practical.
> 
> A receiving domain might caution a signing domain, but without knowing 
> the source of a message has no ability to verify corrective actions, or 
> know when it might be safe to once again to use the signing domain as a 
> basis for acceptance.  This problem is true for nearly any large 
> domain.  Conversely, corrective actions may have been taken and yet 
> problems may persist due to the lack of source information and the 
> potential replay issues.
> 
> issues.  The primary goal of email-address policies should be aimed at 
> safely leveraging DKIM signatures.  The DKIM signature does safely 
> There should be a general understanding of the futility and perils using 
> a DKIM signature as a sole basis of acceptance or rejection.  Some 
> policies may identify suspicious messages, however reliance upon 
> serious security concerns.  As this is a requirements document, perhaps 
> fundamental security concerns need to be understood and agreed upon.  
> What are the underlying security concerns related to some email-address 
> policy and how can security be generally improved upon by this policy?
> 
> -Doug
>

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Sep 2006 02:27:42 +0200

Douglas Otis wrote:
 
> DKIM is unrelated to the message envelope

True, more below.

> Requiring the 2821.Rcpt To to match a 2822.To or CC header
> field email-address is not practical.

Of course, anything not matched is by definition a BCC.

> Any assumption that a DKIM signature can be used as a basis
> for acceptance or rejection introduces very serious denial of
> service issues.

It's THE job of SSP to change this.  Or maybe ONE job, this
algorithm transition stuff is also relevant, but I don't care
where and how it's done (as long as Phil says that it's okay).

> The DKIM signature does safely permit the following when a
> signing domain has been designated by an email-address:

[...skipping annotation...]
>   - Safe DSNs based upon 2821.Mail Froms.

No, as you said above "DKIM is unrelated to the"..."envelope".

To avoid abusive DSNs to innocent bystanders you always need a
verified Return-Path.  Minimally you've to trust that it's no
nonsense (e.g. if it came from a source where that's hopefully
guaranteed).

If you think that _DKIM_ (not the cases discussed in 4408+4409)
safely permits safe DSNs I'd like to know how that's supposed
to work.  IMO it simply does not allow this, and that's no bug
or bad thing, it's a consequence of the "unrelated" (to SMTP).

> There should be a general understanding of the futility and
> perils using a DKIM signature as a sole basis of acceptance
> or rejection.

If a policy makes 2822-compatible statements about signatures,
then using it isn't futile or perilous.  Nobody's forced to
publish dangerous policies, nobody's forced to evaluate them,
this is a completely voluntary business, same idea as SPF (or
SenderID, modulo its known IAB-appeal IESG-note fine print).

> Abuse MUST be handled by identifiers tracking the actual
> sending agent.

Maybe, but that's not a "MUST" for SSP reqierements, it belongs
into another document like 2821bis or BASE.

> What are the underlying security concerns related to some
> email-address policy and how can security be generally
> improved upon by this policy?

Isn't that already covered by the threats RFC ?  For the "SSP
requirements" it would be a waste of time if it tries to list
all potential security considerations of a future SSP proper.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Sep 2006 10:16:29 -0700

On Sep 18, 2006, at 5:27 PM, Frank Ellermann wrote:

>> Requiring the 2821.Rcpt To to match a 2822.To or CC header field  
>> email-address is not practical.
>
>> issues.
> It's THE job of SSP to change this.

Strict policy can not be applied for normal use.  Only strict  
2822.From policy can act as a basis for rejection, but this does not  
permit non-compliant services that will continue to be used for a  
long time.  In addition to the 2822.From domain setting a strict  
policy, the receiver must also hunt for 2822.From policy for each  
2822.From email-address.  In the normal case, there will not be any  
policy record.  The distribution of 2822.From email-addresses is  
greater than that of sending agents.  Even when a record is  
published, the effort represents a sizable burden upon the receiver  
in terms of resources, where seldom would there be any actionable  
information obtained that could resulting in blocking anyway.   
Annotation allows this process to be much more selective, and affords  
greater and more secure protections.

> Or maybe ONE job, this algorithm transition stuff is also relevant,  
> but I don't care where and how it's done (as long as Phil says that  
> it's okay).

It is my understanding the powers-to-be decided coping with  
transition is not needed at this time.  Store and forwarding  
protocols do not allow for negotiations, which necessitates  
conveyance of deprecation information.

>> The DKIM signature does safely permit the following when a signing  
>> domain has been designated by an email-address:
>

Policy can be applied just as easily to the 2821.Mail_From in  
addition to the 2822.From.  A label of the associated signed-domain  
could be base32 encoded as a SHA-256 + CRC32c to ensure a  
deterministic 58 octet label size.  Any different domain would be  
required to satisfy two different algorithms simultaneously, where  
the possibilities should be sufficiently small.

   <base32 SHA-256 + CRC32c>._DKIM-mf.<mail-from domain>.

> nonsense (e.g. if it came from a source where that's hopefully  

When the 2822.From is associated with that of the signing domain via  
DKIM-MF policy, the 2821.Mail-From is assured and can be safely used  
in a DSN.

> safely permits safe DSNs I'd like to know how that's supposed to  
> work.  IMO it simply does not allow this, and that's no bug or bad  
> thing, it's a consequence of the "unrelated" (to SMTP).

This is something DKIM-MF policy can safely provide.  RFC4408 enables  
various DDoS and DNS poisoning attacks as previously described.   
However, a single record policy as illustrated above would not induce  
these serious issues.  The DKIM signature and the DKIM-MF policy  
record provides the requisite association for safe DSNs.  In lieu of  
RFC4408, DKIM safely improves a chance of receiving a DSN, which is  
when the DKIM-MF policy might be checked.

> If a policy makes 2822-compatible statements about signatures, then  
> using it isn't futile or perilous.  Nobody's forced to publish  
> dangerous policies, nobody's forced to evaluate them, this is a  
> completely voluntary business, same idea as SPF (or SenderID,  
> modulo its known IAB-appeal IESG-note fine print).

There is a broader issue being missed.  As with SPF et al, the desire  
was to bring accountability to the originator.  Just as with these  
other protocols, this will not work with DKIM either for the same  
reasons.  From our data, rejections based upon a "soft-fail" + "fail"  
only block about 9% of spam, while also imperiling DNS  
infrastructure.  When based upon just the "fail" as commonly required  
to avoid delivery issues, less than 3% of spam is blocked.  The DSN  
DDoS concern can be addressed using DKIM and a 2821.Mail_From DKIM  
policy record as described above without incurring genuine risks or  
violating proprietary algorithms.  To prevent spoofing, nothing beats  
annotation of retained email-addresses.

>> Abuse MUST be handled by identifiers tracking the actual sending  
>> agent.
>

For the policy requirements, the desire to have customers provide  
delegations to their provider completely overlooks this MUST  
however.  Here policy based associations would be vastly safer.  As  
Olbermann would say, the batteries are in backwards; designations are  
significantly safer than delegations.  In either case, the signing  
domain must be trusted to act based upon the 2822.From address by  
limiting the account and selecting the signing-domain.  With DNS  
delegation, the provider must be trusted to use the correct signing- 
domain which imposes far greater risks.  In any realistic way of  
evaluating risk, DNS delegation increases risks for the 2822.From  
domain.  It would be desirable to have had semantics defined that  
allowed the provider to explicitly assert which email-address had  
been restricted, but that information can also be deduced by a  
2822.From policy association as well.  Designation simply imposes  
different provider expectations.

In either case, the provider is being trusted when designation or  
delegation is used.  There is far greater risks for both the provider  
and the 2822.From domain owner when a DNS delegation method is used.   
With DNS delegations, the provider may not see abuse reports and the  
2822.From domain owner may be attributed for having signed messages  
they did not originate, and will not have logs to prove otherwise.

>> That are the underlying security concerns related to some email- 
>> address policy and how can security be generally improved upon by  
>> this policy?
>
> requirements" it would be a waste of time if it tries to list all  
> potential security considerations of a future SSP proper.

The threats draft missed that the sending agent must be held  
accountable and that the DKIM signature can not play this role.  As a  
result of this oversight caused by understatements of replay concerns  
among others such as use of annotations, the threat draft offers poor  
guidance for the policy effort.  The policy requirements draft  
appears to be a continuation of this short-sighted view. : (

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Sep 2006 10:36:00 -0700

On Sep 19, 2006, at 10:16 AM, Douglas Otis wrote:

> When the 2822.From is associated with that of the signing domain  
> via DKIM-MF policy, the 2821.Mail-From is assured and can be safely  
> used in a DSN.

Correction:

When the 2821.Mail_From is associated with that of the signing domain  
via DKIM-MF policy, the 2821.Mail_From is assured and can be safely  
used in a DSN.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Sep 2006 19:36:26 +0100

Douglas Otis wrote:
> The threats draft missed that the sending agent must be held accountable 
> and that the DKIM signature can not play this role.  As a result of this 
> oversight caused by understatements of replay concerns among others such 
> as use of annotations, the threat draft offers poor guidance for the 
> policy effort.  The policy requirements draft appears to be a 
> continuation of this short-sighted view. : (

Moaning about the fact that the WG's rough consensus wasn't what the
author wished is irrelevant and distracting. Please stop.

The threats draft does represent the WG's rough consensus at that
point in time and with the level of knowledge of the SSP protocol
existing then. While new facts may emerge, and additional levels of
protocol detail may also throw up new threats, we are not going to
re-do the entire threat analysis exercise.

Please focus your contribution towards resolvable issues with
ssp-reqs.

Thanks,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Sep 2006 19:36:43 +0100

Frank,

You may have missed my reply to Doug on this thread. Please read
that and try to move the discussion on to issues that we can track
and resolve. There has already been plenty of open ended discussion
and now its time to get the ssp-reqs document done and move on the the
protocol.

Thanks,
Stephen.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Sep 2006 22:38:21 +0200

Stephen Farrell wrote:
 
> Please read that and try to move the discussion on to issues
> that we can track and resolve.

I've already posted my list of mostly minor issues with -01pre:
<http://permalink.gmane.org/gmane.ietf.dkim/6034>

> now its time to get the ssp-reqs document done

Apparently draft -01 wasn't published so far (?)  

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 20 Sep 2006 00:00:15 +0200

Douglas Otis wrote:

> Only strict 2822.From policy can act as a basis for
> rejection, but this does not permit non-compliant services
> that will continue to be used for a long time.

If senders and receivers remove non-compliant services from
the picture:  good riddance.  I'm more worried about normal
2822 applications.  The -01pre text has this as use case:

Users are free to resend mails to somebody else, and that
has to work with new receivers supporting strict SSP.

> transition is not needed at this time.

Overruling Phil in a security question.  The SHA-256 design
"patent" not even submitted to the IETF IPR page.  If Paul
states that that's no problem I'd believe it.

> RFC4408 enables various DDoS and DNS poisoning attacks as
> previously described.

That's about as relevevant as the mail arriving with 25 DKIM
signatures (one valid), after you got a million you'd figure
out how to disable DKIM verification temporarily.

> based upon just the "fail" as commonly required to avoid
> delivery issues, less than 3% of spam is blocked.

Not too shabby.  The idea is to get this to almost 0%, because
no bad actor tries it anymore.  You probably also get a few
"pass", for those you don't need to worry about DSNs, they're
desired.  The 90% in between are not worse as before.  And as
others said, any scheme is futile if receivers don't like it,
they must get something for their effort.  It's sad that DKIM
and SSP don't fit into the SIQ concept (or rather I don't see
how), that could be a killer application.

> violating proprietary algorithms

That was the other beast, SID and 2822.  For the PRA part I'd
still say that 2822 is prior art.  Given a 2822 header minus 
Return-Path it's "obvious":  Noting that in RFC 4407 was an
excellent idea, but it's neither proprietary nor experimental.
Unless ignoring the Return-Path is the "experiment"... :-)

> the threat draft offers poor guidance for the policy effort.
> The policy requirements draft appears to be a continuation
> of this short-sighted view. : (

The -01pre draft is more like a summary of points discussed
here, the real security considerations go into SSP proper.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Sep 2006 16:45:56 -0700

On Sep 19, 2006, at 3:00 PM, Frank Ellermann wrote:
> signatures (one valid), after you got a million you'd figure out  
> how to disable DKIM verification temporarily.

With DKIM, it should be normal to limit transactions per signing  
domain.  This would be especially true when done in conjunction with  
annotations.  With RFC4406-8, validating a set of identities may not  
provide any attack indication.  A victim domain may not be related to  
the recipient or even the identity being validated or seen in any  
log.  The associated amplification potential can involve any number  
of identities.  This gets more extreme when receivers decide RFC4408  
can also include a DKIM scope.  Even now, the potential for this  
problem dwarfs amplifications available with open recursive reflected  
attacks done in conjunction with EDNS0, and this also defeats normal  
precautions found with BCP38!

>> based upon just the "fail" as commonly required to avoid delivery  
>> issues, less than 3% of spam is blocked.
>
> Not too shabby.  The idea is to get this to almost 0%, because no  
> bad actor tries it anymore.

There are still a number of "pass" results as well?  For example,  
Bell Canada records ends with "+all".  It seems that when no spam is  
blocked by SPF, while also placing DNS in extreme peril, the reason  
for employing this mechanism has been greatly diminished.  A DKIM/ 
Mail-From policy association should provide the desired DSN  
protections without imposing these risks.  This is one reason why  
DKIM policy should consider records for the 2821.Mail_From and  
perhaps even 2821.EHLO to remove any need for RFC4408.  Name paths  
are far safer than IP address path definitions.  Heck, the PRA could  
still be used for that matter.

> You probably also get a few "pass", for those you don't need to  
> worry about DSNs, they're desired.  The 90% in between are not  
> worse as before.  And as others said, any scheme is futile if  
> receivers don't like it, they must get something for their effort.   
> It's sad that DKIM and SSP don't fit into the SIQ concept (or  
> rather I don't see how), that could be a killer application.

Safe MUA annotation of retained email-addresses preventing even look- 
alike spoofing and safe DSN protections seems to be a possible answer.

> That was the other beast, SID and 2822.  For the PRA part I'd still  
> say that 2822 is prior art.  Given a 2822 header minus Return-Path  
> it's "obvious":  Noting that in RFC 4407 was an excellent idea, but  
> it's neither proprietary nor experimental. Unless ignoring the  
> Return-Path is the "experiment"... :-)

By adding a parameter such as m=<any-email-address> to DKIM, there  
would never be a need to employ priority algorithms, as the signature  
could always make this selection explicit.

-Doug