Re: [Privacy-pass] Murray Kucherawy's Discuss on draft-ietf-privacypass-protocol-14: (with DISCUSS and COMMENT)
"Murray S. Kucherawy" <superuser@gmail.com> Mon, 02 October 2023 18:53 UTC
Return-Path: <superuser@gmail.com>
X-Original-To: privacy-pass@ietfa.amsl.com
Delivered-To: privacy-pass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC17BC169525; Mon, 2 Oct 2023 11:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTVwkavWiujH; Mon, 2 Oct 2023 11:53:30 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C787CC15154F; Mon, 2 Oct 2023 11:53:30 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3231e138f44so25942f8f.0; Mon, 02 Oct 2023 11:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696272809; x=1696877609; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lHgRzq6ypQ0tLL9Wuktw2igHxYWMxdNl64zXIbnXbL8=; b=axFQRHwYAYgLB/EsjLDNjzBPVs0Q92UFtvFpI/wjZdva8cKEjz+qbBzHcO6ZP4mURm k2qZWQJmU9ndA1xpJiMXnhWfZ51q+XqiH51M8JKFF7qyShhnqI/tuTmXmbEa/wzGJM2s P2NqA2h1DvzNsvdgYb7lRCXNBpuVfxJJ5LgV67cYfJusLZYXfMQE3ber8WjnNEUIe5MU SeP3AEsH+on+CgYUaW0NYkb1i/ApaB2pHWhf1lTjBG+RMQxFbhyKBtc58baeqt5Y2bBN ztvuIODkYQd64YRWKh2NNp5XpmLXKmwPsWBYl8BLudS9q9C9oYjo6GMciRrzbcvMXSQw tQXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696272809; x=1696877609; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lHgRzq6ypQ0tLL9Wuktw2igHxYWMxdNl64zXIbnXbL8=; b=SHD+KaXJ6U3SNRrZwSAr+CNU3zebnJG3SqbghCYtcUgPPKzmp3Gwhn47vGCS9+8Vca +JRY7+SKvx9PLg4EaG0uIE2RgHAqIH3Riec9CJ/orTPVdg+l4+89RD5GOcyNx/IgXIOD sdziZo0lAfrnKz/oqrx4SwkKNIjpCwmWhAQF3W2CJIioxGAWyrTJLahlYOoaiVkAlTGZ PIHPXv1skx3sedmSRYa7rH0pJeDPOjjI2S/D0DqKfPQjbgmHXhf42Ne1X03BWl9biyrU 39vn1ZoLmqTIIkPc+rZQDkgEZxrSihT5Ps8W21c3VHyAfsa7NDHXsYDczTAUndbZqFGB bRIQ==
X-Gm-Message-State: AOJu0YwIfcc13ApyxKu8+PcwDkCYm6lTWWOejJkdtvQsYp29NZcHoNPw ORWcxHlmhxwF8ApHzqC/+G/AYBDGXuY3DXRlszoM6YbJrraqEQ==
X-Google-Smtp-Source: AGHT+IESj3EJxXAVD7HVe+WRyj4EaBSndxe9Jx60Cs1jlMOjZO1DFhz0YARCiLReQFQcs6Kci8abKquFTEG4+eHQ+vM=
X-Received: by 2002:a5d:5151:0:b0:31f:899b:a47 with SMTP id u17-20020a5d5151000000b0031f899b0a47mr10449863wrt.4.1696272808652; Mon, 02 Oct 2023 11:53:28 -0700 (PDT)
MIME-Version: 1.0
References: <169527418061.14320.3182196780743042962@ietfa.amsl.com> <A692FF17-5A4C-46F0-BFE5-3C59F8A60F29@heapingbits.net>
In-Reply-To: <A692FF17-5A4C-46F0-BFE5-3C59F8A60F29@heapingbits.net>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Mon, 02 Oct 2023 11:53:17 -0700
Message-ID: <CAL0qLwbK6pZdRA-_tN-+ZRL5voEv89t=gxyJj7CR+R3g3DesNg@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-privacypass-protocol@ietf.org, privacypass-chairs@ietf.org, privacy-pass@ietf.org, jsalowey@gmail.com
Content-Type: multipart/alternative; boundary="00000000000033b4900606c04a7e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/PMaT2HwIjrqj-yhUvjX2olq_H7s>
Subject: Re: [Privacy-pass] Murray Kucherawy's Discuss on draft-ietf-privacypass-protocol-14: (with DISCUSS and COMMENT)
X-BeenThere: privacy-pass@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Pass Protocol <privacy-pass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/privacy-pass/>
List-Post: <mailto:privacy-pass@ietf.org>
List-Help: <mailto:privacy-pass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Oct 2023 18:53:34 -0000
The new text in 6.5 says: -- snip -- [...] truncated key IDs in rotation. Collisions can cause the Issuer to use the wrong Issuer Private Key for issuance, which will in turn cause the resulting tokens to be invalid. There is no known security consequence of using the the wrong Issuer Private Key. -- snip -- It's helpful to state that violating this SHOULD is ultimately harmless, but this still seems a strange use of SHOULD to me. "You SHOULD do this, else the protocol breaks" sure strikes me as a MUST. Why might anyone ever consciously choose to deviate from this advice? -MSK On Thu, Sep 21, 2023 at 1:50 PM Christopher Wood <caw@heapingbits.net> wrote: > Thanks for the review, Murray. I attempted to address your feedback in > this PR: > > https://github.com/ietf-wg-privacypass/base-drafts/pull/492 > > I wasn’t entirely sure which SHOULDs you were referring to in Section 4, > so I made an attempt at clarifying the rationale for two of them. Please > let me know if you meant something else. > > Best, > Chris > > On Sep 21, 2023, at 1:29 AM, Murray Kucherawy via Datatracker < > noreply@ietf.org> wrote: > > Murray Kucherawy has entered the following ballot position for > draft-ietf-privacypass-protocol-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Maybe I'm missing something, but you have this in Section 6.5: > > "Since Clients truncate token_key_id in each TokenRequest, Issuers SHOULD > ensure that the truncated form of new key IDs do not collide with other > truncated key IDs in rotation." > > Why would this not be a MUST? That strikes me as something pretty > important, > so it's curious to give implementers a choice to skip this requirement. > What > would a legitimate reason be to not do this? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The "Optional parameters" in each of the subsections of Section 8.3 should > read > "N/A" (as you have it for "Required parameters"), not "None", unless you > meant > to declare that there's an option called "None". > > The first and last SHOULDs in Section 4 are bare. What's the > interoperability > or security impact if I don't do what it says? Same question with the > SHOULD > in Section 5.5. > > > > >
- [Privacy-pass] Murray Kucherawy's Discuss on draf… Murray Kucherawy via Datatracker
- Re: [Privacy-pass] Murray Kucherawy's Discuss on … Christopher Wood
- Re: [Privacy-pass] Murray Kucherawy's Discuss on … Murray S. Kucherawy