Dear DNSOP (and Wes), I was wading through my mailbox and realized that I hadn't seen any discussion of this.
I'm quite sure that 2^16 is not a typo (there is quite a lot of text around this section), but I cannot really figure out / remember what exactly the threat model here is. Here are the relevant paragraphs: Sec 2.1.1.1. The SOA Serial Field: "Although Section 3.2 of [RFC1982] describes how to properly implement a less-than comparison operation with SOA serial numbers that may wrap beyond the 32-bit value in both the SOA record and the CSYNC record, it is important that a child using the soaminimum flag must not increment its SOA serial number value more than 2^16 within the period of time that a parent might wait between polling the child for the CSYNC record." Sec 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." I can (mostly) understand why the SOA must not fully wrap (2^32) or probably even 1/2 wrap (2^31), but what bad thing would happen if it incremented by e.g 2^24? It might just be that 2^16 was sufficiently far from 2^32 that it was viewed as "conservative even with much slop", but that feels somewhat like a cop-out… Can someone help me understand? W On Thu, Nov 09, 2023 at 1:45 PM, Bob Harold <[email protected]> wrote: > https://datatracker.ietf.org/doc/html/rfc7477#section-5 > section 5. Security Considerations > last paragraph > > "the SOA serial number MUST NOT be incremented by more than 2^16" > > 2^16 is a very small fraction of the 2^32 serial number space. It seems > that half of the 2^32 would be sufficient, which is 2^31 (not 2^16). Is > that a typo, or is there a reason for the small range? > > -- > Bob Harold > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
