ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue 1535 - clarify need for domain existence check in the decision tree (step 2)

2008-03-20 12:26:32
Jim,

Jim Fenton wrote:
Dave Crocker wrote:
Just to make sure we are on the same page about the hierarchy  trick in the 
spec:

    The one-level-up hack might be useful for saving some administration, 
but it 
does not provide meaningful "protection", since all an attacker has to do is 
use 
a level down.
  

I'm not entirely clear on what you mean by "a level down", but let me 
try to take a stab at it.

Suppose example.com has "all" signing practices that it wants to extend 
to itself and everything under it (at multiple levels).

I thought we had agreed that the one-level-up hack (or one-level-down, 
depending 
on your spec) specified in the document was intended as an administrative 
convenience, rather than as a discrete security mechanism.


Suppose a message comes with an author address of 
user(_at_)ns(_dot_)example(_dot_)com 
(hostname ns.example.com exists).  The one-level-up query will apply the 
ADSP for example.com.

Right.  But it won't cover the cases in which the site has a multi-level domain 
naming substructure, as many organizations do.  This is why the one-level 
mechanism really is only about saving the administrator from creating a set of 
records.

(Has there been a discussion about the trade-off between saving some 
administrators this effort, versus the transactional overhead of having every 
receiving host do extra queries, so see whether there is a record one-level up?)


Suppose a message comes with an author address of 
user(_at_)foo(_dot_)example(_dot_)com 
(hostname foo.example.com does not exist).  The step-2 query will result 
in an NXDOMAIN, so the ADSP result will be "the domain does not exist".  
"Domain" in this context means the right-hand-side of the address as the 
term is used in RFC 2821.

So the check-for NXDomain is intended to cover those cases where the site has 
set -all and has indeed provided ADSP records (directly or implicitly) for all 
domain names it controls?


Suppose a message comes with an author address of 
user(_at_)foo(_dot_)bar(_dot_)example(_dot_)com (hostname foo.bar.example.com 
does not exist).  
Again, the step-2 query results in an NXDOMAIN, and ADSP says "the 
domain does not exist".

Suppose a message comes with an author address of 
user(_at_)www(_dot_)eng(_dot_)example(_dot_)com (hostname www.eng.example.com 
exists).  In this 
case, the one-level-up query does not reach the example.com ADSP 
record.  For full coverage, there MUST be an ADSP record for 
eng.example.com, as required by section 4.2 paragraph 2.

The point of the one-level-up query was not to relieve domains from 
publishing ADSP records for subdomains, but rather for hostnames and 
other terminal nodes ("terminal node" as used in RFC 2136).  

I do not understand this sentence.  It parses as a sentence, but I not see the 
semantic sense in it.  Please clarify.

The first part of the sentence seems to contradict statements you made earlier 
about the mechanism, when pressed on its relevance.


This
greatly reduces the burden of publication required to get complete ADSP 
coverage. 

And I do not see how your sentence, here, is different from "relieving domains 
from publishing [some] ADSP records for sub-domains.  That's what I mean by 
administrative convenience.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>