Re: [DNSOP] RFC 6781 and double signature KSK rollover

[tjw ietf]

I agree with Matthijs.  Looking at 6781 that makes the most sense.

tim

On Tue, Oct 25, 2016 at 8:17 AM, Matthijs Mekking 
wrote:

>
>
> On 25-10-16 15:15, Marcos Sanz wrote:
>
>> Matthijs,
>>
>> my attention has been brought to the KSK rollover double-signature

>>> style
>>
>>> described in 6781 and what I think is a mistake/oblivion there.

>>> Section
>>
>>> 4.1.2 states

>>>
>> [...]
>>
>> You are right: DS_K_2 may only be provided to the parent *after* the TTL
>>>
>>
>> of DNSKEY_K_1 has passed. RFC 7583 has more accurate timings for
>>> rollovers. The corresponding timeline is described in section 3.3.1.
>>>
>>
>> thanks for the pointer. RFC 7583 does it right.
>>
>> That begs for the question: how to deal with the wrong information
>> propagated in 6781? Submit errata? Label it "Updated by 7583"?
>>
>
> I think an errata is appropriate.
>
> Best regards,
>   Matthijs
>
>
>
>
>> Best,
>> Marcos
>>
>> ___
>> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 6781 and double signature KSK rollover

[Matthijs Mekking]

On 25-10-16 15:15, Marcos Sanz wrote:

Matthijs,


my attention has been brought to the KSK rollover double-signature

style

described in 6781 and what I think is a mistake/oblivion there.

Section

4.1.2 states


[...]


You are right: DS_K_2 may only be provided to the parent *after* the TTL



of DNSKEY_K_1 has passed. RFC 7583 has more accurate timings for
rollovers. The corresponding timeline is described in section 3.3.1.


thanks for the pointer. RFC 7583 does it right.

That begs for the question: how to deal with the wrong information
propagated in 6781? Submit errata? Label it "Updated by 7583"?


I think an errata is appropriate.

Best regards,
  Matthijs




Best,
Marcos

___
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] RFC 6781 and double signature KSK rollover

[Marcos Sanz]

Matthijs,

> > my attention has been brought to the KSK rollover double-signature 
style
> > described in 6781 and what I think is a mistake/oblivion there. 
Section
> > 4.1.2 states

[...]

> You are right: DS_K_2 may only be provided to the parent *after* the TTL 

> of DNSKEY_K_1 has passed. RFC 7583 has more accurate timings for 
> rollovers. The corresponding timeline is described in section 3.3.1.

thanks for the pointer. RFC 7583 does it right.

That begs for the question: how to deal with the wrong information 
propagated in 6781? Submit errata? Label it "Updated by 7583"?

Best,
Marcos

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

Re: [DNSOP] RFC 6781 and double signature KSK rollover

[Marcos Sanz]

Hi Marc,

> For .nl we have rolled the KSK conform the double KSK method as 
described in RFC7583. We didn't notice a mistake or oblivion there :-0

please consider that my comment applied only to RFC 6781.

Best,
Marcos

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

Re: [DNSOP] RFC 6781 and double signature KSK rollover

[Marc Groeneweg]

Hi Marcos,

For .nl we have rolled the KSK conform the double KSK method as described in 
RFC7583. We didn't notice a mistake or oblivion there :-0

Grtz,
Marc

-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Matthijs Mekking
Sent: dinsdag 25 oktober 2016 12:35
To: Marcos Sanz <s...@denic.de>; dnsop@ietf.org
Subject: Re: [DNSOP] RFC 6781 and double signature KSK rollover

Hi Marco,

On 24-10-16 17:47, Marcos Sanz wrote:
> Hi all,
>
> my attention has been brought to the KSK rollover double-signature 
> style described in 6781 and what I think is a mistake/oblivion there. 
> Section
> 4.1.2 states
>
>>  initial:  Initial version of the zone.  The parental DS points to
>>  DNSKEY_K_1.  Before the rollover starts, the child will have to
>>  verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
>>  it is needed during the rollover, and we refer to the value as
>>  TTL_DS.
>>
>>   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
>>  generates a second KSK, DNSKEY_K_2.  The key is provided to the
>>  parent, and the child will have to wait until a new DS RR has been
>>  generated that points to DNSKEY_K_2.  After that DS RR has been
>>  published on all servers authoritative for the parent's zone, the
>>  zone administrator has to wait at least TTL_DS to make sure that
>>  the old DS RR has expired from caches.
>>
>>   DS change:  The parent replaces DS_K_1 with DS_K_2.
>
> In that description it looks as if the only relevant TTL during the 
> rollover is that of the old DS RR. In my eyes though, the replacement 
> of the DS at the parent shouldn't happen before having waited at least 
> the TTL of DNSKEY_K_1 itself. Otherwise validation errors might occur 
> (mismatch between a cached DNSKEY_K_1 and the DS_K_2 at the parent).

You are right: DS_K_2 may only be provided to the parent *after* the TTL of 
DNSKEY_K_1 has passed. RFC 7583 has more accurate timings for rollovers. The 
corresponding timeline is described in section 3.3.1.

Best regards,
   Matthijs


>
> I've seen TLDs doing their KSK rollover the way I describe (so it 
> looks as it is standard operational practice), but the RFC doesn't reflect 
> that.
> There are no errata filed for the RFC so far either.
>
> Any thoughts on that?
>
> Best,
> Marcos
>
> ___
> 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

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

Re: [DNSOP] RFC 6781 and double signature KSK rollover

[Matthijs Mekking]

Hi Marco,

On 24-10-16 17:47, Marcos Sanz wrote:

Hi all,

my attention has been brought to the KSK rollover double-signature style
described in 6781 and what I think is a mistake/oblivion there. Section
4.1.2 states


 initial:  Initial version of the zone.  The parental DS points to
 DNSKEY_K_1.  Before the rollover starts, the child will have to
 verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
 it is needed during the rollover, and we refer to the value as
 TTL_DS.

  new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
 generates a second KSK, DNSKEY_K_2.  The key is provided to the
 parent, and the child will have to wait until a new DS RR has been
 generated that points to DNSKEY_K_2.  After that DS RR has been
 published on all servers authoritative for the parent's zone, the
 zone administrator has to wait at least TTL_DS to make sure that
 the old DS RR has expired from caches.

  DS change:  The parent replaces DS_K_1 with DS_K_2.


In that description it looks as if the only relevant TTL during the
rollover is that of the old DS RR. In my eyes though, the replacement of
the DS at the parent shouldn't happen before having waited at least the
TTL of DNSKEY_K_1 itself. Otherwise validation errors might occur
(mismatch between a cached DNSKEY_K_1 and the DS_K_2 at the parent).


You are right: DS_K_2 may only be provided to the parent *after* the TTL 
of DNSKEY_K_1 has passed. RFC 7583 has more accurate timings for 
rollovers. The corresponding timeline is described in section 3.3.1.


Best regards,
  Matthijs




I've seen TLDs doing their KSK rollover the way I describe (so it looks as
it is standard operational practice), but the RFC doesn't reflect that.
There are no errata filed for the RFC so far either.

Any thoughts on that?

Best,
Marcos

___
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

[DNSOP] RFC 6781 and double signature KSK rollover

[Marcos Sanz]

Hi all,

my attention has been brought to the KSK rollover double-signature style 
described in 6781 and what I think is a mistake/oblivion there. Section 
4.1.2 states 

>  initial:  Initial version of the zone.  The parental DS points to
>  DNSKEY_K_1.  Before the rollover starts, the child will have to
>  verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
>  it is needed during the rollover, and we refer to the value as
>  TTL_DS.
>
>   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
>  generates a second KSK, DNSKEY_K_2.  The key is provided to the
>  parent, and the child will have to wait until a new DS RR has been
>  generated that points to DNSKEY_K_2.  After that DS RR has been
>  published on all servers authoritative for the parent's zone, the
>  zone administrator has to wait at least TTL_DS to make sure that
>  the old DS RR has expired from caches.
>
>   DS change:  The parent replaces DS_K_1 with DS_K_2.

In that description it looks as if the only relevant TTL during the 
rollover is that of the old DS RR. In my eyes though, the replacement of 
the DS at the parent shouldn't happen before having waited at least the 
TTL of DNSKEY_K_1 itself. Otherwise validation errors might occur 
(mismatch between a cached DNSKEY_K_1 and the DS_K_2 at the parent).

I've seen TLDs doing their KSK rollover the way I describe (so it looks as 
it is standard operational practice), but the RFC doesn't reflect that. 
There are no errata filed for the RFC so far either.

Any thoughts on that?

Best,
Marcos

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