Re: [Privacy-pass] Call for Adoption of Key Consistency and Discovery Draft

Ben Schwartz <bemasc@google.com> Wed, 28 September 2022 16:28 UTC

Return-Path: <bemasc@google.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 A2202C152581 for <privacy-pass@ietfa.amsl.com>; Wed, 28 Sep 2022 09:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.597
X-Spam-Level:
X-Spam-Status: No, score=-17.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 SqYPU_AihWFZ for <privacy-pass@ietfa.amsl.com>; Wed, 28 Sep 2022 09:28:32 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 1429CC152594 for <privacy-pass@ietf.org>; Wed, 28 Sep 2022 09:27:54 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id j123so4830959vsc.3 for <privacy-pass@ietf.org>; Wed, 28 Sep 2022 09:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=Pkh94rmAODO+BCS2Hgmxux6A8faNEqj9+a2S7d0nXOY=; b=nIOcVP8QeWwQFiUNnVKDgB/7TAfAlH3cOx3IiLZ4mj3dhovQPQrUTy10c03O2me2Fj w2BoNcXCcDtfp5w4kh4MziGWNlOpU+slQMOd5pPukGPO8+bNeZQ5PxQeLKbT7EkflD+/ GJ/Z/OXJ4df0MmQx1KYt0OsuKH26x/9jQ/+Iw/QgASAHgSu2AJIdOG4sRmbO2odCBiae 4LaMyT06UUP9dCXcmGFoHHqXmIJ9lfaDeqXxNAQ4ORfbbkaW9j5ckv5I9iXGsnRTwaMn Bsl2DoYQK4aJfWNcdWc7NMHLEwos21hGxY3Ql4HFhwMAtMZF/Aj8rH51UbjNptZtNiax NKVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Pkh94rmAODO+BCS2Hgmxux6A8faNEqj9+a2S7d0nXOY=; b=GG41Ly6lwLFdKgEio66qY+KSLeIgqPT+19nzIs+07z/3fzOxenwFD1jor3VVYrWKtp RQJ9F0ag9IYp3vFJjWBWDF7bHDYtrc405J9pxtMb4oNkVltJV0e3B7fiNwcBhiHCjjj2 D58wB4J032/VcJvmq+VOzAwgC8KfH3hVor0s+gGVPenxPZ+VlCnLwAMvkMUhNS0b5gLy e3e4eOeXtT5BEgtTQxxgOLinSNWIdMYaYoili8zTqXbbMtSkXLsE9F0nmnxpWruwK94G 7MAM6VNnPheiWBcMvpQJsYXuX9VrbCEYLBiyQCkRsVf/fG/s/3S/UqwIe9wBF+ilKXMw +bNQ==
X-Gm-Message-State: ACrzQf3uBb8Fp4/ERoAdm69OjUygkm+ZM0LOFKxGC150zg3XRQmDNubQ NX7OKDbUjbDYJMsRjILszHQ5bXgF4TwUWGsaqui3yq5fSTM=
X-Google-Smtp-Source: AMsMyM53vBh0jY/ZcVUbdTj0ScwivBWqdx7/5pn4UvjRK9gelN8b/lMVLvCJCkLXyBcaIxhTHQWIw5w37yMy5V/xWYo=
X-Received: by 2002:a67:f790:0:b0:398:6ab2:800 with SMTP id j16-20020a67f790000000b003986ab20800mr15709417vso.44.1664382472953; Wed, 28 Sep 2022 09:27:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoBwcokG5OEpgyxDMwoQ=eCvGCWtnu8ZBZWxdJqTCoWoeQ@mail.gmail.com> <88FDCAC8-68A4-4209-A5ED-CDC1F3ECAE0F@apple.com>
In-Reply-To: <88FDCAC8-68A4-4209-A5ED-CDC1F3ECAE0F@apple.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 28 Sep 2022 12:27:41 -0400
Message-ID: <CAHbrMsBT-9MFz+bw_Xdp6EYb0B8JR5q5WjTKFkMQ8Oh-JfgEGQ@mail.gmail.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: Joseph Salowey <joe@salowey.net>, privacy-pass@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000018040305e9bf3ea9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/6I_3sJaAQr3lJYxuaE2qglSf4FE>
Subject: Re: [Privacy-pass] Call for Adoption of Key Consistency and Discovery Draft
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: Wed, 28 Sep 2022 16:28:34 -0000

As a PRIVACYPASS chair:

The PRIVACYPASS chairs discussed the question of venue with the OHAI
chairs, and settled on running the adoption call in PRIVACYPASS.  This was
motivated in part by a sense of how busy the two groups are, and in part by
a reading of the charters that placed this topic more clearly in-scope for
PRIVACYPASS.

As an individual in PRIVACYPASS (and author of the DoubleCheck draft):

draft-wood-key-consistency-03 has added a section discussing the
architecture that is instantiated in DoubleCheck.  While I would like to
make some small adjustments to the description, I think those can be
addressed later if the document is adopted.  I would not want to merge the
two drafts, because I feel that draft-wood-key-consistency is rightly an
Informational draft describing potential architectures (usable by standards
developers and creators of closed systems), whereas DoubleCheck is a
proposal for a fully specified interoperable protocol, which could be
spoken among independent parties without any prior arrangement.  Protocols
could similarly be defined for the other architectures in
draft-wood-key-consistency if the IETF deems it necessary.

On Mon, Sep 26, 2022 at 4:49 PM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> wrote:

> I think this is useful work, and important discussion to have in this
> working group. To that end, I support adoption.
>
> I have a bit of a broad question as to the specific venue for the work,
> since the document explicitly has relevance for PRIVACYPASS and OHAI (and
> could apply to other protocols). If we do this here, we would of course
> want cross-group discussion. Is there a rationale for one or the other? I
> also note that draft-schwartz-ohai-consistency-doublecheck is targeted at
> OHAI, and it really seems like these efforts should be in the same place.
> I’m also of the opinion that the double-checking technique could be merged
> into draft-wood-key-consistency overall.
>
> Thanks,
> Tommy
>
> On Sep 18, 2022, at 12:42 PM, Joseph Salowey <joe@salowey.net> wrote:
>
> This is a call for adoption of the Key Consistency and Discovery Draft -
> draft-wood-key-consistency-03 [1]. Please respond to the list and indicate
> if you think the PrivacyPass working group should adopt this work or not.
> Also please indicate if you are willing to contribute text or review the
> document. The call will end on October 6, 2022.
>
> Thanks,
>
> Ben and Joe
> [1] https://datatracker.ietf.org/doc/draft-wood-key-consistency/
> --
> Privacy-pass mailing list
> Privacy-pass@ietf.org
> https://www.ietf.org/mailman/listinfo/privacy-pass
>
>
> --
> Privacy-pass mailing list
> Privacy-pass@ietf.org
> https://www.ietf.org/mailman/listinfo/privacy-pass
>