[ietf-dkim] Re: draft-dkim-pcon

[Douglas Otis <[e-mail]>]

On Jun 16, 2006, at 7:34 AM, Hallam-Baker, Phillip wrote:

>> 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.
>
> Read the draft. It solves every requirement

In addition to usurping the use of the PTR record, this solution  
requires placement of a wildcard domain name containing a PTR RR at  
every label.  DNSsec indicates the synthesized labels needed for  
checking the signature.  Complete coverage with wildcard domain names  
will tend to expose existing labels.  This seems rather impractical.

Not that this appears to be practical, rather than usurping the PTR  
record, perhaps a CNAME might be a practical solution.

See:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard- 
clarify-11.txt

-------
3.3.3 Type Matching

      RFC 1034 concludes part 'c' with this:

#            If the "*" label does not exist, check whether the name
#            we are looking for is the original QNAME in the query
#            or a name we have followed due to a CNAME.  If the name
#            is original, set an authoritative name error in the
#            response and exit.  Otherwise just exit.
#
#            If the "*" label does exist, match RRs at that node
#            against QTYPE.  If any match, copy them into the answer
#            section, but set the owner of the RR to be QNAME, and
#            not the node with the "*" label.  Go to step 6.

     The final paragraph covers the role of the QTYPE in the lookup
     process.

     Based on implementation feedback and similarities between step
     'a' and step 'c' a change to this passage has been made.

     The change is to add the following text to step 'c' prior to the
     instructions to "go to step 6":

              If the data at the source of synthesis is a CNAME, and
              QTYPE doesn't match CNAME, copy the CNAME RR into the
              answer section of the response changing the owner name
              to the QNAME, change QNAME to the canonical name in the
              CNAME RR, and go back to step 1.
------


> The DNS wildcard mechanism is not defined in a manner that is ideal  
> for the type of administration we need.
>
> Changing the DNS protocol is outside scope, changing the DNS  
> infrastructure is something we have done already.

Agree on both points.


>> You mentioned the use of a URL, but to what type of server?
>
> HTTP, all else is noise.

RFC2821 meets RFC2616. : )

Is the response determined by a specific URI namespace?  Overlooking  
zone delegations, as DKIM currently does, it also seems this service  
might also define sub-zone policies and develop a parallel  
structure. : O


>>> No it can't. The attacker can strip out the signature entirely.
>>
>> 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.
>
> You don't understand the issue.

Would you care to elaborate?  Provided the underlying services are  
not altered, confirmation of a newer version being offered by the  
signing domain remains possible.  Lacking this confirmation should  
impose some type of warning, and under no circumstance should a  
deprecated version be accepted without the presence of a non- 
deprecated version from the same signing domain.  While not perfect,  
this should prevent a downgrade attack where both the signing and  
verifying domain have upgraded.  Once the verifier is upgraded to  
understand the new service, the warning is removed.  These types of  
warnings should motivate an upgrade or act as a valuable alert  
without adding any additional dependencies.


>>> 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.
>
> Community projects don't do boring jobs. What you propose would be  
> tedious beyond description.

Blocking ads is exciting?  At least there is a clearer imperative  
when blocking phish.

 From our efforts, this seems to be an overstatement.  Once a trusted  
list provision becomes part of an email message annotation  
application, whether at the MUA or MTA, there are several  
organizations likely willing to contribute.  Perhaps organizations  
such as the APWG would be a good starting point.

> Much better to give network admins the tools to describe their  
> policy themselves than this bizare ad-hoc scheme you are proposing.

An ad-hoc list from a trusted community could still greatly assist  
the network admin with this otherwise tedious task.  : )

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