Document: draft-ietf-calext-subscription-upgrade Title: Calendar subscription upgrades Reviewer: Stephen Farrell Review result: Not Ready Calendaring isn't something with which I'm very familiar so I might be somewhat off base here, and I see that the draft has been returned to the WG based on other reviews, so I'll limit this to what seem like the most obvious security things to address while doing further work on the spec. - The handling of the 'Sync-token' seems underspecified, from a security perspective. I expected to see some guidance as to uniqueness, randomness or unguessability so that clients couldn't easily probe for things based on guesses. - I don't understand why the 'Sync-token' needs to be a URI, nor what processing might happen if e.g. an https URL were used. (Might some proxies try to de-reference such URIs to reduce tracking or to try scan for badness?) I think it'd be necessary to understand that to understand any security or privacy issues that might arise. - The security and privacy considerations text here seem insufficient, overly generic and vague. RFC3986 also doesn't seem like the best reference for (modern) URI security considerations. Other than implying that a secure transport is needed, (without really saying so), RFC5545 says that privacy considerations are described elsewhere so referring to that in section 9 also doesn't seem useful. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
