Subject: [ietf-dkim] Issue #1534: Applying SSP to sub-domains does not work

From: Jim Fenton <[email-masked]>
Date: Mon, 17 Mar 2008 11:24:46 -0700

Eric points out, correctly, that issue 1534 fell through the cracks when 
I was preparing the slides for last week's meeting, so we didn't discuss 
it.  I had intended it to go into the "medium" category, but we 
shouldn't close it without the opportunity for some discussion.

The text of the item from the tracker is:

>
> http://mipassoc.org/pipermail/ietf-dkim/2007q4/008437.html
>
> >> s The signing practices apply only to the named domain, and not
> >> to subdomains.
> >
> > So this is intended to overcome the problem of not being able to use
> wildcards?
> >
> > What is the query behavior that validators need to use, to discover this
> > record, when they start with a message having a deeply-nested From field
> > domain name?
>
>
> To the extent that the above is not sufficiently clear:
>
> There is not way to properly enforce or even discover the semantics of
> this flag, in the general case of sub-domains. This option needs to
> removed or be specified in a way that works.

My response is that the upward query, and the t=s flag (which provides a 
way to limit the application of ASP outside the immediate domain) are 
not intended to cover subdomains.  Rather, they provide a way to cover 
terminal leaf nodes within the domain (e.g., hostnames) that can be used 
as domains (in the 2822 sense) in email addresses.

While the need to cover this hole exists primarily as a consequence of 
the use of hostnames (vs. MX records) as email delivery points, this 
problem can't be solved by requiring MX records for domains publishing 
ASP, as was suggested in Issue 1547.  Suppose that a message from 
blarney.example.com was being ASP checked, and we don't know anything 
about that domain.  First you look for 
_asp._domainkey.blarney.example.com TXT, and if you don't find it, let's 
say you do an MX query for blarney.example.com, and it isn't found either.

The possibility exists that blarney.example.com is a host that receives 
its mail using its A record, and just hasn't published an ASP record.  
At this point you would need to conclude, unless the MX query resulted 
in an NXDOMAIN error, that blarney.example.com has an "unknown" ASP.  
The requirement for an MX record would apply when the ASP record does 
exist, but in that case you wouldn't need to query for it anyway.

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 17 Mar 2008 15:31:27 -0400

You need to throw way the whole idea of mandating an MX.   MX is for 
OUTGOING mail.  DKIM is for IMCOMING mail.

MA applies to the x821.MailFrom domain period.  Attempting to tie to the 
the 2822.FROM is arkward and the proposed solution is isolated to a few 
systems that believe they have a total solution for the world.

-- 
Sincerely

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Mar 2008 16:51:39 -0700

On Mar 17, 2008, at 12:31 PM, Hector Santos wrote:

> OUTGOING mail.  DKIM is for INCOMING mail.

While MX and A records are used to discover inbound SMTP servers, they  
can also play a role in determining whether the domain might also be  
publishing DKIM related policy.

A default behaviour used by some MTAs is to log PTR records found  
within the in-addr.arpa reverse zone for those SMTP clients attempting  
to connect.  In many cases, DNS for this zone is not configured  
properly, either though the lack of delegation or authoritative  
responses.  Errors within the reverse zone are common, where resulting  
processing delays often represent a significant portion the MTA's  
overhead.  Despite its high burden, acceptance often does not demand  
the reverse zones be properly configured, since forward and reverse  
zone are often managed by separate entities.

However, acceptance of a message may demand an MX or A record be  
published within the forward zone.  While there are excuses for poorly  
configured reverse zones, fewer exist for the forward zone.  MX or A  
records published in the forward zone are necessary to discover  
receiving MTAs.  As a result, some MTAs qualify acceptance by testing  
whether originating domains publish a requisite A or MX discovery  
record.  While these records are not essential for receiving a  
message, these records are essential for any subsequent reply.  An  
inability to reply may disqualify the domain as being considered  
valid.  In addition, checks within the forward domain often involve  
less process time overhead.

By mandating MX records in conjunction with DKIM policy records,  
simpler tests can be applied when receiving a message lacking a DKIM  
signature that is within the From header domain.  This category will  
represent the majority of messages received.  To cope with wildcard,  
such as use of a xptr scheme or A record substitution, an empty policy  
record in conjunction with the absence of an MX record can define a  
policy state disavowing DKIM/SMTP.  This state avoids reliance upon  
detecting the non-existence of the domain.

In addition, assessing DKIM policy and MX record presence eliminates a  
need for any domain tree walking.

The following tests can be made when a message is not signed by the  
 From domain which starts with a transaction requesting the MX record.

1) When no MX record:
   A) Query for policy record.
     i) When policy record (even empty), reject message.
     ii) When no policy record, query for A record.
        a) When no A record, reject message.
        b) When A record, assume no policy.

2) When MX record:
   A) Query for policy record.
     i) When no policy record, assume no policy.

This Policy/MX record approach allows dealing with wildcards by  
publishing *.@ TXT "", or by requiring existing nodes contain an empty  
policy record such as _adsp.example.com TXT "".  This combined record  
approach requires a few domains seeking DKIM policy protection to  
ensure a minimum number of DNS transactions are required by  
recipients.  The goal is not to make publishing easier, but to ensure  
determination of the presence of policy requires the fewest number of  
transactions possible without affecting a parent domain or requiring  
the use of wildcards.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 17 Mar 2008 20:59:30 -0400

Douglas Otis wrote:
 > [SNIP]

We know all that and any vendor can come with a total solution.

Like I said, it becomes awkward and also half baked because in reality 
the real contact address could be the Reply-To: header, if any.

The technical reality today is such that all mail responding software 
are required to follow the RFC based mail system rules for responding to 
an originating address:

    Use Reply-To: field. if not available, fall back to From:

In other words, in practice, the only thing that is required for a valid 
response is that Reply-To works, if any and if not, then use From:

So unless the Reply-To: header is taken into account in the "Total 
DKIM+POLICY Solution", it really is not addressing the entire issue.

This is also one area I believe SENDER-ID fails with its protocol theme 
of depending on some PRA that does not take into account the Reply-To 
address.

Think about it:

Assume a message gets to a user and it passes all the CBV, RBL, SPF, 
SENDER-ID, DKIM, ASP POLICY tests or at least they don't raise any 
red-flag, if the Reply-To field is bogus, then it may be all for 
nothing.  The user may be hosed.

What this might suggest

For the DKIM signers:

    If a Reply-To: header is presence, it MUST be included in
    the list of hashed headers for the DKIM signature.

For the DKIM verifier:

    If a Reply-To: header is presence but NOT part of the
    the hashed headers for the DKIM signature, then the
    message SHOULD BE viewed as SUSPICIOUS.

Note how POLICY does not even play a role.  It is the kind of filtering 
rules or ideas that will be explored when (not if) DKIM becomes a major 
part of the ABUSE process

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Mar 2008 01:00:47 -0700

On Mar 17, 2008, at 5:59 PM, Hector Santos wrote:

> Douglas Otis wrote:
>>
>> While MX and A records are used to discover inbound SMTP servers,  
>> they can also play a role in determining whether the domain might  
>> also be publishing DKIM related policy.
>
> The technical reality today is such that all mail responding  
> software are required to follow the RFC based mail system rules for  
> responding to an originating address:
>

DKIM permits reliance on the signing domain.  Although DKIM policy is  
not directly related to SMTP operations, a domain publishing SMTP  
discovery records confirms the validity of the From domain, whose  
policy is in question.  Discovery records can be used to ascertain  
whether policy should be expected, and conversely permit presence of a  
policy record in the absence of MX records to disavow public use of  
the domain.  In addition, this disavowal is determined without  
dependence upon record content.

A receiver must invest a fair amount of resources to determine DKIM  
signature validity.  Confirming validity of the domain prior to  
cryptographic processing offers both receivers and parent domains  
added protections.  Of course, private relationships between  
transmitter and receiver alleviates the need to confirm the  
originating domain's validity and even permits use of other  
transports.  However, DKIM ADSP policy records should only pertain to  
messages publicly delivered to SMTP related destinations.  While other  
protocols might be converted to SMTP, DKIM policy may interfere with  
their acceptance.

> In other words, in practice, the only thing that is required for a  
> valid response is that Reply-To works, if any and if not, then use  
> From:
>
> This is also one area I believe SENDER-ID fails with its protocol  
> theme of depending on some PRA that does not take into account the  
> Reply-To address.

Sender-ID attempts to relate PRAs with IP addresses of all SMTP  
clients that might be used.  This relationship depends upon heuristics  
that, in some cases, conflicts with established practices and  
standards.  The goal of DKIM is to retain validity of the signing  
domain in concert with established practices and standards.  Mailing  
lists that alter message content are not exceptions, but do represent  
cases where policy gains importance.  In this case, your concern  
regarding the change made in definitions for "strict" is justified,  
IMHO.

> nothing.  The user may be hosed.

As you have noted, a DKIM signature is able to block the use of the  
Reply-To field.  As trust moves to the DKIM signing domain, the domain  
should not employ length parameters or leave critical header fields  
open.  To deal with mailing lists, the TPA-SSP draft will be updated  
with a utility that generates third-party authorization labels.  IMHO,  
third-party authorization scales far more economically and offers a  
much safer solution for mailing lists and third-party providers.  The  
authorization scheme is transparent to most users, however who signed  
the message remains easily determined.  Authorization places fewer  
eggs in the same basket.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 19 Mar 2008 10:17:46 -0700

> OUTGOING mail.  DKIM is for IMCOMING mail.

We agree on this.  Sorry if my long-winded explanation of why doesn't 
make that clear.
>
> MA applies to the x821.MailFrom domain period.  Attempting to tie to 
> the the 2822.FROM is arkward and the proposed solution is isolated to 
> a few systems that believe they have a total solution for the world.

That's another good reason that hadn't occurred to me.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 19 Mar 2008 10:22:33 -0700

> as domains (in the 2822 sense) in email addresses.

In an IM discussion, Eric pointed out that the current text for the 
"t=s" flag confuses this, because it says, "...named domain, and not to 
subdomains."  This should probably read, "...named domain, and not to 
terminal nodes (e.g., hostnames) within the named domain."

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Mar 2008 15:30:52 -0700

On Mar 19, 2008, at 10:17 AM, Jim Fenton wrote:

> Hector Santos wrote:
>> You need to throw way the whole idea of mandating an MX.   MX is  
>> for OUTGOING mail.  DKIM is for IMCOMING mail.
>
> We agree on this.  Sorry if my long-winded explanation of why  
> doesn't make that clear.

While email-addresses carried within a message aren't necessarily  
related to SMTP, the impetuous for DKIM is to deal with spoofing of  
publicly transmitted messages over SMTP.  While only MailFrom is  
required to be compatible with SMTP, the From is not.  However,  
development of the DKIM policy should clarify it pertains to messages  
sharing SMTP destinations.  Any originating email-address is only  
valid when the transport is able to carry the message to its  
destination.  In the case of SMTP, this requires publishing discovery  
records, which currently are MX, and A records.

>> MA applies to the x821.MailFrom domain period.  Attempting to tie  
>> to the the 2822.FROM is arkward and the proposed solution is  
>> isolated to a few systems that believe they have a total solution  
>> for the world.
>

This is a good reason to specify the scope of the policy.  What other  
transports operating independently from SMTP will make use of DKIM  
ADSP policy records?  Once those attempting to discover policy are  
able to understand the policy only relates to SMTP sources and  
destinations, then and only then can discovery records play a role in  
validating the domain.  If there is to be any hope in defending the  
DKIM process, determination of a valid domain is likely to be  
essential.  As abuse increases, this aspect of the SMTP protocol  
becomes increasing critical.

-Doug