Re: [DNSOP] additional section, was Over on the dbound list: draft-dcrocker-dns-perimeter-00

[John R Levine]

On Thu, 3 Apr 2019, John Levine wrote:

The part of interest to DNSOP would be section 7 on pages 12 and 13
where it discusses tree walks and potential new additional section
processing to find the closest perimeter record above a name being
checked.


This draft proposes to publish TXT records to mark logical (not zone) 
boundaries, sort of like what the Mozilla PSL does.


Let's say there's a boundary between d.example and example.  Then the 
domain owner would publish _perim.example to show that's where a boundary 
(perimiter in the draft's language) is.  But what if the names go deeper 
and a client is wondering where the boundary is in a.b.c.d.example?  The 
proposal is that the client asks for _perim.a.b.c.d.example, and the DNS 
server returns NXDOMAIN but also puts the _perim.example in the additional 
section, so the client knows that's where the boundary is and doesn't have 
to do a tree walk.


It seems to me that this can't work.  Additional section entries are only 
hints, and just because it returns _perim.example, that doesn't mean that 
_perim.c.d.example doesn't exist.  In a DNS cache, there's no promise that 
additional section records will be remembered for the same time as the 
main answer, or for that matter remembered at all.  The client still has 
to probe all of the intermediate names to check that they don't exist.


Another issue is that qname minimzation breaks this, since the 
authoritative server often won't see the full query.  Or if the boundary 
is above a zone cut, the authoritative server won't have the additional 
record to return.


Although it is legal to put an additional section in an NXDOMAIN response, 
it's uncommon and I don't know how the bailiwick checks would work.


It seems unlikely that any DNS servers or caches would implement a feature 
that triggers TXT record additional section records based on the qname.


Am I missing anything here?

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

PS: for a different design that (ab)uses wildcards to do the same thing 
and avoids tree walks see draft-levine-dbound-dns-02.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] additional section, was Over on the dbound list: draft-dcrocker-dns-perimeter-00

[Ted Lemon]

On Apr 14, 2019, at 11:13 AM, John R Levine  wrote:
> Although it is legal to put an additional section in an NXDOMAIN response, 
> it's uncommon and I don't know how the bailiwick checks would work.

We already do something like this when looking for the zone apex, and it 
potentially has the same problem.   If I look for the zone apex of a 
nonexistent name under a zone that does exist, I’ll get back an SOA record in 
the authority section.   How do I know that that’s the real zone apex?   If I 
look up a.b.c.d.example.com and get back an SOA for example.com, how do I know 
that there is no SOA for c.d.example.com?

The answer is that I don’t, without validating the answer.   And that requires 
traversing the trust anchors to the root, so as you say, this doesn’t save any 
work.

Clearly, this validation should be done—we shouldn’t just assume that what’s in 
the additional section is correct.   I think that this means that in the case 
of a query with DNSSEC enabled, the additional section should contain as much 
of the chain of trust as will fit, in the order the client resolver can be 
expected to need it.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update

[Mark Andrews]

And as DNS is loosely coherent a validator cannot check this rule even when 
getting
answers from a single IP address as there may be a anycast server behind that 
address.
This loose coherence allows for servers to incrementally sign a zone when 
introducing
a new algorithm.  A incrementally signed zoned for a algorithm is no different 
to a
incoherent zone for the purposes of validation.

You don’t publish DS records (or trust anchors) for a algorithm until the 
incoherent
state is resolved (incremental signing with the new algorithm is complete).  
The same
applies to CDS and CDNSKEY.

You can only check if all records are signed with a given algorithm by 
performing a
transfer of a zone and analysing that.  There is no way to do it with 
individual queries.

As for the original question, if all the DNSKEYs for a algorithm are revoked I 
would
only be signing the DNSKEY RRset with that algorithm.  The zone will appear to 
be in
a incoherent state but that isn’t a issue unless there are still DS records 
referencing
that algorithm which there shouldn’t be if they are all revoked. 


> On 13 Apr 2019, at 6:00 am, Edward Lewis  wrote:
> 
> I've been inactive a long time, but someone alerted me to this message.
> (Apologies what below looks like it's from a ranting lunatic.  But it is.)
> 
> On 4/12/19, 11:31, "DNSOP on behalf of Mark Andrews"  on behalf of ma...@isc.org> wrote:
> 
>Well given that the actual rule is all the algorithms listed in the DS 
> RRset
>rather than DNSKEY RRset and is designed to ensure that there is always a
>signature present for each of the algorithms that could be used be used to
>declare that the child zone is treated as secure, the answer is NO.
> 
>Mark
> 
> Looking at "Protocol Modifications for the DNS Security Extensions" (aka RFC 
> 4035):
> ...
> 2.  Zone Signing
> ...
> 2.2.  Including RRSIG RRs in a Zone
> ...
>   There MUST be an RRSIG for each RRset using at least one DNSKEY of
>   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>   itself MUST be signed by each algorithm appearing in the DS RRset
>   located at the delegating parent (if any).
> 
> From this I believe Mark's words are incorrect.  What I read is that the 
> determining factor is what is in a zone's DNSKEY resource record set and that 
> the set must be signed by a key of each of the algorithms in the DS set.  
> This allows the child administrator to have DNSKEY records for DNSSEC 
> security algorithms other than those represented in the parent's DS resource 
> record set and does accommodate other signatures covering the DNSKEY record 
> set.
> 
> Historically there's been great confusion over this passage, partly because 
> the context is usually missed.  This rule governs the actions of signing and 
> serving a zone, not validating a zone.  The purpose of the rule is to allow a 
> validator to "know" deterministically what signatures ought to be present for 
> data.  This is needed to mitigate a downgrade attack enacted by simply 
> filtering signature records.  The validator need not check to make sure all 
> "required" signatures are available, it should be content with anything that 
> works.  I.e., be aggressive in declaring success in the validation process to 
> combat the brittleness introduced by DNSSEC.  (This is intentional, not an 
> afterthought.)
> 
> Imagine one is descending the tree, and determines that the parent's zone 
> data is signed by DNSSEC.  Taking the next step downward toward the desired 
> data, the DS resource record set indicates how the child is secured.  Proven 
> absence of a DS resource record set means the parent considers the child is 
> unsigned (whether the child is or not).
> 
> One ought to imagine that when these rules were written, it was assumed 
> validators taking these steps might not "know" all of the DNSSEC security 
> algorithms.  I.e., a validator might know '8' but not '13'.  If a parent used 
> '8' to sign, and the DS resource record set indicated that only '13' was used 
> by the child (the DS resource record set itself signed by '8'), then the 
> validator would treat the child as unsigned.  But if there were an '8' in 
> there, then the child's DNSKEY set would have to be signed with '8' so the 
> chain would continue.
> 
> It's possible that a child may have DNSKEY resource records for DNSSEC 
> security algorithms not supported by the parent operator.  A child operator 
> may have arranged to have trust anchors in all relying validators out of band 
> to make this "still work."  This is the reason the determination is from the 
> zone's apex DNSKEY resource record set and not the parent's DS resource 
> record set.
> 
> Remember a child is "delegated" responsibility for a domain.  The parent only 
> "gives it life".  What a child zone says about itself rules, local policy and 
> all that.  A child may be under a non-DNSSEC parent and still practice DNSSEC 
> with the validators it has out-of-band co