Subject: Re: [DNSOP] RFC 7477 on Child-to-Parent Synchronization in DNS

From: Bob Harold <[email-masked]>
Date: Mon, 16 Mar 2015 11:37:52 -0400

My apologies for not seeing this sooner.  In section "5. Security
Considerations":

To ensure that an older CSYNC record making use of the soaminimum flag
cannot be replayed to revert values, the SOA serial number MUST NOT be
incremented by more than 2^16 during the lifetime of the signature
window of the associated RRSIGs signing the SOA and CSYNC records.
Note that this is independent of whether or not the increment causes
the 2^32 bit serial number field to wrap.

Why 2^16 instead of (2^31)-1, which is all that is required to prevent the
Serial Number Arithmetic [RFC1982] from comparing improperly?

Are typical signature windows for RRSIG records a year or two?  It would
seem then that 2^16 (65536) increments would only allow an average rate of
less than 8 changes per hour.  For a dynamically updated DNS zone this
could be too small.

-- 
Bob Harold

On Fri, Mar 13, 2015 at 4:11 PM, <[email-masked]> wrote:

> A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 7477
>
>         Title:      Child-to-Parent Synchronization in DNS
>         Author:     W. Hardaker
>         Status:     Standards Track
>         Stream:     IETF
>         Date:       March 2015
>         Mailbox:    [email-masked]
>         Pages:      15
>         Characters: 34471
>         Updates/Obsoletes/SeeAlso:   None
>
>         I-D Tag:    draft-ietf-dnsop-child-syncronization-07.txt
>
>         URL:        https://www.rfc-editor.org/info/rfc7477
>
> This document specifies how a child zone in the DNS can publish a
> record to indicate to a parental agent that the parental agent may
> copy and process certain records from the child zone.  The existence
> of the record and any change in its value can be monitored by a
> parental agent and acted on depending on local policy.
>
> This document is a product of the Domain Name System Operations Working
> Group of the IETF.
>
> This is now a Proposed Standard.
>
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 23 Mar 2015 11:59:12 -0700

> My apologies for not seeing this sooner.  In section "5. Security

Hi Bob,

I've been stewing over this one in my head for a few days since I saw
your message.

In short: I agree with you and am now slapping myself silly.  I suspect
as is it's not "awful", but not ideal.  I'm not sure an errata would be
sufficient for such a change and if it'd be allowed for such a major
processing change.  I'll speak to some people about it this week and see
what others say.
-- 
Wes Hardaker
Parsons