[dns-operations] DNSKEY signatures

[George Barwood]

It seems to me that DNSKEY RRsets should only be signed with the keys that
are designated as secure entry points, that is keys with bit 15 set : DNSKEY Flags field = 257.

However the examples I have seen (including RFC 4035) all seem to sign the DNSKEY RRset with
the zone signing key(s) as well.

The standard ( http://tools.ietf.org/html/rfc4035#section-2.2 ) says

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).

But this doesn't seem to explain the observed practice.

Any explanation? Am I missing something?

[Edward Lewis]

Post by George Barwood
Any explanation? Am I missing something?

http://dnssec-deployment.org/pipermail/dnssec-deployment/2009-September/003387.html

[George Barwood]

Edward,

Thanks for the link.

I have just noted the existence of http://tools.ietf.org/html/rfc3757

where it states

When signing a zone, it is intended that the key(s) with the SEP bit
set (if such keys exist) are used to sign the KEY RR set of the zone.
which seems fairly conclusive. However, I can imagine a possible problem where a
key is used as a SEP but the flag is not set. This could be because the key was
created before the SEP flag was even defined (i.e. pre RFC3757) , or where a
key without the SEP flag has been configured as a trust anchor. I think it's OK to
assume that ONLY DS records are used as trust anchors in the absence of any special
publishing arrangement. So it's maybe not 100% clear cut, but I think with normal
operational practice ( delegation via DS records ), it's fine to sign the DNSKEY
RRset with just the SEP keys. I think the standard could be a bit stronger and say
that keys that are to be used as an SEP ( either by DS records or as configured trust
anchors ) MUST have the SEP bit set. But one can perhaps just put this in the
implementation's operating instructions instead.

George

----- Original Message -----
From: "Edward Lewis" <Ed.Lewis at neustar.biz>
To: <dns-operations at dns-oarc.net>
Cc: <ed.lewis at neustar.biz>
Sent: Monday, April 19, 2010 5:36 PM
Subject: Re: [dns-operations] DNSKEY signatures

Post by Edward Lewis

Post by George Barwood
Any explanation? Am I missing something?

http://dnssec-deployment.org/pipermail/dnssec-deployment/2009-September/003387.html
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at [phone]
Wouldn't it be nice if all of the definitions of equivalence were the same?
_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[Jelte Jansen]

Post by George Barwood
Edward,
Thanks for the link.
I have just noted the existence of http://tools.ietf.org/html/rfc3757
where it states
When signing a zone, it is intended that the key(s) with the SEP bit
set (if such keys exist) are used to sign the KEY RR set of the zone.
which seems fairly conclusive. However, I can imagine a possible problem where a
key is used as a SEP but the flag is not set. This could be because the key was
created before the SEP flag was even defined (i.e. pre RFC3757) , or where a
key without the SEP flag has been configured as a trust anchor. I think it's OK to
assume that ONLY DS records are used as trust anchors in the absence of any special
publishing arrangement. So it's maybe not 100% clear cut, but I think with normal
operational practice ( delegation via DS records ), it's fine to sign the DNSKEY
RRset with just the SEP keys. I think the standard could be a bit stronger and say
that keys that are to be used as an SEP ( either by DS records or as configured trust
anchors ) MUST have the SEP bit set. But one can perhaps just put this in the
implementation's operating instructions instead.

Protocol-wise (in terms of RFC403X validation), SEP has no value.

I used to think of KSKs as signing the DNSKEY set, and ZSKs signing all.
I have since been convinced otherwise and now think of it like this;
they are independent properties.

A key can be a KSK (it signs the DNSKEY set), a ZSK (it signs every
RRset except DNSKEY), none (it's published but not actually used), or
both (it signs all rrsets).

Due to that section you previously mentioned, for every algorithm that
you have one or more keys in, you must have at least one that is a KSK
and one that is a ZSK, but this may be the same key. And if you have one
or more KSKs that are not ZSKs, you don't need your ZSK(s) to be KSKs
too (in fact having them not be saves packet space).

The SEP bit should only (but does not have to) be set on keys that have
the KSK property, it can be used by automation tools (either signers to
decide which keys to use for what, or pullers to decide which should be
seen as anchors or DS sources). If none of the tools use it (a lot do
though), it should be safe to set it to 0.

Jelte

[Andrew Sullivan]

Post by George Barwood
It seems to me that DNSKEY RRsets should only be signed with the keys that
are designated as secure entry points, that is keys with bit 15 set : DNSKEY Flags field = 257.

That is explicitly denied by the RFCs.

A

[George Barwood]

----- Original Message -----
From: "Andrew Sullivan" <ajs at shinkuro.com>
To: <dns-operations at lists.dns-oarc.net>
Sent: Tuesday, April 20, 2010 2:42 PM
Subject: Re: [dns-operations] DNSKEY signatures

Post by Andrew Sullivan

Post by George Barwood
It seems to me that DNSKEY RRsets should only be signed with the keys that
are designated as secure entry points, that is keys with bit 15 set : DNSKEY Flags field = 257.

That is explicitly denied by the RFCs.

Hmm. Where? Maybe my use of "should" is not quite accurate. "may" might more accurate.

The RFCs (AFAIK) do not say anything how a client can know that a particular key is suitable for
use as a trust anchor. Thus this must to some extent lie outside the protocol. It is certainly
necessary to restrict the keys that are used - clients cannot just pick a key and hope for the best.
There might be an external protocol, or some validity statement "This trust anchor is valid
for five years, unless a message is posted to xxxx mailing list announcing an emergency rollover",
whatever. Of course the most common case by far will be to publish a DS record in the parent zone.

The RFCs do allow a Zone Signing Key to be used as a trust anchor, but it seems to me
that an implementation is free to restrict which keys may be used as trust anchors in any
way it sees fit, provided this is made clear (in documentation) to the zone administrator.

The two obvious ways are :
(a) Only keys with the SEP bit set may be used.
(b) Only published DS records may be used.

An implementation might provide a facility for a ZSK that is not
designated as a SEP to be used, but this seems to have no real use,
and is only likely to cause confusion I think.

Well, that's my interpretation so far, but quite possibly it is wrong.

George

Post by Andrew Sullivan
A
--
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.
_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[Andrew Sullivan]

Post by George Barwood
Hmm. Where? Maybe my use of "should" is not quite accurate. "may" might more accurate.

Yes, you may use it this way. But 3757 is quite clear that there is
no in-protocol consequence of the SEP bit. Moreover, 4035 ?5 makes
perfectly clear what the criteria are for validation, and the SEP bit
is not among them.

Post by George Barwood
The RFCs (AFAIK) do not say anything how a client can know that a particular key is suitable for
use as a trust anchor.

You got it via the trust-anchor-getting mechanism. 4035, ?5:

To use DNSSEC RRs for authentication, a security-aware resolver
requires configured knowledge of at least one authenticated DNSKEY or
DS RR. The process for obtaining and authenticating this initial
trust anchor is achieved via some external mechanism. For example, a
resolver could use some off-line authenticated exchange to obtain a
zone's DNSKEY RR or to obtain a DS RR that identifies and
authenticates a zone's DNSKEY RR. The remainder of this section
assumes that the resolver has somehow obtained an initial set of
trust anchors.

Post by George Barwood
whatever. Of course the most common case by far will be to publish a DS record in the parent zone.

Right. And 4035 also explains what the restriction is there. The
DNSKEY RR has to have the Zone Key Flag set, but it doesn't need to
have the SEP bit.

Post by George Barwood
The RFCs do allow a Zone Signing Key to be used as a trust anchor, but it seems to me
that an implementation is free to restrict which keys may be used as trust anchors in any
way it sees fit, provided this is made clear (in documentation) to the zone administrator.

Oh, I think I may have misunderstood you. Of course an administrative
tool could refuse to sign a zone with a key that didn't have the SEP
bit set. IMO this would be a mistake, because I don't really believe
that every zone ought to _have_ different KSKs and ZSKs.

Post by George Barwood
(a) Only keys with the SEP bit set may be used.

The problem here is that many people seem to have developed the
unfortunate belief that SEP == KSK and nothing else. I don't want to
reinforce that.

Post by George Barwood
(b) Only published DS records may be used.

The problem here is that you couldn't use a special trust-anchor-only
signer for particular cases. I think that might be bad too. Also,
one mode of signing is that you sign with the new key and only then
send the DS along, because maybe the parent wants to check to see
whether the DS actually corresponds to some key you have in your zone.

A

[George Barwood]

Post by Andrew Sullivan
Oh, I think I may have misunderstood you. Of course an administrative
tool could refuse to sign a zone with a key that didn't have the SEP
bit set. IMO this would be a mistake, because I don't really believe
that every zone ought to _have_ different KSKs and ZSKs.

Post by George Barwood
(a) Only keys with the SEP bit set may be used.

The problem here is that many people seem to have developed the
unfortunate belief that SEP == KSK and nothing else. I don't want to
reinforce that.

I think bringing the SEP flag into it may have been a mistake on my part.

Maybe what I'm really trying to say is that a signing tool should be able to
be given sufficient information, so that it can know which signatures are
wanted by the zone administrator.

Now there are many possible ways to sign a zone, but an obvious, simple way sign
is to have 2 keys, a KSK and a ZSK, to sign the DNSKEY RRset with the KSK (only),
and to sign the other RRsets with the ZSK (only).

It seems that current signing tools don't allow this simple intent to be communicated.

I intend to make this the default (fully automatic) behavior in my signing implementation,
and possibly offer some options for some other alternatives ( such as just having a single
key that signs everything ).

My worry was that this might be invalid, but I don't think it is. Rather existing implementations
don't seem to offer this straightforward option.

George