draft-ietf-dkim-deployment-07.txt   draft-ietf-dkim-deployment-08.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational E. Siegel Intended status: Informational E. Siegel
Expires: January 12, 2010 Expires: February 26, 2010
P. Hallam-Baker P. Hallam-Baker
Default Deny Security, Inc. Default Deny Security, Inc.
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
July 11, 2009 August 25, 2009
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
draft-ietf-dkim-deployment-07 draft-ietf-dkim-deployment-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 12, 2010. This Internet-Draft will expire on February 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 15 skipping to change at page 4, line 15
9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40
9.1. Security Considerations . . . . . . . . . . . . . . . . . 40 9.1. Security Considerations . . . . . . . . . . . . . . . . . 40
9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
11. Informative References . . . . . . . . . . . . . . . . . . . . 40 11. Informative References . . . . . . . . . . . . . . . . . . . . 40
Appendix A. Migration Strategies . . . . . . . . . . . . . . . . 42 Appendix A. Migration Strategies . . . . . . . . . . . . . . . . 42
A.1. Migrating from DomainKeys . . . . . . . . . . . . . . . . 42 A.1. Migrating from DomainKeys . . . . . . . . . . . . . . . . 42
A.2. Migrating Hash Algorithms . . . . . . . . . . . . . . . . 47 A.2. Migrating Hash Algorithms . . . . . . . . . . . . . . . . 47
A.3. Migrating Signing Algorithms . . . . . . . . . . . . . . . 48 A.3. Migrating Signing Algorithms . . . . . . . . . . . . . . . 48
Appendix B. General Coding Criteria for Cryptographic Appendix B. General Coding Criteria for Cryptographic
Applications . . . . . . . . . . . . . . . . . . . . 49 Applications . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) allows an organization to claim DomainKeys Identified Mail (DKIM) allows an organization to claim
responsibility for transmitting a message, in a way that can be responsibility for transmitting a message, in a way that can be
validated by a recipient. This document provides practical tips for: validated by a recipient. This document provides practical tips for:
those who are developing DKIM software, mailing list managers, those who are developing DKIM software, mailing list managers,
filtering strategies based on the output from DKIM verification, and filtering strategies based on the output from DKIM verification, and
DNS servers; those who are deploying DKIM software, keys, mailing DNS servers; those who are deploying DKIM software, keys, mailing
skipping to change at page 7, line 25 skipping to change at page 7, line 25
| +-------------+ | +-------------+
| ^ | ^
V Responsible | V Responsible |
+-------------+ Identifier +------+------+ +-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity | | Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor | | Identity | . . | Assessor |
+------+------+ . . +-------------+ +------+------+ . . +-------------+
| . . ^ ^ | . . ^ ^
V . . | | V . . | |
+------------------.-------.--------------------+ | | +------------------.-------.--------------------+ | |
| +------+------+ . . . . . +-------------+ | | | +-------------+ | +------+------+ . . . . . +-------------+ | | | +-----------+
| | Identifier | | Identifier +--|--+ +--+ Assessment | | | Identifier | | Identifier +--|--+ +--+ Assessment |
| | Signer +------------->| Validator | | | Databases | | | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-------------+ | +-------------+ +-------------+ | +-----------+
| DKIM Service | | DKIM Service |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 1: Actors in a Trust Sequence using DKIM Figure 1: Actors in a Trust Sequence using DKIM
2.2. Choosing a DKIM Tag for the Assessment Identifier 2.2. Choosing a DKIM Tag for the Assessment Identifier
The signer of a message needs to be able to provide precise data and The signer of a message needs to be able to provide precise data and
know what that data will mean upon delivery to the Assessor. If know what that data will mean upon delivery to the Assessor. If
there is ambiguity in the choice that will be made on the receive there is ambiguity in the choice that will be made on the receive
skipping to change at page 7, line 51 skipping to change at page 7, line 51
and it is easy to confuse their use, although only one defines the and it is easy to confuse their use, although only one defines the
formal input and output of DKIM, with the other two being used for formal input and output of DKIM, with the other two being used for
internal protocol functioning and adjunct purposes, such as auditing internal protocol functioning and adjunct purposes, such as auditing
and debugging. and debugging.
The salient values include the s=, d= and i= parameters in the DKIM- The salient values include the s=, d= and i= parameters in the DKIM-
Signature: header field. In order to achieve the end-to-end Signature: header field. In order to achieve the end-to-end
determinism needed for this collaborative exchange from the signer to determinism needed for this collaborative exchange from the signer to
the assessor, the core model needs to specify what the signer is the assessor, the core model needs to specify what the signer is
required to provide to the assessor. The Update to RFC4871 required to provide to the assessor. The Update to RFC4871
[rfc4871-update]now specifies: [I-D.ietf-dkim-rfc4871-errata]now specifies:
DKIM's primary task is to communicate from the Signer to a DKIM's primary task is to communicate from the Signer to a
recipient-side Identity Assessor a single Signing Domain recipient-side Identity Assessor a single Signing Domain
Identifier (SDID) that refers to a responsible identity. DKIM MAY Identifier (SDID) that refers to a responsible identity. DKIM MAY
optionally provide a single responsible Agent or User Identifier optionally provide a single responsible Agent or User Identifier
(AUID)... A receive-side DKIM verifier MUST communicate the (AUID)... A receive-side DKIM verifier MUST communicate the
Signing Domain Identifier (d=) to a consuming Identity Assessor Signing Domain Identifier (d=) to a consuming Identity Assessor
module and MAY communicate the User Agent Identifier (i=) if module and MAY communicate the User Agent Identifier (i=) if
present.... To the extent that a receiver attempts to intuit any present.... To the extent that a receiver attempts to intuit any
structured semantics for either of the identifiers, this is a structured semantics for either of the identifiers, this is a
skipping to change at page 9, line 31 skipping to change at page 9, line 31
since it can represent any semantics, known only to the signer. since it can represent any semantics, known only to the signer.
Hence, i= serves well as a token that is usable like a Web cookie, Hence, i= serves well as a token that is usable like a Web cookie,
for return to the signing ADMD -- such as for auditing and debugging. for return to the signing ADMD -- such as for auditing and debugging.
Of course in some scenarios the i= string might provide a useful Of course in some scenarios the i= string might provide a useful
adjunct value for additional (heuristic) processing by the Handling adjunct value for additional (heuristic) processing by the Handling
Filter. Filter.
2.3. Choosing the Signing Domain Name 2.3. Choosing the Signing Domain Name
A DKIM signing entity can serve different roles, such as author of A DKIM signing entity can serve different roles, such as being the
content, versus operator of the mail service, versus operator of a author of content, or the operator of the mail service, or the
reputation service. In these different roles, the basis for operator of a reputation service that also provides signing services
on behalf of its customers. In these different roles, the basis for
distinguishing among portions of email traffic can vary. For an distinguishing among portions of email traffic can vary. For an
entity creating DKIM signatures it is likely that different portions entity creating DKIM signatures it is likely that different portions
of its mail will warrant different levels of trust. For example: of its mail will warrant different levels of trust. For example:
* Mail is sent for different purposes, such as marketing vs. * Mail is sent for different purposes, such as marketing vs.
transactional, and recipients demonstrate different patterns of transactional, and recipients demonstrate different patterns of
acceptance between these. acceptance between these.
* For an operator of an email service, there often are distinct * For an operator of an email service, there often are distinct
sub-populations of users warranting different levels of trust sub-populations of users warranting different levels of trust
skipping to change at page 25, line 9 skipping to change at page 25, line 9
and use such information can be assured that it truly pertains to the and use such information can be assured that it truly pertains to the
identity in question. identity in question.
This section lays out a taxonomy of some of the different identities, This section lays out a taxonomy of some of the different identities,
or combinations of identities, that might usefully be represented by or combinations of identities, that might usefully be represented by
a DKIM signature. a DKIM signature.
6.1. Single Domain Signature 6.1. Single Domain Signature
Perhaps the simplest case is when an organization signs its own Perhaps the simplest case is when an organization signs its own
outbound email using its own domain in the SDID [rfc4871-update] of outbound email using its own domain in the SDID
the signature. For example, Company A would sign the outbound mail [I-D.ietf-dkim-rfc4871-errata] of the signature. For example,
from its employees with d=companyA.example. Company A would sign the outbound mail from its employees with
d=companyA.example.
In the most straightforward configuration, the addresses in the In the most straightforward configuration, the addresses in the
RFC5322.From would also be in the companyA.example domain, but that RFC5322.From would also be in the companyA.example domain, but that
direct correlation is not required. direct correlation is not required.
A special case of the Single Domain Signature is an Author Signature A special case of the Single Domain Signature is an Author Signature
as defined by the Author Domain Signing Practices specification as defined by the Author Domain Signing Practices specification
[I-D.ietf-dkim-ssp]. Author signatures are signatures from an [RFC5617]. Author signatures are signatures from an author's
author's organization that have an SDID value that matches that of an organization that have an SDID value that matches that of an
RFC5322.From address of the signed message. RFC5322.From address of the signed message.
Although an author signature might in some cases be proof against Although an author signature might in some cases be proof against
spoofing the domain name of the RFC5322.From address, it is important spoofing the domain name of the RFC5322.From address, it is important
to note that the DKIM and ADSP validation apply only to the exact to note that the DKIM and ADSP validation apply only to the exact
address string and not to look-alike addresses nor to the human- address string and not to look-alike addresses nor to the human-
friendly "display-name" or names and addresses used within the body friendly "display-name" or names and addresses used within the body
of the message. That is, it protects only against the misuse of a of the message. That is, it protects only against the misuse of a
precise address string within the RFC5322.From field and nothing precise address string within the RFC5322.From field and nothing
else. For example, a message from bob@domain.example with a valid else. For example, a message from bob@domain.example with a valid
skipping to change at page 26, line 15 skipping to change at page 26, line 17
Section 2.3, if the type of mail sent from the different subdomains Section 2.3, if the type of mail sent from the different subdomains
is significantly different or if there is reason to believe that the is significantly different or if there is reason to believe that the
reputation of the subdomains would differ, then it may be a good idea reputation of the subdomains would differ, then it may be a good idea
to acknowledge this and provide distinct signatures for each of the to acknowledge this and provide distinct signatures for each of the
subdomains (d=marketing.domain.example, sales.domain.example, etc.). subdomains (d=marketing.domain.example, sales.domain.example, etc.).
However, if the mail and reputations are likely to be similar, then However, if the mail and reputations are likely to be similar, then
the simpler approach of using a single common parent domain in the the simpler approach of using a single common parent domain in the
signature may work well. signature may work well.
Another approach to distinguishing the streams using a single DKIM Another approach to distinguishing the streams using a single DKIM
key would be to leverage the AUID [rfc4871-update] (i= tag) in the key would be to leverage the AUID [I-D.ietf-dkim-rfc4871-errata] (i=
DKIM signature to differentiate the mail streams. For example, tag) in the DKIM signature to differentiate the mail streams. For
marketing email would be signed with i=marketing.domain.example and example, marketing email would be signed with
d=domain.example. i=marketing.domain.example and d=domain.example.
It's important to remember, however, that under core DKIM semantics It's important to remember, however, that under core DKIM semantics
the AUID is opaque to receivers. That means that it will only be an the AUID is opaque to receivers. That means that it will only be an
effective differentiator if there is an out of band agreement about effective differentiator if there is an out of band agreement about
the i= semantics. the i= semantics.
6.3. Third Party Signature 6.3. Third Party Signature
A signature whose domain does not match the domain of the A signature whose domain does not match the domain of the
RFC5322.From address is sometimes referred to as a third party RFC5322.From address is sometimes referred to as a third party
skipping to change at page 30, line 33 skipping to change at page 30, line 34
evaluated under the same reputation or a different one, and so on. evaluated under the same reputation or a different one, and so on.
This section provides some examples of usage scenarios for DKIM This section provides some examples of usage scenarios for DKIM
deployments; the selection is not intended to be exhaustive, but to deployments; the selection is not intended to be exhaustive, but to
illustrate a set of key deployment considerations. illustrate a set of key deployment considerations.
7.1. Author's Organization - Simple 7.1. Author's Organization - Simple
The simplest DKIM configuration is to have some mail from a given The simplest DKIM configuration is to have some mail from a given
organization (Company A) be signed with the same d= value (e.g. organization (Company A) be signed with the same d= value (e.g.
d=companya.example). If there is a desire to associate additional d=companya.example). If there is a desire to associate additional
information, the AUID [rfc4871-update] value can become information, the AUID [I-D.ietf-dkim-rfc4871-errata] value can become
uniqueID@companya.example, or @uniqueID.companya.example. uniqueID@companya.example, or @uniqueID.companya.example.
In this scenario, Company A need only generate a single signing key In this scenario, Company A need only generate a single signing key
and publish it under their top level domain (companya.example); the and publish it under their top level domain (companya.example); the
signing module would then tailor the AUID value as needed at signing signing module would then tailor the AUID value as needed at signing
time. time.
7.2. Author's Organization - Differentiated Types of Mail 7.2. Author's Organization - Differentiated Types of Mail
A slight variation of the one signature case is where Company A signs A slight variation of the one signature case is where Company A signs
skipping to change at page 31, line 27 skipping to change at page 31, line 27
Note that ADSP is not for everyone. Sending domains that do not Note that ADSP is not for everyone. Sending domains that do not
control all legitimate outbound mail purporting to be from their control all legitimate outbound mail purporting to be from their
domain (i.e., with a RFC5322.From address in their domain) are likely domain (i.e., with a RFC5322.From address in their domain) are likely
to experience delivery problems with some percentage of that mail. to experience delivery problems with some percentage of that mail.
Administrators evaluating ADSP for their domains SHOULD carefully Administrators evaluating ADSP for their domains SHOULD carefully
weigh the risk of phishing attacks against the likelihood of weigh the risk of phishing attacks against the likelihood of
undelivered mail. undelivered mail.
This section covers some examples of ADSP usage: for the complete This section covers some examples of ADSP usage: for the complete
specification, see [I-D.ietf-dkim-ssp] specification, see [RFC5617]
7.3.2. A Few Definitions 7.3.2. A Few Definitions
In the ADSP specification, an address in the From header field of a In the ADSP specification, an address in the From header field of a
message [RFC5322] is defined as an "Author Address", and an "Author message [RFC5322] is defined as an "Author Address", and an "Author
Domain" is defined as anything to the right of the '@' in an Author Domain" is defined as anything to the right of the '@' in an Author
Address. Address.
An "Author Signature" is thus any valid signature where the value of An "Author Signature" is thus any valid signature where the value of
the SDID matches an Author Domain in the message. the SDID matches an Author Domain in the message.
It is important to note that unlike the DKIM specification which It is important to note that unlike the DKIM specification which
makes no correlation between the signature domain and any message makes no correlation between the signature domain and any message
headers, the ADSP specification applies only to the author domain. headers, the ADSP specification applies only to the author domain.
In essence, under ADSP, any non-author signatures are ignored In essence, under ADSP, any non-author signatures are ignored
(treated as if they are not present). (treated as if they are not present).
Signers wishing to publish an Author Domain Signing Practices (ADSP) Signers wishing to publish an Author Domain Signing Practices (ADSP)
[I-D.ietf-dkim-ssp] record describing their signing practices will [RFC5617] record describing their signing practices will thus want to
thus want to include an author signature on their outbound mail to include an author signature on their outbound mail to avoid ADSP
avoid ADSP verification failures. For example, if the address in the verification failures. For example, if the address in the
RFC5322.From is bob@company.example, the SDID value of the author RFC5322.From is bob@company.example, the SDID value of the author
signature must be company.example. signature must be company.example.
7.3.3. Some ADSP Examples 7.3.3. Some ADSP Examples
An organization (Company A) may specify its signing practices by An organization (Company A) may specify its signing practices by
publishing an ADSP record with "dkim=all" or "dkim=discardable". In publishing an ADSP record with "dkim=all" or "dkim=discardable". In
order to avoid misdelivery of its mail at receivers that are order to avoid misdelivery of its mail at receivers that are
validating ADSP, Company A MUST first have done an exhaustive validating ADSP, Company A MUST first have done an exhaustive
analysis to determine all sources of outbound mail from its domain analysis to determine all sources of outbound mail from its domain
skipping to change at page 32, line 32 skipping to change at page 32, line 32
have a valid author signature is at risk of being misdelivered or have a valid author signature is at risk of being misdelivered or
discarded. For example, if a message with an RFC5322.From address of discarded. For example, if a message with an RFC5322.From address of
newsletter@companyA.example has a signature with newsletter@companyA.example has a signature with
d=marketing.companyA.example, that message will fail the ADSP check d=marketing.companyA.example, that message will fail the ADSP check
because the signature would not be considered a valid author because the signature would not be considered a valid author
signature. signature.
Because the semantics of an ADSP author signature are more Because the semantics of an ADSP author signature are more
constrained than the semantics of a "pure" DKIM signature, it is constrained than the semantics of a "pure" DKIM signature, it is
important to make sure the nuances are well understood before important to make sure the nuances are well understood before
deploying an ADSP record. The ADSP specification [I-D.ietf-dkim-ssp] deploying an ADSP record. The ADSP specification [RFC5617] provides
provides some fairly extensive lookup examples (in Appendix A) and some fairly extensive lookup examples (in Appendix A) and usage
usage examples (in Appendix B). examples (in Appendix B).
In particular, in order to prevent mail from being negatively In particular, in order to prevent mail from being negatively
impacted or even discarded at the receiver, it is essential to impacted or even discarded at the receiver, it is essential to
perform a thorough survey of outbound mail from a domain before perform a thorough survey of outbound mail from a domain before
publishing an ADSP policy of anything stronger than "unknown". This publishing an ADSP policy of anything stronger than "unknown". This
includes mail that might be sent from external sources that may not includes mail that might be sent from external sources that may not
be authorized to use the domain signature, as well as mail that risks be authorized to use the domain signature, as well as mail that risks
modification in transit that might invalidate an otherwise valid modification in transit that might invalidate an otherwise valid
author signature (e.g. mailing lists, courtesy forwarders, and other author signature (e.g. mailing lists, courtesy forwarders, and other
paths that could add or modify headers, or modify the message body). paths that could add or modify headers, or modify the message body).
skipping to change at page 40, line 31 skipping to change at page 40, line 31
9.2. IANA Considerations 9.2. IANA Considerations
This document has no considerations for IANA. This document has no considerations for IANA.
10. Acknowledgements 10. Acknowledgements
TBD TBD
11. Informative References 11. Informative References
[I-D.ietf-dkim-ssp] [I-D.ietf-dkim-rfc4871-errata]
field, h., Domain, A., error, r., Allman, E., Fenton, J., Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM)
Delany, M., and J. Levine, "DomainKeys Identified Mail Signatures -- Update", draft-ietf-dkim-rfc4871-errata-07
(DKIM) Author Domain Signing Practices (ADSP)", (work in progress), June 2009.
draft-ietf-dkim-ssp-10 (work in progress), May 2009.
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987. and authentication procedures", RFC 989, February 1987.
[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.
[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
Object Security Services", RFC 1848, October 1995. Object Security Services", RFC 1848, October 1995.
skipping to change at page 42, line 5 skipping to change at page 42, line 5
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating [RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009. Message Authentication Status", RFC 5451, April 2009.
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585, Identified Mail (DKIM) Service Overview", RFC 5585,
July 2009. July 2009.
[rfc4871-update] [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine,
Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail "DomainKeys Identified Mail (DKIM) Author Domain Signing
(DKIM) Signatures -- Update", Practices (ADSP)", RFC 5617, August 2009.
I-D draft-ietf-dkim-rfc4871-errata-03, April 2009.
Appendix A. Migration Strategies Appendix A. Migration Strategies
There are three migration occassions worth noting in particular for There are three migration occassions worth noting in particular for
DKIM: DKIM:
1. Migrating from Domain Keys to DKIM. 1. Migrating from Domain Keys to DKIM.
2. Migrating from a current hash algorithm to a new standardized 2. Migrating from a current hash algorithm to a new standardized
hash algorithm. hash algorithm.
 End of changes. 18 change blocks. 
37 lines changed or deleted 37 lines changed or added

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