draft-ietf-dnsext-dnssec-bis-updates-13.txt   draft-ietf-dnsext-dnssec-bis-updates-14.txt 
Network Working Group S. Weiler Network Working Group S. Weiler
Internet-Draft SPARTA, Inc. Internet-Draft SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka Updates: 4033, 4034, 4035, 5155 D. Blacka
(if approved) VeriSign, Inc. (if approved) VeriSign, Inc.
Intended status: Standards Track July 10, 2011 Intended status: Standards Track July 26, 2011
Expires: January 11, 2012 Expires: January 27, 2012
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-13 draft-ietf-dnsext-dnssec-bis-updates-14
Abstract Abstract
This document is a collection of technical clarifications to the This document is a collection of technical clarifications to the
DNSSECbis document set. It is meant to serve as a resource to DNSSECbis document set. It is meant to serve as a resource to
implementors as well as a repository of DNSSECbis errata. implementors as well as a repository of DNSSECbis errata.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2012. This Internet-Draft will expire on January 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 13, line 26 skipping to change at page 13, line 26
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
7. IANA Considerations 7. IANA Considerations
This document specifies no IANA Actions. This document specifies no IANA Actions.
8. Security Considerations 8. Security Considerations
This document adds two cryptographic features to the core DNSSEC This document adds two cryptographic features to the core DNSSEC
protocol. Additionally, it addresses some ambiguities and omissions protocol. Security considerations for those features are discussed
in the core DNSSEC documents that, if not recognized and addressed in in the documents defining them. Additionally, this document
implementations, could lead to security failures. In particular, the addresses some ambiguities and omissions in the core DNSSEC documents
validation algorithm clarifications in Section 4 are critical for that, if not recognized and addressed in implementations, could lead
preserving the security properties DNSSEC offers. Furthermore, to security failures. In particular, the validation algorithm
failure to address some of the interoperability concerns in Section 5 clarifications in Section 4 are critical for preserving the security
could limit the ability to later change or expand DNSSEC, including properties DNSSEC offers. Furthermore, failure to address some of
adding new algorithms. the interoperability concerns in Section 5 could limit the ability to
later change or expand DNSSEC, including adding new algorithms.
The recommendation in Section 5.9 to always set the CD bit has
security implications. By setting the CD bit, a resolver will not
benefit from more stringent validation rules or a more complete set
of trust anchors at an upstream validator.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 4 change blocks. 
12 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/