Subject: [ietf-dkim] off the air till after the holidays

From: Eliot Lear <[email-masked]>
Date: Fri, 21 Dec 2007 07:14:09 +0100

Please don't expect to see new issues opened until after the 2nd.

Happy Holidays,

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 22 Dec 2007 17:56:25 -0500

> Please don't expect to see new issues opened until after the 2nd.

Before the holiday spirits do further damage to my brain cells, I
thought I should gather my thoughts on this together now and during the
interim, post this as a new issue now for preliminary list discussion
and consideration. Then maybe after the 2nd, it may or may not be an
issue to open.

New Issue: Do we need SSP record for DKIM=unknown?

Summary:

Since the NO SSP record world message handling semantics is consistent
with a DKIM-BASE only world, it would be waste of DNS resources for
verifiers to do SSP lookups and the records translate to default
DKIM-BASE semantics.

The incentive for implementing SSP records is to provide a payoff for
all parties; a) the DKIM signer whose values security over delivery and
b) the DKIM verifier whose desire is to provide a higher payoff
(compared to no payoff) service that will benefit the DKIM domain, the 
receiver system and its users.

In addition, by removing the relaxed default SSP attributes, it will
help in reducing exploitations and fraud.  SSP should only be used to
help strengthen the domain DKIM signing process, not add any new
complexity or confusion over what the domains intentions are.

Background:

This might appear complex to explain because I do complicate it with
sub-issues which may be considered separately. So before someone suggest
that these sub-issues may be multiple separate issues, please look at
this first as a whole.  My goal here is to help make SSP worthy for 
adoption consideration by reducing any perceived complexity about it.

Currently, SSP-01 has the following record syntax information:

   dkim       =  unknown|strict|all     default: unknown
   handling   =  process|deny           default: process
   t          =  y|s                    default: undefined

So the default DKIM-BASE behavior from a SSP point of view is:

   dkim=unknown handling=process

and this includes the idea when there is no SSP record.

Overall, we want protocol consistency in DKIM/SSP, therefore:

   - if a verifier has SSP support and performs a domain
     SSP lookup and no record is found, the above is the default
     SSP attributes.

   - Likewise, if a verifier is ignorant of SSP (early
     versions of DKIM-BASE only verifiers),  the SSP specification
     should be modeled on the idea that non-SSP verifiers will
     behave with the default SSP like attributes.

I do believe we achieve this goal here.  However, I also believe it is
redundant, can be exploited and lowers the incentive for using SSP.

To explain why, lets look at some additional sub-issues:

sub-issue: t default not "spelled out"

    I think SSP-01 should be explicit in saying no t= tag means
    the system is not testing and that all sub-domains are in play.
    This is a minor sub-issue especially since we are also considering
    removing the t=y 'testing' semantics.

sub-issue: handling=process default is ambiguous.

    The text for handling=process says:

    process  Messages which are Suspicious from this domain SHOULD
             be processed by the verifier, although the SSP
             failure MAY be considered in subsequent evaluation of
             the message.  This is the default value.

Since handling=process is the default, this is where the key new issue
for the necessity of a SSP record for DKIM=unknown comes into play.

Lets assume there is no SSP record as it realistically might be in the 
current and early DKIM-BASE RFC 4871 adoption period.

In this DKIM-BASE only world, the specification already makes it clear 
that a DKIM-BASE message should be further evaluated using additional 
message processing layer(s).

So in this vain, the default SSP record is redundant.  The only time a 
SSP record is provides added value or payoff is when the domain wants a 
different signing verification logic than what is otherwise provided 
with the DKIM-BASE semantics.

Therefore, one might suggest the only necessary options for SSP might be
just:

   dkim       =  strict|all     default: all
   t          =  s              default: sub-domains allowed

Since we already have a SSP issue on the table to remove the t=y testing
option with a high consensus to remove it, this reduces the tag to a t=s 
only option.

Since the default DKIM-BASE semantics is to further evaluate messages,
valid or invalid, the handling=process is redundant and offers nothing
new to the model.

Conclusion:

Since the NO SSP record world message handling semantics is consistent
with a DKIM-BASE only world, it would be waste of DNS resources for
verifiers to do SSP lookups and the records translate to default
DKIM-BASE semantics.

The incentive for implementing SSP records is to provide a payoff for
all parties; a) the DKIM signer whose values security over delivery and
b) the DKIM verifier whose desire is to provide a higher payoff
(compared to no payoff) service that will benefit the DKIM domain, the 
receiver system and its users.

In addition, by removing the relaxed default SSP attributes, it will
help in reducing exploitations and fraud.  SSP should only be used to
help strengthen the domain DKIM signing process, not add any new
complexity or confusion over what the domains intentions are.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Hector Santos <[email-masked]>
Date: Sun, 23 Dec 2007 18:40:12 -0500

Jim Fenton wrote:
 > Hector,
 >
 > Publishing an SSP record with the default values results in better
 > caching, because a positive result typically has a longer TTL than a
 > negative result, whose TTL which is the minimum TTL of the zone.  With
 > the current lookup algorithm, it also relieves the verifier of the
 > need to confirm the domain's existence, since without an SSP
 > record the result of the query will frequently be an NXDOMAIN.
 >
 > -Jim

Thanks Jim.

Please correct me if I wrong, it would then be "Recommended" for DKIM 
domains to consider using a SSP record even if the domain intent is to 
operate in DKIM-BASE mode?  So even if the DOMAIN has no intention to 
use the benefits of SSP beyond its default behavior, it SHOULD create a 
SSP record in order to be DNS friendly and cooperative with verifiers 
with SSP support?  Is this idea stated or implied in the SSP-01 specs?

On a related note, I didn't want to bring this up before but I think it 
might be something of interest.

With the goals of reducing redundancy, complexing and improving SSP 
adoptability, would it be feasible to consider for SSP restrictive 
policies only that a DKIM domain MAY expose its policy via the DKIM-BASE 
key record?

IOW, if a high value domain's only desire or interest in SSP is to 
expose restrictive handling, would it make sense to write a RFC 4871 
"add-on" or "Extension" I-D or using the opportunity now to write 
directly into the SSP specification the proposal of a new DKIM tag that 
exposes strict or all domain DKIM transaction information?

The idea is this:

      Optional extended DKIM key tag:  SSP=strict|all

For example, following SSP-01

    1.   If a valid Originator Signature exists, the message is not
         Suspicious, and the algorithm terminates.

This means that the signature was verified via DKIM-BASE. It also means 
the DKIM key record was obtained and all information points to a 1st 
party signature.

As I recall during the TA review process,  I believe we all agreed that 
in lieu of an internal key theft, there would be no realistic external 
protocol model threat here with a 1st party valid signature.  So it was 
safe to conclude that a SSP lookup would not be required for a valid 1st 
party signature.

Continuing beyond step 1 implies we the following states:

    a) valid 3rd party signature,
    b) no signature (which can be from a broken signature)

So step 2 and 3 deals with the SSP discovery process.

My proposal is this:

We can reduce step 2 and 3 or short circuits the steps if the DKIM key 
record obtained in step 1 contained the SSP policy information.

So in step 1, we can add a sub-steps:

   1a) If we have a valid 3rd party signature or no signature, and
       the key record contains a tag SSP=strict, then the message
       is Suspicious and the algorithm terminates.

   1b) If we have no signature, and the key record contains
       a tag  SSP=ALL, then the message is Suspicious
       and the algorithm terminates.

The whole point is that under strict DKIM/SSP operations there is only 
one party involved and no other party or unsigned messages are expected 
and under the ALL policy, there is only 1 state the message can be in - 
a signed state.

In both cases, we short circuit the need to do a SSP discovery by adding 
an optional DKIM-BASE SSP= tag option to DKIM-BASE key records.   I 
believe  RFC are allowed to update other RFCs, and this would be a good 
opportunity to close some complex interface issues regarding DKIM-BASE 
and SSP.

If no SSP= tag is found, then the verifier would proceed with the 
current recommended steps.

A point to consider is that the proposal deals a Negative Classification 
only, hence bad guys will not have any incentive to exploit.

Off hand, I don't see a threat here.  So if you see a flaw here, please 
show me the light :-)

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Sun, 23 Dec 2007 19:07:58 -0500

Small Clarification:

>       and the algorithm terminates.

To clarify these steps, requires the no-signature premise to be defined 
as one resulting from where a key record was found but the DKIM
signature verification failed.

Allow me to change the sub-steps to say:

   1a) If we have a valid 3rd party signature or no signature resulting
       from a failed DKIM-signature validation, and the key record
       contains a tag SSP=strict, then the message is Suspicious and
       the algorithm terminates.

   1b) If we have no signature resulting from a failed
       DKIM-signature validation, and the key record contains
       a tag  SSP=ALL, then the message is Suspicious and the
       algorithm terminates.

The point being is that a KEY record was obtained.  We won't have a key 
record when they is a "true, honest to god" no signature message, so 
this proposal only applies when a message is "signed".  When the message 
is truly unsigned or the key record does not has the optional SSP= tag 
it would continue with the step 2/3 SSP discovery process.

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Dec 2007 14:12:16 -0800

Hector Santos wrote:
> use the benefits of SSP beyond its default behavior, it SHOULD create
> a SSP record in order to be DNS friendly and cooperative with
> verifiers with SSP support?  Is this idea stated or implied in the
> SSP-01 specs?

I don't think it says that in SSP-01.  My own view is that this is more
of a deployment issue, and more properly belongs in the overview or
deployment document than in the SSP specification itself.
>
>
> On a related note, I didn't want to bring this up before but I think
> it might be something of interest.
>
> policies only that a DKIM domain MAY expose its policy via the
> DKIM-BASE key record?
>
> directly into the SSP specification the proposal of a new DKIM tag
> that exposes strict or all domain DKIM transaction information?
[details omitted]

The cases where this might be beneficial are when there is an invalid
Author signature or when there's another signature, valid or invalid, in
the Author's domain, in all cases referencing a valid selector.  The
invalid Author signature case will probably be relatively common, but
signatures from other addresses in the domain less so.  It does seem
that this might reduce the number of SSP lookups a bit, however it would
be necessary for a domain using this extension to ensure that the SSP
information in all key records is consistent with that of the domain's
SSP record.

One potential threat occurs if a domain decides to CNAME any of its key
records to an external party.  That party would now have the ability to
publish a key record with a different (probably looser) SSP than that of
the domain's SSP record.  This shouldn't be much of a concern since the
party controlling the record can sign for the author domain anyway, but
if this is done accidentally it would leave an opening for attackers to
take advantage of the situation by adding invalid signatures referencing
the key record with the looser SSP.

The SSP extension to key records would never be sufficient; stand-alone
SSP records would need to be published as well.  I'd like to suggest
that we concentrate on the "basic" SSP concept for now and keep
optimizations such as this for discussion later.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Dec 2007 12:00:48 -0800

On Dec 24, 2007, at 2:12 PM, Jim Fenton wrote:

> The cases where this might be beneficial are when there is an  
> invalid Author signature or when there's another signature, valid or  
> invalid, in the Author's domain, in all cases referencing a valid  
> selector.

Presence of a public key at a selector plays an insignificant role in  
a signature's validity.  While the SSP draft currently attempts to use  
"on-behalf-of" the author to distinguish when SSP records are to be  
retrieved, the resulting added criteria for when a signature is valid  
is likely to be unnecessarily disruptive.

A message can be assumed to comply with either "all" or "strict" when  
the message has:

  1) A valid unrestricted signature at or above any Author's domain

  2) A valid restricted signature on-behalf-of the From header

This two part definition ensures legitimate messages with valid  
signatures are not unnecessarily classified as having invalid  
signatures.  Signing domains should not assume SSP will be applied.   
When a signing domain does not want messages to be accepted based upon  
which header their signature was on-behalf-of, the domain should not  
permit such message to be emitted.

A message sent by an office administrator on behalf of a From author  
and then signed with an unrestricted key should be seen as within the  
signing domain control and therefore compliant with any of their  
policies.  Without modifying message handling defined in DKIM base,  
signing is done by applying a signature on behalf of the Sender  
header.  This mode of handling is important, especially when only a  
Sender header is associated with an identity authenticated by the  
signing domain.  The logic of your first sentence requires an SSP  
"compliant" signature change DKIM base handling to:

  1) remain ambiguous about which header is being signed on-behalf-of
  2) lie about which header contains an authenticated identity
  3) apply two signatures, where one lies or remains ambiguous

> The invalid Author signature case will probably be relatively  
> common, but signatures from other addresses in the domain less so.

Agreed.  Why not presume when signed with an unrestricted key of the  
same domain as found in the From header, the message is to be  
considered compliant with any this domains SSP policies?

> It does seem that this might reduce the number of SSP lookups a bit,  
> however it would be necessary for a domain using this extension to  
> ensure that the SSP information in all key records is consistent  
> with that of the domain's SSP record.

You are describing a "scope" parameter added to Key records that  
restricts which headers are valid for the signature to be on-behalf- 
of.  When private keys are deployed beyond the direct control of the  
signing domain, not only a restriction on the local-part is needed,  
but that of the scope of headers signed as well.  Thus a restricted  
key (g=<local-part>) might represent an "assumed" scope parameter, as  
even a valid signature might not be compliant with a domain's desired  
policy.  An explicit scope placed within a key record could clarify  
which headers are valid for a particular key, but this would be  
unnecessary.

While appropriate for SSP compliance to limit the scope of  
"restricted" key's to being on-behalf-of just the From header, it is  
inappropriate for unrestricted key's scope to be limited in either  
which header or which local-part is signed.   In other words, SSP  
should not attempt to dictate how the i= parameter is to be used.  An  
unrestricted key should be assumed to be within the direct control of  
the signing domain, where the signing domain _MUST_ ensure their  
messages are _NEVER_ in conflict with any of their own policies.   
Policy enforcement of valid signatures by unrestricted keys is the  
sole job of the signing domain, and never something the receiving  
domain should be expected to implement.  The signing domain _MUST_  
enforce their own on-behalf-of policies when using unrestricted keys.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Dec 2007 01:29:30 +0100

Jim Fenton wrote:

> The SSP extension to key records would never be sufficient;
> stand-alone SSP records would need to be published as well.
> I'd like to suggest that we concentrate on the "basic" SSP
> concept for now and keep optimizations such as this for
> discussion later.

+1  It's kind of obvious that for *some* receivers and *some*
mails it might help to offer an "SSP-accelerator" in SPF, as
proposed by Scott (in 2006 IIRC).   No issue for this WG. ;-)

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Dec 2007 18:57:57 -0800

On Dec 27, 2007, at 4:29 PM, Frank Ellermann wrote:

> Jim Fenton wrote:
>
>> The SSP extension to key records would never be sufficient; stand- 
>> alone SSP records would need to be published as well. I'd like to  
>> suggest that we concentrate on the "basic" SSP concept for now and  
>> keep optimizations such as this for discussion later.
>
> +1  It's kind of obvious that for *some* receivers and *some* mails  
> it might help to offer an "SSP-accelerator" in SPF, as proposed by  
> Scott (in 2006 IIRC).   No issue for this WG. ;-)

Adding the scope of the headers validly signed might be something  
considered for key records.  This could rectify an error in the  
current SSP logic.  Hopefully this mistake will be fixed soon without  
altering key records.

A single TPA-SSP name association can eliminate transactions required  
to support SPF record sets.  This association can be done efficiently  
by adding a parameter to SSP records which indicates the extensions  
supported.  It seems illogical to have IP address path registration  
records support a DKIM process, nor would generating a list of IP  
addresses reduce any DKIM overhead.  If anything, DKIM in combination  
with SSP and a single TPA-SSP can supplant any benefit employing  
transactions to construct IP address path registrations.  When  
controlling back-scatter is desired, TPA-SSP already provides a means  
to validate MailFrom domains in a single transaction.  Example code  
needed to generate TPA labels will be offered shortly as well.

Dealing with abuse requires burdening the transmitter and not the  
receiver.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Dec 2007 05:35:06 +0100

Douglas Otis wrote:

> A single TPA-SSP name association can eliminate transactions
> required to support SPF record sets.

Sure, when I wrote "*some* receivers" it was about receivers
using SPF anyway, as an optional SSP-acceleration for *some*
mails (where the relevant domains happen to be identical).

> It seems illogical to have IP address path registration  
> records support a DKIM process

It might be fine for receivers supporting both anyway, they
could use DKIM PASS to overrule an SPF "false positive", and
SPF PASS to overrule an SSP "false positive".  Of course this
won't help if SSP's "1st author" (1st 2822-From) doesn't match
SPF's 2821-From.

It's a timing issue, an implementation can "see" an SPF FAIL
before DATA, and it might be interested to reject it a.s.a.p.
Scott's idea was a flag indicating "we also sign everything",
and the MX could then delay the reject hoping for a DKIM PASS.

We're deep in "receiver policy" territory here, of course an
MX supporting both SPF and SSP can use this strategy anyway
also without flag.  And with at most two DNS queries for SSP 
"accelerating" it is likely pointless.  But I'm not yet sure 
if those _ssp. label records work everywhere - for obvious
reasons SPF's hijacking of TXT records works everywhere, the
new SPF RR also has no wildcard issues (unlike _ssp. labels).

> When controlling back-scatter is desired

Yes, but that's a solved problem, don't worry about it... :-)

 Frank

---

From: Hector Santos <[email-masked]>
Date: Fri, 28 Dec 2007 04:30:10 -0500

> proposed by Scott (in 2006 IIRC).   No issue for this WG. ;-)

Not sure of what specifically you are recollecting here, but I preached 
back in August/2008 in SPF-DISCUSS the analysis for the SPF and DKIM 
association:

   http://article.gmane.org/gmane.mail.spam.spf.discuss/21503

and in thread follow ups, I provided an examples:

   http://article.gmane.org/gmane.mail.spam.spf.discuss/21526

But all that was an independent consideration and didn't attempt to 
change DKIM or SSP and/or attempt to create a dependency of mixed 
SPF/DKIM technologies.

In my view SSP is 100% related to DKIM.  SPF is not from standpoint 
DKIM/SSP must be designed without any SPF dependency.  So unless it is 
your opinion the DKIM total solution includes SPF/SENDERID, I don't 
understand why you keep injecting SPF here confusing the whole SSP/DKIM 
model which already has its own contentious issues without SPF adding to it.

I'm not suggesting implementations will not do both, and in fact, I'm 
sure most will, but they are really independent concepts and DKIM/SSP 
must stand on its own and implementations must be ready to deal with it 
independently.

My view Frank. No need to yell at me. :-)

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Dec 2007 13:57:59 +0100

Hector Santos wrote:
 
> I preached back in August/2008 in SPF-DISCUSS the analysis for
> the SPF and DKIM association:
 
> http://article.gmane.org/gmane.mail.spam.spf.discuss/21503

Sorry, I missed that.  What I was referring to was an old thread
about dkim=something or op=dkim modifiers.

> DKIM/SSP must be designed without any SPF dependency.

Sure, this subthread here was about *optional* SSP accelerators
elsewhere, e.g. in DKIM or SPF records.  I don't understand the
DKIM proposal, why would you look up DKIM for the most important
SSP case "no signature" ?  

> unless it is your opinion the DKIM total solution includes 
> SPF/SENDERID

PRA is an anti-phishing MUA gimmick based on a worldwide upgrade,
you can't do much with a PRA PASS without white list.  With an
SPF PASS you can "accept and bounce", that should be interesting
for anything you plan to do with a message, not limited to DKIM.

> I don't understand why you keep injecting SPF here

Wait a moment, adding SSP info to DKIM was *your* proposal, and
that made no sense for me.  Therefore I mentioned Scott's old
idea of an SSP-accelerator in SPF.  In 2005 you observed that
for about 80% of all mails PRA matches 2821-From, maybe it's
similar for 2821-From matching the 1st 2822-From address.  I'm
not hot about SSP-accelerators in SPF, as Jim said it's likely
too early to discuss optimizations.

> they are really independent concepts and DKIM/SSP must stand
> on its own and implementations must be ready to deal with it 
> independently.

Indeed.  As long as your bounces don't hit innocent bystanders
and as long as you don't drop legit mail do whatever you like ;-)

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Dec 2007 10:18:46 -0800

On Dec 27, 2007, at 8:35 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>>
>> It seems illogical to have IP address path registration records  
>> support a DKIM process
>
> It might be fine for receivers supporting both anyway, they could  
> use DKIM PASS to overrule an SPF "false positive", and SPF PASS to  
> overrule an SSP "false positive".  Of course this won't help if  
> SSP's "1st author" (1st 2822-From) doesn't match SPF's 2821-From.

Having DKIM "overrule" SPF's IP address path authorization failures  
eliminates the touted overhead advantage achieved basing results upon  
the MailFrom's IP address path registration.

> It's a timing issue, an implementation can "see" an SPF FAIL before  
> DATA, and it might be interested to reject it a.s.a.p. Scott's idea  
> was a flag indicating "we also sign everything", and the MX could  
> then delay the reject hoping for a DKIM PASS.

Rejections based upon the MailFrom IP address path failures,  
regardless of the asserted SSP policy, would diminish DKIM's delivery  
integrity.  TPA-SSP can better validate MailFrom and is independent of  
the registered IP address path.  By dealing with backscatter using by- 
name validation, many of the problems associated with path  
registration can be overcome, and by-name is compatible with DKIM's  
advantages.

> We're deep in "receiver policy" territory here, of course an MX  
> supporting both SPF and SSP can use this strategy anyway also  
> without flag.  And with at most two DNS queries for SSP  
> "accelerating" it is likely pointless.  But I'm not yet sure if  
> those _ssp. label records work everywhere - for obvious reasons  
> SPF's hijacking of TXT records works everywhere, the new SPF RR also  
> has no wildcard issues (unlike _ssp. labels).

A new resource record is not a solution, as both record types must  
still be published to ensure legacy compatibility.  Wildcards for any  
policy assertion requires these policy records be replicated at  
_every_ existing node, which also makes every node visible.  When a  
new RR must be introduced to publish a protocol's policy, then  
Phillip's concept holds greater promise, and does not result in  
records that must contain "everything", including the kitchen sink.

Wildcards create many problems and reduce DKIM policy coverage, as  
described in section 4.2 of SSP.  The issue involving wildcards really  
demands that SMTP should soon mandate publishing MX records to ensure  
message acceptance, at least for IPv6 in 2821bis. : )

> Yes, but that's a solved problem, don't worry about it... :-)

Sorry, but SPF neither a safe or compatible solution.  Validation by- 
name safely scales, is faster, and is compatible with DKIM.  : )

-Doiug

---

From: Hector Santos <[email-masked]>
Date: Fri, 28 Dec 2007 14:02:24 -0500

Frank Ellermann wrote:

> I don't understand the DKIM proposal, why would you look up
> DKIM for the most important SSP case "no signature" ?

You are also thinking optimization, which is good. :-)

Well, did you notice there is no such direct definition for SSP "no
signature"?

> that made no sense for me.  

Well trying to understand it first should be a prerequisite. :-)

> I'm

We were talking about about SPF or SSP-accelerators in SPF.

Read his entire response again. He provided various views including one 
that that agrees with the proposal benefits.  Once the holidays are 
over, I will raise/discuss the two new issues again.

Personally, the genera idea that when something is considered an
"optimization" therefore it should be pushed aside as an implementation
or deployment issue isn't always automatic or cut and dry. Especially
when the current deployment draft has little to no regards for SSP and 
itself also changes the semantics of DKIM signatures.

So while one might want to dismiss it as a "optimization," in my 
engineering opinion, DKIM/SSP are tied at the hip.  It is what the SSP 
proposal needs to address the lingering DNS concerns and possible 
security effects. In fact, just look at what the SSP draft TO BE DONE 
section says:

    (Unresolved Issues/To Be Done)

    Need to consider handling of multiple responses to a DNS query for
    the SSP record.

So one can't have it both ways.

SSP as a proposal, at this point needs to maximize its adoptability
effectiveness and that includes "selling" how it improves the DKIM-BASE
system.

  1) if SSP helps make DKIM-BASE "work better" and it helps resolves
     DNS caching and NXDOMAIN issues or concerns by having a
     default record, then that should be part of specification.

  2) For those DKIM people who always wanted restrictive and nothing
     but restrictive mail handling should be able to do so
     without confusing others or creating more DNS related issues.

RFC includes recommendations that are both normative and non-normative. 
There is no reason to brush aside non-normative information when it 
helps "sell" the product better.  SSP is fundamentally about the 
maximization for the efficacy of the DKIM-BASE protocol.   Thats its 
purpose and optimization is a fundamental part of the process.

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Dec 2007 22:17:35 +0100

Douglas Otis wrote:
 
> regardless of the asserted SSP policy, would diminish DKIM's
> delivery integrity.

SPF FAIL users have had it with "delivery integrity", DKIM or
otherwise, they are determined to eradicate the backscatter at
all costs.  The proposal to use DKIM PASS as second opinion is
from a receiver's POV worried about "traditional forwarding".

After the final dot of the DATA at the border is the last point
in time to arrive at a reliable decision wrt reject vs. accept.

> TPA-SSP can better validate MailFrom

| The application of TPA-SSP at the MailFrom represents an
| entirely optional strategy which may or may not prove either
| effective or practical.  The MailFrom scope is offered only
| for experimentation.

Please inform me about the outcome of the optional experiments,
RFC number, implementations, test suite, deployment, the works.
What you have at the moment is only a draft, it would be unwise
to confuse this with worldwide adoption.

> A new resource record is not a solution, as both record types
> must still be published to ensure legacy compatibility.

Existing SPF versions (in essence v=spf1 and spf2.0/pra) must do
this, future users of the now existing SPF RR are not forced to
replicate their policies in TXT records.  Or are you talking
about the problem with existing MS platforms and new RR types ?
I hope that this will go away.

> Phillip's concept holds greater promise

We failed to get this WG to support it :-( 

> and does not result in records that must contain "everything",
> including the kitchen sink.

Records can be separate while sharing an RR type.  Of course the
complete set including the kitchen sink has to fit into a reply
sent over UDP.  If that's not good enough you need a new RR type,
or a special label like _ssp.  With a new label it is not more
trivial to cover wildcards at the unlabelled domain, you have to
decide what's most important.  Apparently the SSP decision was:

"We might want lots of info" => "we cannot share an existing RR",
"it has to work with TXT" => "we need our own label", and after
these decisions wildcards are not more trivial, tough.  But one
of the two premises ("lots of info") might be wrong, so far SSP
needs about 25 bytes - ignoring [FWS] for the moment, submitted
as "SSP issue".

> The issue involving wildcards really demands that SMTP should
> soon mandate publishing MX records to ensure message acceptance,
> at least for IPv6 in 2821bis. : )

The Last Call ended 2007-12-24, and after five objections I did
not add this point again, and we failed to get support for this
2821bis issue :-(  

You can't build TPA-SSP on two rejected ideas, 2821bis will keep
its ugly address fallback also for IPv6 / AAAA.  It was a window
of opportunity because 2821 didn't mention AAAA explicitly, but
I saw to it that 2821bis does, so this window will be closed.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Sat, 29 Dec 2007 13:36:48 -0800

On Dec 28, 2007, at 1:17 PM, Frank Ellermann wrote:

> otherwise, they are determined to eradicate the backscatter at all  
> costs.  The proposal to use DKIM PASS as second opinion is from a  
> receiver's POV worried about "traditional forwarding".
>
> After the final dot of the DATA at the border is the last point in  
> time to arrive at a reliable decision wrt reject vs. accept.

DKIM requires acceptance of the message body.  DKIM's ability to offer  
reliable indications of misbehaviour will bolster that of content  
filtering results.  A connection blocking strategy fed with reliable  
information is commonly used for short periods to protect resources  
needed to process messages.  As such, DKIM can help overcome problems  
created by the unreliable application IP address path registration  
strategies.  Mitigating backscatter can be handled using TPA-SSP where  
a MailFrom's association with DKIM signatures can validate or  
invalidate issuance of DSNs.  DKIM can prove helpful at restoring  
integrity to SMTP, even after the dot. : )

> Please inform me about the outcome of the optional experiments, RFC  
> number, implementations, test suite, deployment, the works. What you  
> have at the moment is only a draft, it would be unwise to confuse  
> this with worldwide adoption.

This draft suggests a safer backscatter mitigation strategy that _is_  
compatible with DKIM, and fully independent of other strategies.

Including all used and unused client IP addresses, valid/invalid local- 
parts, handling requests, and record links within a record set has  
resulted in a bloated and incredibly dangerous sequence of DNS  
transactions.  These transactions are also highly dependent upon an  
unassured level of caching.  The "everything at once" approach  
represents a potential overhead that can well exceed that of accepting  
messages.  For DKIM to help restore SMTP delivery integrity (which can  
happen if a few things are fixed in SSP's current definition of a  
valid signature), reliance upon unreliable IP address path  
registration can and should be avoided.

>> still be published to ensure legacy compatibility.
>
> replicate their policies in TXT records.  Or are you talking about  
> the problem with existing MS platforms and new RR types ? I hope  
> that this will go away.

A query for a typically non-existent resource record places a barrier  
for unlikely adoption of a new RR.  Rather than ensuring support for  
MS RPC translations, MS might even view demise of DNS an advantage, as  
their alternative is heavily patented.

> Apparently the SSP decision was:
>
> these decisions wildcards are not more trivial, tough.  But one of  
> the two premises ("lots of info") might be wrong, so far SSP needs  
> about 25 bytes - ignoring [FWS] for the moment, submitted as "SSP  
> issue".

Concerns remained regarding enterprise support of new RRs.  SPF now  
demands at least 10 linked records be permitted for each name  
validated.  The impact of IPv6 may cause this sequence to be further  
extended, where additional transactions will also be needed to resolve  
hostname addresses.  Using SPF to validate a DKIM domain in some  
manner might then impose this 10xplus sequence for each of several  
possible signatures.   The number of overall transactions could be  
staggering.

>> The issue involving wildcards really demands that SMTP should soon  
>> mandate publishing MX records to ensure message acceptance, at  
>> least for IPv6 in 2821bis. : )
>
> The Last Call ended 2007-12-24, and after five objections I did not  
> add this point again, and we failed to get support for this 2821bis  
> issue :-(

While not imposing change when consensus is not clear is  
understandable, a lack of a discovery record for assured acceptance  
can lead to serious DNS related risks.

> You can't build TPA-SSP on two rejected ideas, 2821bis will keep its  
> ugly address fallback also for IPv6 / AAAA.  It was a window of  
> opportunity because 2821 didn't mention AAAA explicitly, but I saw  
> to it that 2821bis does, so this window will be closed.

The entire email policy concept is affected, not just SSP or TPA-SSP.   
The alternative for asserting policy without an assured discovery  
record is to walk the DNS tree for A or AAAA records.  The lack of a  
specific discovery record represents a serious architectural  
extensibility defect for SMTP!

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 31 Dec 2007 04:15:17 +0100

Douglas Otis wrote:
 
> DKIM requires acceptance of the message body.

Obviously.  Receivers will still reject messages before DATA
where that makes sense from their POV, e.g. because they use
services explained in the ASRG SIQ and DNSBL drafts, or in
the ASRG LMAP draft, i.e. what is now RFC 4405 and RFC 4408.

Hector's SMTP HEAD draft offered a kind of compromise between
before vs. after DATA, but it won't help with DKIM, and it's
not clear how to combine it with the "selective reject" I-D.

> DKIM's ability to offer reliable indications of misbehaviour
> will bolster that of content filtering results.

DKIM without SSP (or similar) doesn't have such ability.

> DKIM can help overcome problems created by the unreliable 
> application IP address path registration strategies.

DKIM doesn't come near to the envelope sender address, we
made sure that it doesn't depend on SMTP.  Backscatter is
mainly an SMTP issue (+ RFC 3798 + 3834 + sieve vacation).

> DKIM can prove helpful at restoring integrity to SMTP,
> even after the dot. : )

DKIM operates on messages (SDU, 2822), not on envelopes
(PDU, 2821).  You can use DKIM on the other side of a UUCP
link if you have access on DNS, or whereever you find a
"fresh" message/rfc822 (e.g. as MIME part), it's not based
on SMTP.  For various reasons DKIM does *not* try to solve
the SMTP issue backscatter.

> The "everything at once" approach represents a potential
> overhead that can well exceed that of accepting messages.

Receivers are free to say "enough already" when it pleases
them, in fact they MUST and SHOULD do this (RFC 4408 10.1).

IMO "a", "all", "include", "ip4", "ip6", and "redirect" are
essential for a simplified SPF.  The "ptr" is no problem,
the Authentication-Results I-D offers a similar test with
similar processing limits.  

The "exists" is rather exotic at the moment (in theory SES
is a nice idea), and tossing %{l} out, or maybe limit "mx"
to at most one per record, because the original RMX idea
makes sense, might be possible in a 4408bis.  

Nobody is going to learn new TPA-SSP tricks from scratch,
unless you go to draconian simplifications like "nobody
must send from an MTA to an MX of a 3rd party, when that
MTA isn't listed as MX of the sender".  This just won't 
fly, no matter how long we could argue that it's the idea
of an STD 10 "MX" - I'm not even sure that it's the case.
 
> reliance upon unreliable IP address path registration 
> can and should be avoided.

Without time travel and removing RFC 1123 5.3.6(a) before
it was published all you can get is "BTNRP", better than
no reverse path (i.e. SPF).  If some senders get their
"permitted IP enumeration" wrong that is no problem for
receivers, it's a problem for these senders, they fix it.

 [MS issue with new RR types]
> MS might even view demise of DNS an advantage, as their
> alternative is heavily patented.

Sometimes they're forced to adopt standards if they don't
want to lose market share.  Does this issue still exist in
Vista, or does it only affect XP and older MS platforms ?

>> one of the two premises ("lots of info") might be wrong,
>> so far SSP needs about 25 bytes - ignoring [FWS] for the
>> moment, submitted as "SSP issue".
 
> Concerns remained regarding enterprise support of new RRs.

We all know that the SPF RR has an "MS-compatible" sibling.

At the moment "sender policy framework" stands for "we can
do 'sender permitted from' or even 'purported responsible
address', and HELO", not much for a wannabe-framework.  It
is kind of obvious to add SSP *IFF* it fits.  RFC 5016 tries
to make sure that it won't fit (5.3 point 5), but IMO nobody
cares about cryptic abbreviations in a text-like DNS record.  

Of course it is good to use readable and/or intuitive terms 
while talking about such abbreviations... :-)

> SPF now demands at least 10 linked records be permitted
> for each name validated.

You can have *at most* 10 "redirect".  As you well know, I 
deleted various synonyms for "intentionally telling what is
known to be not true".  If you eat up the overall limit 10
for "redirect" you have no "a", no "mx", no "include", etc. 

The "redirect" is a v=spf1 and spf2.0/* feature, adding SSP
to the SPF RR introduced by say v=ssp1 would define its own
syntax, for 25 bytes it doesn't need a "redirect" feature -
it would need the 25 bytes in the RR set (shared with SPF).

> The impact of IPv6 may cause this sequence to be further  
> extended

Nonsense, with ten "redirect" you have at least 4500 bytes
to enumerate permitted IPs.  You can and should aggregate
them to CIDRs, it is no problem if you permit many IPs which
are never sending mail as long as they are your IPs or known
to behave.

Besides this "redirect" business has nothing to do with SSP:

Assuming SSP does share the SPF RR, and that for a given
SPF RR set the v=spf1 and spf2.0/* records already use the
UDP limit (~450), then it would be necessary to split one
of these v=spf1 or spf2.0/* records with "redirect" to make
room for the 25 bytes in a v=ssp1 record.  They could also
decide that the PRA experiment is now finished and pull the
spf2.0/pra record to make room for v=ssp1.  After all SSP
is supposed to be "better" than spf2.0/pra, isn't it ?  Of
course I'm not convinced that "1st author" is a sound idea.

> Using SPF to validate a DKIM domain in some manner might
> then impose this 10xplus sequence for each of several  
> possible signatures.

Nobody proposed to use SPF to "validate a DKIM domain in
some manner".  SPF validates envelope sender addresses, it
allows "accept and bounce" after a PASS.  SPF is for SMTP,
not for DKIM.  If you reject a SSP FAIL at your border you
don't need SPF, neither the protocol(s), nor the record(s).

I proposed to put the SSP info into a separate DNS record
in the existing SPF RR set.  You don't need to look at any
v=spf1 or spf2.0/* record after a query=spf, you'd look
for the v=ssp1 record.  

>>> The issue involving wildcards really demands that SMTP
>>> should soon mandate publishing MX records to ensure 

>> The Last Call ended 2007-12-24, and after five objections
>> I did not add this point again, and we failed to get
>> support for this 2821bis issue :-(

> understandable, a lack of a discovery record for assured
> acceptance can lead to serious DNS related risks.

Let's say that there are still more pressing problems with
DNS attacks than your idea to abuse SPF to query addresses
in ten MX sets.  RFC 4408 is still the only RFC I'm aware of
mentioning that MX queries can be an issue, with MUSTard and
a SHOULD to mitigate it.  If that turns out to be not good
enough 4408bis will have to fix it, e.g. as noted above.

> The entire email policy concept is affected, not just SSP
> or TPA-SSP.  The alternative for asserting policy without
> an assured discovery record is to walk the DNS tree for A
> or AAAA records.  The lack of a specific discovery record
> represents a serious architectural extensibility defect 
> for SMTP!

Yes, that's what SPF is for.  Trying to "reinvent" it again
is a dubious plan, simplifying it is more attractive.

 Frank