[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.
- [secdir] Secdir ietf last call review of draft-ie… Stephen Farrell via Datatracker