[dns-operations] org/DNSKEY RR not found

[Edward Lewis]

On 8/10/15, 8:40, "dns-operations on behalf of Casey Deccio"
<dns-operations-bounces at dns-oarc.net on behalf of casey at deccio.net> wrote:

>The potential problem, as Mark suggests, is a mismatch between RRSIG and
>DNSKEY.  For example, suppose some subset of your servers are serving the
>set of DNSKEYs consisting of A, B, and C, and some subset is serving the
>set of DNSKEYs consisting of A, B, and D.  Your resolver will only get a
>DNSKEY RRset from one of them (until its TTL expires), so it will only
>have either A, B, and C or A, B, and D.  Let's suppose it now has A, B,
>and C in cache.  Now it queries any server again and receives an A RRset
>with (only) RRSIG matching DNSKEY D.  It has no way to verify this RRSIG.
> This is problematic.

One of the things I have been contemplating for some years now is that
DNSSEC is a clumsy extension to the protocol.  What I mean by clumsy is,
it's hard to operate smoothly with the tools we have available.  When the
extensions were designed, there was a delicate balance needed between
sufficiently secure, sufficiently flexible, and an ability to migrate.  To
achieve this, a validator has to be optimistic when attempting to validate
received data, that is, not overly restrictive.   One consideration is
that creating a secure chain of trust (meaning generating signatures) is
or should be hard enough that if one secure chain is found despite many
broken chains, success is declared.

When I read of problems like this, I am a bit concerned.  Let's first
assume that A, B, C, and D are of the same algorithm.  (Juggling
algorithms is possible, but that's like talking about the 4th or 5th
dimension.)  If they are of the same algorithm, then the received data
"MUST" (as in the receiver can have the expectation) be a signature of
either A, B, C, or D.  If the signature is D and the key set is A, B, C,
then that's a botched set up.  If the key set is A, B, C on some servers
and A, B, D on another set of servers (for the same zone), then that's a
botched set up.  It's acceptable to have different key sets on different
servers so long as signatures are validated by a key common to all sets
seen - "acceptable" in the sense that this is needed during changes to
keys and dissemination of zone updates.  In stable operational profiles,
it's not "good manners" to do this, i.e., not a best current practice.
But dissimilar sets have to be anticipated.  IOW, if the signature is from
key A, then A,B,C and A,B,D sets are fine but hopefully temporary.

>However, if the "missing" key(s) do not have any RRSIGs in the wild
>(e.g., because they are being introduced into the DNSKEY RRset as part of
>pre-publishing or being retired due to post-publishing), then it is not
>an issue.  It is not always easy to tell from a snapshot in time, even
>from the RRSIGs that are returned in response to the diagnostic queries
>that are sent, how much of a problem it is, so DNSViz flags it as a
>potential problem.  However, despite the "red" error, note that the color
>of the nodes--which represents their authentication status--is still
>blue, indicating that the chain of trust is in tact.

Casey's explanation makes me think about the clumsiness.  Looking at a
snapshot, no one knows why a key is present - whether it is in pre publish
mode, used for some obscure data set in the zone, or waiting to be
retired.  Worse, we don't know if it is just from that one server or all
servers.  (One cannot, using queries alone, know if all the servers are
simultaneously holding one set, it's simply infeasible, if only because
the speed of light is not infinite.)  So, I don't think DNSviz can do "any
better" in flagging the state seen.  (Perhaps not red, maybe pink, for
potential problems? ;) )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150810/42d40f0f/attachment.bin>