Re: [DNSOP] KSK rollover choices

[Wes Hardaker]

Joe Abley  writes:

> I think the wider problem space might be better described as trust
> anchor publication and retrieval.

Couldn't have said it better myself (more specifically, I didn't).  The
problem space is much bigger than 5011, and 5011 is but one tool to
solve a piece of the whole space.
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover choices

[Joe Abley]

On 1 Nov 2018, at 15:14, Wes Hardaker  wrote:

> Russ Housley  writes:
> 
>> It is a good time to do rfc5011-bis.  Real world experience from the
>> KSK roll makes a lot os sense to me.
> 
> I think step one would be to list the aspects of it that worked well,
> and the aspects that didn't.  From that we can determine the need for a
> replacement and what features would be needed in order to accommodate the
> aspects that didn't work well.  I do believe it worked quite well over
> all, but there are elements that were lacking and may be worth doing a
> bis to address.  [but we really need a upsides-and-downsides list based
> on experience first in order to evaluate the need to do a bis].

I'm not sure that "5011bis" is a helpful way to phrase this.

5011 solves the area it is concerned with (conventionally long-lived devices 
that don't ship on the shelf for long periods) very nicely, as far as I can 
see. There have been some variable implementations that might suggest the need 
for improved clarity in the specification or better test suites or something, 
but I don't think our recent experience has provided clear signs that 5011 as a 
protocol is deficient or unsuitable.

I think the wider problem space might be better described as trust anchor 
publication and retrieval. Within that perimeter we can find scope for 
improvement in areas like emergency key rollover, pre-publication of trust 
anchors for standby keys, retrieval of trust anchor (bootstrapping) by 
ephemeral or unattended devices, etc, etc. The area that 5011 addresses is kind 
of the best part.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover choices

[Wes Hardaker]

Russ Housley  writes:

> It is a good time to do rfc5011-bis.  Real world experience from the
> KSK roll makes a lot os sense to me.

I think step one would be to list the aspects of it that worked well,
and the aspects that didn't.  From that we can determine the need for a
replacement and what features would be needed in order to accommodate the
aspects that didn't work well.  I do believe it worked quite well over
all, but there are elements that were lacking and may be worth doing a
bis to address.  [but we really need a upsides-and-downsides list based
on experience first in order to evaluate the need to do a bis].
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover choices

[Russ Housley]

> On Oct 30, 2018, at 8:27 PM, Mark Andrews  wrote:
> 
>> On 31 Oct 2018, at 11:16 am, Jim Reid  wrote:
>> 
>> On 30 Oct 2018, at 22:31, Mark Andrews  wrote:
>>> 
>>> Ultra frequent key rolls are not necessary.  It takes years the latest 
>>> releases of name servers to make it into shipping OS’s.
>> 
>> So what? Key rollover policies cannot and should not be driven by vendor OS 
>> release schedules. Or the BIND/whatever version they choose to distribute. 
>> If key rollovers became dependent on these considerations, we’d never be 
>> able to roll the root’s KSK.
>> 
>> Software that had hard-wired the old key caused trouble for the recent 
>> rollover so we simply have to be in a much better place next time. I hope 
>> you don't want to perpetuate that legacy behaviour, albeit in a slightly 
>> different form.
>> 
>> If the (hypothetical) problem is DNS software gets shipped with the current 
>> KSK on the release date and that might lurk in vendor distributions long 
>> after the KSK has rolled, the solution is obvious. Don’t do that.
> 
> Bootstrap is still a issue.  Over fast TA rolling makes it more of a issue.
> 
> I think we would replace RFC 5011 with something else before we roll the root 
> key next while using RFC 5011 timings for the roll for legacy 
> implementations.  We really need a way to signal how long a TA is expected to 
> be valid for.  This allows machines to safely fail to insecure if they have 
> been off for too long.

It is a good time to do rfc5011-bis.  Real world experience from the KSK roll 
makes a lot os sense to me.

And, an operational considerations section can address the bootstrap issue.

Russ

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover choices

[Michael StJohns]

On 10/31/2018 2:54 PM, Paul Vixie wrote:



Jim Reid wrote:



On 31 Oct 2018, at 00:27, Mark Andrews  wrote:

Bootstrap is still a issue.  Over fast TA rolling makes it more of
a issue.


Indeed. And that's the underlying problem that needs to be fixed IMO
- for instance when/if there's an emergency rollover.


bootstrappers should have https access to a complete history of root 
ksk, each one signed by its predecessor. this doesn't handle 
revocation, but nothing in dnssec handles revocation, and that's by 
design, and so i'm inclined not to worry about it.

there are at least two things wrong with the above:

1) 5011 provides revocation for ALL keys, not just the root keys, and 
that's by design.  Set the revoke bit on a key, self-sign the RRset with 
that key, and it should prevent trust being traced through the key.
2) the simple history approach will not work.  Simply consider that you 
might need to deal with compromised keys and tell me how I can ensure I 
have ALL the information I need based on a history that can actually 
reflect all types of real world input.   Something like a block chain 
(with yet another set of signatures) over a set of versions of the root 
dnskey RRSet might work, but that will require another chain of trust 
besides the dnssec chain.





but that's the backup plan. the primary expectation is, devices which 
come off the shelf after a dnssec ksk roll will have some means of 
reaching and trusting their manufacturer's software update service, 
which will offer them a current ksk for validation.


I think the primary expectation should really be the only plan.


manufacturers who don't last long enough to do this, or who for 
whatever other reason don't do this, will be shipping future bricks. 
and i'm fine with that, since it's in their power to do the right 
thing, which is the best we can offer.



Yup -

Mike


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover choices

[Joe Abley]

Hi Paul,

On 31 Oct 2018, at 14:54, Paul Vixie  wrote:

> Jim Reid wrote:
> 
>>> On 31 Oct 2018, at 00:27, Mark Andrews  wrote:
>>> 
>>> Bootstrap is still a issue.  Over fast TA rolling makes it more of
>>> a issue.
>> 
>> Indeed. And that's the underlying problem that needs to be fixed IMO
>> - for instance when/if there's an emergency rollover.
> 
> bootstrappers should have https access to a complete history of root ksk, 
> each one signed by its predecessor. this doesn't handle revocation, but 
> nothing in dnssec handles revocation, and that's by design, and so i'm 
> inclined not to worry about it.

The existing scheme provides bootstrappers with a complete history of trust 
anchors (published by digest). The published object was intended to be 
accompanied by a detached signature that could be trusted by a vendor, since 
there was to be a certificate chain from the object-signing certificate back to 
an X.509 trust anchor that made sense to the client (e.g. an iOS code-signing 
key, a Windows code-signing key, an ISC code-signing key, etc, etc). This is 
described in RFC 7958.

The only "vendor" that ever published such a certificate was the (largely 
proof-of-concept) "ICANN" vendor.

I'm not suggesting that the scheme described in that document is good, or that 
it shouldn't be replaced with something better, but it's one possible starting 
point for the discussion.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover choices

[Paul Vixie]

Jim Reid wrote:



On 31 Oct 2018, at 00:27, Mark Andrews  wrote:

Bootstrap is still a issue.  Over fast TA rolling makes it more of
a issue.


Indeed. And that's the underlying problem that needs to be fixed IMO
- for instance when/if there's an emergency rollover.


bootstrappers should have https access to a complete history of root 
ksk, each one signed by its predecessor. this doesn't handle revocation, 
but nothing in dnssec handles revocation, and that's by design, and so 
i'm inclined not to worry about it.


but that's the backup plan. the primary expectation is, devices which 
come off the shelf after a dnssec ksk roll will have some means of 
reaching and trusting their manufacturer's software update service, 
which will offer them a current ksk for validation.


manufacturers who don't last long enough to do this, or who for whatever 
other reason don't do this, will be shipping future bricks. and i'm fine 
with that, since it's in their power to do the right thing, which is the 
best we can offer.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover choices

[Jim Reid]

> On 31 Oct 2018, at 00:27, Mark Andrews  wrote:
> 
> Bootstrap is still a issue.  Over fast TA rolling makes it more of a issue.

Indeed. And that's the underlying problem that needs to be fixed IMO - for 
instance when/if there's an emergency rollover.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] KSK rollover choices

[Paul Hoffman]

Just a brief note that the threads about KSK futures started on the 
ksk-rollo...@icann.org  mailing list and should 
probably still be there. The only bit that was meant to be on this Working 
Group mailing list was an announcement of the side-meetings next week.

If at some point there is DNS protocol or operational work to be done, it can 
be brought here. Until then, let's leave this mailing list to the quite active 
list of topics that the Chairs are already juggling.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover choices

[Mark Andrews]

> On 31 Oct 2018, at 11:16 am, Jim Reid  wrote:
> 
> On 30 Oct 2018, at 22:31, Mark Andrews  wrote:
>> 
>> Ultra frequent key rolls are not necessary.  It takes years the latest 
>> releases of name servers to make it into shipping OS’s.
> 
> So what? Key rollover policies cannot and should not be driven by vendor OS 
> release schedules. Or the BIND/whatever version they choose to distribute. If 
> key rollovers became dependent on these considerations, we’d never be able to 
> roll the root’s KSK.
> 
> Software that had hard-wired the old key caused trouble for the recent 
> rollover so we simply have to be in a much better place next time. I hope you 
> don't want to perpetuate that legacy behaviour, albeit in a slightly 
> different form.
> 
> If the (hypothetical) problem is DNS software gets shipped with the current 
> KSK on the release date and that might lurk in vendor distributions long 
> after the KSK has rolled, the solution is obvious. Don’t do that.

Bootstrap is still a issue.  Over fast TA rolling makes it more of a issue.

I think we would replace RFC 5011 with something else before we roll the root 
key next while using RFC 5011 timings for the roll for legacy implementations.  
We really need a way to signal how long a TA is expected to be valid for.  This 
allows machines to safely fail to insecure if they have been off for too long.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] KSK rollover choices

[Jim Reid]

On 30 Oct 2018, at 22:31, Mark Andrews  wrote:
> 
> Ultra frequent key rolls are not necessary.  It takes years the latest 
> releases of name servers to make it into shipping OS’s.

So what? Key rollover policies cannot and should not be driven by vendor OS 
release schedules. Or the BIND/whatever version they choose to distribute. If 
key rollovers became dependent on these considerations, we’d never be able to 
roll the root’s KSK.

Software that had hard-wired the old key caused trouble for the recent rollover 
so we simply have to be in a much better place next time. I hope you don't want 
to perpetuate that legacy behaviour, albeit in a slightly different form.

If the (hypothetical) problem is DNS software gets shipped with the current KSK 
on the release date and that might lurk in vendor distributions long after the 
KSK has rolled, the solution is obvious. Don’t do that.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] KSK rollover postponed

[Mikael Abrahamsson]

https://www.icann.org/news/announcement-2017-09-27-en

Thought this might be relevant to some.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] KSK rollover in .cz

[Jaromír Talíř]

Hi,

I have just a quick information from DNSSEC movement in .cz. Next
Tuesday we will start our first KSK rollover for .cz domain. We decided
to chose stronger algorithm RSASHA512 and to switch from NSEC to NSEC3.
That means we have to follow procedure for algorithm rollover as
described in
http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03#section-4.1.5.
This involves four changes in standard signing procedure. On Tuesday,
August 3, we will implement first two changes. In the morning we will
insert new signatures for all RRSET created using new RSASHA512 keys
without publishing new keys. In the evening, after all TTLs when new
RRSIGs will be in all resolvers we will also include new keys into
zonefile. 

Then we will send request for exchange of keys in root zone to IANA. In
the same time, as our way to promote DNSSEC validation using root zone,
we will also  remove all our keys from ITAR and DLV. We communicated
this intensively in past several weeks together with promotion of root
zone signing, so we don't expect problems from resolvers operators.

We will do last two changes in our rollover process on August 24, to
give IANA time to implement changes in root zone. Again, in the morning
we will start with removing old keys from zonefile and in the evening we
will remove also old signatures and resign zone using NSEC3. We have
chosen NSEC3 without OptOut for two reasons. Right now we have more than
100 000 signed domains out of almost 700 000, and we expect it to grow,
so the difference in the size is not an issue. Second, we think it's not
a good idea to lower security level even for not-secured domains which
would happen with OptOut.

Jaromir

-- 
Jaromir Talir
technicky reditel / Chief Technical Officer
---
CZ.NIC, z.s.p.o.  --.cz domain registry
Americka 23, 120 00 Praha 2, Czech Republic
mailto:jaromir.ta...@nic.cz  http://nic.cz/
sip:jaromir.ta...@nic.cz tel:+420.222745107
mob:+420.739632712   fax:+420.222745112
---

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[George Barwood]

Chris,

Thanks for your comments.

- Original Message - 
From: "Chris Thompson" 
To: "George Barwood" 
Cc: 
Sent: Saturday, May 22, 2010 8:07 PM
Subject: Re: [DNSOP] KSK rollover


> On May 22 2010, George Barwood wrote:
> 
>>Well, I have uploaded a draft :
>>
>>http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt
>>
>>Comments and/or indications of support are of course welome, on or off list.
> 
> Section 3:
> 
> | The CDS record MUST be signed with a Key Signing Key, that is a key
> | for which there is a DS record.
> 
> (a) That's a new definition of "key signing key", I think. RFC3757 comes
>closest with KSK = key with SEP bit = "which DNSKEYs are to be sent
>for *generating* DS RRs" (my emphasis), but I take it you mean a key
>for which a DS record *already* exists.

Ok - so I guess I should just possibly say simply:

"The CDS record MUST be signed with a key for which there is a DS record."
 
> (b) Why? Why shouldn't a chain of trust through (say) a KSK and a ZSK 
>be enough? Insisting on a one-step chain seems contrary to the
>spirit, at least, of RFC 4034 section 2.1.1.

My reasoning is that

(i) Zone signing keys are used more frequently than a KSK, since they are 
needed whenever the
zone content changes ( in particular if dynamic update is supported, the ZSK 
must be kept online ).
Therefore Zone signing keys are more exposed to compromise. They also tend to 
be shorter, and
are therefore possibly easier to crack.

(ii) The CDS record is not verified during normal operation, so any cost 
associated with
the longer signature does not matter.

(iii) My intuition suggests that access to a Zone signing key should not give 
permission 
to update the CDS RRset.

This reasoning may not hold up under closer scrutiny, it's just my take on it ( 
and as the acknowledgments
mention, I received a hint on this from Olafur Gudmundsson - maybe he has 
better insight into this )).

Re RFC 4034, section 2.1.1 : isn't that simply saying that "all" keys have Bit 
7 set in the flags field?
Both Zone Signing Keys and Key Signing Keys are "Zone keys", inasmuch as they 
are used to 
verify RRSIGs.

[ By "all" I mean all DNSSEC keys that we use today ]

Regards,
George

> -- 
> Chris Thompson   University of Cambridge Computing Service,
> Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
> Phone: +44 1223 334715   United Kingdom.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Chris Thompson]

On May 22 2010, George Barwood wrote:


Well, I have uploaded a draft :

http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt

Comments and/or indications of support are of course welome, on or off list.


Section 3:

| The CDS record MUST be signed with a Key Signing Key, that is a key
| for which there is a DS record.

(a) That's a new definition of "key signing key", I think. RFC3757 comes
   closest with KSK = key with SEP bit = "which DNSKEYs are to be sent
   for *generating* DS RRs" (my emphasis), but I take it you mean a key
   for which a DS record *already* exists.

(b) Why? Why shouldn't a chain of trust through (say) a KSK and a ZSK 
   be enough? Insisting on a one-step chain seems contrary to the

   spirit, at least, of RFC 4034 section 2.1.1.

--
Chris Thompson   University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715   United Kingdom.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[George Barwood]

Well, I have uploaded a draft :

http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt

Comments and/or indications of support are of course welome, on or off list.

George

- Original Message - 
From: "George Barwood" 
To: 
Sent: Thursday, May 13, 2010 8:56 AM
Subject: [DNSOP] KSK rollover


>I have been thinking about KSK rollover in my DNSSEC implementation, and it 
>seems
> that there is currently no  specification for KSK rollover within the DNSSEC 
> protocol.
> 
> There is this expired requirements draft
> 
> http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-key-rollover-requirements/
> 
> but that's all I found.
> 
> Have I missed something? It seems to me that this is a rather vital component 
> if
> DNSSEC is to be widely deployed.
> 
> Are there any plans to revive and/or implement these requirements?
> 
> George Barwood
> ___
> 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] KSK rollover

[Mark Andrews]

In message , Joe Abley writes
:
> 
> On 2010-05-13, at 22:32, Mark Andrews wrote:
> 
> > Which is essentially registrar to registry.  It really does not
> > make for a general solution to the problem unless every operator
> > of every zone that delegates any zone runs epp in addition to running
> > a DNS server.
> 
> Sure, but be aware that you're conflating several of
> 
>  - delegated zone editor
>  - delegated zone publisher
>  - authoritative nameserver operator for delegated zone
>  - registrant
>  - registrar
>  - registry
>  - parent zone editor
>  - parent zone publisher
>  - authoritative nameserver operator for the parent zone
> 
> in your general solution, which makes it no more general, really. =
> Granted there are probably not often nine different entities carrying =
> out those functions, but increasingly there are more than two.
> 
> The EPP answer at least has some basis in current reality.
> 
> I suspect there is no general solution.
> 
> Joe

On the other hand I'm sure that there is a general solution.
We need to define how the child talks to the parent so that
the parent can be sure that it is the child making the request.

The rest depends on the business models the parent and child are
using.

child component with authority to update ->
PROTOCOL ->
 parent component the authority to accept update from child ->
parent processes ->
 published zone.

parent processes could be:
forward to registrar
registrar authenticates send back ack/nak via parent component
convert to epp and update registry
registry publishes.

or they could just be:
authenticate
update parent zone
send back ack/nak

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Joe Abley]

On 2010-05-13, at 22:32, Mark Andrews wrote:

> Which is essentially registrar to registry.  It really does not
> make for a general solution to the problem unless every operator
> of every zone that delegates any zone runs epp in addition to running
> a DNS server.

Sure, but be aware that you're conflating several of

 - delegated zone editor
 - delegated zone publisher
 - authoritative nameserver operator for delegated zone
 - registrant
 - registrar
 - registry
 - parent zone editor
 - parent zone publisher
 - authoritative nameserver operator for the parent zone

in your general solution, which makes it no more general, really. Granted there 
are probably not often nine different entities carrying out those functions, 
but increasingly there are more than two.

The EPP answer at least has some basis in current reality.

I suspect there is no general solution.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Mark Andrews]

In message <74ae2b2b-a09a-4fbf-b6c3-7eebe89ca...@hopcount.ca>, Joe Abley writes
:
> 
> On 2010-05-13, at 19:33, Mark Andrews wrote:
> 
> > There are lots of way to do this.
> > * Use UPDATE to update the delegation records in the parent.
> >   This would work today it only requires a willingness to do so.
> >   This can be done securely (TSIG) and will scale.
> >   UPDATE was designed to support this.
> > * Try to guess which keys should have DS's based on SEP bits.
> > * Use a different RR type (DLV does this).  poll/notify to
> >   incorporate.  (Ed the daily delegation check could do this.
> :-))
> > * Use some epp extension.
> > * Use a modified UPDATE which accepts and forwards to the
> >   registrar for inclusion in the zone rather than immediately
> >   updates the zone.  When a registrar is not involved it is
> >   handled as a plain UPDATE.
> > * 
> 
> ... and there's also the approach that is actually being implemented,
> which is described in RFC 4310.

Which is essentially registrar to registry.  It really does not
make for a general solution to the problem unless every operator
of every zone that delegates any zone runs epp in addition to running
a DNS server.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Joe Abley]

On 2010-05-13, at 22:13, Joe Abley wrote:

> ... and there's also the approach that is actually being implemented, which 
> is described in RFC 4310.

Or 5910, since that seems to exist now. :-)

Internet Engineering Task Force (IETF)  J. Gould
Request for Comments: 5910 S. Hollenbeck
Obsoletes: 4310   VeriSign, Inc.
Category: Standards Track   May 2010
ISSN: 2070-1721


  Domain Name System (DNS) Security Extensions Mapping
 for the Extensible Provisioning Protocol (EPP)


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Joe Abley]

On 2010-05-13, at 19:33, Mark Andrews wrote:

>   There are lots of way to do this.
>   * Use UPDATE to update the delegation records in the parent.
> This would work today it only requires a willingness to do so.
> This can be done securely (TSIG) and will scale.
> UPDATE was designed to support this.
>   * Try to guess which keys should have DS's based on SEP bits.
>   * Use a different RR type (DLV does this).  poll/notify to
> incorporate.  (Ed the daily delegation check could do this. :-))
>   * Use some epp extension.
>   * Use a modified UPDATE which accepts and forwards to the
> registrar for inclusion in the zone rather than immediately
> updates the zone.  When a registrar is not involved it is
> handled as a plain UPDATE.
>   * 

... and there's also the approach that is actually being implemented, which is 
described in RFC 4310.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Mark Andrews]

In message <44c21cd9ee514b039eafeafa707a2...@local>, "George Barwood" writes:
> 
> - Original Message - 
> From: "Patrik Wallstrom" 
> To: "George Barwood" 
> Cc: 
> Sent: Thursday, May 13, 2010 9:06 AM
> Subject: Re: [DNSOP] KSK rollover
> 
> 
> 
> >On May 13, 2010, at 9:56 AM, George Barwood wrote:
> 
> >> I have been thinking about KSK rollover in my DNSSEC implementation, and i
> t seems
> > that there is currently no  specification for KSK rollover within the DNSSE
> C protocol.
> >> 
> >> There is this expired requirements draft
> >> 
> >> http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-key-rollover-requirements/
> >> 
> >> but that's all I found.
> >> 
> >> Have I missed something? It seems to me that this is a rather vital compon
> ent if
> >> DNSSEC is to be widely deployed.
> >> 
> >> Are there any plans to revive and/or implement these requirements?
> 
> > You probably want to read the Key Timing Considerations draft:
> > http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02
> 
> That is certainly relevant to rollover, but it doesn't specify any means by
> which the new DS records can be placed in the parent zone.
> 
> http://tools.ietf.org/html/rfc5011 "Automated Updates of DNS Security
> (DNSSEC) Trust Anchors"
> 
> has some relevance, but doesn't provide for parent notification, or for
> publishing a DS record *before* the key is published in the zone, which
> is I think desirable.

RFC5011 really isn't applicable to this case.
 
> The mechanism that occurs to me is to have a new RRtype, say "CDS", with
> identical format to the DS record, but placed in the child zone ( and 
> signed by the child zone). The parent, at regular intervals, or on
> receiving a notification from the child, would retrieve the contents of
> the CDS RRset, and use it as the new DS RRset ( of course after validating
> it using the old DS RRset ).

There are lots of way to do this.
* Use UPDATE to update the delegation records in the parent.
  This would work today it only requires a willingness to do so.
  This can be done securely (TSIG) and will scale.
  UPDATE was designed to support this.
* Try to guess which keys should have DS's based on SEP bits.
* Use a different RR type (DLV does this).  poll/notify to
  incorporate.  (Ed the daily delegation check could do this. :-))
* Use some epp extension.
* Use a modified UPDATE which accepts and forwards to the
  registrar for inclusion in the zone rather than immediately
  updates the zone.  When a registrar is not involved it is
  handled as a plain UPDATE.
* 

> There probably needs to be consideration of how the system can recover after
> a KSK is compromised, maybe there should be some minimum time interval
> before a new DS record is fully trusted. I have not thought that through.
> 
> Well, that's just my immediate thoughts, there may be a better way.
> 
> I'm somewhat puzzled that thre is no specification, and apparently no
> activity on this.

There is plenty of activity.  Most of it has been people
looking at how to fit this into the registry/registrar model
and worries about patent infringement that are claimed to
have been filed for some of the above.  I doubt that any
thing we do in this area is truly novel but the USPO grants
patents on such trivial things that its become a issue.

Mark

> KSK rollover is probably a fairly rare event (maybe once every few years), so
> possibly the feeling is that manual procedures will be sufficient. I think a
> standardized, automated in-protocol mechanism would be advisable though.
> Maybe I'm wrong.
> 
> Best regards,
> George
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Edward Lewis]

At 17:37 +0100 5/13/10, George Barwood wrote:


I'm somewhat puzzled that thre is no specification, and apparently no
activity on this.


http://www.ripe.net/ripe/meetings/ripe-59/presentations/lewis-dnssec.pdf

There's activity.  There's no standard underway because of the 
plethora of situations.  There are proposed solutions that extend 
DNS, some extend EPP, and sooner or later some will extend other 
provisioning protocols.


I doubt we will come to one standard practice.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStarYou can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Evan Hunt]

> That is certainly relevant to rollover, but it doesn't specify any means
> by which the new DS records can be placed in the parent zone.

You're correct, there's no mechanism for doing this within the DNS.  You
need to update DS records through your registrar just as you do with NS
records and glue.

I hear there's an effort under way to develop an in-protocol mechanism
for DS tracking, but I don't know how far along it is.

> The mechanism that occurs to me is to have a new RRtype, say "CDS", with
> identical format to the DS record, but placed in the child zone ( and
> signed by the child zone).

You've got a chicken-egg problem there: How does the parent know it
should trust the key that signed the CDS?

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[George Barwood]

- Original Message - 
From: "Patrik Wallstrom" 
To: "George Barwood" 
Cc: 
Sent: Thursday, May 13, 2010 9:06 AM
Subject: Re: [DNSOP] KSK rollover



>On May 13, 2010, at 9:56 AM, George Barwood wrote:

>> I have been thinking about KSK rollover in my DNSSEC implementation, and it 
>> seems
> that there is currently no  specification for KSK rollover within the DNSSEC 
> protocol.
>> 
>> There is this expired requirements draft
>> 
>> http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-key-rollover-requirements/
>> 
>> but that's all I found.
>> 
>> Have I missed something? It seems to me that this is a rather vital 
>> component if
>> DNSSEC is to be widely deployed.
>> 
>> Are there any plans to revive and/or implement these requirements?

> You probably want to read the Key Timing Considerations draft:
> http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02

That is certainly relevant to rollover, but it doesn't specify any means by 
which
the new DS records can be placed in the parent zone.

http://tools.ietf.org/html/rfc5011 "Automated Updates of DNS Security (DNSSEC) 
Trust Anchors"

has some relevance, but doesn't provide for parent notification, or for 
publishing
a DS record *before* the key is published in the zone, which is I think 
desirable.

The mechanism that occurs to me is to have a new RRtype, say "CDS", with 
identical
format to the DS record, but placed in the child zone ( and signed by the child 
zone).
The parent, at regular intervals, or on receiving a notification from the 
child, would
retrieve the contents of the CDS RRset, and use it as the new DS RRset ( of 
course
after validating it using the old DS RRset ).

There probably needs to be consideration of how the system can recover after
a KSK is compromised, maybe there should be some minimum time interval
before a new DS record is fully trusted. I have not thought that through.

Well, that's just my immediate thoughts, there may be a better way.

I'm somewhat puzzled that thre is no specification, and apparently no activity 
on this.

KSK rollover is probably a fairly rare event (maybe once every few years), so 
possibly
the feeling is that manual procedures will be sufficient. I think a 
standardized, automated
in-protocol mechanism would be advisable though. Maybe I'm wrong.

Best regards,
George


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK rollover

[Patrik Wallstrom]

On May 13, 2010, at 9:56 AM, George Barwood wrote:

> I have been thinking about KSK rollover in my DNSSEC implementation, and it 
> seems
> that there is currently no  specification for KSK rollover within the DNSSEC 
> protocol.
> 
> There is this expired requirements draft
> 
> http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-key-rollover-requirements/
> 
> but that's all I found.
> 
> Have I missed something? It seems to me that this is a rather vital component 
> if
> DNSSEC is to be widely deployed.
> 
> Are there any plans to revive and/or implement these requirements?

You probably want to read the Key Timing Considerations draft:
http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] KSK rollover

[George Barwood]

I have been thinking about KSK rollover in my DNSSEC implementation, and it 
seems
that there is currently no  specification for KSK rollover within the DNSSEC 
protocol.

There is this expired requirements draft

http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-key-rollover-requirements/

but that's all I found.

Have I missed something? It seems to me that this is a rather vital component if
DNSSEC is to be widely deployed.

Are there any plans to revive and/or implement these requirements?

George Barwood
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop