Re: [MLS] [Keytrans] Charter for KEYTRANS
Kevin Lewi <klewi@cs.stanford.edu> Thu, 08 June 2023 01:05 UTC
Return-Path: <klewi@cs.stanford.edu>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CAEC1519A5; Wed, 7 Jun 2023 18:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.193
X-Spam-Level:
X-Spam-Status: No, score=-4.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 oyXA86uVeVMY; Wed, 7 Jun 2023 18:05:34 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.stanford.edu [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A38C14CF1C; Wed, 7 Jun 2023 18:05:33 -0700 (PDT)
Received: from mail-lj1-f179.google.com ([209.85.208.179]:45389) by smtp2.cs.Stanford.EDU with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <klewi@cs.stanford.edu>) id 1q745k-000888-Q7; Wed, 07 Jun 2023 18:05:33 -0700
Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2b1b72dc2feso67124681fa.3; Wed, 07 Jun 2023 18:05:32 -0700 (PDT)
X-Gm-Message-State: AC+VfDyimHvmAV2QrUo+tpbRVjZaU+HrAjAgMUJDGke3WodJBdjL8H90 A64RNW6K9lwNk/GnJ1Ca6rwfHq0wWGA21kNZTfc=
X-Google-Smtp-Source: ACHHUZ6PrT06LvR8lL1iFo5ZZ+VxOIjgEUQLW7AMwm4TWEAKT2/Zm/dEQmi9EkT80YEsO0MMo/zRFGCKLgKKoySU5cA=
X-Received: by 2002:a2e:855a:0:b0:2b0:2976:1726 with SMTP id u26-20020a2e855a000000b002b029761726mr3221828ljj.10.1686186331523; Wed, 07 Jun 2023 18:05:31 -0700 (PDT)
MIME-Version: 1.0
References: <960d9858aa334c51a1392644a2059699@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <CABcZeBNbvezx5hP39+APhrRJqdCSwvhPO3nUF_ThpdD81y2Arw@mail.gmail.com> <CABcZeBORBu54+rqBsQXptc56dtk1cV_702-64nPZ=PbF_GecZQ@mail.gmail.com>
In-Reply-To: <CABcZeBORBu54+rqBsQXptc56dtk1cV_702-64nPZ=PbF_GecZQ@mail.gmail.com>
From: Kevin Lewi <klewi@cs.stanford.edu>
Date: Wed, 07 Jun 2023 18:05:20 -0700
X-Gmail-Original-Message-ID: <CACitvs964Z9U=9WPGsUncOzN2DNTq8uXFOYxQFiapFqzqvLFDA@mail.gmail.com>
Message-ID: <CACitvs964Z9U=9WPGsUncOzN2DNTq8uXFOYxQFiapFqzqvLFDA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Roman Danyliw <rdd@cert.org>, keytrans@ietf.org, "mls@ietf.org" <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000050d00305fd93d9a1"
X-Scan-Signature: 0bbd9715bed71a189373455fad6c9eb1
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/yiHqtCylrNVG7Ta2WNvt7VwXpLQ>
Subject: Re: [MLS] [Keytrans] Charter for KEYTRANS
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jun 2023 01:05:37 -0000
I am in agreement with ekr's comments here, especially: > This group should confine itself to providing transparency for the identity->key bindings. You can always recharter later once that's done. I believe this will not only remove some confusion echoed in the above replies, but also help us to focus on something we can concretely build, with less risk of overpromising and underdelivering. And I am also supportive of the change in wording from "authenticating" to something like "providing public verifiability", since authenticating is likely to involve other components of an e2ee system that keytrans should (in my opinion) not try to address. Otherwise, the charter looks good to me! Kevin On Wed, Jun 7, 2023 at 3:42 PM Eric Rescorla <ekr@rtfm.com> wrote: > Replying with keytrans in the CC list > > On Wed, Jun 7, 2023 at 3:39 PM Eric Rescorla <ekr@rtfm.com> wrote: > >> Document: charter-ietf-keytrans-00-01.txt >> >> I share a number of Richard's concerns about the level of >> generality of this proposed charter. >> >> I'm not sure that "authentication mechanism" is the term that I would >> use here. Specifically, it seems likely that people will want to >> deploy CT-like models in which there is a separate directory which >> actually provides authentication and then a transparency mechanism >> that is provided separately. I recognize that some ways of deploying >> KT also are usable as authentication, but that's not the only way to >> do things. The word I would use here is "public verifiability" >> of the consensus data. >> >> I concur with Richard that going from transparency about key >> bindings to transparency about bindings and group state >> is a huge scope expansion, and I think an unwise one. MLS already >> provides a measure of consistency for group state and I think >> This group should confine itself to providing transparency >> for the identity->key bindings. You can always recharter later >> once that's done. >> >> The KEYTRANS working group will develop a standard for >> authenticating information about artifacts in an end-to-end >> encrypted messaging system with the above properties. >> >> As above, I don't think the right word here is "authenticating >> information" but rather "public verifiability". >> >> I would also strike the language here about end-to-end >> encrypted messaging systems. While it's true that that's >> the motivating case, if the system is cognizant of that >> then something has gone wrong. >> >> These comments would also entail some changes later in the charter, >> but it's probably more helpful to discuss them in only one place, >> so I'll stop here. >> >> -Ekr >> >> >> >> On Tue, May 23, 2023 at 12:18 PM Roman Danyliw <rdd@cert.org> wrote: >> >>> Hi! >>> >>> Since the KEYTRANS BoF at IETF 116 ( >>> https://datatracker.ietf.org/meeting/116/session/keytrans) there has >>> been follow-up discussion on crafting a charter. Since KEYTRANS is >>> targeting a similar audience as MLS and is proposing an artifact to >>> integrate with MLS, I'm sharing it here for visibility and review here. >>> >>> Current version of the KEYTRANS charter text >>> >>> https://docs.google.com/document/d/12NMFA0P1OYtE6_QoqP3J80tDr0z2-FEm2ZdiWeauAHE/edit >>> >>> Multiple threads of discussion >>> -- initial charter >>> >>> https://mailarchive.ietf.org/arch/msg/keytrans/6VIEM87-TNe1OYXZRUyAwJX_1vo/ >>> >>> -- AD review of charter >>> >>> https://mailarchive.ietf.org/arch/msg/keytrans/GfDMvADn5ZgdR7ZfTZt2y296Nuo/ >>> >>> While posting here, please bring any feedback to the keytrans@ietf >>> mailing list. >>> >>> Regards, >>> Roman >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> -- > Keytrans mailing list > Keytrans@ietf.org > https://www.ietf.org/mailman/listinfo/keytrans >
- [MLS] Charter for KEYTRANS Roman Danyliw
- Re: [MLS] Charter for KEYTRANS Eric Rescorla
- Re: [MLS] Charter for KEYTRANS Eric Rescorla
- Re: [MLS] [Keytrans] Charter for KEYTRANS Kevin Lewi