Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandateto r

On Feb 16, 2008, at 8:24 AM, Hector Santos wrote:

> > Technically, this approach creates a problem when the domain uses  
> > DKIM and publishes the policy record, but then does not support SMTP.
> Well, I saw that thread. My input: Since the 80s we had multi-mail  
> format networking/gateway products that has served millions over the  
> course of that time. I think we have a pretty good idea of the  
> practical aspects of it.  Primarily, the idea of attempting to  
> obtain gateway perfection and persistent mail integrity, DKIM or  
> not, during transformation processes is expecting a bit much. :-)
Other "public" protocols may implement DKIM where messages do not  
enter into SMTP infrastructure.  As a result, the future may require  
policy be based upon which "public" transport carrying the message,  
and not treat DKIM as only protecting messages related to SMTP+  
infrastructure.
> Preserving MIME tells our gateway to import and save mail in raw (as  
> is) or save it in our local proprietary format (text with separated  
> attachments).  Preserving MIME has only become important over the  
> years as our customers as their user's began to use offline readers  
> more, e.g. POP3 and News Readers.   As the era of HTML mail is more  
> acceptable, that is another reason users are turning on this  
> option.   But there are customers, for security reasons, who don't  
> even offer the option to their users and save the user's mail in our  
> native format.  This is important when it comes the type of MUA  
> question.
A less secure means to deal with "delivery" corruption would be to  
rely on something like the Authentication-Results headers assured to  
have been filtered at border MTAs.  It will be awhile before this  
approach can be trusted by generally distributed applications.
> Keep focus. DKIM is for a x822 mail system and IMV regardless of how  
> x822 mail is sent, moved, gated, transformed, and re-transformed, it  
> still has to be a x822 system when it finally gets to where ever.
Domains may wish to declare "all" of their SMTP messages will be  
signed, but at the same time are not sign their News or IM messages.   
Domains may also wish to declare News or IM messages are not sent to  
limit a risk caused when gateways apply a different policy for  
messages carried over different "public" transports that are then  
introduced into SMTP+ infrastructure.  As such, "all" needs to be  
qualified.   Either policy records scope the "public" transport, or  
the policy record must be limited to messages destine for SMTP  
infrastructure, where all other "public" transport policies that do  
not enter into SMTP infrastructure are published separately.  Keeping  
policy in one record would help simplify the application of policy at  
"public" protocol gateways, otherwise DKIM policy must be published  
separately and likely will be structured differently.
With the scoping information, gateways bridging other "public"  
protocols would need to:
 a) apply policy based upon the destination protocol (likely, but  
might cause some messages to be considered non-compliant)
 b) internally track and display the "public" reception protocol  
(unlikely, but the most tolerant approach)
> > When their messages are converted by a protocol gateway to SMTP, a   
> > policy/discovery record check would detect SMTP is not supported.
> I think if you are proposing a method for a domain to declare a  
> policy that says:
>  "Do not expect any mail purported to be from me to originate from a  
> QWK, Fidonet, NEWS (NNTP) or XYZ protocol posted system"
> while it sounds like a good idea, I think it is an overkill and I  
> believe you can the same benefits by using policies that restrict  
> 3rd party signatures.
When an expectation of seeing a First-Party signature causes a message  
to be categorized as non-compliant, then this expectation needs to be  
calibrated with the "public" transport or communication will become  
disrupted needlessly.  Policy based upon the "public" transport  
appears to be essential, otherwise DKIM is not DKIM when signing an IM  
or News message.
> > DKIM has value at the MUA where scaling and overhead is much less  
> > of a problem.
> It depends. What kind of MUA are you referring to?  Online or Offline?
>
> You see, some vendors have to deal with design implementations for  
> many  mail reading device methods, online and offline.   An Offline  
> MUA has different considerations than an Online MUA.
> Should we ignore DKIM for users who want to pickup their mail via  
> POP3? and just think about the online users?
> I think a good reason for the chaotic discussions here is that we  
> subjective product designs that is imposing their own feature list  
> on everyone else!!
An extension supporting off-line message validation could offer an  
Authentication-Results header that includes a declaration of the  
"public" transport, related public keys, and policy.  Whether that  
ever happens depends upon the marketplace.  Most of free and low cost  
solutions are "on-line", where a "check it yourself" plug-ins is  
already available.
> We should instead focus on the functional and logical points of the  
> fundamental protocol and let implementators decide how it best fits  
> their product lines.
Agreed.

> Instead we get people mandating you can't do this or that, which  
> might be ok, if it made sense and had considerations for the general  
> case of systems out there.

DKIM may provide a basis for reputation, replacing use of the IP  
address.  This becomes more important as IPv6 use increases.
<rant>
DKIM should have provided a simple autonomous means to authorize Third- 
Party providers.  Expecting Third-party providers to hold thousands of  
domain's private keys within on-line servers is unwise from a security  
standpoint.  As most domains are using third-party providers, setting  
up DNS delegations, CNAMEs, exchanging keys, and applying customer  
specific signatures are expensive to manage, error prone, in addition  
to being unsafe.
</rant>

> It really isn't that hard.  Either you sign or you don't.  That idea  
> is vendor product independent.  All I want to know is what the  
> domain intended and expected when we are asked to begin looking at  
> this new level of mail information.
>       "ok, I looked, I see, now what? What I am doing this for?"
>
> It is really a simple concept.
>
> Did you always expect a 1st signature?  Yeah? Ok, well I don't see  
> one, so reject the message.  Sometimes?  Ok, fine. Status Quo.
An assurance of guarding the original signature had been the "strict"  
assertion.  This changed into "Discardable, don't even bother to  
reject" and is worthless for the category of messages where a "strict"  
assertion could have been beneficial.
> Did you expect a 3rd party signature?  No?  Ok, reject it.  Don't  
> care? ok, fine. Status Quo.
This statement is confusing.  Do you mean:

a) that a signature added to an already signed message leads to  
rejection?
b) that the domain signed, and when this signature is damaged or  
removed, there should be an acceptable Third-Party signature added?
If you meant "b", then I would agree.

> etc, etc.
>
> I really don't see why it matters from where it sent and how.  Do  
> you have a preferred type of burglar knocking on your door? <g>
Many different doors could be helped by DKIM.  While there might be an  
expectation that those knocking at the front door will validate their  
affiliation, there may be different expectations for those at the back  
door.  The difference might be as simply as not buying wares from  
those at the back door.  When someone escorts them to the front door,  
they might be asked to validate their affiliation, although likely  
unprepared to do so.  While moving everyone to a common doorway may  
seem ideal, this creates a significant problem when the front door  
carries a greater obligation.  Different doors need different policies  
when there are different levels of trust based upon the door used.  At  
some distant point in the future, perhaps all doors will be treated  
the same, but time has not arrived.
-Doug


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