Skip to main content

Telechat Review of draft-ietf-sidr-repos-struct-
review-ietf-sidr-repos-struct-secdir-telechat-sheffer-2011-07-09-00

Request Review of draft-ietf-sidr-repos-struct
Requested revision No specific revision (document currently at 09)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2011-07-12
Requested 2011-06-17
Authors Geoff Huston , Robert Loomans , George G. Michaelson
I-D last updated 2011-07-09
Completed reviews Secdir Last Call review of -?? by Joseph A. Salowey
Secdir Telechat review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer
State Completed
Request Telechat review on draft-ietf-sidr-repos-struct by Security Area Directorate Assigned
Completed 2011-07-09
review-ietf-sidr-repos-struct-secdir-telechat-sheffer-2011-07-09-00
I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


These comments were written primarily for the benefit of the security 


area directors. Document editors and WG chairs should treat these 


comments just like any other last call comments







This draft describes the structure of the RPKI repositories. This is a 


dedicated, even more complex than usual PKI deployment.







The security considerations are short, considering that the entire 


document is about the security underpinnings of a critical 


infrastructure. However they do make sense to me. I do have two comments:






• The mandatory use or Rsync (vs. e.g. simple HTTP) in a one-way content 


retrieval context seems like a questionable security vs. operational 


cost trade-off. Rsync is complex and has seen various security 


vulnerabilities over the years: 


http://secunia.com/advisories/search/?search=rsync

. BTW, the reference 


"to rsync" only defines the URI format. As to a formal specification of 


the protocol, guess what? 


http://lists.samba.org/archive/rsync/2008-October/021927.html

.


• The following sentence seems to require clarification, and hints at 


possible risks/mitigations: "However, even the use of manifests and CRLs 


will not allow a relying party to detect all forms of substitution 


attacks based on older (but not expired) valid objects."




Thanks,
Yaron