Subject: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17]

From: Peter Koch <[email-masked]>
Date: Mon, 18 Apr 2011 19:41:38 +0200

Dear DNSOP WG,

this is to initiate a working group last call (WGLC) on

	"DNSSEC Operational Practices, Version 2"
	  <draft-ietf-dnsop-rfc4641bis-06.txt>

Owing to the length of the document, the WGLC will last for four weeks
instead of the usual two, and will therefore end on

		Tuesday, 17 May, 23:59 UTC.

The IETF tools site gives easy access to the current and previous
versions as well as differences and the like at

	<http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-06>.

The document is aimed at a status of "Informational".

Please review the document and send any comments you may have to the
list.  If you have no comments but support (or do not support) the
document being published, please send that information to the list.

The document is subject to the normal five reviewer threshold.

    Stephen and Peter
     DNSOP co-chairs

---

From: "George Barwood" <[email-masked]>
Date: Mon, 18 Apr 2011 20:01:30 +0100

I have a few comments.

(1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split.
With the signing of the root zone and many TLDs, manual distribution of trust anchors is likely
to be uncommon. One advantage (not mentioned in the document) of using a single key system is
that it is not necessary for validators to check the RRSIG for the DNSKEY RRset when it is
completely authenticated by the parent DS. Current practice appears to be the opposite, so I would
like to see the recommendation tilted more strongly in favour of single keys, 
"Use a single key unless you are the root zone or you have unusual requirements"
in order  to redress the balance ( operators are like sheep ).

(2) There is no point in using a larger key size than the smallest key size in the parent chain
( again assuming no manual trust anchors ). i.e. if the parent DS record is signed with a 1024 bit key, 
there is no point in using keys larger than 1024 bits. Again, current practice appears to be the opposite.
I don't think this is mentioned, even if it is obvious.

(3) Using a longer TTL for negative DS responses might be useful. Currently the negative TTL for
the com zone is only 900 seconds (the SOA TTL). This is probably appropriate for a NameError
(NxDomain) response, but 1 day might be more appropriate for a negative DS response, to improve
caching performance and reduce load on servers.

I support publication of this document.

Regards,
George Barwood

----- Original Message ----- 
From: "Peter Koch" <[email-masked]>
To: "IETF DNSOP WG" <[email-masked]>
Sent: Monday, April 18, 2011 6:41 PM
Subject: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17]

---

From: Joe Abley <[email-masked]>
Date: Mon, 18 Apr 2011 16:26:31 -0400

> (1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split.

In practice, for a TLD zone operator, rolling a KSK is a more complicated and time-consuming process than rolling a ZSK. A ZSK roll can be achieved quickly, entirely using systems operated by the TLD operator, whilst a KSK roll necessarily involves review by external organisations which takes more time.

(An emergency DS RRSet change for the root zone is required to be implemented within 48 hours of submission, assuming the request is well-formed. There have been no such requests to date so it is not possible to offer data on the actual time for implementation.)

Where a KSK/ZSK split exists, the frequency of use of each key is not the same -- ZSKs are typically exercised more frequently (every time an RRSIG over any RRSet in the zone needs to be generated) than ZSKs (which only need to be exercised as part of a ZSK roll).

I don't think it's unreasonable for these facts, as an inject to an appropriate threat analysis, to result in a recommendation to operate with a ZSK/KSK split -- such an arrangement facilitates different levels of protection for each key commensurate with the ease with which it might be rolled and the frequency with which it is required to be used.

I'm not saying it's the only way to go, but I think recommending against the practice makes little sense.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Apr 2011 17:34:56 -0400 (EDT)

On Mon, 18 Apr 2011, George Barwood wrote:

> to be uncommon.

Not true. Any responsible organisation will configure their own zone's trust anchoes in their
resolvers, so they can operate internally when their WAN/UPlink is down.

> (2) There is no point in using a larger key size than the smallest key size in the parent chain

See 1) Those will benefit from additional strength that seems excessive to any parent.

> caching performance and reduce load on servers.

I think this issue should probably looked at in the light of the "child centric" vs "parent centric"
issues we have seen. I don't know the right answer, but some others might have better feedback on this.

Paul

---

From: "George Barwood" <[email-masked]>
Date: Tue, 19 Apr 2011 00:14:47 +0100

----- Original Message ----- 
From: "Paul Wouters" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "IETF DNSOP WG" <[email-masked]>
Sent: Monday, April 18, 2011 10:34 PM
Subject: Re: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17]

> resolvers, so they can operate internally when their WAN/UPlink is down.

Possibly. But I think this will be quite rare, and will only apply to organisations with
very significant resources (maybe governments). I really doubt the significant extra
complexity of managing these trust anchors is likely to lead to an overall increase in security.
How are you going to distribute them? If you have a distribution mechanism ( other than the public
one ) then you can presumably update the trust root config in a timely way when needed, so nothing is gained.

> See 1) Those will benefit from additional strength that seems excessive to any parent.

I really doubt security would be improved in practical terms.
The extra complexity of non-standard configuration would probably outweigh
the minute benefit of longer keys, both in security terms, and even more certainly
in terms of reliability. But anyway, yes, if you are really planning this, then
a ZSK/KSK split might possibly be helpful, but not for typical domains.
 
> issues we have seen. I don't know the right answer, but some others might have better feedback on this.

The DNSSEC standard seems vague (AFAICS) on the TTL of the negative DS information included with a referral
from a secure to a non-secure zone (the SOA is not sent). I'm really not sure how it's meant to work ( this is possibly a bit off-topic here though - I asked a question in dnsext recently, no response yet ).

---

From: Doug Barton <[email-masked]>
Date: Mon, 18 Apr 2011 16:22:28 -0700

On 04/18/2011 16:14, George Barwood wrote:
 > From: "Paul Wouters"<[email-masked]>
>>> (1) It's my belief that almost all Zones except for the root zone
>>> should NOT use a KSK/ZSK split. With the signing of the root zone
>>> and many TLDs, manual distribution of trust anchors is likely to
>>> be uncommon.
>>
>> Not true. Any responsible organisation will configure their own
>> zone's trust anchoes in their resolvers, so they can operate
>> internally when their WAN/UPlink is down.
>
> Possibly. But I think this will be quite rare, and will only apply to
> organisations with very significant resources (maybe governments).

I would do this at any enterprise I was involved with.

> I really doubt the significant extra complexity of managing these trust
> anchors is likely to lead to an overall increase in security. How are
> you going to distribute them?

The same way that I would distribute all of the other name server 
configuration files.

> If you have a distribution mechanism (
> other than the public one ) then you can presumably update the trust
> root config in a timely way when needed, so nothing is gained.

I'm not sure how that's germane to Paul's point. I'm going to have the 
root zone trust anchor configured already, but I would not want to have 
to configure all of the relevant TLD trust anchors as well. I would much 
rather configure the trust anchors for _my_ zones that I care about 
being able to continue functioning should the big-I Internet be 
unavailable.

> I really doubt security would be improved in practical terms. The
> extra complexity of non-standard configuration would probably
> outweigh the minute benefit of longer keys, both in security terms,
> and even more certainly in terms of reliability. But anyway, yes, if
> you are really planning this, then a ZSK/KSK split might possibly be
> helpful, but not for typical domains.

TIMTOWTDI. :) This could also be useful for situations where you are 
anticipating the parent moving to a stronger key, or where the primary 
value of the signatures is in an island of trust scenario.

I also wanted to voice my agreement with Joe's response.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 19 Apr 2011 10:19:41 +0200

Hi George, dnsop,

> in order  to redress the balance ( operators are like sheep ).

This document is *not* intended to become a BCP. Therefore, I am not
eager to add such a recommendation. I believe the operational motivation
for ZSK/KSK split (3.1) is sufficient for operators to be able to decide
whether a split or a Single Type Signing Scheme is recommended.

> I don't think this is mentioned, even if it is obvious.

The document does mention that an attacker will attack the key that
costs lowest resources. The comparison with TLS trust anchors is made.
Perhaps, a clarifying note on DS records can be made here as well.

> caching performance and reduce load on servers.

You might be right, I don't know whether which value is more appropriate
in one case or another. In one case 900 seconds might be preferred, in
the other case 1 day is maybe the best solution.
I don't want to advocate BCP values for SOA TTL and SOA MINIMUM.

(What I don't understand is how you would set different TTLs for
DS-related negative answers and not DS-related negative answers)

Best regards,

Matthijs

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 19 Apr 2011 11:42:02 +0200

> (1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split.

I don't think this is true.
I think the split of when to use a KSK/ZSK and when not is not that
clear. But it depends on:

- -Time and operational difficulty to communicate a new DS to parent
- -Size of the zone, and frequency of updates to zone content.

A large zone, that has frequent updates, and has a timeconsuming,
difficult or strict parent-child relation is better off using KSK/ZSK.

A small zone, that has very few updates, can just as well use 1 key.

I have some more questions on the draft.
In section 3.4.3 I read:
  "Although
   not mandatory, one could administer a zone using a "hidden master"
   scheme that minimize the risk.  In this arrangement the master that
   processes the updates is unavailable from general hosts on the
   Internet; it is not listed in the NS RRSet, although its name appears
   in the SOA RRs MNAME field."
This seems to me to define what should be listed in the SOA RRs MNAME
field in case a hidden master is used. Another definition could well be
that when you use a hidden master, one of the public nameservers should
be appointed to be the public master, and it's name should be in the SOA
RRs MNAME field, as that server should allways be accesible over the
public Internet, and the name in the MNAME field should allways resolve
(to a public IP) and be in the NS RRset.
If would appreciate if someone could point me to standard-track text
where this is defined.

Section 4.3.5.2, first paragraph:
"If the registry and registrars allow for DS records to be published,
   that do not point to a published DNSKEY in the child zone, the
   Double-DS KSK Rollover is preferred to resolve the non-cooperative
   case."

I think this should be:

"the Double-DS KSK Rollover is preferred to resolve the cooperative
   case."

In the non-cooperative case even a Double-DS does not make sense, and
one should go insecure.

I have not finnished to review the complete document yet, but will do
before the deadline.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 19 Apr 2011 11:59:43 +0200

> document being published, please send that information to the list.

Another observation on the examples in section 4.1.*:

- -I don't understand why the DNSKEY RRset should be signed with the ZSK.
It's not wrong, but I don't see the point of signing the DNSKEY RRset
with a ZSK. It's not needed and enlarges the zone. It's sufficiant if
the DNSKEY RRset is signed by the KSK only.
All RRSIG_Z_*(DNSKEY) can be removed.

- -- 
Antoin Verschuren

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 19 Apr 2011 12:18:19 +0200

Hi Antoin,

On 04/19/2011 11:42 AM, Antoin Verschuren wrote:
> -Time and operational difficulty to communicate a new DS to parent
> -Size of the zone, and frequency of updates to zone content.
> 

Would it be resolved if we use the following text?
s/appears/may appear/

    ...; it is not listed in the NS RRSet, although its name may appear
    in the SOA RRs MNAME field.

> In the non-cooperative case even a Double-DS does not make sense, and

You are right.

Best regards,
  Matthijs

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 19 Apr 2011 12:55:11 +0200

>     in the SOA RRs MNAME field.

I think the definition of a hidden master is that it is not reachable
from the public Internet, and therefor it's hostname does not need to
resolve on the public Internet.
The SOA RRs MNAME field was defined before hidden masters were used, so
I don't know if a hostname in the MNAME field should resolve and be
reachable. If it is, then it's no longer a hidden master, but just a
public master that is not in the NS set.

I think the best way forward for now is to say "it is not listed in the
NS RRSet" and not mention anything about the MNAME field.

- -- 
Antoin Verschuren

---

From: "Marc Lampo" <[email-masked]>
Date: Tue, 19 Apr 2011 14:31:02 +0200 (CEST)

Some comments :

3.1 Operational Motivation for ZSK and KSK

I explicitly agree with Antoin Verschuren [[email-masked]] that
more criteria should be taken into account, more then listed in the
present document (like the ones he proposes).

As extra observation, I would prefer "child-parent" rather then
"registrar-registry" (globally : any reference to "registrar" or
"registry").
Motivation : registrar is linked to the "customer" layer and "registry" to
the "tld" layer of a "customer.tld." domain name.  But DNSSEC can go below
that level !  As I am in Belgium, "just.fgov.be." is a delegated subdomain
: if they will, one day, soon ?, implement DNSSEC, the communicating DS
information is not between registrar and registry.
In broader scope : the document should not limit to DNSSEC between a label
and a top-level-domain (or tld - root-domain).

4.1 Key Rollovers

For non-tld's, I agree, again, with Antoin Verschuren
[[email-masked]] : recommend double-sign rollover.

The present document states, "neutrally", that double-sign rollover
involves more signatures and hence, larger zone files.  While this is
true, well maintained (public) zone files should be small anyway (except
for tld's).
The average company does not offer hundreds of services on hundreds of IP
addresses.

A DNS administrator who leaves data like "test-mx" in hers or his public
data should learn not to publish anything not meant to be distributed.
Recommending pre-publish for "large" zone files (with "lots" of
unnecessary data in it) is "pearls to the pigs" ;-)

4.1.2 Key Signing Rollovers

I see some tld's perform rollover with 3 keys (not 2).

Assuming a start position with 2 keys :
Initial : KSK1 & KSK2 (both being used for signing)
Start of rollover : add KSK3  --> KSK1 & KSK2 & KSK3 (all used for
signing)
End of rollover : remove KSK1 --> KSK2 & KSK3 (both used for signing)
Advantage :
 Only 2 actions to complete key rollover
 During the rollover, there is one key that is completely untouched.
 --> if chain-of-trust would break via KSK1 or KSK3, that KSK2
(DS/DNSKEY/RRSIG) is always available.

As the KSK signs only the DNSKEY RRset, this "costs" only one extra RRSIG
in the zone file.

Kind regards,

Marc Lampo

-----Original Message-----
From: Peter Koch [mailto:[email-masked]] 
Sent: 18 April 2011 07:42 PM
To: IETF DNSOP WG
Subject: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17]

Dear DNSOP WG,

    Stephen and Peter
     DNSOP co-chairs

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 19 Apr 2011 14:56:12 +0200

> document being published, please send that information to the list.

More comments:

Section 4.1.2 last paragraph:
"In this mechanism, there are periods where there are two DS
   RRs at the parent.  Since at the moment of writing the protocol for
   this interaction has not been developed, further discussion is out of
   scope for this document."

This is strange, as the Double DS rollover mechanism is used furtheron
in the document in section 4.1.3 figure 5. I think this text is a
leftover from a previous version. It is true that an automated rollover
with an in-band interaction has not been developped yet, but this text
seems to sugest that Double-DS has not been invented yet.
And if such interaction were developped, this should be discussed in
section 4.1.3 where Double-DS is defined, as this is what the
interaction is trying to automate.

When I take section 4.3.5 into considderation, I think that the
Double-DS mechanism is almost mandatory for a parent to implement,
otherwise you cannot accomodate secure child dns operator changes.
Since this mechanism can also be used for regular rollovers, as section
4.1.3 describes, I think Double-DS will be the default rollover
mechanism, and double signature only an alternative that will not be
deployed by all parents like registries that need to implement these
procedures. They will want to stick to one size fits all.

Sugestion: Remove the last paragraph of section 4.1.2 starting at "An
   alternative mechanism has been considered."
There's no use in discussing something that doen't excist yet.

section 4.1.3:
"A zone key rollover can be handled ...."
Please use the same syntax:
"A ZSK rollover can be handled..... "
It's less confusing.

Section 4.1.4 last paragraph:
"Since this
   leads to increase in zone and packet size at both child and parent
   there are little benefits to a Double-DS rollover with a Single Type
   signing scheme."
Same as above.
A Double-DS rollover is the only rollover mechanism you can use during a
secure dns operator change. Even with a Single Type signing scheme.

- -- 
Antoin Verschuren

---

From: "Osterweil, Eric" <[email-masked]>
Date: Tue, 19 Apr 2011 11:14:52 -0400

On 4/18/11 4:26 PM, "Joe Abley" <[email-masked]> wrote:

> In practice, for a TLD zone operator, rolling a KSK is a more complicated and
> time-consuming process than rolling a ZSK. A ZSK roll can be achieved quickly,
> entirely using systems operated by the TLD operator, whilst a KSK roll
> necessarily involves review by external organisations which takes more time.
> 
> (An emergency DS RRSet change for the root zone is required to be implemented
> within 48 hours of submission, assuming the request is well-formed. There have
> been no such requests to date so it is not possible to offer data on the
> actual time for implementation.)
> 
> Where a KSK/ZSK split exists, the frequency of use of each key is not the same
> -- ZSKs are typically exercised more frequently (every time an RRSIG over any
> RRSet in the zone needs to be generated) than ZSKs (which only need to be
> exercised as part of a ZSK roll).
> 
> I don't think it's unreasonable for these facts, as an inject to an
> appropriate threat analysis, to result in a recommendation to operate with a
> ZSK/KSK split -- such an arrangement facilitates different levels of
> protection for each key commensurate with the ease with which it might be
> rolled and the frequency with which it is required to be used.
> 

+1

Eric

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Apr 2011 12:48:29 -0400 (EDT)

> The average company does not offer hundreds of services on hundreds of IP

In almost all enterprises and government locations I have seen, there is one
very large dhcp based zone, with thousands or tens of thousands of entries
in a single zone. Picking the latest customer I was at, these are the top
sizes:

[paul@bofh]$ for zone in intranet/*ldns; do wc -l $zone | sed "s/ .*$//"; done | sort -n -r | head -10
144711
132489
52430
41155
20312
17326
15087
11196
10289
8587

These zones, all hosted on the same primary server, would see an additional half a million
RRSIGs with a double-sign rollover. And for redundancy, this customer also loads all their
auth zones on most of their name servers globally, and it would surely mean they need to
upgrade hardware just to comply with this recommendation.

-1 for this recommendation. TLDs are not that special in size.

Whether this is "well maintained" or "public" I will not judge on. It is just what I
encounter in the wild.

> data should learn not to publish anything not meant to be distributed.

I don't think 4641bis is supposed to make any value judgement about DNS data. Nor in fact,
do we really know what other new RRTYPE records (like HASTLS and TLSA) will end up in
the "well maintained public zone files".

4641bis should be about what is safe for the general use. If anything, TLDs are less
important for 4641bis because I expect TLDs to have DNS experts that can make their
own judgement and interpretation, whereas 4641bis will hopefully be a "default" setting
for most DNS servers/signers for organisations with less embedded DNS skills.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Apr 2011 12:53:31 -0400 (EDT)

> NS RRSet" and not mention anything about the MNAME field.

It wouldn't be bad to mention something about not putting "bogus" text in the
MNAME field. One example (not to pick on them specifically) is easydns, which
puts dns0.easydns.com in the MNAME, with the idea that no one should resolve
that anyway because it is not in the NS RRSet of their domains. But it still
leaks out RFC19198 space (hopefully into a close by AS112 server)

Though perhaps this is too out of scope for 4641bis

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Apr 2011 13:10:11 -0400 (EDT)

> In the non-cooperative case even a Double-DS does not make sense, and

I'm not sure if this is true in all cases.

Let's split the cases of non-cooperative. I think these will be:

1) shut down all dns
2) make no changes
3) make malicious changes

Against 1) and 3) you cannot do much (technically). Queries going to
the losing DNS operator will be manipulated, with or without valid
RRSIGs. One could argue here to immediately drop their DS record so
at least their manipulation does not enjoy the protection of DNSSEC
validation.  Putting in your own DS might even change those queries from
"insecure" to "bogus", which would be even better.

For queries that do not go to the losing DNS operator, having a new DS record
would cause new queries to be "secure" instead of "insecure".

For queries that have partially cached trust paths, adding your new DS
won't hurt, removing the old DS might make it better

So with this case, I agree with you. But these are likely the more rare
cases.

2) I believe is the more common case. It is eve more important to child
centric zones. Adding a DS won't hurt, and leaving the old DS in there
won't hurt either. Once most of the child centric zones finally caught
up with the new parents, the old DS can be removed.

Perhaps it is worth splitting the non-cooperative in these use cases?

Paul

---

From: David Blacka <[email-masked]>
Date: Tue, 19 Apr 2011 13:26:02 -0400

> (1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split.

A compelling reason to use the KSK/ZSK split is that you want to use different security practices for the SEP key (which is harder to roll) vs. the zone signing keys.  A common example of this is to keep the KSK "offline", which may be impractical for a ZSK.

> I don't think this is mentioned, even if it is obvious.

I don't think I agree with this logic.  It is true that the security of the whole chain is only as strong as the weakest link, but there is value in having your more difficult-to-roll KSK not be the weakest link.

--
David Blacka                          <[email-masked]> 
Principal Engineer      Verisign Infrastructure Engineering

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 20 Apr 2011 10:07:13 +0200

> Perhaps it is worth splitting the non-cooperative in these use cases?

That's excactly what was done in the draft.
There was just a mistake of putting the word "non-cooperative" where
"cooperative" was meant in the first sentence. And then continues to
describe the non-cooperative case.

There's realy nothing to describe in the non-cooperative case.
If your DNS provider wants to screw up, he can. Be warned. Be consious
about it, and sign a good contract with your DNS provider to prevent him
from screwing up. That's the only advise we can give.

- -- 
Antoin Verschuren

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 20 Apr 2011 10:23:54 +0200

> -1 for this recommendation. TLDs are not that special in size.

I aggree with Paul here.
There are enough large zones out there that are not a TLD, but on a
deeper level in the DNS. And they are just as important.
There is no judgment to be made about importance.

You just look at zone size, and the decision to use double-DS or
double-signature should be made on the operational impact.

For a small zone, double-signature may have almost the same impact as
double-DS, and in that case a faster rollover with less parent
interaction (double-signature) may be prefered.

For a larger zone, the increase in size may not be neglected, and more
parent interaction in the double-DS rollover may be prefered over the
larger zone file.

And again, if the rollover includes a change of DNS operator, Double-DS
is the only way to go if you want to stay secure.

- -- 
Antoin Verschuren

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 20 Apr 2011 10:43:19 +0200

Hi Paul,

> Perhaps it is worth splitting the non-cooperative in these use cases?

The losing operator still needs to publish the DNSKEYs of the winning
operator. Otherwise, you can get in a situation where a validator
fetches RRs from the gaining operators name server, but still have the
losing operator DNSKEY RRset in cache (that thus does not contain the
DNSKEYs of the winning operator).

Best regards,

Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 20 Apr 2011 10:52:18 +0200

Hi Antoin,

I agree those signatures for the DNSKEY RRset with the ZSK are redundant.

Also in Figure 9: Rollover for cooperating operators.

Furthermore, in the STSS Rollovers, I think the DNSKEY_K_* notations
should be replaced with DNSKEY_S_*.

Best regards,

Matthijs

On 04/19/2011 11:59 AM, Antoin Verschuren wrote:
> -I don't understand why the DNSKEY RRset should be signed with the ZSK.

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 20 Apr 2011 11:06:36 +0200

Hi again,

> procedures. They will want to stick to one size fits all.

I don't think the Double-DS is mandatory, you can still accommodate the
secure child dns operator change with the ZSK Pre-Publish/ KSK
Double-Signature approach (Figure 9).

> There's no use in discussing something that doen't excist yet.

Consider it done.

> "A ZSK rollover can be handled..... "

Ok.

> secure dns operator change. Even with a Single Type signing scheme.

As I said above, it's not.

Best regards,

Matthijs

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 20 Apr 2011 11:53:59 +0200

On 20-04-11 11:06, Matthijs Mekking wrote:

Hi Matthijs,

> Double-Signature approach (Figure 9).

Aagh, I missed that one.
Figure 9 is not possible!

RRSIG_K_B(DNSKEY) can never be generated at child A, because he does not
have B's private key !
Same for RRSIG_K_A(DNSKEY) at child B. Child B cannot create sigs with
child A's private key !

This example is wrong.

Really, the only way it can work is with double-DS

Child A can only generate RRSIG_K_A(DNSKEY)
and child B can only generate RRSIG_K_B(DNSKEY)

Both DS_A and DS_B need to be at the parrent for the rollover.

- -- 
Antoin Verschuren

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 20 Apr 2011 11:58:59 +0200

Hi Antoin,

It is assumed that in the cooperating case, both operators allow
publishing of the signatures.

So they don't create the signature themselves, they merely copy the
signature and publish it in their version of the zone.

Best regards,

Matthijs

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 20 Apr 2011 13:43:06 +0200

> signature and publish it in their version of the zone.

Ok, so that's a second option I hadn't thought about, because it is
impractical in practice. I guess in theory this will work, but only if
the zone, DNSKEYset and RRSIGs are static for the complete rollover period.

In the case I have seen and discussed so far, only the public keys were
exchanged, and not the signatures. Exchanging signatures takes again
another step in the process, as a new signature can only be created
after recieving the new keys. And it only works if the signatures have
an expire that is longer than the transfer process.

When you use the Doule-DS rollover, child A only needs to recieve B's
new public keys, and signs it only with KSK_A. child B has allready
queried A's public keys and has allready signed the DNSKEY set with only
KSK_B.
For the Double-DS method, that is sufficiant.

I guess you can now also have child A copy RRSIG_K_B(DNSKEY) and child B
copy RRSIG_K_A(DNSKEY), but this is another step in the process that
consumes propagation time and extra interaction. It also disallows the
childs to refresh the signatures when they expire, unless they have yet
another interaction.

This was the scheme I had in mind with Double-DS and cooperating DNS
providers:

- ------------------------------------------------------------
    initial            |        Double DS                    |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A                            DS_A
                                     DS_B
    ------------------------------------------------------------
    Child at A:            Child at A:       Child at B:
     SOA_A0                 SOA_A1            SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)    RRSIG_Z_B(SOA)

     NS_A                   NS_A              NS_B
     RRSIG_Z_A(NS)          RRSIG_Z_A(NS)     RRSIG_Z_B(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
     DNSKEY_K_A             DNSKEY_Z_B         DNSKEY_Z_B
     RRSIG_K_A(DNSKEY)      DNSKEY_K_A         DNSKEY_K_A
                            DNSKEY_K_B         DNSKEY_K_B
                            RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

    ------------------------------------------------------------
          Redelegation                 |   post migration      |
    ------------------------------------------------------------
    Parent:
              NS_B                           NS_B
              DS_A                           DS_B
              DS_B
    ------------------------------------------------------------
    Child at A:       Child at B:             Child at B:

     SOA_A2             SOA_B1                SOA_B2
     RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)        RRSIG_Z_B(SOA)

     NS_B               NS_B                  NS_B
     RRSIG_Z_A(NS)      RRSIG_Z_B(NS)         RRSIG_Z_B(NS)

     DNSKEY_Z_A         DNSKEY_Z_A            DNSKEY_Z_B
     DNSKEY_Z_B         DNSKEY_Z_B            DNSKEY_K_B
     DNSKEY_K_A         DNSKEY_K_A            RRSIG_K_B(DNSKEY)
     DNSKEY_K_B         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)

    ------------------------------------------------------------

There is less data to exchange.

- -- 
Antoin Verschuren

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 20 Apr 2011 14:31:37 +0200

Hi,

I agree that the Double-DS approach is more practicable than the current
rollover for cooperating operators. This is mentioned very briefly in
the -06 version (last paragraph 4.3.5.1).

However, we do want to provide an alternative for registries and
registrars that does not allow a Double-DS rollover scheme.

I do want to describe the cons of the current approach in more detail
(the ones you have mentioned in your mail). If it is necessary to add
the corresponding figure, it should then probably go into an appendix.

Proposed text (to replace the last paragraph in 4.3.5.1):

   The requirement to exchange signatures has a couple of drawbacks.  It
   requires more operational overhead, because not only the operators
   have to exchange public keys, they also have to exchange the
   signatures of the new DNSKEY RRset.  Also, it disallows the children
   to refresh the signatures when they expire for a certain period.
   Both drawbacks do not exist if you replace the Double Signature KSK
   rollover with a Double-DS KSK rollover.

   Thus, if the registry and registrars allow for DS records to be
   published, that do not point to a published DNSKEY in the child zone,
   the Double-DS KSK rollover is preferred (also known as Pre-
   Publication KSK Rollover, see Figure 5), in combination with the Pre-
   Publish ZSK rollover.  This does not require to share the KSK
   signatures between the operators.  Both the losing and the gaining
   operator still need to publish the public ZSK of each other.

Best regards,

Matthijs

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Apr 2011 10:30:48 -0400 (EDT)

> DNSKEYs of the winning operator).

How would the RRs be fetched from the new operator? That means the NS
set was updated. For which it needed the new DS to confirm the NS set.
In which case there might be old (validated) cache from the losing operator,
but no new records from that losing operator needing old DNSKEYs?

Paul

---

From: "George Barwood" <[email-masked]>
Date: Wed, 20 Apr 2011 22:50:50 +0100

----- Original Message ----- 
From: "Joe Abley" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Peter Koch" <[email-masked]>; "IETF DNSOP WG" <[email-masked]>
Sent: Monday, April 18, 2011 9:26 PM
Subject: Re: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17]

> I don't think it's unreasonable for these facts, as an inject to an appropriate threat analysis, to result in a 
> recommendation to operate with a ZSK/KSK split -- such an arrangement facilitates different levels of protection 
> for each key commensurate with the ease with which it might be rolled and the frequency with which it is required to > be used.

> I'm not saying it's the only way to go, but I think recommending against the practice makes little sense.

The arguments for  operating with a split still seem very weak to me.
The only strong argument seems to be that if there are high costs for rolling the KSK,
the risk of those costs being incurred can be reduced by having stronger KSK protection.
However rolling the KSK should be easy, since it is good security practice to change
secret keys regularly.

An additional point : if a split is used, by publishing a DS record for the ZSK,
the performance benefits of the single key scheme can be obtained ( the DNSKEY
RRset can be fully validated without doing an expensive and slow public key operation ).
If the DS record is not for the current ZSK, it will still work, but slower ( the DNSKEY
signature will need to be checked ).

Fully automatic updates of the parent DS RRset would make this technique more practical.

George

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Apr 2011 18:01:31 -0400

> The arguments for  operating with a split still seem very weak to me.

Since you're proposing a SHOULD NOT, I think the pertinent point is (a) whether it does any harm, and (b) whether it is useful in some circumstances.

I have seen no discussion of any harm, and several examples of why it might be useful.

Hence, to me, SHOULD NOT does not seem appropriate.

> However rolling the KSK should be easy, since it is good security practice to change

The first clause seems like a rampant generalisation, and the second is contentious (see ekr's various comments on this list regarding the cryptographic benefit of rolling non-compromised RSA keys).

> Fully automatic updates of the parent DS RRset would make this technique more practical.

Given that there is no sign of such a mechanism in general, and (in my opinion) there's at least one significant use case where any such mechanism is unlikely to be deployed (the root zone), I don't see a lot of practical value in that comment, either.

Joe

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 21 Apr 2011 09:17:05 +0200

Hi Paul,

> but no new records from that losing operator needing old DNSKEYs?

Suppose 11111 is the keytag of the DNSKEY of the losing operator and
22222 is the keytag of the DNSKEY of the winning operator.

I have still in my cache the DNKEY RRset with only the 11111 keytag.
I have received a request for <www.example.com A>.
It is not in the cache, I am going to query for it.
The NS set was updated, pointing me to the version of the zone of the
winning operator.

www.example.com A 1.2.3.4
www.example.com RRSIG A ... 22222 example.com ...

Signature made with keytag 22222 does not match the cached DNSKEY RRset
with key 11111.

Best regards,

Matthijs

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Apr 2011 11:19:04 -0400 (EDT)

> The NS set was updated, pointing me to the version of the zone of the

How is the NS set "updated" without validating that NS set using the
DNSKEY set and DS record of the winning operator?

> Signature made with keytag 22222 does not match the cached DNSKEY RRset

But you can only get here if you had followed the new glue at the TLD,
validated the new NS set at the new operator, using its new DNSKEY set,
for which you would need the new DS. So by the time you're passed the
NS set, you have all the DNSKEY's needed for other zone content.

The situation described in the draft cannot happen for proper validators.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Apr 2011 11:30:14 -0400

>NS set, you have all the DNSKEY's needed for other zone content.

You don't have to pre-validate hints (referrals).  In fact, it's 
better if you don't.

>The situation described in the draft cannot happen for proper validators.

I'd design a validating iterative resolver to be goal-directed and 
thus depth-first.  As one traverses from the root (or last cached 
point) to the answer, relying on optimism is expedient.  Once you get 
the suspected answer and then apply validation - if the result 
validates what does it matter if you got there through some shady 
paths?

Once the answer is delivered to the client, then it is wise to spend 
time validating and caching the hints.

If the suspected answer doesn't validate, then it's time to become 
pessimistic and chunk down the tree via validated referrals.  This is 
the approach I used when writing an early version of a validator 
(i.e., back in the 20th century).

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

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Apr 2011 15:09:38 +0200

Hi Paul,

> DNSKEY set and DS record of the winning operator?

How do you know which DNSKEY is from the winning operator?

There are two DS records at the parent (DS 11111, DS 22222) and the
first one matches the cached DNSKEY RR.

Best regards,

Matthijs

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Apr 2011 10:14:20 -0400 (EDT)

> first one matches the cached DNSKEY RR.

Again, how did YOU validate the new NSset if you don't have the right
DNSKEY? Please read the original text again. It assumes you somehow got
an updated *validated* NSset of the new operator, without having the
DNSKEY that validated that NSset. I keep telling you that is not possible.

Paul

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Apr 2011 16:39:03 +0200

I seem to be unable to find it in the specification that you need to
validate the new NS set. So, I don't assume that NS RRset is validated,
just updated.

I do know that the referral should be authenticated with the DS RRset,
signed with the parent key. So, I assume that the following is possible:

1. If that DS is validated with a DNSKEY RR from the parent, and it
matches the algorithm and key tag of a DNSKEY RR of the child, the
referral is considered authenticated.

2. I can use the NS RRset *from the parent* to resend my query for
<www.example.com IN A>.

3. From there, I get the new RRset signed with a key from the winning
operator.

Please show me the text from the specification that tells me that this
is impossible.

Best regards,

Matthijs