Last Call: draft-ietf-dkim-ssp-requirements (Requirements for a DKIM Signing Practices Protocol) to Informational RFC

Douglas Otis <dotis@mail-abuse.org> Fri, 29 June 2007 04:30 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I487r-0002mz-AF; Fri, 29 Jun 2007 00:30:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I487p-0002ln-Sk for ietf@ietf.org; Fri, 29 Jun 2007 00:30:29 -0400
Received: from harry.mail-abuse.org ([168.61.5.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I486r-0008Mo-SS for ietf@ietf.org; Fri, 29 Jun 2007 00:30:29 -0400
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 4B73241427 for <ietf@ietf.org>; Thu, 28 Jun 2007 21:29:29 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: <071001CD-80B9-4487-A54A-C07370CAC6EF@mail-abuse.org>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
To: IETF General Discussion Mailing List <ietf@ietf.org>
From: Douglas Otis <dotis@mail-abuse.org>
Date: Thu, 28 Jun 2007 21:29:49 -0700
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Subject: Last Call: draft-ietf-dkim-ssp-requirements (Requirements for a DKIM Signing Practices Protocol) to Informational RFC
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

This draft lays out what is destine to become email acceptance  
criteria based upon DKIM signing practices.  DKIM depends upon public- 
key cryptography and uses public keys published under temporary  
labels below a _domainkey domain that must be at or above the  
identity being signed to meet "strict" acceptance criteria.  Once SSP  
is deployed, those wishing to benefit from DKIM protections must  
ensure their messages meet the "strict" expectation of a signature  
added by a domain at or above their email-address domain.  This  
"strict" practice is the only significant restriction currently  
anticipated by these SSP requirements.

What is missing as a requirement in this document that would offer a  
practical means to facilitate meeting the "strict" requirement  
established by SSP itself.  Currently this requires either some type  
of undefined exchange of keys, delegation of a DNS zone at or below  
the _domainkey label, or a CNAME DNS resource record tracking an  
email provider's public versions of the public key they use, in  
conjunction with some agreed upon domain selector and the customer's  
domain reference placed within the signature.  None of these  
solutions are not either very practical or really all that safe.   
This approach also obscures who actually signed the message and on  
who's behalf.

There is a requirement that could offer a solution that is both safe  
and scaleable.  This requirement would remove any necessity to use ad- 
hoc exchanges of keys, delegation one's DNS zone, or setting up  
fragile CNAMEs coordinated at the customer's domain, tracking the  
selectors and public keys used by "authorized" email providers.  The  
requirement is to facilitate the authorization of "third-party"  
domains by name.  This can scale and would be far safer and easier to  
administer as well.

There is a draft that illustrates how this might work for SSP.

This draft has not yet reached the internet-draft directory, so here  
is a copy that can be viewed now.

http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.txt
http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.html

-Doug





  

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf