[secdir] Secdir ietf last call review of draft-ietf-calext-subscription-upgrade-13

Stephen Farrell via Datatracker <noreply@ietf.org> Mon, 14 April 2025 13:13 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@mail2.ietf.org
Received: from [10.244.8.129] (unknown [104.131.183.230]) by mail2.ietf.org (Postfix) with ESMTP id 9C31A1BB8C04; Mon, 14 Apr 2025 06:13:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <174463640647.1167582.8116822942843928947@dt-datatracker-64c5c9b5f9-hz6qg>
Date: Mon, 14 Apr 2025 06:13:26 -0700
Message-ID-Hash: SX7ZCXPXBCPEB224Y2LCVFQL7MB7YYIA
X-Message-ID-Hash: SX7ZCXPXBCPEB224Y2LCVFQL7MB7YYIA
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: calsify@ietf.org, draft-ietf-calext-subscription-upgrade.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: [secdir] Secdir ietf last call review of draft-ietf-calext-subscription-upgrade-13
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/xXQ-v2r95rXm5uK69LxDtOyZmco>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

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.