Re: [Privacy-pass] Murray Kucherawy's No Objection on draft-ietf-privacypass-protocol-15: (with COMMENT)

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 02 October 2023 22:59 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 93F9AC14CE33; Mon, 2 Oct 2023 15:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 UCtkSQ2typvJ; Mon, 2 Oct 2023 15:59:08 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 7B061C14CE2C; Mon, 2 Oct 2023 15:59:08 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-537efaf742aso80518a12.0; Mon, 02 Oct 2023 15:59:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696287546; x=1696892346; 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=M2zePv6mhJMQmn76LAbMakfX+wD1wLjzoeXWVoCK2R0=; b=OW3Bcp6i3ndST1+oY+Pz1TBHM9dfxLe/oUwcrK5eXpi9fot5OpmN5YD9N0ORJxP+od ibV1OUxpKnHoGJ9llMFHrz2D9eS6pACc+sf3cPW00/X7B4aJR7rEz/W+SuSmZXLNYd6r 3OyI+E06Qv/Uox0Kl6DlA3VvbpYEZeSadgerAincQvisF7sQe/2SqXFGHqUi4KFtgHuk q50KCtWoIbUaWUgZCZTLt/rKbfPAhhLf7NJsaS8POZhaXHsL82Oh7RR9DzFkoh/FbFE2 QCKoqMObYxNeyJIXWFdOcNWClMPzb6gzsGMpV4krkQNcn8BS5WsRrrgc7AxC5MFTJQIo ZNmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696287546; x=1696892346; 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=M2zePv6mhJMQmn76LAbMakfX+wD1wLjzoeXWVoCK2R0=; b=MnjfVVkdcwDMz+ENq2JJYp0bg1x0M7L5ypQzPfb+u+2mVA6DprHMs6d+rC19EiRaw+ ElZVcN/4nANTHfXIc+9+D6Q7dUYR32DVXyk7jY19SXryNidMMuvX3tKlhAdjuiXohox1 jKARTNr+1S6gf/yYgErbh+RO3Uo7lQn+cPvxF6LTO1/UFfR9WZjOs7ChVCRbm8MQmFqg JCbVa0WirlY73AGZ56/CJJqmCrZhol/sErokWpnz7zkEpiXhu6pZrtZbjDvKQJS02bWM swMvFnnJd/1QqkqeKIoB7vUhDmyDz8CZ3oxOO2JsWNvm19Ieque2pjgIV7he384nlhe9 3D3A==
X-Gm-Message-State: AOJu0Yxw8KWunvlNlQkIDBwcJoZOc1BRCDTJazWQSV+//dl8TGlfAycB qo2C4qIGrk5tl3wxrZPK13pxxJ8hna9UN6cwhvE=
X-Google-Smtp-Source: AGHT+IGsNgjSUJu33IBvCC7bUAYqYV5qxPgNl/tzEdPNMmTcalpWVh1wPmEKyEi4+CS5rry5DjsNDFJR5XY7lKq50xg=
X-Received: by 2002:a17:906:518c:b0:9a1:aea8:cb5a with SMTP id y12-20020a170906518c00b009a1aea8cb5amr11836228ejk.1.1696287545730; Mon, 02 Oct 2023 15:59:05 -0700 (PDT)
MIME-Version: 1.0
References: <169627293125.59140.1276674241095262126@ietfa.amsl.com> <EDDFB334-AEAE-4CCC-9851-8A975F7FEDA7@apple.com> <EF167A8C-3B24-4101-8431-3A00BBC642CB@heapingbits.net>
In-Reply-To: <EF167A8C-3B24-4101-8431-3A00BBC642CB@heapingbits.net>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Mon, 02 Oct 2023 15:58:53 -0700
Message-ID: <CAL0qLwZRFagO-F-g2Dhr+p6boQ2w4b4TL-FnBe2erPzVB5CFDw@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: Tommy Pauly <tpauly@apple.com>, 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="00000000000099ab670606c3b8e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/QP9cPHLqotg1TrEU_L-qKH9sZhY>
Subject: Re: [Privacy-pass] Murray Kucherawy's No Objection on draft-ietf-privacypass-protocol-15: (with 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 22:59:09 -0000

"A possible exception to this constraint would be a colliding key that is
still in use but in the process of being rotated out, in which case the
collision cannot reasonably be avoided but it is expected to be transient."

On Mon, Oct 2, 2023 at 2:04 PM Christopher Wood <caw@heapingbits.net> wrote:

> Tommy’s interpretation is correct. We’re happy to take text suggestions to
> convey this intent more clearly.
>
> Best,
> Chris
>
> On Oct 2, 2023, at 3:57 PM, Tommy Pauly <tpauly@apple.com> wrote:
>
> Thanks for the comment, Murray.
>
> Chiming in as an individual here (since I’m not an author), my
> interpretation of why a SHOULD is appropriate is that there *could* be
> cases where another key conflicts that is “in rotation” (as in still
> accepted by redeeming parties) but is quite old and isn’t expected to be
> used for any *new* challenges or token issuances. I could imagine a case
> where the issuer rotates keys quite frequently, and all challenging parties
> challenge with the new key, but if a client had a previous token with an
> older key and presented it, the redeeming party might be willing to accept
> the key. In such cases, it would be possible to fill up the space of 255
> key IDs.
>
> Unlikely, but possible — something I don’t think we need to strictly
> forbid.
>
> Thanks,
> Tommy
>
>
> 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."
>
> Version -15 goes on to say that there are no security implications of a
> collision (whew) but basically says the operation is invalid after that.
> That
> leads me to think this is a strange use of SHOULD, i.e., "You SHOULD do
> this or
> things don't work."  I still don't understand why that's not a MUST.  Why
> might
> one legitimately decide not to do what this says?
>
>
>
> --
> Privacy-pass mailing list
> Privacy-pass@ietf.org
> https://www.ietf.org/mailman/listinfo/privacy-pass
>
>
>