draft-ietf-dnsext-trustupdate-threshold-00.txt   draft-ietf-dnsext-trustupdate-threshold-01.txt 
Network Working Group J. Ihren Network Working Group J. Ihren
Internet-Draft Autonomica AB Internet-Draft Autonomica AB
Expires: April 18, 2005 O. Kolkman Expires: April 23, 2006 O. Kolkman
RIPE NCC RIPE NCC
B. Manning B. Manning
EP.net EP.net
October 18, 2004 October 23, 2005
An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
DNSSEC Trust Anchors. DNSSEC Trust Anchors.
draft-ietf-dnsext-trustupdate-threshold-00 draft-ietf-dnsext-trustupdate-threshold-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents
patent or other IPR claims of which I am aware have been disclosed, that any applicable patent or other IPR claims of which he
and any of which I become aware will be disclosed, in accordance with or she is aware have been or will be disclosed, and any of
RFC 3668. which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2005. This Internet-Draft will expire on April 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
The DNS Security Extensions (DNSSEC) works by validating so called The DNS Security Extensions (DNSSEC) works by validating so called
chains of authority. The start of these chains of authority are chains of authority. The start of these chains of authority are
usually public keys that are anchored in the DNS clients. These keys usually public keys that are anchored in the DNS clients. These keys
are known as the so called trust anchors. are known as the so called trust anchors.
This memo describes a method how these client trust anchors can be This memo describes a method how these client trust anchors can be
replaced using the DNS validation and querying mechanisms (in-band) replaced using the DNS validation and querying mechanisms (in-band)
skipping to change at page 2, line 21 skipping to change at page 2, line 21
mechanisms. mechanisms.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Key Signing Keys, Zone Signing Keys and Secure Entry 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry
Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Background . . . . . . . . . . . . . . . . . 5 2. Introduction and Background . . . . . . . . . . . . . . . . . 5
2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5
3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7
3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Why Rollover?. . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8 3.2 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9 3.3 Threshold-based Trust Update . . . . . . . . . . . . . . . 8
3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10 3.4 Possible Trust Update States . . . . . . . . . . . . . . . 9
3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11 3.5 Implementation notes . . . . . . . . . . . . . . . . . . . 10
3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12 3.6 Possible transactions . . . . . . . . . . . . . . . . . . 11
3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12 3.6.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12 3.6.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12
3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12 3.6.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12
3.6 Removal of trust anchors for a trust point . . . . . . . . 12 3.6.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12
3.7 No need for resolver-side overlap of old and new keys . . 13 3.7 Removal of trust anchors for a trust point . . . . . . . . 12
3.8 No need for resolver-side overlap of old and new keys . . 13
4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14
4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1 Bootstrapping trust anchors using a priming key . . . 14 4.1.1 Bootstrapping trust anchors using a priming key . . . 14
4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15
5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1 Threshold-based Trust Update Security Considerations . . . 17 6.1 Threshold-based Trust Update Security Considerations . . . 17
6.2 Priming Key Security Considerations . . . . . . . . . . . 17 6.2 Priming Key Security Considerations . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 7, line 7 skipping to change at page 7, line 7
The choice for which domains trust anchors are to be configured is a The choice for which domains trust anchors are to be configured is a
local policy issue. So is the choice which trust anchors has local policy issue. So is the choice which trust anchors has
prevalence if there are multiple chains of trust to a given piece of prevalence if there are multiple chains of trust to a given piece of
DNS data (e.g. when a parent zone and its child both have trust DNS data (e.g. when a parent zone and its child both have trust
anchors configured). Both issues are out of the scope of this anchors configured). Both issues are out of the scope of this
document. document.
3. Threshold-based Trust Anchor Rollover 3. Threshold-based Trust Anchor Rollover
3.1 The Rollover 3.1 Why Rollover?
Any cryptographic system must be able to periodically replace the
secret keys used. Reasons for this include everything from accidental
compromise to cryptographic exposure through prolonged use. In this
case we argue that the compromise case is the most crucial and difficult
one, as the exposure can be managed through controlled, periodic
rollovers while the compromise case causes either no rollover (because
it isn't detected in time) or immediate emergency rollover.
Also it is crucial to note that for the compromise case a compromised
key must not enable the attacker to do his own rollover into new keys
under attacker control. Especially in the case of a compromise that isn't
immediately detected this is important.
3.2 The Rollover
When a key pair is replaced all signatures (in DNSSEC these are the When a key pair is replaced all signatures (in DNSSEC these are the
RRSIG records) created with the old key will be replaced by new RRSIG records) created with the old key will be replaced by new
signatures created by the new key. Access to the new public key is signatures created by the new key. Access to the new public key is
needed to verify these signatures. needed to verify these signatures.
Since zone signing keys are in "the middle" of a chain of authority Since zone signing keys are in "the middle" of a chain of authority
they can be verified using the signature made by a key signing key. they can be verified using the signature made by a key signing key.
Rollover of zone signing keys is therefore transparent to validators Rollover of zone signing keys is therefore transparent to validators
and requires no action in the validator end. and requires no action in the validator end.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
When the rollover becomes visible to the verifying stub resolver it When the rollover becomes visible to the verifying stub resolver it
will be able to verify the RRSIGs associated with key1, key3 ... will be able to verify the RRSIGs associated with key1, key3 ...
keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will
not be used for validation, since that key is previously unknown and not be used for validation, since that key is previously unknown and
therefore not trusted. therefore not trusted.
Note that this example is simplified. Because of operational Note that this example is simplified. Because of operational
considerations described in [5] having a period during which the two considerations described in [5] having a period during which the two
key signing keys are both available is necessary. key signing keys are both available is necessary.
3.2 Threshold-based Trust Update 3.3 Threshold-based Trust Update
The threshold-based trust update algorithm applies as follows. If The threshold-based trust update algorithm applies as follows. If
for a particular secure entry point for a particular secure entry point
o if the DNSKEY RRset in the zone has been replaced by a more recent o if the DNSKEY RRset in the zone has been replaced by a more recent
one (as determined by comparing the RRSIG inception dates) one (as determined by comparing the RRSIG inception dates)
and and
o if at least M configured trust anchors directly verify the related o if at least M configured trust anchors directly verify the related
RRSIGs over the new DNSKEY RRset RRSIGs over the new DNSKEY RRset
and and
o the number of configured trust anchors that verify the related o the number of configured trust anchors that verify the related
skipping to change at page 9, line 20 skipping to change at page 9, line 20
secure entry point. This is not a recommended configuration, since secure entry point. This is not a recommended configuration, since
that will allow an attacker to initiate rollover of the trust anchors that will allow an attacker to initiate rollover of the trust anchors
himself given access to just one compromised key. Hence M should in himself given access to just one compromised key. Hence M should in
be strictly larger than 1 as shown by the third requirement above. be strictly larger than 1 as shown by the third requirement above.
If the rollover acceptance policy is M=1 then the result for the If the rollover acceptance policy is M=1 then the result for the
rollover in our example above should be that the local database of rollover in our example above should be that the local database of
trust anchors is updated by removing key "key2" from and adding key trust anchors is updated by removing key "key2" from and adding key
"keyY+1" to the key store. "keyY+1" to the key store.
3.3 Possible Trust Update States 3.4 Possible Trust Update States
We define five states for trust anchor configuration at the client We define five states for trust anchor configuration at the client
side. side.
PRIMING: There are no trust anchors configured. There may be priming PRIMING: There are no trust anchors configured. There may be priming
keys available for initial priming of trust anchors. keys available for initial priming of trust anchors.
IN-SYNC: The set of trust anchors configured exactly matches the set IN-SYNC: The set of trust anchors configured exactly matches the set
of SEP keys used by the zone owner to sign the zone. of SEP keys used by the zone owner to sign the zone.
OUT-OF-SYNC: The set of trust anchors is not exactly the same as the OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
set of SEP keys used by the zone owner to sign the zone but there set of SEP keys used by the zone owner to sign the zone but there
are enough SEP key in use by the zone owner that is also in the are enough SEP key in use by the zone owner that is also in the
skipping to change at page 10, line 34 skipping to change at page 10, line 34
new state is UNSYNCABLE. Note, however, that the remaining new state is UNSYNCABLE. Note, however, that the remaining
up-to-date trust anchor is still enough to do successful validation up-to-date trust anchor is still enough to do successful validation
so the validator is still "working" from a DNSSEC point of view. so the validator is still "working" from a DNSSEC point of view.
The STALE state, finally, is where a validator ends up when it has The STALE state, finally, is where a validator ends up when it has
zero remaining current trust anchors. This is a dangerous state, zero remaining current trust anchors. This is a dangerous state,
since the stale trust anchors will cause all validation to fail. The since the stale trust anchors will cause all validation to fail. The
escape is to remove the stale trust anchors and thereby revert to the escape is to remove the stale trust anchors and thereby revert to the
PRIMING state. PRIMING state.
3.4 Implementation notes 3.5 Implementation notes
The DNSSEC protocol specification ordains that a DNSKEY to which a DS The DNSSEC protocol specification ordains that a DNSKEY to which a DS
record points should be self-signed. Since the keys that serve as record points should be self-signed. Since the keys that serve as
trust anchors and the keys that are pointed to by DS records serve trust anchors and the keys that are pointed to by DS records serve
the same purpose, they are both secure entry points, we RECOMMEND the same purpose, they are both secure entry points, we RECOMMEND
that zone owners who want to facilitate the automated rollover scheme that zone owners who want to facilitate the automated rollover scheme
documented herein self-sign DNSKEYs with the SEP bit set and that documented herein self-sign DNSKEYs with the SEP bit set and that
implementation check that DNSKEYs with the SEP bit set are implementation check that DNSKEYs with the SEP bit set are
self-signed. self-signed.
skipping to change at page 11, line 49 skipping to change at page 11, line 49
audit. audit.
There is one case where a "bad" state may be escaped from in an There is one case where a "bad" state may be escaped from in an
automated fashion. This is when entering the STALE state where all automated fashion. This is when entering the STALE state where all
DNSSEC validation starts to fail. If this happens it is concievable DNSSEC validation starts to fail. If this happens it is concievable
that it is better to completely discard the stale trust anchors that it is better to completely discard the stale trust anchors
(thereby reverting to the PRIMING state where validation is not (thereby reverting to the PRIMING state where validation is not
possible). A local policy that automates removal of stale trust possible). A local policy that automates removal of stale trust
anchors is therefore suggested. anchors is therefore suggested.
3.5 Possible transactions 3.6 Possible transactions
3.5.1 Single DNSKEY replaced 3.6.1 Single DNSKEY replaced
This is probably the most typical transaction on the zone owners This is probably the most typical transaction on the zone owners
part. The result should be that if the threshold criterion is part. The result should be that if the threshold criterion is
satisfied then the key store is updated by removal of the old trust satisfied then the key store is updated by removal of the old trust
anchor and addition of the new key as a new trust anchor. Note that anchor and addition of the new key as a new trust anchor. Note that
if the DNSKEY RRset contains exactly M keys replacement of keys is if the DNSKEY RRset contains exactly M keys replacement of keys is
not possible, i.e. for automatic rollover to work M must be stricly not possible, i.e. for automatic rollover to work M must be stricly
less than N. less than N.
3.5.2 Addition of a new DNSKEY (no removal) 3.6.2 Addition of a new DNSKEY (no removal)
If the threshold criterion is satisfied then the new key is added as If the threshold criterion is satisfied then the new key is added as
a configured trust anchor. Not more than N-M keys can be added at a configured trust anchor. Not more than N-M keys can be added at
once, since otherwise the algorithm will fail. once, since otherwise the algorithm will fail.
3.5.3 Removal of old DNSKEY (no addition) 3.6.3 Removal of old DNSKEY (no addition)
If the threshold criterion is satisfied then the old key is removed If the threshold criterion is satisfied then the old key is removed
from being a configured trust anchor. Note that it is not possible from being a configured trust anchor. Note that it is not possible
to reduce the size of the DNSKEY RRset to a size smaller than the to reduce the size of the DNSKEY RRset to a size smaller than the
minimum required value for M. minimum required value for M.
3.5.4 Multiple DNSKEYs replaced 3.6.4 Multiple DNSKEYs replaced
Arguably it is not a good idea for the zone administrator to replace Arguably it is not a good idea for the zone administrator to replace
several keys at the same time, but from the resolver point of view several keys at the same time, but from the resolver point of view
this is exactly what will happen if the validating resolver for some this is exactly what will happen if the validating resolver for some
reason failed to notice a previous rollover event. reason failed to notice a previous rollover event.
Not more than N-M keys can be replaced at one time or the threshold Not more than N-M keys can be replaced at one time or the threshold
criterion will not be satisfied. Or, expressed another way: as long criterion will not be satisfied. Or, expressed another way: as long
as the number of changed keys is less than or equal to N-M the as the number of changed keys is less than or equal to N-M the
validator is in state OUT-OF-SYNC. When the number of changed keys validator is in state OUT-OF-SYNC. When the number of changed keys
becomes greater than N-M the state changes to UNSYNCABLE and manual becomes greater than N-M the state changes to UNSYNCABLE and manual
action is needed. action is needed.
3.6 Removal of trust anchors for a trust point 3.7 Removal of trust anchors for a trust point
If the parent of a secure entry point gets signed and it's trusted If the parent of a secure entry point gets signed and it's trusted
keys get configured in the key store of the validating resolver then keys get configured in the key store of the validating resolver then
the configured trust anchors for the child should be removed entirely the configured trust anchors for the child should be removed entirely
unless explicitly configured (in the utility configuration) to be an unless explicitly configured (in the utility configuration) to be an
exception. exception.
The reason for such a configuration would be that the resolver has a The reason for such a configuration would be that the resolver has a
local policy that requires maintenance of trusted keys further down local policy that requires maintenance of trusted keys further down
the tree hierarchy than strictly needed from the point of view. the tree hierarchy than strictly needed from the point of view.
The default action when the parent zone changes from unsigned to The default action when the parent zone changes from unsigned to
signed should be to remove the configured trust anchors for the signed should be to remove the configured trust anchors for the
child. This form of "garbage collect" will ensure that the automatic child. This form of "garbage collect" will ensure that the automatic
rollover machinery scales as DNSSEC deployment progresses. rollover machinery scales as DNSSEC deployment progresses.
3.7 No need for resolver-side overlap of old and new keys 3.8 No need for resolver-side overlap of old and new keys
It is worth pointing out that there is no need for the resolver to It is worth pointing out that there is no need for the resolver to
keep state about old keys versus new keys, beyond the requirement of keep state about old keys versus new keys, beyond the requirement of
tracking signature inception time for the covering RRSIGs as tracking signature inception time for the covering RRSIGs as
described in Section 3.4. described in Section 3.4.
From the resolver point of view there are only trusted and not From the resolver point of view there are only trusted and not
trusted keys. The reason is that the zone owner needs to do proper trusted keys. The reason is that the zone owner needs to do proper
maintenance of RRSIGs regardless of the resolver rollover mechanism maintenance of RRSIGs regardless of the resolver rollover mechanism
and hence must ensure that no key rolled out out the DNSKEY set until and hence must ensure that no key rolled out out the DNSKEY set until
skipping to change at page 20, line 16 skipping to change at page 20, line 16
8.1 Normative References 8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, May 2004. RFC 3757, May 2004.
[3] Arends, R., "Resource Records for the DNS Security Extensions", [3] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
draft-ietf-dnsext-dnssec-records-10 (work in progress), "Resource Records for the DNS Security Extensions", RFC 4034,
September 2004. March 2005.
8.2 Informative References
[4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
"DNS Security Introduction and Requirements", "DNS Security Introduction and Requirements", RFC 4033,
draft-ietf-dnsext-dnssec-intro-12 (work in progress), September March 2005.
2004.
8.2 Informative References
[5] Kolkman, O., "DNSSEC Operational Practices", [5] Kolkman, O., "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practices-01 (work in draft-ietf-dnsop-dnssec-operational-practices-01 (work in
progress), May 2004. progress), May 2004.
[6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January 1999. 2459, January 1999.
Authors' Addresses Authors' Addresses
Johan Ihren Johan Ihren
Autonomica AB Autonomica AB
Bellmansgatan 30 Bellmansgatan 30
Stockholm SE-118 47 Stockholm SE-118 47
Sweden Sweden
EMail: johani@autonomica.se EMail: johani@autonomica.se
Olaf M. Kolkman Olaf M. Kolkman
RIPE NCC NLnet Labs
Singel 256 Kruislaan 419
Amsterdam 1016 AB 1098 VA Amsterdam
NL NL
Phone: +31 20 535 4444 EMail: olaf@nlnetlabs.nl
EMail: olaf@ripe.net URI: http://www.nlnetlabs.nl/
URI: http://www.ripe.net/
Bill Manning Bill Manning
EP.net EP.net
Marina del Rey, CA 90295 Marina del Rey, CA 90295
USA USA
Appendix A. Acknowledgments Appendix A. Acknowledgments
The present design for in-band automatic rollovers of DNSSEC trust The present design for in-band automatic rollovers of DNSSEC trust
anchors is the result of many conversations and it is no longer anchors is the result of many conversations and it is no longer
skipping to change at page 23, line 10 skipping to change at page 23, line 10
In addition we've also had appreciated help from (in no particular In addition we've also had appreciated help from (in no particular
order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
Larson and Mark Kosters. Larson and Mark Kosters.
Appendix B. Document History Appendix B. Document History
This appendix will be removed if and when the document is submitted This appendix will be removed if and when the document is submitted
to the RFC editor. to the RFC editor.
The version you are reading is tagged as $Revision: 1.3 $. The version you are reading is tagged as $Revision: 1.2 $.
Text between square brackets, other than references, are editorial Text between square brackets, other than references, are editorial
comments and will be removed. comments and will be removed.
B.1 prior to version 00 B.1 prior to version 00
This draft was initially published as a personal submission under the This draft was initially published as a personal submission under the
name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt. name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
Kolkman documented the ideas provided by Ihren and Manning. In the Kolkman documented the ideas provided by Ihren and Manning. In the
skipping to change at page 24, line 5 skipping to change at page 23, line 40
adopted as a working group document. adopted as a working group document.
o A small section on the concept of stale trust anchors was added. o A small section on the concept of stale trust anchors was added.
o The different possible states are more clearly defined, including o The different possible states are more clearly defined, including
examples of transitions between states. examples of transitions between states.
o The terminology is changed throughout the document. The old term o The terminology is changed throughout the document. The old term
"M-N" is replaced by "threshold" (more or less). Also the "M-N" is replaced by "threshold" (more or less). Also the
interpretation of the constants M and N is significantly interpretation of the constants M and N is significantly
simplified to bring the usage more in line with "standard" simplified to bring the usage more in line with "standard"
threshold terminlogy. threshold terminlogy.
B.3 version 01
o This is a notice that the draft temporarily expired.
B.4 version 02
o Resurrected the draft
o Added new section on why rollovers are needed with particular
empathatis on the compromise case.
o Updated references and author affiliations.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 24 change blocks. 
46 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/