[DNSOP] Other comments on draft-york-dnsop-deploying-dnssec-crypto-algs-04

[Edward Lewis <[e-mail]>]

Ref: https://www.ietf.org/id/draft-york-dnsop-deploying-dnssec-crypto-algs-04.txt

 

##      Observations on Deploying New DNSSEC Cryptographic Algorithms

##             draft-york-dnsop-deploying-dnssec-crypto-algs-04

## 

## Abstract

## 

##    As new cryptographic algorithms are developed for use in DNSSEC

##    signing and validation, this document captures the steps needed for

##    new algorithms to be deployed and enter general usage.  The intent is

##    to ensure a common understanding of the typical deployment process

##    and potentially identify opportunities for improvement of operations.

 

"New cryptographic algorithms are" not "developed for use iN DNSSEC" but

new DNS Security Algorithms Numbers are assigned for cryptographic algorithms

and hash functions used in DNSSEC operations when the use is defined.

 

## 1.  Introduction

## 

##    The DNS Security Extensions (DNSSEC), broadly defined in [RFC4033],

##    [RFC4034] and [RFC4035], make use of cryptographic algorithms in both

 

"makes use"

 

##    the signing of DNS records and the validation of DNSSEC signatures by

##    recursive resolvers.

 

also hash functions...

 

##    The current list of cryptographic algorithms can be found in the IANA

##    "Domain Name System Security (DNSSEC) Algorithm Numbers" registry

##    located at <http://www.iana.org/assignments/dns-sec-alg-numbers/>

##    Algorithms are added to this IANA registry through a process defined

##    in [RFC6014].  Note that [RFC6944] provides some guidance as to which

##    of these algorithms should be implemented and supported.

 

The registry is introduced as DNS Security Algorithm Numbers in the IANA

Considerations of "Resource Records for the DNS Security Extensions", a.k.a.

RFC 4034.  The webpage cited has DNSSEC in the top part, but the registry entry

itself says DNS.  I'm not sure where the DNSSEC title came from, I don't see

any traceback to where it came from.  I'd stick with the formal name as defined

in RFC 4034.

 

##    Historically DNSSEC signatures have primarily used cryptographic

##    algorithms based on RSA keys.  As deployment of DNSSEC has increased

##    there has been interest in using newer and more secure algorithms,

##    particularly those using elliptic curve cryptography.

 

"Recently DNSSEC" ...historically we cavepeople used DSA. ;)

 

##    o  Usage in a Delegation Signer ("DS") record {{?RFC3658}} for the

##       "chain of trust" connecting back to the root of DNS

 

RFC 3658 is considered to have been obsoleted by RFC 4034, use the latter

as the reference.

 

##    In order for a new cryptographic algorithm to be fully deployed, all

##    aspects of the DNS infrastructure that interact with DNSSEC must be

##    updated to use the new algorithm.

## 

##    This document outlines the current understanding of the components of

##    the DNS infrastructure that need to be updated to deploy a new

##    cryptographic algorithm.

## 

##    It should be noted that DNSSEC is not alone in complexity of

##    deployment.  The IAB documented "Guidelines for Cryptographic

##    Algorithm Agility" in [?!RFC7696] to highlight the importance of this

##    issue.

 

I'd highlight that this is an issue with software and operational

infrastructure as opposed to protocol development.  Obstacles are more

likely to be found in registration than, say, the validation algorithm,

although the latter is at the mercy of a suitably modern cryptographic

library.

 

## 2.  Aspects of Deploying New Algorithms

## 

##    For a new cryptographic algorithm to be deployed in DNSSEC, the

##    following aspects of the DNS infrastructure must be updated:

## 

##    o  DNS resolvers performing validation

 

Particularly the crypto libraries.

 

## 

## 2.2.  Authoritative DNS Servers

## 

##    The one exception is if the new cryptographic algorithms are used in

##    the creation of NSEC/NSEC3 responses.  In the case of new NSEC/NSEC3

##    algorithms, the authoritative DNS server software would need to be

##    updated to be able to use the new algorithms.

 

This is where the distinction between cryptographic algorithm and DNS

security algorithm number is important.  In NSEC3 the server needs to know

what hash-named owned NSEC3 records are to be returned.  The server needs to

be able to hash the QNAME to know how to react, beyond that nothing else is

needed.  NSEC doesn't have this dependency.

 

## 2.4.  Registries

## 

##    The registry for a top-level domain (TLD) needs to accept DS records

##    using the new cryptographic algorithm.

 

Or be able to make them from DNSKEYs, as some TLDs operate.

 

## 2.5.  Registrars

## 

##    Note that work is currently underway in [I-D.ietf-dnsop-maintain-ds]

##    to provide an automated mechanism to update the DS records with a

##    registry.  If this method becomes widely adopted, registrar web

##    interfaces may no longer be needed.

 

I wouldn't tie this to that.  Just to keep things simple, document processing

wise.  (This document to that document.)

 

Overall, registrars and registries are pretty much the same here - their

provisioning software needs to be appropriately restrictive, and not overly

so.

 

>From reading this, the document needs more work.  First is fixing the the name

of what is to be worked - the DNS Security Algorithm Numbers.  Recognize that

the validation side is free to accept what they choose but encourage that side

to make "good choices."  The signing side is complicated by the registration

and provisioning systems that externally govern the DNS protocol operations.