Subject: [dnsext] question on RFC 5011, section 2.4.3

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Mar 2009 11:47:32 -0400

#2.4.3.  Minimum Trust Anchors per Trust Point
#
#   A compliant resolver MUST be able to manage at least five SEP keys
#   per trust point.

Does this mean that any delegation has to accommodate "at least five" 
DS records?

And, is this minimum per algorithm?  Like, 5 RSA-SHA1's and 5 DSA-NSEC3-SHA1's?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Michael Graff <[email-masked]>
Date: Fri, 13 Mar 2009 11:15:30 -0500

I'm actually wondering the same thing but from a dlv point of view. I  
am not certain 5011 is intending to be used at the ds or dlv level at  
all, but only for otherwise hard-configured trust anchors?

Adding this rollover to Isc's dlv will, at first glance, require some  
changes.

I find the more interesting question to be which dlv to publish when a  
revoke is detected. It changes the key tag, so do we publish the old  
dlv or a new one or both?

My first take is old one for the hold down period then nothing for  
that key.

--Michael

On Mar 13, 2009, at 10:47, Edward Lewis <[email-masked]> wrote:

> Does this mean that any delegation has to accommodate "at least  
> five" DS records?
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Evan Hunt <[email-masked]>
Date: Fri, 13 Mar 2009 17:37:11 +0000

> Does this mean that any delegation has to accommodate "at least five" 

My reading of this is that it refers to the resolver/validator, not to the
authoritative zone or its parent.

The resolver maintains, in local storage, a set of trust anchors for a
given trust point.  If a new, properly-validated key is added to the
DNSKEY RRset seen at the zone apex, then the resolver adds that key to
its local storage, and eventually begins using it as a trust anchor.
If an key at the zone apex is marked revoked, then the resolver stops
using it as a trust anchor, and eventually deletes it from local storage.
This implies there has to be space in local storage for multiple keys
per trust point; the RFC sets a minimum size.

DS is... sort of orthogonal to this.  5011 addresses *trust anchors*--that
is, the *top* of an island of security.  If your zone has a signed parent,
it's not an island; so long as my resolver has a trust anchor for your
parent, I don't need to maintain one for *you*.  5011 has little, if
anything, to say about the delegation.

But, I'm sure it will happen that a zone with a signed parent will want to
support 5011 anyway.  (In fact, I already know of one: dlv.isc.org.)
However, I don't think this changes things for the parents much.  A child
may have multiple KSKs in its DNSKEY RRset, but the parent still only needs
to publish a DS record for the active one.  It might be a good idea to
support advance publication of the stand-by key, so that key rollover
events run more smoothly, but this is optional.

In any case, unless I've overlooked something, I don't see why a delegation
would ever need to support DS records for more than two keys at a time.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Mar 2009 13:46:55 -0400

>would ever need to support DS records for more than two keys at a time.

...per algorithm?

In either case, I'm uneasy trying to meet only the minimum 
requirements here.  For one, security makes things brittle, we don't 
want to make things to tight.  Also, we are only beginning to get 
around to operational experience and that's a better way to determine 
how things will work than what we have so far.

I can imagine a single DS to multiple KEYs, two DS to one key, and 
other configurations.  DNSSEC was designed to allow multiple 
different keys to sign a zone and that shouldn't be cut off because 
we think we can be more efficient with allowing minimal keys and DSs.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Evan Hunt <[email-masked]>
Date: Fri, 13 Mar 2009 18:22:05 +0000

> >would ever need to support DS records for more than two keys at a time.

That would seem advisable, yes.

> requirements here.

I agree, but I thought we were speaking of minimum requirements. :)

> DNSSEC was designed to allow multiple different keys to sign a zone and
> that shouldn't be cut off because we think we can be more efficient with
> allowing minimal keys and DSs.

At the protocol level, I don't think there's any problem.  A parent can
hold as many DS records for a child zone as it likes (subject to disk space
and bandwidth), just as it can hold as many NS records as it likes.  But
a registry may place arbitrary operational limits on the number of DS
records that can be submitted into a TLD.  That's the point I was
addressing--how small a limit can they set and have the system still work
well.

IMHO a registry MUST allow enough DS records for one KSK, SHOULD allow
enough for two, and MAY allow more than that.  But it's not 5011 saying
so; 5011 doesn't address this.  It's just me making a suggestion.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 13 Mar 2009 14:19:47 -0400

I wrote it to mean 5 SEP keys which could be provided/stored either as DS or DNSKEY or bare. Remember that 5011 only sees DNSKEY records when considering whether or not to update a resolvers trust point state.

And its the minimum per trust point, not per algorithm...   It maybe should have been per algorithm, but since the trust point only needs one valid signature over the apex DNSKEY RRSet it's unclear this is needed.  

Hmm.. ok - here's a question.  Does the collection of algorithms in set of trust anchors define the algorithms with which the zone must be signed or is it the collection of algorithms in the apex DNSKEY RRSet that defines those algorithms and why?  The 5011 assumption is that it's the latter. 

At 11:47 AM 3/13/2009, Edward Lewis wrote:
>Does this mean that any delegation has to accommodate "at least five" DS records?
>

---

From: Michael StJohns <[email-masked]>
Date: Fri, 13 Mar 2009 14:27:04 -0400

Hi Michael

>all, but only for otherwise hard-configured trust anchors?

Since you have an ongoing relationship with the zone to which a DLV record points, I'd say it really doesn't apply to you.  They should just provide the updated records or deletion thereof.

>My first take is old one for the hold down period then nothing for  

The old one (sans REVOKE bit) will be gone - its replaced in the DNSKEY RRSet with the one with the revoke bit.  When your customer does this, they should send you an update with the new DNSKEY or DNSKEY RRSet (or at least the appropriate identifying information).   Ideally, the DLV pointer will point to a non-revoked SEP key.... 

Mike

>>And, is this minimum per algorithm?  Like, 5 RSA-SHA1's and 5 DSA- NSEC3-SHA1's?
>>
>>-- 
>>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-
>>Edward Lewis

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Mar 2009 14:43:56 -0400

At 14:19 -0400 3/13/09, Michael StJohns wrote:

Hmm.. ok - here's a question.  Does the collection of algorithms in 
set of trust anchors define the algorithms with which the zone must 
be signed or is it the collection of algorithms in the apex DNSKEY 
RRSet that defines those algorithms and why?  The 5011 assumption is 
that it's the latter.

I recall writing that if an algorithm is used to sign one RRset in a 
zone, it signs all.  Not a key, but an algorithm.

The rationale stemmed from what was in a DS RRset.  The DS RRset does 
not limit the keys used to sign the zone, but it is the way a 
resolver can determine if the zone is signed with an algorithm the 
resolver "knows."  What's in the DS RRset is a subset of what's in 
the DNSKEY RRset (meaning there can be more keys in the DNSKEY and 
more algorithms in the DNSKEY set than the DNS set.

My impression is that a trust anchor, be it a DS or DNSKEY, is a way 
to validate the first DS seen (going down a subtree with DNSSEC). 
Once there, any of the keys can be used to descend to the next link 
in the chain.

Descending the chain does not have to be done in one algorithm.

I can have a DS with key alg 5.  I find in the DNSKEY set a 
corresponding key (to the hash in the DS) and a key of alg 7.  I can 
use that key to validate the DS set of the next zone down, which may 
have alg 6 in there.  And so on.

To make this all more robust, we need to allow for a plethora of 
algorithms and require that just one path is needed - a "thread of 
trust?"

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 13 Mar 2009 14:49:21 -0400

At 13:46 13/03/2009, Edward Lewis wrote:
>around to operational experience and that's a better way to 
>determine how things will work than what we have so far.

Things are different depending on what role you are keeping trust anchors.
For a zone it may need to have 1-3 per DNSKEY algorithm at the same time
(current, next one, old one).

For a delegation parent this is two different policy issues:
         How many DS records per DNSKEY algorithm can be listed at 
the same time
         How many DS digest algorithms are listed.

For the first one the number can be as low as 1 or as high as the 
policy allows.
The issue here is how many times does a child want to update a parent
during a rollover?
here are few ways to do it in actions
K = DNSKEY S= RRSIG D= DS
k = Old key K = New key (same for Sigs and DS)
One DS
         ksd ==> kKsSd ==> kKsSD ==> KSD
Two DS
         ksd ==> kKsd ==> kKsSdD ==> KSdD ==> KSD

Registry needs to be able to support both IMHO.

For trust anchor maintainers using TIMERS
things are more difficult as the maintainer must keep track of old keys
for a long time.
5 keys per algorithm is lower bound for that system

         Olafur

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Mar 2009 15:03:00 -0400

>5 keys per algorithm is lower bound for that system

The question is - why 5?  (Like, where did that number come from?)

And do they need to be current?

---

From: Michael StJohns <[email-masked]>
Date: Fri, 13 Mar 2009 16:36:20 -0400

I don't think that exactly answers my question but that's OK..

I think the answer to my question is that the trust anchor can point to any key which signs the apex DNSKEY; that the trust anchor set need not include all keys which sign the apex (but 5011 may pick them up over time if they are SEP keys), that the set of algorithms that must sign the zone is determined by the set of keys that sign the apex DNSKEY RRSet whether they are SEP keys or not.

At 02:43 PM 3/13/2009, Edward Lewis wrote:
>I recall writing that if an algorithm is used to sign one RRset in a zone, it signs all.  Not a key, but an algorithm.
>
>The rationale stemmed from what was in a DS RRset.  The DS RRset does not limit the keys used to sign the zone, but it is the way a resolver can determine if the zone is signed with an algorithm the resolver "knows."  What's in the DS RRset is a subset of what's in the DNSKEY RRset (meaning there can be more keys in the DNSKEY and more algorithms in the DNSKEY set than the DNS set.
>
>My impression is that a trust anchor, be it a DS or DNSKEY, is a way to validate the first DS seen (going down a subtree with DNSSEC).  Once there, any of the keys can be used to descend to the next link in the chain.
>
>I can have a DS with key alg 5.  I find in the DNSKEY set a corresponding key (to the hash in the DS) and a key of alg 7.  I can use that key to validate the DS set of the next zone down, which may have alg 6 in there.  And so on.
>
>To make this all more robust, we need to allow for a plethora of algorithms and require that just one path is needed - a "thread of trust?"
>
>
>--

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Mar 2009 16:57:47 -0400

At 16:36 -0400 3/13/09, Michael StJohns wrote:
>I think the answer to my question is that the trust anchor can point to any
>key which signs the apex DNSKEY; that the trust anchor set need not include
>all keys which sign the apex (but 5011 may pick them up over time if they are
>SEP keys), that the set of algorithms that must sign the zone is determined by
>the set of keys that sign the apex DNSKEY RRSet whether they are SEP keys or
>not.

Ack.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2009 14:55:59 -0700

At 4:36 PM -0400 3/13/09, Michael StJohns wrote:
>I think the answer to my question is that the trust anchor can point to any key which signs the apex DNSKEY; that the trust anchor set need not include all keys which sign the apex (but 5011 may pick them up over time if they are SEP keys),

Yes, but....

>that the set of algorithms that must sign the zone is determined by the set of keys that sign the apex DNSKEY RRSet whether they are SEP keys or not.

I don't get this. Trust anchors are keys; they don't have algorithms inherently attached. An RSA key, for example, can be used in "RSA-with-SHA1" or "RSA-with-SHA256" or (later) "RSA-with-SHA3-256" and so on. To me, "the algorithms that must sign the zone" doesn't make sense; "the keys that must sign the zone" does.

Regardless of where we end up with this, the result of this thread should go in an 5011bis document or possibly in draft-ietf-dnsop-dnssec-trust-anchor. There is a lack of clarity here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael StJohns <[email-masked]>
Date: Fri, 13 Mar 2009 18:17:43 -0400

Hi Paul -

Trust anchors have two purposes in DNSSEC: they provide trusted public keys, but they also set the "this subtree must be signed" bit in the resolver that has them configured.

One of the anti-downgrade "policies" which is somewhere in the pile of accepted wisdom for DNSSEC says that a "zone" must be signed (e.g. all the RRSets in the zone must be signed) with at least one key per each key algorithm present in the apex DNSKEY rrset.  E.g. if the apex RRSet has 5 SHA1RSA keys, it only needs to be signed once, but if the apex set has 2 SHA1RSA keys, an SHA256RSA key and 4 ECP256SHA256 (as yet undefined) keys, each RRSet would need at least 3 signatures.  Shorthand for that in discussions has always been "signed by the algorithm".

Trust anchors are pretty much undefined with respect to how they're stored. They consist - for DNSSEC - of a pointer to a DNSKEY of some sort (name, key tag, hash, fingerprint, etc).  Given that 5011 trust anchors are derived from DNSKEYs its possible to capture the key type (which is actually the signature algorithm).  Hence my aside about whether or not the trust anchor sets the expected set algorithms - answer is no.

Later, Mike

---

From: Michael Graff <[email-masked]>
Date: Fri, 13 Mar 2009 17:32:08 -0500

I don't see a lack of any clarity. A key has a key type and even  
though the keying material could be used for more than one key type,  
the type is an integral part if what makes THIS trust anchor bind to  
THAT dnskey.

--Michael

On Mar 13, 2009, at 16:55, Paul Hoffman <[email-masked]> wrote:

>> I think the answer to my question is that the trust anchor can  
>> point to any key which signs the apex DNSKEY; that the trust anchor  
>> set need not include all keys which sign the apex (but 5011 may  
>> pick them up over time if they are SEP keys),
>
> Yes, but....
>
>> that the set of algorithms that must sign the zone is determined by  
>> the set of keys that sign the apex DNSKEY RRSet whether they are  
>> SEP keys or not.
>
> I don't get this. Trust anchors are keys; they don't have algorithms  
> inherently attached. An RSA key, for example, can be used in "RSA- 
> with-SHA1" or "RSA-with-SHA256" or (later) "RSA-with-SHA3-256" and  
> so on. To me, "the algorithms that must sign the zone" doesn't make  
> sense; "the keys that must sign the zone" does.
>
> Regardless of where we end up with this, the result of this thread  
> should go in an 5011bis document or possibly in draft-ietf-dnsop- 
> dnssec-trust-anchor. There is a lack of clarity here.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
> --

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2009 16:35:53 -0700

>Trust anchors have two purposes in DNSSEC: they provide trusted public keys, but they also set the "this subtree must be signed" bit in the resolver that has them configured.

Sure.

>One of the anti-downgrade "policies" which is somewhere in the pile of accepted wisdom for DNSSEC says

That does not sound like a good way to run the system we claim will help secure the DNS.

> that a "zone" must be signed (e.g. all the RRSets in the zone must be signed) with at least one key per each key algorithm present in the apex DNSKEY rrset.  E.g. if the apex RRSet has 5 SHA1RSA keys, it only needs to be signed once, but if the apex set has 2 SHA1RSA keys, an SHA256RSA key and 4 ECP256SHA256 (as yet undefined) keys, each RRSet would need at least 3 signatures.  Shorthand for that in discussions has always been "signed by the algorithm".

I would want to see that written down someplace. It seems like a bad design.

>Trust anchors are pretty much undefined with respect to how they're stored. They consist - for DNSSEC - of a pointer to a DNSKEY of some sort (name, key tag, hash, fingerprint, etc).  Given that 501…

Good, but...

At 5:32 PM -0500 3/13/09, Michael Graff wrote:
>I don't see a lack of any clarity. A key has a key type and even though the keying material could be used for more than one key type, the type is an integral part if what makes THIS trust anchor bind to THAT dnskey.

If you two disagree, and it is not written down, there is a lack of clarity.

--Paul Hoffman, Director
--VPN Consortium

---

From: Chris Thompson <[email-masked]>
Date: 14 Mar 2009 01:17:39 +0000

>At 6:17 PM -0400 3/13/09, Michael StJohns wrote:
[...]
>> that a "zone" must be signed (e.g. all the RRSets in the zone must be 
>>signed) with at least one key per each key algorithm present in the apex
>>DNSKEY rrset.  E.g. if the apex RRSet has 5 SHA1RSA keys, it only needs 
>>to be signed once, but if the apex set has 2 SHA1RSA keys, an SHA256RSA 
>>key and 4 ECP256SHA256 (as yet undefined) keys, each RRSet would need at
>>least 3 signatures.  Shorthand for that in discussions has always been 
>>"signed by the algorithm".
>

RFC 4035, end of section 2.2:

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

I don't see why Michael had to call it "accepted wisdom", when it is
in fact "published wisdom"!

-- 
Chris Thompson
Email: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2009 19:27:29 -0700

>in fact "published wisdom"!

Well, there you go.

So, what on earth is the reason for those requirements? They are counter to the idea of a trust anchor; they aren't needed for preventing bid-down attacks. Clues would be appreciated.

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Sat, 14 Mar 2009 15:29:55 -0400

At 16:35 -0700 3/13/09, Paul Hoffman wrote:
>Someone else (MSJ?) wrote:
>>DNSKEY rrset.  E.g. if the apex RRSet has 5 SHA1RSA keys, it only needs to
>>be signed once, but if the apex set has 2 SHA1RSA keys, an SHA256RSA key
>>and 4 ECP256SHA256 (as yet undefined) keys, each RRSet would need at least
>>3 signatures.  Shorthand for that in discussions has always been "signed
>>by the algorithm".
>

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

"Algorithm" is as defined on this page:

http://iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

---

From: Michael StJohns <[email-masked]>
Date: Mon, 23 Mar 2009 12:56:02 -0400

At 09:17 PM 3/13/2009, Chris Thompson wrote:
>>>that a "zone" must be signed (e.g. all the RRSets in the zone must be signed) with at least one key per each key algorithm present in the apex
>>>DNSKEY rrset.  E.g. if the apex RRSet has 5 SHA1RSA keys, it only needs to be signed once, but if the apex set has 2 SHA1RSA keys, an SHA256RSA key and 4 ECP256SHA256 (as yet undefined) keys, each RRSet would need at
>>>least 3 signatures.  Shorthand for that in discussions has always been "signed by the algorithm".
>>

It's accepted wisdom that this (what's written down) must be done for anti-downgrade.  Or at least anti-downgrade was the reason I was given for the requirement stated above.  But I don't think that reasoning is anywhere in the spec.  Sorry for not being more clear.

Mike