Subject: [ietf-dkim] RE: draft-dkim-pcon

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 15 Jun 2006 18:32:54 -0700

> From: Douglas Otis [mailto:[email-masked]] 

>  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. 

Clearly there needs to be a means of securing referenced content but that is a well understood problem. A URL plus a digest of the linked content for example.

> 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?

It would appear that your proposal would by your own definition be highly reckless.

> 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.  

No it can't. The attacker can strip out the signature entirely.

> 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.

This mechanism is already possible today, just make ldap.verisign.com your root for downloading policy data.

For some reason the market does not seem to be too keen on that idea.

I don't think they will want MAPS as their root either. 

_______________________________________________
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 22:58:16 -0700

On Jun 15, 2006, at 6:32 PM, Hallam-Baker, Phillip wrote:
>
>> From: Douglas Otis
>
>> 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.
>
> Clearly there needs to be a means of securing referenced content  
> but that is a well understood problem. A URL plus a digest of the  
> linked content for example.

The idea of a URL concept exists within the CERT RR and seems to be a  
reasonable extension that might be included within the key, for  
example.  Would you agree, as it currently stands, a wildcard is not  
practical for ensuring any sub-zone has a policy?  Changing the way  
DNS works also seems out of scope for this WG.

>> 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?
>

There might be a method that exposes a limited portion of the  
information in read only form.  You may have not noticed the question  
marks.  This was asking for your take on what would be a suitable  
server, as DNS appears ill suited for publishing the amount of data  
required for many applications within a common record.  Attaching  
appendages at each label also transforms a label tree into a  
directory structure, which is why LDAP came to mind.  You mentioned  
the use of a URL, but to what type of server?

>> 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.
>

A message with only a deprecated signature should be considered not  
signed, thus any non-deprecated signature "striped out" would nullify  
a deprecated signature.  Once both signer and verifier upgrade, the  
downgrade attack is eliminated.  Until the verifier upgrades, a down  
grade attack is not an issue.  Messages with a signature using an  
unknown service should be marked with a red 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.
>
> This mechanism is already possible today, just make  
> ldap.verisign.com your root for downloading policy data.

This was not a suggestion for that type of service.  Of the millions  
of domains, a relatively small percentage of transactional domains  
are being attacked.  A community effort similar to http:// 
adblock.mozdev.org/ could construct a user modifiable list of popular  
transactional domains.  A user could include less popular domains  
confirmed by a pass-phrase from web-site using a certificate, while  
avoiding a need for this effort in the majority of cases.  As an  
alternative, this could also become an extension of the address book  
that annotates messages based upon a list of signing domains.  The  
address book could be setup by way of an LDAP server, within a  
corporate network.  A policy record offered by a bad actor might  
indicate any number of hoops an email-address must jump through.  An  
obstacle course offers little in the way of protection, once signed  
messages become the norm for trusted transactions.  A list of popular  
transactional domains offers proactive protections without expensive  
surveillance and similar domain acquisitions.  Little else seems  
needed.  Guidance with respect to what is normal for the signing  
domain could be included within or adjacent to the key.

-Doug