.\" $Id: draft-ietf-dnsext-sigalgopt-00.ms,v 1.5 1999/10/19 16:04:35 sra Exp $ .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF Austein & Vixie .ds RF [Page %] .ds CF Expires 18 April 2000 .ds LH draft-ietf-dnsind-sigalgopt-00.txt .ds RH October 1999 .ds CH .hy 0 .ad l Network Working Group R. Austein draft-ietf-dnsind-sigalgopt-00.txt On Sabbatical P. Vixie Internet Software Consortium October 1999 .sp 2 .ce DNS SIGALGOPT .sp 2 .fi .ne 4 Status of this document .sp .in 3 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at Distribution of this document is unlimited. Please send comments to the namedroppers@internic.net mailing list. .ti 0 .ne 4 Abstract This document describes a mechanism for conserving packet space in a DNS response message in the presence of multiple DNSSEC signature algorithms. .ti 0 .ne 4 Motivation and Scope DNSSEC [DNSSEC] specifies a general framework for attaching cryptographic signatures to DNS resource records. The framework includes provisions for multiple signature protocols, possibly even on a per-name basis. While this open-ended framework is good and useful, it poses a problem when multiple signature protocols are in use and DNS message sizes are limited by the underlying UDP transport packet size. EDNS0 [EDNS0] provides a way to specify a larger payload size, but this still does not entirely solve the problem for large RRsets. Worse, in cases where multiple signature algorithms generate a response packet so large that it must be truncated, the signatures that fit into the truncated response will be useless if the resolver doesn't know how to verify signatures generated with that algorithm. This note proposes a way for a resolver to indicate which signature algorithms it understands to a name server in the form of an ordered list. When this mechanism is in use, the name server can conserve packet space by (a) not sending signatures with algorithms that the resolver will not understand, and (b) not sending multiple signatures for the same resource records. .ti 0 .ne 4 Mechanism [DNSSEC] SIG RRs include a one-octet code indicating the algorithm associated with a particular signature. The SIGALGOPT option defined below allows the resolver to specify an ordered list of signature algorithms using the same one-octet codes that DNSSEC uses. SIGALGOPT is encoded in the variable RDATA part of the OPT pseudo-RR in the DNS request (see [EDNS0]). The OPTION-CODE for SIGALGOPT is [TBD]. The OPTION-DATA for SIGALGOPT is an ordered list of the one-octet codes used by DNSSEC. If the SIGALGOPT option in a query specifies multiple signature algorithms and signatures using more than one of those algorithms are available in the zone, the server must respond with the signatures corresponding to the first algorithm on the SIGALGOPT list that matches, omitting any signatures corresponding to the remaining algorithms. We have deliberately not provided a mechanism to return all the matching signatures, because the purpose of the SIGALGOPT mechanism is to minimize packet size. If the resolver wants to see all available signatures, it should just leave off the SIGALGOPT option entirely. .ti 0 .ne 4 Security Considerations Good question. What horrible things could a bad guy do by creating/altering/deleting SIGALGOPT? Are any of the possible attacks more interesting than denial of service? .ti 0 .ne 4 IANA Considerations SIGALGOPT will need an option code. The signature algorithm codes themselves are borrowed from DNSSEC and do not create any new issues for IANA. .in 8 .ti 0 .ne 4 References .ti 3 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. .ti 3 [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, November 1987. .ti 3 [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987. .ti 3 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. .in 6 .ti 0 .ne 4 Author's addresses: .nf Rob Austein On Sabbatical sra@hactrn.net Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1 650 779 7001 vixie@isc.org .fi .\" .\" Local Variables: .\" mode:nroff .\" indent-tabs-mode: nil .\" End: