]> ICANN

paul.hoffman@icann.org

Some DNS operators want to test what will happen when DNSSEC algorithms that have large DNSKEY records, RRSIG records, or both, are deployed. For example, they may want to see the effects on TCP retries due to large DNSSEC records. This document defines a new DNS security algorithm, named "Variable Length Nonparticipating", for such testing. To prevent possible security issues with this new algorithm, signatures with this algorithm never participate in DNSSEC validation. This document might never become an RFC; it's purpose is just to register the new algorithm in the IANA "DNS Security Algorithm Numbers" registry.

Introduction The DNS community is considering new signing algorithms based on post-quantum cryptography for DNSSEC (). Post-quantum algorithms generally have larger public key sizes, larger signatures, or both. The algorithms under consideration have different security parameters that result in different sized keys and signatures. This document defines a new DNS security algorithm, named "Variable Length Nonparticipating", that offers no security, just the ability to create keys and signatures of desired sizes for testing. To ensure the security of the DNS, the signatures created by the Variable Length Nonparticipating algorithm do not participate in any DNSSEC validation calculations. This allows a zone operator to add DNSKEY and RRSIG records to existing RRsets to test larger sizes while still allowing zones to be validated correctly with their existing keys and signtures. The term "TBD1" is used throughout this document to indicate the algorithm number assigned by IANA for this algorithm. See for the registration for this algorithm.

BCP 14 Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Algorithm Description for Variable Length Nonparticipating See for the description of the resource records and fields used here. For DNSKEY records, the Algorithm field MUST be TBD1. For RRSIG records, the Algorithm field MUST be TBD1. The contents of the Public Key field and the Signature field is opaque, and are not interpreted by validators. The fields can be any length under the 65535 limit set in . A DNSSEC validator that is validating a resource record set MUST ignore any RRSIG record with the Variable Length Nonparticipating algorithm. For DS records that cover DNSKEY records, the Algorithm field MUST be TBD1. Note that such DS records are permitted by may not be required for all use cases where the Variable Length Nonparticipating record is used.

Examples The following is an example of the Variable Length Nonparticipating algorithm. The public key is 1720 (0x06b8) bytes long and the signature is 2103 (0x0837) bytes long. The data in each is the length (as a two-byte value) followed by 0x00 values.

IANA Considerations IANA is requested to add the following to the DNS Security Algorithm Numbers registry (https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml) after approval by a designated expert. Number: TBD1 (proposal: next unassigned in range 18-22) Description: Variable Length Nonparticipating Mnemonic: VARIABLE-LENGTH-NONPARTICIPATING Zone Signing: Y Trans. Sec.: * Use for DNSSEC Signing: MAY Use for DNSSEC Validation: MAY Implement for DNSSEC Signing: MAY Implement for DNSSEC Validation: MAY Reference: This document

Security Considerations specifies that any validation of signatures that use the Variable Length Nonparticipating algorithm MUST always ignore the signature. This does not affect the validation of signatures of any other algorithm number.

&RFC4034; &RFC4035; &RFC9364; &RFC2119; &RFC8174; &RFC1035;