< draft-ietf-httpbis-security-properties-00.txt		draft-ietf-httpbis-security-properties-01.txt >
	Network Working Group P. Hoffman		Network Working Group P. Hoffman
	Internet-Draft VPN Consortium		Internet-Draft VPN Consortium
	Intended status: Informational A. Melnikov		Intended status: Informational A. Melnikov
	Expires: July 26, 2008 Isode Ltd.		Expires: August 25, 2008 Isode Ltd.
	January 23, 2008		February 22, 2008
	Security Requirements for HTTP		Security Requirements for HTTP
	draft-ietf-httpbis-security-properties-00.txt		draft-ietf-httpbis-security-properties-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		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
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 July 26, 2008.		This Internet-Draft will expire on August 25, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	Recent IESG practice dictates that IETF protocols must specify		Recent IESG practice dictates that IETF protocols must specify
	mandatory-to-implement security mechanisms, so that all conformant		mandatory-to-implement security mechanisms, so that all conformant
	implementations share a common baseline. This document examines all		implementations share a common baseline. This document examines all
	widely deployed HTTP security technologies, and analyzes the trade-		widely deployed HTTP security technologies, and analyzes the trade-
	offs of each.		offs of each.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3		2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3
	2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 3		2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 3
	2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 4		2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 4
	2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 4		2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5
	2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5		2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5
	2.2.3. Other Access Authentication Schemes . . . . . . . . . 6		2.2.3. Other Access Authentication Schemes . . . . . . . . . 6
	2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 6		2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 6
	2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 6
	2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 6		2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 7
	3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 7		3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. Normative References . . . . . . . . . . . . . . . . . . . . . 7		5. Normative References . . . . . . . . . . . . . . . . . . . . . 7
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 8		Appendix B. Document History . . . . . . . . . . . . . . . . . . 9
	B.1. Changes between draft-sayre-http-security-variance-00		B.1. Changes between draft-sayre-http-security-variance-00
	and draft-ietf-http-security-properties-00 . . . . . . . . 8		and draft-ietf-httpbis-security-properties-00 . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
			Intellectual Property and Copyright Statements . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Recent IESG practice dictates that IETF protocols are required to		Recent IESG practice dictates that IETF protocols are required to
	specify mandatory to implement security mechanisms. "The IETF		specify mandatory to implement security mechanisms. "The IETF
	Standards Process" [RFC2026] does not require that protocols specify		Standards Process" [RFC2026] does not require that protocols specify
	mandatory security mechanisms. "Strong Security Requirements for		mandatory security mechanisms. "Strong Security Requirements for
	IETF Standard Protocols" [RFC3365] requires that all IETF protocols		IETF Standard Protocols" [RFC3365] requires that all IETF protocols
	provide a mechanism for implementors to provide strong security. RFC		provide a mechanism for implementers to provide strong security. RFC
	3365 does not define the term "strong security".		3365 does not define the term "strong security".
	"Security Mechanisms for the Internet" [RFC3631] is not an IETF		"Security Mechanisms for the Internet" [RFC3631] is not an IETF
	procedural RFC, but it is perhaps most relevant. Section 2.2 states:		procedural RFC, but it is perhaps most relevant. Section 2.2 states:
	We have evolved in the IETF the notion of "mandatory to implement"		We have evolved in the IETF the notion of "mandatory to implement"
	mechanisms. This philosophy evolves from our primary desire to		mechanisms. This philosophy evolves from our primary desire to
	ensure interoperability between different implementations of a		ensure interoperability between different implementations of a
	protocol. If a protocol offers many options for how to perform a		protocol. If a protocol offers many options for how to perform a
	particular task, but fails to provide for at least one that all		particular task, but fails to provide for at least one that all
	skipping to change at page 3, line 39 ¶		skipping to change at page 3, line 39 ¶
	to Web applications, documents the properties that result from each		to Web applications, documents the properties that result from each
	method, and will make Best Current Practice recommendations for HTTP		method, and will make Best Current Practice recommendations for HTTP
	security in a later document version. At the moment, it is mostly a		security in a later document version. At the moment, it is mostly a
	laundry list of security technologies and tradeoffs.		laundry list of security technologies and tradeoffs.
	2. Existing HTTP Security Mechanisms		2. Existing HTTP Security Mechanisms
	For HTTP, the IETF generally defines "security mechanisms" as some		For HTTP, the IETF generally defines "security mechanisms" as some
	combination of access authentication and/or a secure transport.		combination of access authentication and/or a secure transport.
			[[ There is a suggestion that this section be split into "browser-
			like" and "automation-like" subsections. ]]
			[[ NTLM (shudder) was brought up in the WG a few times in the
			discussion of the -00 draft. Should we add a section on it? ]]
	2.1. Forms And Cookies		2.1. Forms And Cookies
	Almost all HTTP authentication is accomplished through HTML forms,		Almost all HTTP authentication that involves a human using a web
	with session keys stored in cookies. For cookies, most		browser is accomplished through HTML forms, with session identifiers
	implementations rely on the "Netscape specification", which is		stored in cookies. For cookies, most implementations rely on the
	described loosely in section 10 of "HTTP State Management Mechanism"		"Netscape specification", which is described loosely in section 10 of
	[RFC2109]. The protocol in RFC 2109 is relatively widely		"HTTP State Management Mechanism" [RFC2109]. The protocol in RFC
	implemented, but most clients don't advertise support for it. RFC		2109 is relatively widely implemented, but most clients don't
	2109 was later updated [RFC2965], but the newer version is not widely		advertise support for it. RFC 2109 was later updated [RFC2965], but
	implemented.		the newer version is not widely implemented.
	Forms and cookies have number of properties that make them an		Forms and cookies have many properties that make them an excellent
	excellent solution for some implementors. However, many of those		solution for some implementers. However, many of those properties
	properties introduce serious security trade-offs.		introduce serious security trade-offs.
	HTML forms provide a large degree of control over presentation, which		HTML forms provide a large degree of control over presentation, which
	is an imperative for many websites. However, this increases user		is an imperative for many websites. However, this increases user
	reliance on the appearance of the interface. Many users do not		reliance on the appearance of the interface. Many users do not
	understand the construction of URIs [RFC3986], or their presentation		understand the construction of URIs [RFC3986], or their presentation
	in common clients [[ CITATION NEEDED ]]. As a result, forms are		in common clients [PhishingHOWTO]. As a result, forms are extremely
	extremely vulnerable to spoofing.		vulnerable to spoofing.
	HTML forms provide acceptable internationalization if used carefully,		HTML forms provide acceptable internationalization if used carefully,
	at the cost of being transmitted as normal HTTP content in all cases		at the cost of being transmitted as normal HTTP content in all cases
	(credentials are not differentiated in the protocol).		(credentials are not differentiated in the protocol).
	HTML forms provide a facility for sites to indicate that a password		HTML forms provide a facility for sites to indicate that a password
	should never be pre-populated. [[ More needed here on autocomplete ]]		should never be pre-populated. [[ More needed here on autocomplete ]]
	The cookies that result from a successful form submission make it		The cookies that result from a successful form submission make it
	unessecary to validate credentials with each HTTP request; this makes		unnecessary to validate credentials with each HTTP request; this
	cookies an excellent property for scalability. Cookies are		makes cookies an excellent property for scalability. Cookies are
	susceptible to a large variety of XSS (cross-site scripting) attacks,		susceptible to a large variety of XSS (cross-site scripting) attacks,
	and measures to prevent such attacks will never be as stringent as		and measures to prevent such attacks will never be as stringent as
	necessary for authentication credentials because cookies are used for		necessary for authentication credentials because cookies are used for
	many purposes. Cookies are also susceptible to a wide variety of		many purposes. Cookies are also susceptible to a wide variety of
	attacks from malicious intermediaries and observers. The possible		attacks from malicious intermediaries and observers. The possible
	attacks depend on the contents of the cookie data. There is no		attacks depend on the contents of the cookie data. There is no
	standard format for most of the data.		standard format for most of the data.
	HTML forms and cookies provide flexible ways of ending a session from		HTML forms and cookies provide flexible ways of ending a session from
	the client.		the client.
	HTML forms require an HTML rendering engine, which many protocols		HTML forms require an HTML rendering engine for which many protocols
	have no use for.		have no use.
	2.2. HTTP Access Authentication		2.2. HTTP Access Authentication
	HTTP 1.1 provides a simple authentication framework, and "HTTP		HTTP 1.1 provides a simple authentication framework, "HTTP
	Authentication: Basic and Digest Access Authentication" [RFC2617]		Authentication: Basic and Digest Access Authentication" [RFC2617],
	defines two optional mechanisms. Both of these mechanisms are		which defines two optional mechanisms. Both of these mechanisms are
	extremely rarely used in comparison to forms and cookies, but some		extremely rarely used in comparison to forms and cookies, but some
	degree of support for one or both is available in many		degree of support for one or both is available in many
	implementations. Neither scheme provides presentation control,		implementations. Neither scheme provides presentation control,
	logout capabilities, or interoperable internationalization.		logout capabilities, or interoperable internationalization.
	2.2.1. Basic Authentication		2.2.1. Basic Authentication
	Basic Authentication (normally called just "Basic") transmits		Basic Authentication (normally called just "Basic") transmits
	usernames and passwords in the clear. It is very easy to implement,		usernames and passwords in the clear. It is very easy to implement,
	but not at all secure unless used over a secure transport.		but not at all secure unless used over a secure transport.
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 42 ¶
	Digest has some properties that are preferable to Basic and Cookies.		Digest has some properties that are preferable to Basic and Cookies.
	Credentials are not immediately reusable by parties that observe or		Credentials are not immediately reusable by parties that observe or
	receive them, and session data can be transmitted along side		receive them, and session data can be transmitted along side
	credentials with each request, allowing servers to validate		credentials with each request, allowing servers to validate
	credentials only when absolutely necessary. Authentication data		credentials only when absolutely necessary. Authentication data
	session keys are distinct from other protocol traffic.		session keys are distinct from other protocol traffic.
	Digest includes many modes of operation, but only the simplest modes		Digest includes many modes of operation, but only the simplest modes
	enjoy any degree of interoperability. For example, most		enjoy any degree of interoperability. For example, most
	implementations do not implement the mode that provides full message		implementations do not implement the mode that provides full message
	integrity. Additionally, implementation experience has shown that		integrity. Perhaps one reason is that implementation experience has
	the message integrity mode is impractical because it requires servers		shown that in some cases, especially those involving large requests
	to analyze the full request before determining whether the client		or responses such as streams, the message integrity mode is
	knows the shared secret.		impractical because it requires servers to analyze the full request
			before determining whether the client knows the shared secret or
			whether message-body integrity has been violated and hence whether
			the request can be processed.
	Digest is extremely susceptible to offline dictionary attacks, making		Digest is extremely susceptible to offline dictionary attacks, making
	it practical for attackers to perform a namespace walk consisting of		it practical for attackers to perform a namespace walk consisting of
	a few million passwords [[ CITATION NEEDED ]].		a few million passwords [[ CITATION NEEDED ]].
	Many of the most widely-deployed HTTP/1.1 clients are not compliant		Many of the most widely-deployed HTTP/1.1 clients are not compliant
	when GET requests include a query string [Apache_Digest].		when GET requests include a query string [Apache_Digest].
	Digest either requires that authentication databases be expressly		Digest either requires that authentication databases be expressly
	designed to accomodate it, or requires access to cleartext passwords.		designed to accommodate it, or requires access to cleartext
	As a result, many authentication databases that chose to do the		passwords. As a result, many authentication databases that chose to
	former are incompatible, including the most common method of storing		do the former are incompatible, including the most common method of
	passwords for use with Forms and Cookies.		storing passwords for use with Forms and Cookies.
	Many Digest capabilities included to prevent replay attacks expose		Many Digest capabilities included to prevent replay attacks expose
	the server to Denial of Service attacks.		the server to Denial of Service attacks.
	Digest is not interoperable when used with credentials that contain		Digest is not interoperable when used with credentials that contain
	characters outside of the ISO 8859-1 repertoire.		characters outside of the ISO 8859-1 repertoire.
	2.2.3. Other Access Authentication Schemes		2.2.3. Other Access Authentication Schemes
	There are many niche schemes that make use of the HTTP Authentication		There are many niche schemes that make use of the HTTP Authentication
	framework, but very few are well documented. Some are bound to		framework, but very few are well documented. Some are bound to
	transport layer connections.		transport layer connections.
	2.2.3.1. Negotiate (GSS-API) Authentication		2.2.3.1. Negotiate (GSS-API) Authentication
	[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP		[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
	Authentication in Microsoft Windows" [RFC4559] goes here.]]		Authentication in Microsoft Windows" [RFC4559] goes here. ]]
	2.3. Centrally-Issued Tickets		2.3. Centrally-Issued Tickets
	Many large Internet services rely on authentication schemes that		Many large Internet services rely on authentication schemes that
	center on clients consulting a single service for a time-limited		center on clients consulting a single service for a time-limited
	ticket that is validated with undocumented heuristics. Centralized		ticket that is validated with undocumented heuristics. Centralized
	ticket issuing has the advantage that users may employ one set of		ticket issuing has the advantage that users may employ one set of
	credentials for many services, and clients don't send credentials to		credentials for many services, and clients don't send credentials to
	many servers. This approach is often no more than a sophisticated		many servers. This approach is often no more than a sophisticated
	application of forms and cookies.		application of forms and cookies.
	skipping to change at page 6, line 44 ¶		skipping to change at page 7, line 4 ¶
	progress, as usual.		progress, as usual.
	2.4. Web Services		2.4. Web Services
	Many security properties mentioned in this document have been recast		Many security properties mentioned in this document have been recast
	in XML-based protocols, using HTTP as a substitute for TCP. Like the		in XML-based protocols, using HTTP as a substitute for TCP. Like the
	amalgam of HTTP technologies mentioned above, the XML-based protocols		amalgam of HTTP technologies mentioned above, the XML-based protocols
	are defined by an ever-changing combination of standard and vendor-		are defined by an ever-changing combination of standard and vendor-
	produced specifications, some of which may be obsoleted at any time		produced specifications, some of which may be obsoleted at any time
	[WS-Pagecount] without any documented change control procedures.		[WS-Pagecount] without any documented change control procedures.
	These protocols usually don't have much in common with the		These protocols usually don't have much in common with the
	Architecture of the World Wide Web. It's not clear why term "Web" is		Architecture of the World Wide Web. It's not clear why the term "Web"
	used to group them, but they are obviously out of scope for HTTP-		is used to group them, but they are obviously out of scope for HTTP-
	based application protocols.		based application protocols.
			[[ This section could really use a good definition of "Web Services"
			to differentiate it from REST. ]]
	2.5. Transport Layer Security		2.5. Transport Layer Security
	[[ A discussion of HTTP over TLS needs to be added here. ]]		[[ A discussion of HTTP over TLS needs to be added here. ]]
	[[ Discussion of connection confidentiality should be separate from		[[ Discussion of connection confidentiality should be separate from
	the discussion of access authentication based on mutual		the discussion of access authentication based on mutual
	authentication with certificates in TLS. ]]		authentication with certificates in TLS. ]]
	3. Revisions To HTTP		3. Revisions To HTTP
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 43 ¶
	This entire document is about security considerations.		This entire document is about security considerations.
	5. Normative References		5. Normative References
	[Apache_Digest]		[Apache_Digest]
	Apache Software Foundation, "Apache HTTP Server -		Apache Software Foundation, "Apache HTTP Server -
	mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/		mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
	mod_auth_digest.html>.		mod_auth_digest.html>.
			[PhishingHOWTO]
			Gutmann, P., "Phishing Tips and Techniques",
			February 2008,
			<http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.		3", BCP 9, RFC 2026, October 1996.
	[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management		[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
	Mechanism", RFC 2109, February 1997.		Mechanism", RFC 2109, February 1997.
	[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use		[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
	and Interpretation of HTTP Version Numbers", RFC 2145,		and Interpretation of HTTP Version Numbers", RFC 2145,
	May 1997.		May 1997.
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 46 ¶
	Kerberos and NTLM HTTP Authentication in Microsoft		Kerberos and NTLM HTTP Authentication in Microsoft
	Windows", RFC 4559, June 2006.		Windows", RFC 4559, June 2006.
	[WS-Pagecount]		[WS-Pagecount]
	Bray, T., "WS-Pagecount", September 2004, <http://		Bray, T., "WS-Pagecount", September 2004, <http://
	www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.		www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Much of the material in this document was written by Rob Sayre, who		Much of the material in this document was written by Rob Sayre, who
	first promoted the topic.		first promoted the topic. Many others on the HTTPbis Working Group
			have contributed to this document in the discussion.
	Appendix B. Document History		Appendix B. Document History
	[This entire section is to be removed when published as an RFC.]		[This entire section is to be removed when published as an RFC.]
	B.1. Changes between draft-sayre-http-security-variance-00 and		B.1. Changes between draft-sayre-http-security-variance-00 and
	draft-ietf-http-security-properties-00		draft-ietf-httpbis-security-properties-00
	Changed the authors to Paul Hoffman and Alexey Melnikov, with		Changed the authors to Paul Hoffman and Alexey Melnikov, with
	permission of Rob Sayre.		permission of Rob Sayre.
	Made lots of minor editorial changes.		Made lots of minor editorial changes.
	Removed what was section 2 (Requirements Notation), the reference to		Removed what was section 2 (Requirements Notation), the reference to
	RFC 2119, and any use of 2119ish all-caps words.		RFC 2119, and any use of 2119ish all-caps words.
	In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1		In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
	repertoire" to match the defintion of "TEXT" in RFC 2616.		repertoire" to match the definition of "TEXT" in RFC 2616.
	Added minor text to the Security Considerations section.		Added minor text to the Security Considerations section.
	Added URLs to the two non-RFC references.		Added URLs to the two non-RFC references.
			B.2. Changes between -00 and -01
			Fixed some editorial nits reported by Iain Calder.
			Added the suggestions about splitting for browsers and automation,
			and about adding NTLM, to be beginning of 2.
			In 2.1, added "that involves a human using a web browser" in the
			first sentence.
			In 2.1, changed "session key" to "session identifier".
			In 2.2.2, changed
			Digest includes many modes of operation, but only the simplest modes
			enjoy any degree of interoperability. For example, most
			implementations do not implement the mode that provides full message
			integrity. Additionally, implementation experience has shown that
			the message integrity mode is impractical because it requires servers
			to analyze the full request before determining whether the client
			knows the shared secret.
			to
			Digest includes many modes of operation, but only the simplest
			modes enjoy any degree of interoperability. For example, most
			implementations do not implement the mode that provides full message
			integrity. Perhaps one reason is that implementation experience has
			shown that in some cases, especially those involving large requests
			or responses such as streams, the message integrity mode is
			impractical because it requires servers to analyze the full request
			before determining whether the client knows the shared secret or
			whether message-body integrity has been violated and hence whether
			the request can be processed.
			In 2.4, asked for a definition of "Web Services".
			In A, added the WG.
	Authors' Addresses		Authors' Addresses
	Paul Hoffman		Paul Hoffman
	VPN Consortium		VPN Consortium
	Email: paul.hoffman@vpnc.org		Email: paul.hoffman@vpnc.org
	Alexey Melnikov		Alexey Melnikov
	Isode Ltd.		Isode Ltd.
End of changes. 26 change blocks.
	45 lines changed or deleted		103 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/