rfc9674v1.txt		rfc9674.txt
	skipping to change at line 76 ¶		skipping to change at line 76 ¶
	This document specifies a Same-Origin Policy (SOP) requirement for		This document specifies a Same-Origin Policy (SOP) requirement for
	RPKI Repository Delta Protocol (RRDP) servers and clients. The SOP		RPKI Repository Delta Protocol (RRDP) servers and clients. The SOP
	concept is a security mechanism to restrict how a document loaded		concept is a security mechanism to restrict how a document loaded
	from one origin can cause interaction with resources from another		from one origin can cause interaction with resources from another
	origin. See [RFC6454] for an overview of the concept of an "origin".		origin. See [RFC6454] for an overview of the concept of an "origin".
	Application of a SOP in RRDP client/server communication isolates		Application of a SOP in RRDP client/server communication isolates
	resources such as Delta and Snapshot files from different Repository		resources such as Delta and Snapshot files from different Repository
	Servers, reducing possible attack vectors. Another way to avoid		Servers, reducing possible attack vectors. Another way to avoid
	undesirable implications (as described in Section 2) would be for a		undesirable implications (as described in Section 2) would be for a
	future version of the RRDP protocol to use relative URIs instead of		future version of RRDP to use relative URIs instead of absolute URIs.
	absolute URIs. This document updates [RFC8182].		This document updates [RFC8182].
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Implications of Cross-Origin Resource Requests in RRDP		2. Implications of Cross-Origin Resource Requests in RRDP
	The first RRDP protocol specification did not explicitly disallow		The first RRDP specification did not explicitly disallow 'cross-
	'cross-origin' URI references from the Update Notification file		origin' URI references from the Update Notification file
	(Section 3.5.1 of [RFC8182]) towards Delta (Section 3.5.3 of		(Section 3.5.1 of [RFC8182]) towards Delta (Section 3.5.3 of
	[RFC8182]) and Snapshot (Section 3.5.2 of [RFC8182]) files, and it		[RFC8182]) and Snapshot (Section 3.5.2 of [RFC8182]) files, and it
	was silent on the topic of HTTP Redirection (Section 15.4 of		was silent on the topic of HTTP Redirection (Section 15.4 of
	[RFC9110]).		[RFC9110]).
	The implication of cross-origin references in Update Notification		The implication of cross-origin references in Update Notification
	files is that one Repository Server can reference RRDP resources on		files is that one Repository Server can reference RRDP resources on
	another Repository Server and in doing so inappropriately increase		another Repository Server and in doing so inappropriately increase
	the resource consumption for both RRDP clients and the referenced		the resource consumption for both RRDP clients and the referenced
	Repository Server. An adversary could also employ cross-origin HTTP		Repository Server. An adversary could also employ cross-origin HTTP
	skipping to change at line 141 ¶		skipping to change at line 141 ¶
	NEW		NEW
	| * The Relying Party MUST verify whether the "uri" attributes in		| * The Relying Party MUST verify whether the "uri" attributes in
	| the Update Notification File are of the same origin as the		| the Update Notification File are of the same origin as the
	| Update Notification File itself. If this verification fails,		| Update Notification File itself. If this verification fails,
	| the file MUST be rejected and RRDP cannot be used; see		| the file MUST be rejected and RRDP cannot be used; see
	| Section 3.4.5 for considerations. Implementations SHOULD log a		| Section 3.4.5 for considerations. Implementations SHOULD log a
	| message when cross-origin referrals are detected.		| message when cross-origin referrals are detected.
	|		|
	| * The Relying Party MUST NOT follow HTTP Redirection following		| * The Relying Party MUST NOT follow HTTP Redirection that results
	| from attempts to download Update Notification, Delta, and		| from attempts to download Update Notification, Delta, and
	| Snapshot files if the target origin is different from the		| Snapshot files if the target origin is different from the
	| origin of the Update Notification File specified in the		| origin of the Update Notification File specified in the
	| referring RRDP SIA AccessDescription. If this verification		| referring RRDP SIA AccessDescription. If this verification
	| fails, the RRDP session MUST be rejected and RRDP cannot be		| fails, the RRDP session MUST be rejected and RRDP cannot be
	| used; see Section 3.4.5 for considerations. Implementations		| used; see Section 3.4.5 for considerations. Implementations
	| SHOULD log a message when cross-origin redirects are detected.		| SHOULD log a message when cross-origin redirects are detected.
	4. Deployability in the Internet's Current RPKI		4. Deployability in the Internet's Current RPKI
	skipping to change at line 165 ¶		skipping to change at line 165 ¶
	employed a same-origin HTTP redirect. In the period October 2021 -		employed a same-origin HTTP redirect. In the period October 2021 -
	October 2024 no RRDP Repository Servers were observed that employed		October 2024 no RRDP Repository Servers were observed that employed
	cross-origin URIs in Update Notification Files.		cross-origin URIs in Update Notification Files.
	This means that imposing a requirement for the application of a Same-		This means that imposing a requirement for the application of a Same-
	Origin Policy does not cause any existing commonly used RRDP		Origin Policy does not cause any existing commonly used RRDP
	Repository Server operations to become non-compliant.		Repository Server operations to become non-compliant.
	5. Security Considerations		5. Security Considerations
	This document addresses an oversight in the original RRDP protocol		This document addresses an oversight in the original RRDP
	specification: Cross-origin requests are detrimental as they allow		specification: Cross-origin requests are detrimental as they allow
	one repository operator to increase resource consumption for other		one repository operator to increase resource consumption for other
	repository operators and RRDP clients.		repository operators and RRDP clients.
	6. IANA Considerations		6. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	7. References		7. References
	skipping to change at line 204 ¶		skipping to change at line 204 ¶
	<https://www.rfc-editor.org/info/rfc8182>.		<https://www.rfc-editor.org/info/rfc8182>.
	[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
	7.2. Informative References		7.2. Informative References
	[rpkiviews]		[rpkiviews]
	"Index of /josephine.sobornost.net/rpkidata/",		Snijders, J., "rpkiviews", <https://www.rpkiviews.org>.
	<https://www.rpkiviews.org>.
	Acknowledgements		Acknowledgements
	The author wishes to thank Theo Buehler, Claudio Jeker, Alberto		The author wishes to thank Theo Buehler, Claudio Jeker, Alberto
	Leiva, Tim Bruijnzeels, Ties de Kock, Martin Hoffmann, and Mikhail		Leiva, Tim Bruijnzeels, Ties de Kock, Martin Hoffmann, and Mikhail
	Puzanov for their helpful feedback, comments, and implementation		Puzanov for their helpful feedback, comments, and implementation
	work. The author wishes to thank Keyur Patel, Meral Shirazipour,		work. The author wishes to thank Keyur Patel, Meral Shirazipour,
	Niclas Comstedt, Dan Harkins, Erik Kline, Roman Danyliw, and Éric		Niclas Comstedt, Dan Harkins, Erik Kline, Roman Danyliw, and Éric
	Vyncke for their review.		Vyncke for their review.
End of changes. 5 change blocks.
	8 lines changed or deleted		7 lines changed or added
This html diff was produced by rfcdiff 1.48.