rfc9155xml2.original.xml   rfc9155.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.5246.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5226.xml">
<!ENTITY RFC6151 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6151.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8446.xml">
<!ENTITY RFC8447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8447.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC
] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-tls-md5-sha1-deprecate-09" ipr="trust200
902" updates="5246">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-tls-md5-sha1
-deprecate-09" number="9155" ipr="trust200902" updates="5246" obsoletes="" submi
<front> ssionType="IETF" category="std"
<!-- The abbreviated title is used in the page header - it is only necessary consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sor
if the tRefs="true"
full title is longer than 39 characters --> version="3">
<title abbrev="draft-ietf-tls-md5-sha1-deprecate">Deprecating MD5 and SHA-1 s
ignature hashes in (D)TLS 1.2</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Loganaden Velvindron" initials="L.V."
surname="Velvindron">
<organization>cyberstorm.mu</organization>
<address> <!-- xml2rfc v2v3 conversion 3.10.0 -->
<postal>
<street></street>
<!-- Reorder these if your country does things differently --> <front>
<title abbrev="Signature Hashes in (D)TLS 1.2">Deprecating MD5 and SHA-1 Sign
ature Hashes in (D)TLS 1.2</title>
<seriesInfo name="RFC" value="9155"/>
<author fullname="Loganaden Velvindron" initials="L." surname="Velvindron">
<organization>cyberstorm.mu</organization>
<address>
<postal>
<street/>
<city>Rose Hill</city> <city>Rose Hill</city>
<region/>
<region></region> <code/>
<country>MU</country>
<code></code> </postal>
<phone>+230 59762817</phone>
<country>MU</country> <email>logan@cyberstorm.mu</email>
</postal>
<phone>+230 59762817</phone>
<email>logan@cyberstorm.mu</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Kathleen Moriarty" initials="K." surname="Moriarty">
<author fullname="Kathleen Moriarty" initials="K.M." surname="Moriarty" > <organization abbrev="CIS">Center for Internet Security</organization>
<organization abbrev="CIS">Center for Internet Security</organization> <address>
<address> <postal>
<postal> <street/>
<street/> <city>East Greenbush</city>
<city>East Greenbush</city> <region>NY</region>
<region>NY</region> <country>United States of America</country>
<country>United States of America</country> </postal>
</postal> <email>Kathleen.Moriarty.ietf@gmail.com</email>
<email>Kathleen.Moriarty.ietf@gmail.com</email> </address>
</address> </author>
</author> <author fullname="Alessandro Ghedini" initials="A." surname="Ghedini">
<organization>Cloudflare Inc.</organization>
<author fullname="Alessandro Ghedini" initials="A.G." surname="Ghedini" > <address>
<organization>Cloudflare Inc.</organization> <email>alessandro@cloudflare.com</email>
<address> </address>
<email>alessandro@cloudflare.com</email> </author>
</address> <date year="2021" month="December"/>
</author>
<date year="2021" />
<!-- If the month and year are both specified and are the current ones, xml2r
fc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area> <area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<workgroup>Internet Engineering Task Force</workgroup> <keyword>tls</keyword>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>tls</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to a
ttack and this document deprecates their use in TLS 1.2 digital signatures.
However, this document does not deprecate SHA-1 in HMAC for record prote
ction. This document updates RFC 5246.
</t>
</abstract>
</front>
<middle> <abstract>
<section title="Introduction"> <t>
<t>The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to a
in <xref ttack, and this document deprecates their use in (D)TLS 1.2 digital signatures.
target="RFC5246"/>. MD5 and SHA-1 have been proven to be insecure, However, this document does not deprecate SHA-1 with Hashed Message Auth
subject to collision attacks <xref target="Wang" />. In 2011, <xref target= entication Code (HMAC), as used in record protection. This document updates RFC
"RFC6151" /> detailed the security considerations, including collision attacks 5246.
for MD5. NIST formally deprecated use of SHA-1 in 2011 </t>
<xref target="NISTSP800-131A-R2" /> and </abstract>
disallowed its use for digital signatures at the end of 2013, based on both </front>
the Wang et al. attack and the <middle>
potential for brute-force attack. In 2016, researchers from INRIA identifie <section numbered="true" toc="default">
d <name>Introduction</name>
<t>The usage of MD5 and SHA-1 for signature hashing in (D)TLS 1.2 is speci
fied in <xref target="RFC5246" format="default"/>. MD5 and SHA-1 have been prove
n to be insecure,
subject to collision attacks <xref target="Wang" format="default"/>. In 201
1, <xref target="RFC6151" format="default"/> detailed the security consideration
s, including collision attacks
for MD5.
NIST formally deprecated use of SHA-1 in 2011
<xref target="NISTSP800-131A-R2" format="default"/> and
disallowed its use for digital signatures at the end of 2013, based on both
the attack described in <xref target="Wang" format="default"/> and the
potential for brute-force attack. In 2016, researchers from the National In
stitute for Research in Digital Science and Technology (INRIA) identified
a new class of transcript collision attacks on TLS (and other protocols) a new class of transcript collision attacks on TLS (and other protocols)
that rely on efficient collision-finding algorithms on the underlying hash that relies on efficient collision-finding algorithms on the underlying hash
constructions <xref target="Transcript-Collision" />. Further, in 2017, constructions <xref target="Transcript-Collision" format="default"/>. Furth
researchers from Google and CWI Amsterdam er, in 2017,
<xref target="SHA-1-Collision" /> researchers from Google and Centrum Wiskunde &amp; Informatica (CWI) Amsterd
am
<xref target="SHA-1-Collision" format="default"/>
proved SHA-1 collision attacks were practical. proved SHA-1 collision attacks were practical.
This document updates <xref target="RFC5246" /> This document updates <xref target="RFC5246" format="default"/>
in such a way that MD5 and SHA-1 MUST NOT in such a way that MD5 and SHA-1 <bcp14>MUST NOT</bcp14>
be used for digital signatures. However, this document does not deprecate be used for digital signatures. However, this document does not deprecate
SHA-1 in HMAC for record protection. SHA-1 with HMAC, as used in record protection.
Note that the CABF has also deprecated use of SHA-1 for use in certificate Note that the CA/Browser Forum (CABF) has also deprecated use of SHA-1 for
signatures <xref target="CABF"/>. use in certificate signatures <xref target="CABF" format="default"/>.
</t> </t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Requirements Language"> </section>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", </section>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <section anchor="Signature_algorithms" numbered="true" toc="default">
"OPTIONAL" in this document are to be interpreted as described in BCP <name>Signature Algorithms</name>
14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when, t <t>
hey appear in all Clients <bcp14>MUST</bcp14> include the signature_algorithms extension. Clien
capitals, as shown here.</t> ts <bcp14>MUST NOT</bcp14> include MD5
</section>
</section>
<section anchor="Signature_algorithms" title="Signature Algorithms">
<t>
Clients MUST include the signature_algorithms extension. Clients MUST NOT inc
lude MD5
and SHA-1 in this extension. and SHA-1 in this extension.
</t> </t>
</section> </section>
<section anchor="cert_requests" title="Certificate Request"> <section anchor="cert_requests" numbered="true" toc="default">
<t> <name>Certificate Request</name>
Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest messages. <t>
</t> Servers <bcp14>SHOULD NOT</bcp14> include MD5 and SHA-1 in CertificateRequest
</section> messages.
<section anchor="serverkeyexchange" title="Server Key Exchange"> </t>
<t> </section>
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange <section anchor="serverkeyexchange" numbered="true" toc="default">
<name>Server Key Exchange</name>
<t>
Servers <bcp14>MUST NOT</bcp14> include MD5 and SHA-1 in ServerKeyExchange
messages. If the client receives a ServerKeyExchange message messages. If the client receives a ServerKeyExchange message
indicating MD5 or SHA-1, then it MUST abort the connection with indicating MD5 or SHA-1, then it <bcp14>MUST</bcp14> abort the connection wit h
an illegal_parameter alert. an illegal_parameter alert.
</t> </t>
</section> </section>
<section anchor="CertificateVerify" title="Certificate Verify"> <section anchor="CertificateVerify" numbered="true" toc="default">
<t> <name>Certificate Verify</name>
Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a <t>
server receives a CertificateVerify message with MD5 or SHA-1 it MUST Clients <bcp14>MUST NOT</bcp14> include MD5 and SHA-1 in CertificateVerify me
ssages. If a
server receives a CertificateVerify message with MD5 or SHA-1, it <bcp14>MUST
</bcp14>
abort the connection with an illegal_parameter alert. abort the connection with an illegal_parameter alert.
</t> </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t> The document updates the "TLS SignatureScheme" registry to change the recomm <t>IANA has updated the "TLS SignatureScheme" registry by changing the rec
ended status of ommended status of
SHA-1 based signature schemes to N (not recommended) as defined by <xref target= SHA-1-based signature schemes to "N" (not recommended), as defined by <xref targ
"RFC8447"></xref>. et="RFC8447" format="default"/>.
The following entries are to be updated: The following entries have been updated; other entries in the registry remain th
</t> e same.
<texttable>
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>Recommended</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>0x0201</c> <c>rsa_pkcs1_sha1</c> <c>N</c> <c><xref target="RFC8446"
></xref> [RFCTBD]</c>
<c>0x0203</c> <c>ecdsa_sha1</c> <c>N</c><c><xref target="RFC8446"></xref>
[RFCTBD]</c>
</texttable>
<t>Other entries of the registry remain the same. </t>
<t>
IANA is also requested to update the Reference for the TLS SignatureAlgorithm an
d TLS HashAlgorithm registries to refer to this RFC:
</t>
<t>
OLD:
</t>
<t>
Reference
</t>
<t>
[RFC5246][RFC8447]
</t>
<t>
NEW:
</t>
<t>
Reference
</t> </t>
<t> <table align="center">
[RFC5246][RFC8447][RFC-to-be] <thead>
<tr>
<th align="center">Value</th>
<th align="center">Description</th>
<th align="center">Recommended</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0x0201</td>
<td align="center">rsa_pkcs1_sha1</td>
<td align="center">N</td>
<td align="center">
<xref target="RFC8446" format="default"/> [RFC9155]</td>
</tr>
<tr>
<td align="center">0x0203</td>
<td align="center">ecdsa_sha1</td>
<td align="center">N</td>
<td align="center">
<xref target="RFC8446" format="default"/> [RFC9155]</td>
</tr>
</tbody>
</table>
<t>
IANA has also updated the reference for the "TLS SignatureAlgorithm" and "TLS
HashAlgorithm" registries to refer to this document in addition to RFCs 5246 and
8447.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue <t> Concerns with (D)TLS 1.2 implementations falling back to SHA-1 is an i
. ssue.
This document updates the TLS 1.2 specification to deprecate suppo This document updates the TLS 1.2 specification <xref target="RFC5
rt for MD5 246" format="default"/> to deprecate support for MD5
and SHA-1 for digital signatures. However, this document does not and SHA-1 for digital signatures. However, this document does not
deprecate SHA-1 in HMAC for record protection. deprecate SHA-1 with HMAC, as used in record protection.
</t> </t>
</section> </section>
</middle>
<section anchor="Acknowledgement" title="Acknowledgement">
<t> The authors would like to thank Hubert Kario for his help in writing th
e initial
draft. We are also grateful to Daniel Migault, Martin Thomson, Sea
n Turner, Christopher Wood and David Cooper
for their feedback.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative --> <references>
<name>References</name>
<!-- There are 2 ways to insert reference entries from the citation libraries <references>
: <name>Normative References</name>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
as shown) C.2119.xml"/>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
"?> here FC.5246.xml"/>
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ml") FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Both are cited textually in the same manner: by using xref elements. FC.8446.xml"/>
If you use the PI option, xml2rfc will, by default, try to find included fil <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
es in the same FC.8447.xml"/>
directory as the including file. You can also define the XML_LIBRARY environ </references>
ment variable <references>
with a value containing a set of directories to search. These can be either <name>Informative References</name>
in the local <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.
filing system or remote ones accessed by http (http://domain/dir/... ).--> 6151.xml"/>
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2
119.xml"?-->
&RFC2119;
&RFC5246;
&RFC8174;
&RFC8446;
&RFC8447;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC6151; <reference anchor="NISTSP800-131A-R2" target="https://nvlpubs.nist.gov/n
<reference anchor="NISTSP800-131A-R2" istpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf">
target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2 <front>
.pdf"> <title>Transitioning the Use of Cryptographic Algorithms and Key Len
<front> gths</title>
<title> <author initials="E." surname="Barker" fullname="Elaine Barker">
Transitioning the Use of Cryptographic Algorithms and Key Lengths <organization/>
</title> </author>
<author initials="E.B" surname="Barker" fullname="Elaine Barker"> <author initials="A." surname="Roginsky" fullname="Allen Roginsky">
<organization /> <organization/>
</author> </author>
<author initials="A.R" surname="Roginsky" fullname="Allen Roginsky"> <date month="March" year="2019"/>
<organization /> </front>
</author> <seriesInfo name="NIST Special Publication" value="800-131A, Revision 2
<date month="March" year="2019" /> "/>
</front> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-131Ar2"/>
</reference> </reference>
<reference anchor="CABF" <reference anchor="CABF" target="https://cabforum.org/2014/10/16/ballot-
target="https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/"> 118-sha-1-sunset/">
<front> <front>
<title> <title>Ballot 118 -- SHA-1 Sunset (passed)</title>
Ballot 118 -- SHA-1 Sunset (passed) <author>
</title> <organization>CA/Browser Forum</organization>
<author> </author>
<organization>CA/Browser Forum</organization> <date year="2014" month="October"/>
</author> </front>
<date year="2014" /> </reference>
</front>
</reference>
<reference anchor="Transcript-Collision" <reference anchor="Transcript-Collision" target="https://hal.inria.fr/ha
target="https://hal.inria.fr/hal-01244855/document"> l-01244855/document">
<front> <front>
<title> <title>
Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH
</title> </title>
<author initials="K.B" surname="Bhargavan" fullname="Karthikeyan Bhargavan"> <author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhar
<organization /> gavan">
</author> <organization/>
<author initials="G.L" surname="Leurent" fullname="Gaetan Leurent"> </author>
<organization /> <author initials="G." surname="Leurent" fullname="Gaetan Leurent">
</author> <organization/>
<date month="February" year="2016" /> </author>
</front> <date month="February" year="2016"/>
</reference> </front>
<seriesInfo name="DOI" value="10.14722/ndss.2016.23418"/>
<reference anchor="SHA-1-Collision" </reference>
target="https://eprint.iacr.org/2017/190">
<front>
<title>
The first collision for full SHA-1
</title>
<author initials="M.S" surname="Stevens" fullname="Marc Stevens">
<organization />
</author>
<author initials="E.B" surname="Bursztein" fullname="Elie Bursztein">
<organization />
</author>
<author initials="P.K" surname="Karpman" fullname="Pierre Karpman">
<organization />
</author>
<author initials="A.A" surname="Albertini" fullname="Ange Albertini">
<organization />
</author>
<author initials="Y.M" surname="Markov" fullname="Yarik Markov">
<organization />
</author>
<date month="March" year="2019" />
</front>
</reference>
<reference anchor="Wang"
target="https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf">
<front>
<title>
Finding Collisions in the Full SHA-1
</title>
<author initials="X.W" surname="Wang" fullname="Xiaoyun Wang">
<organization />
</author>
<author initials="Y.Y" surname="Yin" fullname="Yiqun Lisa Yin">
<organization />
</author>
<author initials="H.Y" surname="Yu" fullname="Hongbo Yu">
<organization />
</author>
<date year="2005" />
</front>
</reference>
</references>
<!-- Change Log <reference anchor="SHA-1-Collision" target="https://eprint.iacr.org/2017
/190">
<front>
<title>The First Collision for Full SHA-1</title>
<author initials="M." surname="Stevens" fullname="Marc Stevens">
<organization/>
</author>
<author initials="E." surname="Bursztein" fullname="Elie Bursztein">
<organization/>
</author>
<author initials="P." surname="Karpman" fullname="Pierre Karpman">
<organization/>
</author>
<author initials="A." surname="Albertini" fullname="Ange Albertini">
<organization/>
</author>
<author initials="Y." surname="Markov" fullname="Yarik Markov">
<organization/>
</author>
<date year="2017"/>
</front>
</reference>
--> <reference anchor="Wang" target="https://www.iacr.org/archive/crypto2005
</back> /36210017/36210017.pdf">
<front>
<title>Finding Collisions in the Full SHA-1</title>
<author initials="X." surname="Wang" fullname="Xiaoyun Wang">
<organization/>
</author>
<author initials="Y." surname="Yin" fullname="Yiqun Lisa Yin">
<organization/>
</author>
<author initials="H." surname="Yu" fullname="Hongbo Yu">
<organization/>
</author>
<date year="2005"/>
</front>
<seriesInfo name="DOI" value="10.1007/11535218_2"/>
</reference>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t> The authors would like to thank <contact fullname="Hubert Kario"/> for
his help in writing the initial
draft version of this document. We are also grateful to <contact f
ullname="Daniel Migault"/>, <contact fullname="Martin Thomson"/>, <contact fulln
ame="Sean Turner"/>, <contact fullname="Christopher Wood"/>, and <contact fullna
me="David Cooper"/>
for their feedback.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 29 change blocks. 
397 lines changed or deleted 296 lines changed or added

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