Comment on RE: [ietf-dkim] 1365 yes/no

[Douglas Otis]

On Fri, 2007-03-02 at 07:00 -0800, Hallam-Baker, Phillip wrote:
> > [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Steve Atkins
> 
> > It's been out of scope since day one. The argument for 
> > keeping it has been "Yeah, it's out of scope, but what the 
> > hell, we're throwing stuff that's far less useful into the 
> > pile of stuff. At least this one piece has some conceivable 
> > real world use, lets keep it."
> 
> I agree, but that is the reason that I don't want to open up that
> discussion now.

Rather than an assertion of "Never Sends Email" an assertion of "Never
sends DKIM Signed messages" would be of value to domains. This should
also be very much in scope or charter.

Perhaps this places the domain on an accreditation list as such to
preclude DKIM related traffic, while at the same time allowing
recipients to immediately reject any signed message as those spoofing
their domain.  This would help ensure bad actors are defeated before any
damage is done.

Combining "Always Signs" with "Never sends DKIM Signed messages" may
also mean "Never sends messages".  Oh well.

> What I would like to do is to get a policy framework described that
> actually works and then have an open discussion on additional policy
> statements. Otherwise what happens is that we end up with a scheme
> that only addresses the low hanging fruit that was obvious at the
> time. I want a more systematic approach.

It should also be kept simple, and not evolve into a macro expanded
language resulting in hundreds of subsequent DNS transactions consuming
none of the sender's resources beyond the initial query. : o

> I do not think that the argument that SSP/SenderID has precedence here
> is actually very convincing. It might have been convincing if they had
> adopted a prefix scheme or if they had managed to get to their work to
> proposed standard.

I was unhappy with the WG closing when it did.  The group might have
been able to revolve the major DDoS and security threats imposed by the
scheme.  As it is now, this past work remains a threat should it ever
become widely adopted as experiment.

> As it is I would prefer to work on the basis that DKIM is going to
> define THE authoritative outbound email policy which might in turn
> mention the existence of an SPF record. This makes a lot of sense
> since we have the opportunity to make the discovery scheme work
> properly. 
> 
> So the sorts of thing I would like to see in the outbound email policy
> record is:
> 
>     DKIM
>     DKIM-TEST
>     NOMAIL
>     PHISHING-TARGET
>     SPF

I can agree with you up to the point where you wish to list SPF.  I
would rather see an effort made to replace the dangerous SPF lists with
a name based scheme on perhaps the use of APL RRs instead.  By all means
don't entrench an idea that has come of the rails.

-Doug