[dns-operations] Google DNS ignores DNSSEC validation failure

[Edward Lewis]

On 10/2/16, 08:58, "dns-operations on behalf of Viktor Dukhovni" <dns-operations-bounces at dns-oarc.net on behalf of ietf-dane at dukhovni.org> wrote:

>    Taking the "arguably" side of the branch, we get opportunities for
>    an MiTM to mint arbitrary insecure names in signed zones, provided
>    the name does not exist in the parent.  Since this is a bad outcome,
>    that choice should not be available.

The first question is how a MiTM could pull this off?

If a MiTM pulled off a Kaminsky-style cache poisoning, that is, force the victim recursive server to ask for the insecure name and then manage to respond with the unsigned data.  A DNSSEC validating recursive server would then proceed to DNSSEC validate the data and discover that there is a negative existence proof.  (I am assuming DNSSEC here because the central question depends on the request for the DS record.  Otherwise this is just a gullible cache and no one would be the wiser.)

In this case, it was not a Kaminsky-style cache poisoning but a misconfigured authority server.  The result ought to be the same, that the data would not pass validation if, at the time the response was received the validator would see proof that delegation did not exist (not just that there was no DS).

One thing to watch out for, wildcards and NSEC 3 opt-out do allow for unsecured delegations to be forged into a zone.  But that is no worse than the state without DNSSEC (which is why opt-out became accepted despite that).

OTOH, if the response for insecuretest.switch.ch's SOA or NS records came when the delegation existed (without a DS) the records would be validly cached.  If then, within the TTL of that data, the delegation was removed, then it is not clear whether the recursive server would be correct to remove the cached entries or not.

>
>    In other words, when adding as yet unvalidated data to the cache
>    (that is not yet known to be secure or insecure) if the parent
>    domain is signed and the DS record returns NXDOMAIN, if the
>    specification does not currently require that the unvalidated
>    records MUST be deemed bogus, then a document to that effect needs
>    to be produced.

Separate the question of "adding [as yet] unvalidated data" from "having no longer validable data in the cache."

Perhaps I misunderstood the original question - if the set up was as described and a recursive server responded with the SOA record, that would be an error.  (Where I may be confused - if the recursive server had validated the SOA, cached it, and then the zone reconfigured, the SOA response is arguably correct.)

>    
>    This would still allow for returning cached records that were
>    legitimately determined to be insecurely delegated in the past,
>    but would not allow forgery of new data by an MiTM.

Hmm, will that is what I see as the intention, so perhaps I'm arguing the wrong point.

The specification ought to drop these records (SOA, NS) if the delegation does not exist all along.  The IETF document comment I had related to "things changing" as the reason for the conflict.

Whether or not the spec says to, as a coder I would have not cached or responded with (unless +CD was in the query) the SOA and NS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2013 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20161002/21df7869/attachment.bin>