On Apr 22, 2013, at 13:50, Chris Thompson wrote:
> On Apr 22 2013, Edward Lewis wrote:
>
>> We really do need to drop the KSK and ZSK terminology because there are
>> Common Signing Keys coming "back" in vogue. The factor is whether a key
>> is a SEP or not. Recall that in the validation and signing engines,
>> the SEP bit is not significant, it is there for the convenience of key
>> management tools.
>
> I was extremely pleased to see that draft-kumari-ogud-dnsop-cds-01 dropped
> all mention of KSK and ZSK (well, almost - there is a reference to KSK in
> the introduction). It may be that there is still too much talk about the
> SEP bit.
>
> The essence of the previous requirement that CDS RRsets were to be signed
> with a KSK is much better captured by the current text:
>
> The CDS record MUST be at the zone apex, and MUST be signed with a
> key that is represented in the current DNSKEY and DS RRset's. If
> these conditions are not met the CDS record MUST be ignored.
What confuses me is that signing in DNSSEC is not done on a record by record
basis but on a set basis. Meaning, you can't "ignore" a record within a set.
For the use case of wanting to publish a DS record for an unpublished DNSKEY,
how will this work? In this case, I can sign the set with an existing DNSKEY
that is represented in the DS set. With that, all CDS records would be
authenticated. Perhaps this is just a wording issue, but the alternative to
that is that none of the CDS set is valid.
Requiring a CDS to be signed by a key that is present and signs the DNSKEY set
as well as being referenced in the DS set before it is accepted as a request of
the child is different from requiring the set be signed by a key with a KSK
designation or even an SEP bit turned on. The former is setting up rules
"above" the normal validation of DNSSEC data and therefore can be set into a
code path reserved for a special function. The latter (placing more
requirements on what key can be used to validate data) represents a change to
the basic validation rules in DNSSEC - that is something I want to avoid
because it would open up a new set of issues that we've not explored. (Well,
actually, in the early days, we toyed with key role-based rules for
authentication and the models failed. If anyone reads the ancient texts,
there's a talk about key strength, which was part of the failed experiments.)
I would accept that the parent ought to be aware of what key signs the CDS set
and could use that information in determining the authenticity and
authorization of the request. In some use cases this could be acceptable to me
(said in the sense that I'm not sure yet.) However, in other cases, I would
want stronger checks to take place.
Note that I am not saying that it would be bad to define a key change where the
parent only needs the CDS set to be signed by (ultimately) a key represented in
the existing DS set. (I'm using multiple negatives here on purpose "not
saying...it would be bad".) I think that such a practice can co-exist with
stronger practices, like those requiring out of band notifications and
confirmations. I want there to be the possibility of more than one model for
authentication and authorization, based on the existence of a "standard" CDS.
I don't want "my way" to be the one, I just want to make sure that I can handle
multiple ways with a common data representation.
In my code, I'd want to sign the CDS set like it was an A record set. For
zones that need the signer to be in the DS set too, that would be a special
case but one that could be triggered automatically. Somehow, perhaps in the
CDS record itself ("request for SEP signature bit").
> That is, the chain of trust used by the parent to validate a CDS is
> restricted to be of length 1. That is all it knows on earth, and all
> it needs to know (with apologies to John Keats).
I really don't think this is important. For example you might have a
registrant who "owns" a name, outsource it's web and dns operations to a third
party, register the name via a reseller (that provides a WhoIs proxy service to
hide the registrant) who then uses a registrar that talks to a registry to get
a name into TLD that is run by a backend operator. Having a trust chain of
length 1 in DNSSEC is a false sense of "closeness" here. We talk of trying to
prevent a false sense of security at times.
In sum, think of the way the SEP bit was born. As a help to tools that set up
a zone. Not as a factor in normal line DNSSEC processing, something not to be
used or assumed by the validators. For the CDS, the special processing line is
tied to how you provision the parent than how data is validated. For this I'd
make sure the recommendations and/or rules in the document take steps to
enforce the nature of the SEP bit and not lead us into confusion. And, again,
I want to be able to deal with multiple back-end procedures for finding,
accepting, and processing the request that a CDS represents.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
