Algorithm Negotiation in DNSSEC
draft-huque-dnssec-alg-nego-03

Document Type Active Internet-Draft (individual)
Last updated 2018-07-22
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                                 S. Huque
Internet-Draft                                                Salesforce
Intended status: Standards Track                              H. Shulman
Expires: January 23, 2019                           Fraunhofer Institute
                                                                 S. Kerr
                                                              Oracle Dyn
                                                           July 22, 2018

                    Algorithm Negotiation in DNSSEC
                     draft-huque-dnssec-alg-nego-03

Abstract

   This document specifies a DNS extension that allows a DNS client to
   specify a list of DNSSEC algorithms, in preference order, that the
   client desires to use.  A DNS server upon receipt of this extension
   can choose to selectively respond with DNSSEC signatures using the
   most preferred algorithm they support.  This mechanism may make it
   easier for DNS zone operators to support signing zone data
   simultaneously with multiple DNSSEC algorithms, without significantly
   increasing the size of DNS responses.  It will also allow an easier
   way to transition to new algorithms while still retaining support for
   older DNS validators that do not yet support the new algorithms.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 23, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Huque, et al.           Expires January 23, 2019                [Page 1]
Internet-Draft        DNSSEC Algorithm Negotiation             July 2018

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  DNSSEC Preferred Algorithms Option  . . . . . . . . . . . . .   4
   3.  Why not use RFC 6975 for Algorithm Signaling? . . . . . . . .   4
   4.  Changes to Clients  . . . . . . . . . . . . . . . . . . . . .   5
   5.  Changes to Servers  . . . . . . . . . . . . . . . . . . . . .   5
   6.  Cache Considerations  . . . . . . . . . . . . . . . . . . . .   6
   7.  Preventing Downgrade Attacks  . . . . . . . . . . . . . . . .   6
   8.  Dealing with Proxies and Middleboxes  . . . . . . . . . . . .   6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     12.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The DNS Security Extensions (DNSSEC) specifications [RFC4033]
   [RFC4034] [RFC4035] support multiple signature algorithms.  A DNS
   zone can be signed simultaneously with multiple algorithms, but there
   is no provision in the current specifications to negotiate the
   selective delivery of signatures of a specific algorithm in DNS
   responses.

   In contrast, many other security protocols, like TLS, IKE, SSH and
   others, support an algorithm or cipher suite negotiation mechanism to
   enable the client and server to select the "best" algorithm they
   jointly support.

   This means that DNS servers have to send responses with signatures of
   all algorithms that the requested data are signed with, which can
   result in significantly large responses.  Not only is this
   inefficient in terms of the additional communication and processing
   overhead, but it often causes a variety of operational problems.
   Most DNS queries and responses utilize UDP transport today.  While
Show full document text