Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On Jul 8, 2013, at 3:32 PM, Patrik Fältström p...@frobbit.se wrote:
On 8 jul 2013, at 20:49, Dickson, Brian bdick...@verisign.com wrote:
However, maybe something like a PNS (parent NS) in the child, where the
child is authoritative for the data, could signal {change | validation}
(depending on the RRR requirements), would do the trick?
Might solve some events, but I do not think it solves the most important
situation, that DNS is moved from one DNS provider to another. The old DNS
provider can not be asked to enter NS records for the gaining provider... And
using NS (in reality, as you look for auth servers) to fetch NS data seems to
me be a bit...fishy... ;-) The attack vector against such a situation is very
complicated.
And is *precisely* why this document / technique is not trying to solve it.
CDS is specifically only for rolling your DNSKEY. It is specifically NOT for:
establishing trust.
recovering from a key compromise.
changing operators.
changing your NS.
a duck.
It is designed to be easy to clean, simple and easy to implement. It is
designed to solve the common case -- there are a whole slew of cases that it
simply rules out of scope.
This is designed to be the answer to I feel like I should roll my keys because
XXX, but I'm simply too lazy / likely to screw it up with the current
interface -- where XXX is something related to age, some policy, etc, NOT
because I wandered into the directory where I store keys and found a file
called exploit.php…
If I need to move DNS hosting folk, change my NS records, transfer my domain to
another registrar, revoke all keys, etc I'll go old skool and do the out of
band / web dance.
We want to make this annoying (probably repetitive) bit easier, ocean boiling
is left for later….
[ Please note: I'm currently sitting in a hotel in South Africa, with less than
stellar Internet access, and a funny timezone. Replies may be terse and
delayed. ]
W
Patrik
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Let's just say that if complete and utter chaos was lightning, he'd be the
sort to stand on a hilltop in a thunderstorm wearing wet copper armour and
shouting 'All gods are bastards'.
-- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On 7/12/13 8:19 AM, Warren Kumari wrote:
On Jul 8, 2013, at 3:32 PM, Patrik Fältström p...@frobbit.se wrote:
On 8 jul 2013, at 20:49, Dickson, Brian bdick...@verisign.com wrote:
However, maybe something like a PNS (parent NS) in the child, where the
child is authoritative for the data, could signal {change | validation}
(depending on the RRR requirements), would do the trick?
Might solve some events, but I do not think it solves the most important
situation, that DNS is moved from one DNS provider to another. The old DNS
provider can not be asked to enter NS records for the gaining provider... And
using NS (in reality, as you look for auth servers) to fetch NS data seems to
me be a bit...fishy... ;-) The attack vector against such a situation is very
complicated.
And is *precisely* why this document / technique is not trying to solve it.
This is why this is a good idea to me.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On Jul 11, 2013, at 3:54 AM, Antoin Verschuren antoin.verschu...@sidn.nl wrote: I've given Ed's words a really good thought, and slept a night over it. I think the reason why some of us don't feel comfortable with many of the assumptions in our requirements is because we try to avoid a framework we as technicians are not comfortable with, and that is trust. Trust is more a layer's thing. As sysadmins we expect trust is evident, and we all try to do the good thing so why would anyone doubt us at some point. We don't realize trust is something that needs to be gained by convincing somebody else to express it, it cannot be self-proclaimed. Quite right. But there is a second reason: the proposals are trying to use the DNS protocol to transmit the data and, seeing the limitations of doing so, adjust their requirements. A different way to design the protocol would be to list the real requirements and stick to them. This would very likely involve using a different communications protocol, such as RESTful-HTTP-over-TLS. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On 8 Jul 2013, at 18:03, Olafur Gudmundsson o...@ogud.com wrote: John, Thanks for a excellent and timely review we just about pushing out a new version when it arrived. We have accepted most of your edits and suggestions except when the text was already removed/reworded. Instead I want to focus on your Q1: How will a ``Child'' know if the ``Parent'' is doing CDS? IMHO, we need to figure out how/if to place a flag in parent saying what kinds of sync it is willing to do from signed children. I don't see the point of a flag. Since the auth servers for the child and parent never talk to each other the child would have to set up some tool to see the flag. It seems likely to me that the parent would have to give info about such a flag on a web page somewhere so the web page might as well be the flag. regards John --- j...@sinodun.com http://sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
Hello for the first time! I'm a bit new to this IETF stuff, but a long time participant in the world of DNS. I was pointed to this list by a friend, and in reading some of the more recent threads I felt compelled to jump in (I hope this sort of participation is copacetic). On Tue, 9 Jul 2013, Dickson, Brian wrote: to a different set, tools are likely better than doing it manually. CDS addresses the DS/DNSKEY part, but leaves the NS part unchanged. It's a problem which I presume exists or might exist, which goes along with the CDS problem: how do you automate X, where X is currently done via web form? (Automate might merely be integrate into a provisioning system). I don't know if the problem actually exists, so until someone says, Yeah, it is a problem, it is probably premature. You mean all the lame delegations in the world doesn't show an actual problem? I'm not sure I'm understanding you. Why would this not be a problem? I feel that Paul seems exactly right. Losing synchronization between the NS set and the crypto RRs (DS/DNSKEYs) seems like an alarming prospect (if I read Mr. Dickson's response right). In other words, Yeah, it is a problem. jl ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 08-07-13 20:28, Patrik Fältström schreef: One such situation is what is to happen when NS records changes in the parent zone. An immediate reaction is that change of NS records should trigger fetch of CDS record from the child zone so that the new DS can be included in the new version of the zone that have the new NS records. Careful thinking should say whether that is a correct thinking of me. Why would DS records change when NS records change? I guess you're thinking only one scenario here, and that is when NS records change, the DNS operator of the master changes and the zone will get different key material. But this is not the general case, only the most difficult one to solve. Only changing one slave NS by another does not change the operator maintaining the key material. Changing the operator maintaining the key material does happen, and when it does, changing the DS after changing the NS will not help you autoprovision. The zone will get bogus if you change the DS after changing the NS, and so no CDS change can be validated at all. Changing the key material operator needs pre-publishing of the new key material in the zone of the losing operator for the NS change to be validated. The new NS RRset in the child is signed with the new key material only. I know you all wish the world was simpler, but it isn't, We've tried. And a third if the auth servers queried at should be the ones that there are NS records for in the parent zone or the NS records that exists in the child zone. I agree with Andrew here that the NS RRset in the child zone is authoritative, but it can only be used if validated. Lastly, I think it should be very clear not only what the priority is between different versions of CDS records, but also between CDS records and epp commands. If different registries implement different policies here, the world might risk being much messier than what we want. Exactly my statement. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschu...@sidn.nl XMPP: antoin.verschu...@jabber.sidn.nl HTTP://www.sidn.nl/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJR27+5AAoJEDqHrM883Agn4wsH/1xXv9FkndogVEbzUQdLZhLD XB7JqT1QmKATKf+Ec6Rp1RLsA6QgA8XvyZOSzlUM/jEGARtldp1YncPsue/FO7an oRaTi/vk4o1rR+e8A/LKZvl0Ix0RbVZ+yA2NS+TtXCKm/eMJOjZy5TA9oNwINhfA 55d+V+jVro5rdfNO8yRflpe+Np3M9AOWmPdTgLTlw6axwvh8bZeJJ4jHjmrxpQWm GhXpVuRztG1+TJP+zBStKNNvvnMFps7oL3fdb+UlbI67f7KSpSfG4eyw3GSO/poA 0XF6nOfWZD/QFQoBIq8gWi4od2J9ImOcgsrCofnT+CdOP9+IBzQiYQqKxZHeDH0= =34D4 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 08-07-13 20:49, Dickson, Brian schreef: Upon receiving a change request for the NS set, the zone publisher could check the child for matching PNS records. Facilitates automation, just as CDS would. Thoughts? That's why I said I liked draft-hardaker-dnsop-csync-00.txt better, as it tries to solve the more general case of sending technical delegation data from child to parent, whether it is NS, DS, DNSKEY, or any other records we might need in the future to maintain a delegation. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschu...@sidn.nl XMPP: antoin.verschu...@jabber.sidn.nl HTTP://www.sidn.nl/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJR28EUAAoJEDqHrM883AgnzTgH/RjGNu4DL23dJP1SCPkqbRLc SmdzbHHqOgszK7gb+x4crWzpo6w5WhFZNonrod1UXyXpLapJuzezSBlTAdboWgAi 0ZPUPwEaEeoe+Ser+5oj68PWC1WJE0HP8pLAowy6QOJ4Umg24iwAo4OH8PjyIPVR LSibZU0gB1TdK4KcXIOll8JEvx9tfncy45lHXjf3f58I+8t3+1jb5yACQHEMIRd3 y8b5FxmphppQ/X67uumhAcDLtCBKsX0oEYRAH1FF2+hn8vaabat7J+u6EhH6E/+6 Qc+CC2hNm9+lR32Ecl437EEeW0s6SDmxWUGShqq6A6zMfOgKaAKJICipnJ5+CNg= =iPqi -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On 9 jul 2013, at 09:46, Antoin Verschuren antoin.verschu...@sidn.nl wrote: Signed PGP part Op 08-07-13 20:28, Patrik Fältström schreef: One such situation is what is to happen when NS records changes in the parent zone. An immediate reaction is that change of NS records should trigger fetch of CDS record from the child zone so that the new DS can be included in the new version of the zone that have the new NS records. Careful thinking should say whether that is a correct thinking of me. Why would DS records change when NS records change? I guess you're thinking only one scenario here, and that is when NS records change, the DNS operator of the master changes and the zone will get different key material. But this is not the general case, only the most difficult one to solve. Only changing one slave NS by another does not change the operator maintaining the key material. I am only saying change of the NS record should _trigger_ a fetch of the CDS. If the CDS has not changed, then the DNSSEC data in the parent should not change. Changing the operator maintaining the key material does happen, and when it does, changing the DS after changing the NS will not help you autoprovision. The zone will get bogus if you change the DS after changing the NS, and so no CDS change can be validated at all. The registry get an EPP update via a secure channel to change the NS. They can at that time (before the new zone is published) issue queries for CDS at the suggested new target of the NS, and if the CDS exists there they can fetch the CDS, see if key material changed, and incorporate the data in the zone that is to be published. Changing the key material operator needs pre-publishing of the new key material in the zone of the losing operator for the NS change to be validated. The new NS RRset in the child is signed with the new key material only. I know you all wish the world was simpler, but it isn't, We've tried. For newcomers to this discussion, Antoin and myself is in the middle of this discussion about how to do a change of DNS operator (and because of that change of maintainer of key material) in reality. We have, as you can see, different opinion on the topic :-) And a third if the auth servers queried at should be the ones that there are NS records for in the parent zone or the NS records that exists in the child zone. I agree with Andrew here that the NS RRset in the child zone is authoritative, but it can only be used if validated. But it can be validated thanks to the trust in the epp channel. Lastly, I think it should be very clear not only what the priority is between different versions of CDS records, but also between CDS records and epp commands. If different registries implement different policies here, the world might risk being much messier than what we want. Exactly my statement. Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 09-07-13 10:05, Patrik Fältström schreef: The registry get an EPP update via a secure channel to change the NS. They can at that time (before the new zone is published) issue queries for CDS at the suggested new target of the NS, and if the CDS exists there they can fetch the CDS, see if key material changed, and incorporate the data in the zone that is to be published. That CDS record will not validate at that point in time, so it will always be ignored. The pre-requisite for CDS is that the record can be validated, and the new zone is not yet in the chain of trust if the DNSKEY RRset that is present in the validating resolver does not contain the key by which the CDS record in the new zone is signed. You could do a theoretical validation of that record with the assumed future state of the zone and delegation at the parent, but all validating resolvers in the real world will have a DNSKEY RRset cached from the past, and are not aware of any future change until after it has happened. So during the DNSKEY TTL all records that should validate against the DNSKEY RRset will have a chance of being bogus, depending on from which zone the signatures come and which DNSKEY RRset is cached.. Unless you have pre-published a DNSKEY RRset that contains the ZSK's of both zones, so both signatures validate. But then there is no need to query the CDS record, because you cannot do a simultaneous second key rollover during a key maintainer change. You'll have to wait at least one child NS TTL after the NS change at the parent until it's safe to remove the old key and do another key rollover, so querying CDS immediately after changing the NS at the parent will always result in zero changes if you want your zone to work. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschu...@sidn.nl XMPP: antoin.verschu...@jabber.sidn.nl HTTP://www.sidn.nl/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJR295eAAoJEDqHrM883AgnFC4IANZXG6Rl8HB3U6U7UZS3URxf ham8o3+5hi9nx1s1KN4zljBWjnL0O0N2jBK+keSWLHLmmWzinFMjtHEv4RFaE9Ho ++jC0kZT2Z0Re65A2ZOh9lewpSvzBul9axcrD10w/yehVJhm5L4mAOhoL29dsegv PMsHpqDy1DJ0MvWrx+wdzGKTCG0S79SAbUedt0kLPt8tH0FFMAFUON1yFj3cYp2W ovpWGN1R0ex7g66CCSBWcx5otp8GJx1wIs1pra1xt3QmhOHTxKzGkuRIUjRRpMf7 AoogKu6i1LnxFVwGmlZab2Gebkx0g5aY3whrxZ65g30Wn1kPcFS1QBeHrQO+vDI= =A5ER -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On Jul 9, 2013, at 5:56 AM, Antoin Verschuren antoin.verschu...@sidn.nl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 09-07-13 10:05, Patrik Fältström schreef: The registry get an EPP update via a secure channel to change the NS. They can at that time (before the new zone is published) issue queries for CDS at the suggested new target of the NS, and if the CDS exists there they can fetch the CDS, see if key material changed, and incorporate the data in the zone that is to be published. That CDS record will not validate at that point in time, so it will always be ignored. The pre-requisite for CDS is that the record can be validated, and the new zone is not yet in the chain of trust if the DNSKEY RRset that is present in the validating resolver does not contain the key by which the CDS record in the new zone is signed. Antion, is right CDS or CSYNC can only help with operator change when the OLD operator is highly cooperative. Old Operator has to be willing and able to publish change information about the new operator in its copy of the zone and it has to publish it long enough for the parent to pick it up. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On 7/8/13 9:39 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Mon, Jul 08, 2013 at 06:49:53PM +, Dickson, Brian wrote: Thoughts? My immediate thought is, What problem is this trying to solve? Automating NS changes on the parent side, via child-signed-and-signalled in-zone data. If the CDS keys are needed for a change of DNS provider, it implies a new NS set on the parent (as well as the apex of the child). E.g. if someone needs to move a bunch of domains from one set of name servers to a different set, tools are likely better than doing it manually. CDS addresses the DS/DNSKEY part, but leaves the NS part unchanged. It's a problem which I presume exists or might exist, which goes along with the CDS problem: how do you automate X, where X is currently done via web form? (Automate might merely be integrate into a provisioning system). I don't know if the problem actually exists, so until someone says, Yeah, it is a problem, it is probably premature. It would really only make sense (or add value) if the domains were already DNSSEC delegations, and already doing CDS. If the key roll is being prompted by NS changes, then tying (loosely or tightly) the NS move with the CDS change, then the process reduces the probability of resolution breaking for any of the bunch. It would make sense basically only if the PNS RRset was signed, and would provide cryptographic protection on it, allowing for an in-band method of changing the NS on the parent side. It's not necessary, merely a convenience, or a way of facilitating better provisioning tools. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
Hi,
I have read draft draft-kumari-ogud-dnsop-cds-02. (Unfortunately, I have not
had time to read all the on list discussion, so apologies if I duplicate
comments)
IMHO:
Section 1.2 and 2.2.1 (Highlighted roles) should be combined and used
consistently through-out.
Section 2.1 refers to parties, section 2.2 refers to entities. One should be
chosen and added to 1.2/2.2.1.
2.2:
- last instance of the word organization should be plural
- s/same as operates the enterprises DNS servers/same as that which operates
the enterprises DNS servers/
- A domain name holder (child) - It is not immediately obvious if this is the
child defined in the subsequent section.
2.2.1:
- Remove the word DNS from the end of both DNS operator definitions.
- s/clutural/cultural/
- s/child delegation/Child/
2.3:
- s/In number/In a number/
- s/A further complication is when the DNS Operation is separate from the
Registrant./A further complication is when the Child DNS operator is not the
Child./
- The sentence, There are two common cases of this, registrar handles
the DNS operation and a third party takes care of the DNS operation. would
be clearer if it read something like There are two common cases of this
a) the registrar handles the DNS operation or b) a third party takes care of
the DNS operation.
- reorder the following sentences to reflect the order a,b above.
- the Registrant either needs to relay changes in DNS delegation are we
changing the delegation (implies NS to me)?
- we will use the word Child Operator, is this the same as Child DNS operator
defined in 2.2.1? Also s/word/phrase/
2.4:
- After a DNS operator first signs its zone whose zone, which DNS operator?
3:
- First paragraph has nothing to do with the CDS (Child DS) record definition
and should be (re-)moved.
3.1:
- Add a reference to the DS wire and presentation format. Also is there a need
to give a reference for the RR code?
3.1.1:
- Given the difficulties that can occur with going unsigned, I think this
section should be removed.
4.1
- much of the text in this section is not really about CDS Publication. The
first
sentence talks about consumption as does the final paragraph. Remove all text
except the Location, Signer and Continuity sections. Keep the text the
absence of CDS record signals No change in the current DS set. The use of
CDS is optional. Remove the MUST from Continuity - You can not tell a child
DNS operator not to break their or their customers own zone - It might be a
bad idea, but if that is what they want to do then so be it. It might be
better if Continuity was at least in part the parents responsibility
4.2 and 4.3
- Move the final paragraph of 4.2 to section 4.1
- Move the third paragraph of 4.3 to section 4.1
- I dislike the wording in these 2 sections especially the
term, Parental Agent who is this in 1.2/2.2.1?
I suggest the following text:
4.2. CDS Consumption
4.2.1 Detecting a changed CDS
How the Parent DNS operator (or registrar??? I will just use the term
Parent DNS operator from now on) detects changes to a CDS record may differ,
below are two examples of how this can take place.
Polling The Parent DNS operator operates a tool that
periodically checks each delegation that has a DS record to see
if there is a CDS record.
Pushing The Parent DNS operator in its user interface has a button
{Fetch DS} that when pushed initiates the CDS processing. If the
Parent zone does not contain a DS for this delegation then the
push MUST be ignored.
In either case the Parent DNS operator may apply additional rules
that defer the acceptance of a CDS change, these rules may include a
condition that the CDS must remain in place and valid for some time period
before it is accepted. It may be appropriate in the Pushing case to assume
that the Child is ready and thus accept changes without delay.
If the CDS RRset does not exist, the parent MUST take no action.
Specifically it MUST NOT delete or alter the existing DS RRset.
4.2.2 Using the new CDS
Regardless of how the Parent DNS operator detected changes to a CDS RR, the
Parent DNS operator MUST use a DNSSEC validator to obtain a validated CDS
RRset from the Child zone. It would be a good idea if the Parent DNS
operator
checked all NS RRs listed at the delegation. However, due to the use of
technologies such as load balancing and anycast, this should not be taken as
proof that the new CDS is present on all nodes serving the Child zone.
The Parent DNS operator MUST ensure that old versions of the CDS RRset
do not overwrite newer versions. This MAY be accomplished by checking that
the signature inception in the RRSIG for CDS is newer and/or the serial
number on the child's SOA is greater.
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On 7/8/13 2:28 PM, Patrik Fältström p...@frobbit.se wrote:
I have also had a look at this document which I in general do believe is
sound, although there are a few events I would like to have described in
the document. Reason for this is that I see it being really important
that it is implemented the same way in all usage scenarios.
One such situation is what is to happen when NS records changes in the
parent zone.
I think, perhaps, that a corresponding mechanism for NS change (or change
validation), will be what we eventually conclude is also a good idea (or
even necessary to provide some means of protection/validation to an
otherwise unprotected-but-critical element).
For the same kinds of reasons as parent/child DS vs DNSKEY mismatch
(pre-publication of DS without publication of DNSKEY), there are reasons
that parent and child NS sets are not always the same.
So, using the child NS set to directly validate the parent NS set is a
non-starter.
However, maybe something like a PNS (parent NS) in the child, where the
child is authoritative for the data, could signal {change | validation}
(depending on the RRR requirements), would do the trick?
Upon receiving a change request for the NS set, the zone publisher could
check the child for matching PNS records.
Facilitates automation, just as CDS would.
Thoughts?
Brian
An immediate reaction is that change of NS records should trigger fetch
of CDS record from the child zone so that the new DS can be included in
the new version of the zone that have the new NS records. Careful
thinking should say whether that is a correct thinking of me.
Another situation is what to do (by the parent) when inconsistent CDS
records are found from the authoritative servers for the zone (with and
without identical serial numbers in the SOA).
And a third if the auth servers queried at should be the ones that there
are NS records for in the parent zone or the NS records that exists in
the child zone.
This to resolve inconsistencies between information in parent and child
zones and between auth servers.
Lastly, I think it should be very clear not only what the priority is
between different versions of CDS records, but also between CDS records
and epp commands. If different registries implement different policies
here, the world might risk being much messier than what we want.
Hope this helps.
Patrik
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On 8 jul 2013, at 20:49, Dickson, Brian bdick...@verisign.com wrote:
However, maybe something like a PNS (parent NS) in the child, where the
child is authoritative for the data, could signal {change | validation}
(depending on the RRR requirements), would do the trick?
Might solve some events, but I do not think it solves the most important
situation, that DNS is moved from one DNS provider to another. The old DNS
provider can not be asked to enter NS records for the gaining provider... And
using NS (in reality, as you look for auth servers) to fetch NS data seems to
me be a bit...fishy... ;-) The attack vector against such a situation is very
complicated.
Patrik
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On Mon, Jul 08, 2013 at 06:49:53PM +, Dickson, Brian wrote: Thoughts? My immediate thought is, What problem is this trying to solve? In the DNSSSEC case, the problem is that you're trying not to break the chain of trust, and you need a mechanism that is cryptographically securable to make the communication. This is made harder in some sense by the fact that the DS and DNSKEY RRsets are authoritative on different sides of the zone cut. In the NS case, because the child side RRset is the really authoritative one, that's the one that generally gets cached. Since both sides of the cut have the same RRTYPE, and since only one of the RRsets can be cached, you end up with only one such set and it's the one that gets used. It's it possible to bollocks this so that resolution fails? Yes. But that's not a result of disagreement between two different RRsets, so in this case having the additional communication path (especially inside the DNS) is less necessary. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On Jul 1, 2013, at 9:25 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote: Hi Olafur, On 06/28/2013 08:18 PM, Olafur Gudmundsson wrote: On Jun 25, 2013, at 6:05 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote: * Nit: In section 1, it says there may be two interactions with the parent. This could also be only one, this could be more in some freaky rollovers, so I would prefer that it reads: there may be one ore more interactions with the parent. Applied * Section 3. I appreciate that most ZSK /KSK terminology is carefully replaced with, but in section 3 is still something that itches: The SEP bit is an optional bit to indicate that the key is allowed to sign the DNSKEY RRset. That is not true. Without the SEP bit, the key may also sign the DNSKEY RRset. I agree but still want to bring up the SEP bit, would some thing like this be better: The SEP bit is an optional bit that indicates that the child expects to sign the DNSKEY RRset with that key, while the key is in use. This text is better. Still, I want to propose text: The SEP bit, if set, indicates that the DNSKEY is intended for use as a secure entry point, thus are used to sign the DNSKEY RRset, and the Parental Agent can calculate DS records based on that. I applied this text with the change used to sign -- expected to sign This removes the notion of optional (strictly the bit is not optional, the setting of it is). * Section 4.2. It is suggested that RFC 5011-like hold down timers are being used, e.g. new keying information must be published for a month before acceptance as a new trust anchor. This makes the duration of key rollovers unnecessary long. The hold down timers in RFC 5011 are there to mitigate against a compromise. The compromise allows the attacker to sign data in the zone. I hear you and want other people to chime in, both in the context of compromise and time to perform rollover. If rollover is done by automated systems that perform checks before progressing who cares how long the rollover takes? It depends on what you gain with the long wait. I said in my e-mail that for me it makes sense to do hold down timers in the RFC5011 case, but we don't need to be that conservative with CDS. But I guess it has to do with local policy, what checks you require. I don't have very strong feelings about this. I just want to see it as fast as possible:). I guess if everything is done automagically, this is less of a pain. A nit drawback I see is that during the transition period you have to deal with a larger DNSKEY and/or DS RRset. I understand when a Human is involved in key rollover you want it to happen as fast as possible to minimize the chance of her forgetting a step. When this is fully automated in tools why is fast needed ? Similar we could look at a compromise that allows the attacker to upload a DS/DNSKEY to the parent. However, there are no mechanisms to mitigate against this attack. Why should we have mitigation for the CDS proposal, if there is none for the current mechanism? The difference between CDS and RFC 5011 is the location of the trust anchor your are updating. With CDS, you are updating the DS in the parent. With RFC 5011, you are updating lots of trust anchors in the wild. The latter may indeed require a bit more conservative approach. * Section 4.3. I wonder if the SHOULD in the first sentence should be a MUST. I think a better way is to encourage the child to ONLY publish CDS when there is a need to change the DS record and remove after parents performs change. I prefer the approach where the CDS represents what DS should be in the parent. You can make checks: if it is the same, we are in sync. If not, the parental agent still has work to do. Adding behavior to remove the CDS again after the update has taken place at all parent name servers, makes the usage at the child unnecessary complex. I got a comment off-line saying it is better for Parents that Mandating CDS removal as then there is no question at parent side as what to do. When CDS is present parent needs to perform checks it is in sync. For now I will leave this as an open issue, * Section 4.4. I dislike the idea of the side effect of parent calculates DS, so I would like to see that only the augment mode is supported (where I think it should read: it will make sure there are CDS records for the digest algorithm(s) it require(s) (CDS instead of DS)). You are not alone, but there are some people in your neighborhood that feel strongly the other way and argued strongly against version 01 because this was outlawed. Hm, yes. And I remember that they require the DNSKEY too. Still, I would still like to see that the CDS should match the to be calculated DS. The publishing Future DNSKEYs does not go well with several rollover scenarios (those based on Double-DS). I am wondering if the policy is
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On Jun 17, 2013, at 1:32 PM, Warren Kumari war...@kumari.net wrote: Hi there all, We have just posted a new version of draft-kumari-ogud-dnsop-cds This incorporates comments from both the list and in person discussions. The authors believe this version is ready for WG adoption and request the DNSOP chairs to kick off an adoption call. It has now been 2 weeks since we requested a call for adoption on this. Chairs? W W Begin forwarded message: From: internet-dra...@ietf.org Subject: New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt Date: June 17, 2013 12:58:29 PM EDT To: Olafur Gudmundsson o...@ogud.com, Warren Kumari war...@kumari.net, George Barwood george.barw...@blueyonder.co.uk A new version of I-D, draft-kumari-ogud-dnsop-cds-02.txt has been successfully submitted by Warren Kumari and posted to the IETF repository. Filename: draft-kumari-ogud-dnsop-cds Revision: 02 Title:Automating DNSSEC delegation trust maintenance Creation date:2013-06-17 Group:Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-02.txt Status: http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds Htmlized:http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-kumari-ogud-dnsop-cds-02 Abstract: This document describes a method to allow DNS operators to more easily update DNSSEC Key Signing Keys using DNS as communication channel. This document does not address the initial configuration of trust anchors for a domain. The IETF Secretariat -- Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'. -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic) -- Hope is not a strategy. -- Ben Treynor, Google ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On Jun 25, 2013, at 6:05 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote: Hi, On 06/21/2013 11:58 PM, Wes Hardaker wrote: Paul Wouters p...@cypherpunks.ca writes: I am in favour of adopting this draft as a WG item. Ditto. Another ditto. I am pleased to see that there is still activity on the topic of automating the synchronization between DNSKEY at the child and the DS at the parent. Thanks I don't think the CDS record should be able to cause a child domain to go from secure to insecure, or from insecure to secure. That (infrequent) change should have an additional authentication, eg via EPP or otherwise) Ditto. I think the goal of any of the automatic update techniques should be to make the routine easy but it shouldn't be a goal to handle the infrequent, and challenging cases. (infrequent and easy is fine). Unless we can show a clear, secured, path for some transition I don't think it's worth solving. Another ditto. Agreeing with it's not worth solving to deal with the irregular cases. Going unsigned is an irregular case. Also backing a previous made comment by other people: * I prefer to have the CDS wire format to be similar to the DS wire format. With the current draft, it is already possible to automate all possible key rollovers, no need for managerial hooks to say this record is proposed, must be added, deleted, is valid for only this period etc. Comments on the draft (apologies for its length): Thanks for the comments. * Nit: In section 1, it says there may be two interactions with the parent. This could also be only one, this could be more in some freaky rollovers, so I would prefer that it reads: there may be one ore more interactions with the parent. Applied * Section 3. I appreciate that most ZSK /KSK terminology is carefully replaced with, but in section 3 is still something that itches: The SEP bit is an optional bit to indicate that the key is allowed to sign the DNSKEY RRset. That is not true. Without the SEP bit, the key may also sign the DNSKEY RRset. I agree but still want to bring up the SEP bit, would some thing like this be better: The SEP bit is an optional bit that indicates that the child expects to sign the DNSKEY RRset with that key, while the key is in use. * Section 3.1.1. As said above, I don't like the idea of using the CDS record to go unsigned. Ack, this is going to be a design point allow or not allow this function. We can remove this part and later propose it as part of an extension, just like any protocol to automate the tickling of the parent. * Nit: Section 4.1. I think the last paragraph fits better in section 4.2. CDS Consumption. Reworked both sections to address this * Section 4.2. About the polling strategy. I am wondering how well this scales with respect to the number of delegations. The next version will indicate that polling has scaling issues, but punt the problem of defining a mechanishm to another document. The thinking is the parental notification is the HARDEST part of the proposal, and we might need multiple solutions depending number of delegations and other factors. Having said that in many cases in particular the enterprise and university cases polling is perfectly fine and will scale, thus our thinking is we will document that and start a parallel document on MAGIC system that does the notification, along the lines you documented few years back. * Section 4.2. It is suggested that RFC 5011-like hold down timers are being used, e.g. new keying information must be published for a month before acceptance as a new trust anchor. This makes the duration of key rollovers unnecessary long. The hold down timers in RFC 5011 are there to mitigate against a compromise. The compromise allows the attacker to sign data in the zone. I hear you and want other people to chime in, both in the context of compromise and time to perform rollover. If rollover is done by automated systems that perform checks before progressing who cares how long the rollover takes? Similar we could look at a compromise that allows the attacker to upload a DS/DNSKEY to the parent. However, there are no mechanisms to mitigate against this attack. Why should we have mitigation for the CDS proposal, if there is none for the current mechanism? The difference between CDS and RFC 5011 is the location of the trust anchor your are updating. With CDS, you are updating the DS in the parent. With RFC 5011, you are updating lots of trust anchors in the wild. The latter may indeed require a bit more conservative approach. * Section 4.3. I wonder if the SHOULD in the first sentence should be a MUST. I think a better way is to encourage the child to ONLY publish CDS when there is a need to change the DS record and remove after parents performs change. * Section 4.4. I dislike the idea of the side effect of parent calculates DS, so I would like to
