draft-ietf-dnsext-delegation-signer-07.txt   draft-ietf-dnsext-delegation-signer-08.txt 
DNSEXT Working Group Olafur Gudmundsson DNSEXT Working Group Olafur Gudmundsson
<draft-ietf-dnsext-delegation-signer-07.txt> <draft-ietf-dnsext-delegation-signer-08.txt>
Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090. Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
Delegation Signer Resource Record Delegation Signer Resource Record
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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
Comments should be sent to the authors or the DNSEXT WG mailing list Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org namedroppers@ops.ietf.org
This draft expires on September 30, 2002. This draft expires on December 30, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All rights reserved. Copyright (C) The Internet Society (2002). All rights reserved.
Abstract Abstract
The delegation signer (DS) resource record is inserted at a zone cut The delegation signer (DS) resource record is inserted at a zone cut
(i.e., a delegation point) to indicate that the delegated zone is (i.e., a delegation point) to indicate that the delegated zone is
digitally signed and that the delegated zone recognizes the indicated digitally signed and that the delegated zone recognizes the indicated
skipping to change at page 3, line 39 skipping to change at page 3, line 39
prohibit the storage of non-DNSSEC keys at the zone apex. There are prohibit the storage of non-DNSSEC keys at the zone apex. There are
other possible solutions, but they are outside the scope of this other possible solutions, but they are outside the scope of this
document. document.
1.2 Reserved Words 1.2 Reserved Words
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in RFC2119. interpreted as described in RFC2119.
2 DS (Delegation KEY Signer) 2 Specification of the Delegation key Signer
This section defines the Delegation Signer (DS) RR type and the
changes to DNS to accommodate it.
2.1 Delegation Signer Record Model 2.1 Delegation Signer Record Model
This document presents a replacement for the DNSSEC KEY record chain This document presents a replacement for the DNSSEC KEY record chain
of trust [RFC2535] that uses a new RR that resides only at the of trust [RFC2535] that uses a new RR that resides only at the
parent. This record identifies the key(s) that the child uses to parent. This record identifies the key(s) that the child uses to
self-sign its own KEY RRset. self-sign its own KEY RRset.
The chain of trust is now established by verifying the parent KEY The chain of trust is now established by verifying the parent KEY
RRset, the DS RRset from the parent and the KEY RRset at the child. RRset, the DS RRset from the parent and the KEY RRset at the child.
skipping to change at page 4, line 17 skipping to change at page 4, line 19
sign its apex KEY RRset. The parent is ignorant of all other keys in sign its apex KEY RRset. The parent is ignorant of all other keys in
the child's apex KEY RRset. Furthermore, the child maintains full the child's apex KEY RRset. Furthermore, the child maintains full
control over the apex KEY RRset and its content. The child can control over the apex KEY RRset and its content. The child can
maintain any policies regarding its KEY usage for DNSSEC and other maintain any policies regarding its KEY usage for DNSSEC and other
applications and protocols with minimal impact on the parent. Thus if applications and protocols with minimal impact on the parent. Thus if
the child wants to have frequent key rollover for its DNS zone keys, the child wants to have frequent key rollover for its DNS zone keys,
the parent does not need to be aware of it: the child can use one key the parent does not need to be aware of it: the child can use one key
to sign only its apex KEY RRset and other keys to sign the other to sign only its apex KEY RRset and other keys to sign the other
RRsets in the zone. RRsets in the zone.
This model fits well with a slow rollout of DNSSEC and the islands of This model fits well with a slow roll out of DNSSEC and the islands
security model. In this model, someone who trusts "good.example." can of security model. In this model, someone who trusts "good.example."
preconfigure a key from "good.example." as a trusted key, and from can preconfigure a key from "good.example." as a trusted key, and
then on trusts any data signed by that key or that has a chain of from then on trusts any data signed by that key or that has a chain
trust to that key. If "example." starts advertising DS records, of trust to that key. If "example." starts advertising DS records,
"good.example." does not have to change operations by suspending "good.example." does not have to change operations by suspending
self-signing. DS records can also be used to identify trusted keys self-signing. DS records can also be used to identify trusted keys
instead of KEY records. Another significant advantage is that the instead of KEY records. Another significant advantage is that the
amount of information stored in large delegation zones is reduced: amount of information stored in large delegation zones is reduced:
rather than the NULL KEY record at every unsecure delegation required rather than the NULL KEY record at every unsecure delegation required
by RFC 2535, only secure delegations require additional information by RFC 2535, only secure delegations require additional information
in the form of a signed DS RRset. in the form of a signed DS RRset.
The main disadvantage of this approach is that verifying a zone's KEY The main disadvantage of this approach is that verifying a zone's KEY
RRset requires two signature verification operations instead of the RRset requires two signature verification operations instead of the
one required by RFC 2535. There is no impact on the number of one required by RFC 2535. There is no impact on the number of
signatures verified for other types of RRsets. signatures verified for other types of RRsets.
2.2 Protocol Change 2.2 Protocol Change
All DNS servers and resolvers that support DS MUST support the OK bit All DNS servers and resolvers that support DS MUST support the OK bit
[RFC3225] and a larger message size [RFC3226]. Each secure [RFC3225] and a larger message size [RFC3226]. In order for a
delegation in a secure zone MUST contain a DS RRset. If a query delegation to be considered secure the delegation MUST contain a DS
contains the OK bit, a server returning a referral for the delegation RRset. If a query contains the OK bit, a server returning a referral
MUST include the following RRsets in the authority section in this for the delegation MUST include the following RRsets in the authority
order: section in this order:
parent NS RRset parent NS RRset
DS and SIG(DS) (if DS is present) DS and SIG(DS) (if DS is present)
parent NXT and SIG(NXT) (If no DS) parent NXT and SIG(NXT) (If no DS)
This increases the size of referral messages and may cause some or This increases the size of referral messages and may cause some or
all glue to be omitted. If the DS or NXT RRsets with signatures do all glue to be omitted. If the DS or NXT RRsets with signatures do
not fit in the DNS message, the TC bit MUST be set. Additional not fit in the DNS message, the TC bit MUST be set. Additional
section processing is not changed. section processing is not changed.
A DS RRset accompanying an NS RRset indicates that the child zone is A DS RRset accompanying an NS RRset indicates that the child zone is
skipping to change at page 5, line 24 skipping to change at page 5, line 27
control of the zone owner with each entry (RRset) signed by a special control of the zone owner with each entry (RRset) signed by a special
private key held by the zone manager. But the DNS protocol views the private key held by the zone manager. But the DNS protocol views the
leaf nodes in a zone that are also the apex nodes of a child zone leaf nodes in a zone that are also the apex nodes of a child zone
(i.e., delegation points) as "really" belonging to the child zone. (i.e., delegation points) as "really" belonging to the child zone.
The corresponding domain names appear in two master files and might The corresponding domain names appear in two master files and might
have RRsets signed by both the parent and child zones' keys. A have RRsets signed by both the parent and child zones' keys. A
retrieval could get a mixture of these RRsets and SIGs, especially retrieval could get a mixture of these RRsets and SIGs, especially
since one server could be serving both the zone above and below a since one server could be serving both the zone above and below a
delegation point [RFC 2181]. delegation point [RFC 2181].
For every secure delegation there MUST be a DS RRset stored in the Each DS RRset stored in the parent zone MUST be signed by one of the
parent zone signed by the parent zone's private key. The parent zone parent zone's private key. The parent zone MUST NOT contain a KEY
MUST NOT contain a KEY RRset at any delegation points. Delegations in RRset at any delegation point. Delegations in the parent MAY contain
the parent MAY contain only the following RR types: NS, DS, NXT and only the following RR types: NS, DS, NXT and SIG. The NS RRset MUST
SIG. The NS RRset MUST NOT be signed. The NXT RRset is the NOT be signed. The NXT RRset is the exceptional case: it will always
exceptional case: it will always appear differently and appear differently and authoritatively in both the parent and child
authoritatively in both the parent and child zones if both are zones if both are secure.
secure.
A secure zones MUST contain a self-signed KEY RRset at its apex. A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
Upon verifying the DS RRset from the parent, a resolver MAY trust any verifying the DS RRset from the parent, a resolver MAY trust any KEY
KEY identified in the DS RRset as a valid signer of the child's apex identified in the DS RRset as a valid signer of the child's apex KEY
KEY RRset. Resolvers configured to trust one of the keys signing the RRset. Resolvers configured to trust one of the keys signing the KEY
KEY RRset MAY now treat any data signed by the zone keys in the KEY RRset MAY now treat any data signed by the zone keys in the KEY RRset
RRset as secure. In all other cases resolvers MUST consider the zone as secure. In all other cases resolvers MUST consider the zone
unsecure. A DS RRset MUST NOT appear at a zone's apex. unsecure. A DS RRset MUST NOT appear at a zone's apex.
An authoritative server queried for type DS MUST return the DS RRset An authoritative server queried for type DS MUST return the DS RRset
in the answer section. in the answer section.
2.2.2 Signer's Name (replaces RFC3008 section 2.7) 2.2.2 Signer's Name (replaces RFC3008 section 2.7)
The signer's name field of a SIG RR MUST contain the name of the zone The signer's name field of a SIG RR MUST contain the name of the zone
to which the data and signature belong. The combination of signer's to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is name, key tag, and algorithm MUST identify a zone key if the SIG is
skipping to change at page 7, line 44 skipping to change at page 7, line 46
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The key tag is calculated as specified in RFC2535. Algorithm MUST be The key tag is calculated as specified in RFC2535. Algorithm MUST be
an algorithm number assigned in the range 1..251 and the algorithm an algorithm number assigned in the range 1..251 and the algorithm
MUST be allowed to sign DNS data. The digest type is an identifier MUST be allowed to sign DNS data. The digest type is an identifier
for the digest algorithm used. The digest is calculated over the for the digest algorithm used. The digest is calculated over the
canonical name of the delegated domain name followed by the whole canonical name of the delegated domain name followed by the whole
RDATA of the KEY record (all four fields). RDATA of the KEY record (all four fields).
digest = hash( cannonical FQDN on KEY RR | KEY_RR_rdata) digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
Digest type value 0 is reserved, value 1 is SHA-1, and reserving Digest type value 0 is reserved, value 1 is SHA-1, and reserving
other types requires IETF standards action. For interoperability other types requires IETF standards action. For interoperability
reasons, as few digest algorithms as possible should be reserved. The reasons, as few digest algorithms as possible should be reserved. The
only reason to reserve additional digest types is to increase only reason to reserve additional digest types is to increase
security. security.
DS records MUST point to zone KEY records that are allowed to DS records MUST point to zone KEY records that are allowed to
authenticate DNS data. The indicated KEY record's protocol field authenticate DNS data. The indicated KEY record's protocol field
MUST be set to 3; flag field bits 0 and 6 MUST be set to 0; bit 7 MUST be set to 3; flag field bits 0 and 6 MUST be set to 0; bit 7
MUST be set to 1. The value of other bits is not significant for the MUST be set to 1. The value of other bits is not significant for the
purposes of this document. purposes of this document.
The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
of key size. of key size, new digest types probably will have larger digests.
2.4.1 Justifications for Fields 2.4.1 Justifications for Fields
The algorithm and key tag fields are present to allow resolvers to The algorithm and key tag fields are present to allow resolvers to
quickly identify the candidate KEY records to examine. SHA-1 is a quickly identify the candidate KEY records to examine. SHA-1 is a
strong cryptographic checksum: it is computationally infeasible for strong cryptographic checksum: it is computationally infeasible for
an attacker to generate a KEY record that has the same SHA-1 digest. an attacker to generate a KEY record that has the same SHA-1 digest.
Combining the name of the key and the key rdata as input to the Combining the name of the key and the key rdata as input to the
digest provides stronger assurance of the binding. Having the key digest provides stronger assurance of the binding. Having the key
tag in the DS record adds greater assurance than the SHA-1 digest tag in the DS record adds greater assurance than the SHA-1 digest
skipping to change at page 10, line 5 skipping to change at page 10, line 5
2.7 KEY and corresponding DS record example 2.7 KEY and corresponding DS record example
This is a example of a KEY record and corresponding DS record. This is a example of a KEY record and corresponding DS record.
dskey.example. KEY 256 3 1 ( dskey.example. KEY 256 3 1 (
AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
) ; key id = 28668 ) ; key id = 28668
DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
3 Resolver Example 3 Resolver
3.1 DS Example
To create a chain of trust, a resolver goes from trusted KEY to DS to To create a chain of trust, a resolver goes from trusted KEY to DS to
KEY. KEY.
Assume the key for domain "example." is trusted. Zone "example." Assume the key for domain "example." is trusted. Zone "example."
contains at least the following records: contains at least the following records:
example. SOA <soa stuff> example. SOA <soa stuff>
example. NS ns.example. example. NS ns.example.
example. KEY <stuff> example. KEY <stuff>
example. NXT NS SOA KEY SIG NXT example. NXT NS SOA KEY SIG NXT secure.example.
example. SIG(SOA) example. SIG(SOA)
example. SIG(NS) example. SIG(NS)
example. SIG(NXT) example. SIG(NXT)
example. SIG(KEY) example. SIG(KEY)
secure.example. NS ns1.secure.example. secure.example. NS ns1.secure.example.
secure.example. DS tag=10243 alg=3 digest_type=1 <foofoo> secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo>
secure.example. NXT NS SIG NXT DS unsecure.example. secure.example. NXT NS SIG NXT DS unsecure.example.
secure.example. SIG(NXT) secure.example. SIG(NXT)
secure.example. SIG(DS) secure.example. SIG(DS)
unsecure.example NS ns1.unsecure.example. unsecure.example NS ns1.unsecure.example.
unsecure.example. NXT NS SIG NXT .example. unsecure.example. NXT NS SIG NXT example.
unsecure.example. SIG(NXT) unsecure.example. SIG(NXT)
In zone "secure.example." following records exist: In zone "secure.example." following records exist:
secure.example. SOA <soa stuff> secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example. secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3> secure.example. KEY <tag=12345 alg=3>
secure.example. SIG(KEY) <key-tag=12345 alg=3> secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=12345 alg=3> secure.example. SIG(SOA) <key-tag=12345 alg=3>
secure.example. SIG(NS) <key-tag=12345 alg=5> secure.example. SIG(NS) <key-tag=12345 alg=5>
skipping to change at page 11, line 38 skipping to change at page 11, line 38
This document proposes a change to the validation chain of KEY This document proposes a change to the validation chain of KEY
records in DNSSEC. The change is not believed to reduce security in records in DNSSEC. The change is not believed to reduce security in
the overall system. In RFC2535 DNSSEC, the child zone has to the overall system. In RFC2535 DNSSEC, the child zone has to
communicate keys to its parent and prudent parents will require some communicate keys to its parent and prudent parents will require some
authentication with that transaction. The modified protocol will authentication with that transaction. The modified protocol will
require the same authentication, but allows the child to exert more require the same authentication, but allows the child to exert more
local control over its own KEY RRset. local control over its own KEY RRset.
There is a remote possibility that an attacker could generate a valid There is a remote possibility that an attacker could generate a valid
KEY that matches all the DS fields and thus forge data from the KEY that matches all the DS fields, of a specific DS set, and thus
child. This possibility is considered impractical, as on average more forge data from the child. This possibility is considered
than 2^80 keys would have to be generated before a match would be impractical, as on average more than
found. 2 ^ (160 - <Number of keys in DS set>)
keys would have to be generated before a match would be found.
An attacker that wants to match any DS record will have to generate
on average at least 2^80 keys.
The DS record represents a change to the DNSSEC protocol and there is The DS record represents a change to the DNSSEC protocol and there is
an installed base of implementations, as well as textbooks on how to an installed base of implementations, as well as textbooks on how to
set up secure delegations. Implementations that do not understand the set up secure delegations. Implementations that do not understand the
DS record will not be able to follow the KEY to DS to KEY chain and DS record will not be able to follow the KEY to DS to KEY chain and
will consider all zones secured that way as unsecure. will consider all zones secured that way as unsecure.
5 IANA Considerations: 5 IANA Considerations:
IANA needs to allocate an RR type code for DS from the standard RR IANA needs to allocate an RR type code for DS from the standard RR
type space (type 43 requested). type space (type 43 requested).
IANA needs to open a new registry for the DS RR type for digest IANA needs to open a new registry for the DS RR type for digest
algorithms. Defined types are: algorithms. Defined types are:
0 is Reserved, 0 is Reserved,
1 is SHA-1. 1 is SHA-1.
Adding new reservations requires IETF standards action. Adding new reservations requires IETF standards action.
4 Acknowledgments 6 Acknowledgments
Over the last few years a number of people have contributed ideas Over the last few years a number of people have contributed ideas
that are captured in this document. The core idea of using one key to that are captured in this document. The core idea of using one key to
sign only the KEY RRset comes from discussions with Bill Manning and sign only the KEY RRset comes from discussions with Bill Manning and
Perry Metzger on how to put in a single root key in all resolvers. Perry Metzger on how to put in a single root key in all resolvers.
Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott
Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan
Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard
Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve
Bellovin, Rob Austein, Derek Atkins, Roy Arends, Harald Alvestrand, Bellovin, Rob Austein, Derek Atkins, Roy Arends, Harald Alvestrand,
and others have provided useful comments. and others have provided useful comments.
References: Normative References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and [RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987. Specification'', STD 13, RFC 1035, November 1987.
[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', [RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'',
RFC 2181, July 1997. RFC 2181, July 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999. 2535, March 1999.
skipping to change at page 13, line 12 skipping to change at page 13, line 12
[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver [RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
message size requirements'', RFC 3226, December 2001. message size requirements'', RFC 3226, December 2001.
Author Address Author Address
Olafur Gudmundsson Olafur Gudmundsson
3826 Legation Street, NW 3826 Legation Street, NW
Washington, DC, 20015 Washington, DC, 20015
USA USA
<ogud@ogud.com> <ogud@ogud.com>
Appendix A: Changes from Prior versions
Changes from Version 06
Made IANA section more explicit.
Removed the requirement that both DS and NXT be returned on positive
answers.
Added explicit DS example along with a KEY.
Added more explicit text what goes into DS calculation.
Updated example to be right length and added explicit DS and
corresponding KEY example (section 2.7).
Changes from version 05
Major wording changes for clarity contributed by Matt Larson.
Added explicit rule that query for type DS MUST be answered from the
upper side of delegation.
Changes from version 04
Reworded document to obsolete RFC2535 chain of trust, no backwards
compatibility. Require DS and NXT records in referrals in authority
section.
Removed the NODS bit.
Added the requirement for OK bit and Message size.
Rewrote Abstract to better express what is in the document.
Removed size field from examples and simplified them.
Changes from version 03
Added strict rules on what KEY records can be pointed to by DS.
Changes from version 02
Added text outlawing DS at non delegations.
Added table showing the contents of DS, SIG@child, and RFC1034
delegations.
Added the NODS type/bit definition to distinguish insecure DS
delegation from secure SIG@child one.
Added the requirement that NXT be returned with referral answers.
Minor text edits.
Changes from version 01
Deleted KEY size field as it did not contribute anything but
complexity.
Number of wordsmith changes to make document more readable.
The word CAN was used when SHOULD was intended.
Deleted section 2.4 "Justifications for compact format" moved
relevant text to section 2.2.
Reverse alphabetized the acknowledgments section.
Reorganized sections 1 and 2 for readability.
Changes from version 00
Changed name from DK to DS based on working group comments.
Dropped verbose format based on WG comments.
Added text about TTL issue/problem in caching servers.
Added text about islands of security and clarified the cost impact.
Major editing of arguments and some reordering of text for clarity.
Added section on transition issues.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

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