165 lines
5.3 KiB
Plaintext
165 lines
5.3 KiB
Plaintext
Network Working Group R. Austein
|
||
draft-ietf-dnsind-sigalgopt-00.txt On Sabbatical
|
||
P. Vixie
|
||
Internet Software Consortium
|
||
October 1999
|
||
|
||
|
||
DNS SIGALGOPT
|
||
|
||
|
||
Status of this document
|
||
|
||
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
|
||
<http://www.ietf.org/ietf/1id-abstracts.txt>
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
<http://www.ietf.org/shadow.html>
|
||
|
||
Distribution of this document is unlimited. Please send comments to
|
||
the namedroppers@internic.net mailing list.
|
||
|
||
Abstract
|
||
|
||
This document describes a mechanism for conserving packet space in a
|
||
DNS response message in the presence of multiple DNSSEC signature
|
||
algorithms.
|
||
|
||
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
|
||
|
||
|
||
|
||
Austein & Vixie Expires 18 April 2000 [Page 1]
|
||
|
||
draft-ietf-dnsind-sigalgopt-00.txt October 1999
|
||
|
||
|
||
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.
|
||
|
||
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 n 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.
|
||
|
||
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?
|
||
|
||
|
||
|
||
|
||
Austein & Vixie Expires 18 April 2000 [Page 2]
|
||
|
||
draft-ietf-dnsind-sigalgopt-00.txt October 1999
|
||
|
||
|
||
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.
|
||
|
||
References
|
||
|
||
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
|
||
2535, March 1999.
|
||
|
||
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
|
||
facilities", RFC 1034, November 1987.
|
||
|
||
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
|
||
and specification", RFC 1035, November 1987.
|
||
|
||
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
|
||
August 1999.
|
||
|
||
Author's addresses:
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Austein & Vixie Expires 18 April 2000 [Page 3]
|