Subject: [ietf-dkim] Considerations for Development of DKIM Policy Language

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Jun 2006 17:21:35 -0700

Attached is the set of points I think are relevant to the DKIM policy discussion.

It is in PDF. There is also the obligatory copy in TXT format for the drafts editor and those of you still using punch card readers that don't support arial font.

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 15 Jun 2006 15:30:18 -0700

Use of wildcards for locating policy records is reminiscent of  
concepts applied to the then (barely used) TXT resource records, but  
now it is the (barely used) PTR resource record.  Wildcards have  
limitations necessitating inordinate replication at every instance of  
an existing name.  A common policy record used with many applications  
also seems unlikely to fit within a 512 byte DNS message constraint,  
and imposing a linking script is highly reckless from a security  
standpoint.  It seems a new policy service is really needed, rather  
than new DNS policy resource records or new methods for handling  
wildcards.  What existing server would be suitable?  LDAPv3 (RFC3377)  
referenced from the email-address domain SRV record?

DKIM provides a valuable service without attempting to accommodate  
per-user policies via DNS.  The down-grade attack affecting S/MIME et  
al, can be avoided by incorporating a version "deprecation" ('d')  
flag.  Lists of trusted signing domains replace a need to separately  
discover a less meaningful domain policy records.  Bad actors are  
just as capable at publishing policy records.  A trusted list avoids  
look-alike domain attacks and excessive traffic hunting for  
sporadically published records.  Trusted list also offer a safe basis  
for annotating messages.  It seems that mechanisms for accessing  
trusted lists (an element or extension of the address book) within  
applications protocols such as IMAP would be more productive  
extending the value of the DKIM signature.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 15 Jun 2006 17:02:17 -0700

> Attached is the set of points I think are relevant to the DKIM policy discussion.
Phill,

A few comments below.  Hope I'm not too late if you're submitting this
as an individual I-D this week.

Page 1 expires in December, and all the other pages expire in August,
according to the page footers.

Use of the word "policy".  There are so many things that are called
"policy", and I'm not sure which ones you mean here.  You might want to
introduce what's included in that definition, and importantly what's
not.  An example of what's not might be a security policy saying that
all computers connected to your LAN must be running current anti-virus
software.  There's also the concern about how imperative (vs.
declarative) such policies may be, given the recipient's freedom to do
as they choose and possible local legal considerations.  That's why I
expect we'll end up with the word "practices".

Section 2, paragraph 1.  SSP (currently) stands for "Sender Signing
Policy".  You might also want to add a reference to the I-D.

Section 2, paragraph 5: SIP Identity is another example of a protocol
that might benefit from layered policy/practices/whatever.

Section 3.1, paragraph 2: What do you mean by "constant recourse"? 
Later in the section, what constitutes a change to DNS infrastructure? 
Is creation of a new RR included?

Section 3.3 example: Why can't this sort of information be included in
key records published by the domain?

Section 3.4, paragraph 1:  "principle" -> "principal"  As you later
mention, even if a new RR is defined, that doesn't remove the need for
heuristics or search strategies (although they may be simpler).

Paragraph 2, what you mean by the "dynamic DNS component"?

Policy discovery strategy example: As SSP is currently written (subject
to change, of course!) the lookup would be to
_policy._domainkey.alice.example.com.  Alice is a subdomain, right, and
not that person at example who so often tries to communicate securely
with Bob?  The example doesn't describe what happens if the result is
NXDOMAIN vs. if it's NOERROR with no answer (or is this the same?)

I'm really confused as to why the use of a PTR would help here.  If
example.com wants to publish a policy, and some host named
alice.example.com exists,  and a message is sent from
[email-masked], it still won't find example.com's policy.  We
don't want to require that an extra record be published with every A
record in the domain!

In step 3 of your example, is this the point at which the policy for
DKIM is differentiated with that of other services?  Does _dkim become
_emailtls to retrieve the policy having to do with use of TLS by MTAs?

Section 4.1, DKIKM -> DKIM

Hope this helps; this was a quick and not-so-thorough review.

-Jim