From lassey@google.com Mon Nov 27 14:10:43 2023 Return-Path: X-Original-To: tigress@ietfa.amsl.com Delivered-To: tigress@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E68C15108F for ; Mon, 27 Nov 2023 14:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.606 X-Spam-Level: X-Spam-Status: No, score=-17.606 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, 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, 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 Z_9y1JJE7nKp for ; Mon, 27 Nov 2023 14:10:41 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 0C1E0C14CEFA for ; Mon, 27 Nov 2023 14:10:41 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a013d22effcso649497566b.2 for ; Mon, 27 Nov 2023 14:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701123039; x=1701727839; 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=qu1HNzHTcV4Epn0pkssB0hdLFHycJH3M4lNProRNaRU=; b=VRF3MYgKry7lpWk7//6f6LrsC7E662WqeFNxsVLDMyCjbd6sEEAyz6Zu19zSbDQjD6 sXzND7Ry0Q2W+xf0vCf9pNUUanKntu5YjwziGOWQTEVqg/zWzhSfCU9mYD2B6zB457z8 Z/WKVatZcinjCOmsiOmVS04PKwyVmRPn3XkRDaacSv1Tu4UYo51KHHF/CPwbtgu9ivfT CzYI+8tR4mPDuVPitnntDQa2iVsDiIzkNXs0z9WkedYWj0XCoXjJCif3tczHE22akzQO CSRCUXbGXOqGLNpX23fiBu6jE+NngkgY+OuPL2dWRuPYC0gEYDiXcBSZuuyOxO7wkq4W Df8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701123039; x=1701727839; 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=qu1HNzHTcV4Epn0pkssB0hdLFHycJH3M4lNProRNaRU=; b=prUGRQdO+iChwbfpsVJO1EIXIK0R7FPj0BKSW1XUntjbE+yBUfP2jcDWtBEiaXfnGo PldRU1S9FLDr08ziVZgtp8OQYwpryfQAlG5ZB8YzbtIIG/5xE2zATwMxhCrnP1IBRtGC 3rS+lMOiyMxhyGkCVdRkVOk9lVPV19PtAZPj/uVYewVJbF4e/TO5UYPXFPbfFbDLrLtl WJDUSrm8193MUO8aqO7Ni8die5gEvbt2zDRds5sa5pxrLZZhvTqu4O2fxpobsxYjQBAe R89cgoojH4FuBlJ8P6+ZGuL+lYhwOaXm/JVYGBcUpXqDvYkuxPAw4dtJJywchoZB201S 5+LQ== X-Gm-Message-State: AOJu0YxsGHqlD05t6zVl6pSEysiQot9ncq+LmcnaakhAEyDnNqcnRmrU 6raERgo45SlHLiJwmhgWoQjE/QQocZlPqzBQ8tbKyw== X-Google-Smtp-Source: AGHT+IHNq+HdqhRIsundjmDauzNKAddmLix8MNSj1d7ACT+XKFZ7EG5tkqxegR/F7HQ6W9uQ1BX7Ml+AeAzIF33I3FU= X-Received: by 2002:a17:906:f8c8:b0:a0d:6afc:56ff with SMTP id lh8-20020a170906f8c800b00a0d6afc56ffmr4936547ejb.34.1701123039027; Mon, 27 Nov 2023 14:10:39 -0800 (PST) MIME-Version: 1.0 References: <866c814027bb35ad96524dd451eaa837d3318a61.camel@sunet.se> In-Reply-To: From: Brad Lassey Date: Mon, 27 Nov 2023 17:09:56 -0500 Message-ID: To: Yogesh Karandikar Cc: Watson Ladd , Leif Johansson , tigress@ietf.org Content-Type: multipart/alternative; boundary="0000000000007665ac060b29925a" Archived-At: Subject: Re: [Tigress] post-118 direction X-BeenThere: tigress@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Transfer dIGital cREdentialS Securely List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2023 22:10:43 -0000 --0000000000007665ac060b29925a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 27, 2023 at 5:04=E2=80=AFPM Yogesh Karandikar wrote: > Replies inline. > > > Thanks, > Yogesh > > On Nov 27, 2023, at 10:35=E2=80=AFAM, Watson Ladd = wrote: > > On Thu, Nov 23, 2023 at 9:01=E2=80=AFAM Leif Johansson w= rote: > > > > Folks, > > The chairs have conferred and we recognize the following consensus: > > 1. assume that the invite channel is secure and adjust proposals > accordingly - at some point we need to identify what (if any) consensus > exists within the WG to pursue a solution > > I agree with this direction. > > > I thought the orthogonal option (#3) in the poll meant: > > 3.1 assume the invite channel can be *non-secure* and proceed with a > solution. > > 3.2 Orthogonal work to add security on top of a non-secure channel > (second-factor or other methods). > > > If we assume invite_channel to be secure (option #1 in the poll), I=E2=80= =99m not > sure why orthogonal work would be required. > > > What's the meaning of secure here? I think based on what EKR and > others have said on the list this makes sense to pursue first as most > channels being proposed are secure in the relevant sense > > > In this context, secure =3D=3D =E2=80=9Cinvitation is delivered to only t= he recipient > selected by share initiator=E2=80=9D. > > Hence non_secure would mean that someone else besides the selected > recipient has access to the invitation. > > > > 2. address invitation channels that are not fully secure in a way that > is orthogonal to the solutions the WG decides to pursue for the core > protocol. > > This, I suspect, would be a useful work item that could be pursued outsid= e of this working group as it is generally applicable and I don't think is covered by our charter and I don't think it would be the best use of resources to narrowly tailor such a solution to the tigress use case. > > I suspect that orthogonality is tricky to actually achieve here. > > > Please respond with your support and/or disagreement. If you disagree > please provide whatever insights you are able to. > > Also please indicate your willingness to eventually implement and/or > support the results of (1) and (2). > > Best R > Leif & Prachi > > -- > Tigress mailing list > Tigress@ietf.org > https://www.ietf.org/mailman/listinfo/tigress > > > > > -- > Astra mortemque praestare gradatim > > -- > Tigress mailing list > Tigress@ietf.org > https://www.ietf.org/mailman/listinfo/tigress > > > -- > Tigress mailing list > Tigress@ietf.org > https://www.ietf.org/mailman/listinfo/tigress > --0000000000007665ac060b29925a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 27, 2023 at 5:04=E2=80=AFPM Yogesh Kara= ndikar <ykarandikar=3D40ap= ple.com@dmarc.ietf.org> wrote:
Rep= lies =C2=A0inline.


Thanks,
Yoge= sh

On Nov 27, 2023, at 10:35=E2=80=AFAM, Watson L= add <watsonbl= add@gmail.com> wrote:

On Thu, Nov 23, 2023 at 9:01=E2=80=AFAM Leif Johansson <leifj@sunet.se> wrote:


Folks,

The chairs have co= nferred and we recognize the following consensus:

1. assume that the= invite channel is secure and adjust proposals
accordingly - at some poi= nt we need to identify what (if any) consensus
exists within the WG to p= ursue a solution
I agree with this direction.=C2=A0=C2=A0
=

<= /div>

I thought the orthogonal option (#3) in th= e poll meant:=C2=A0

3.1 assume the invite channel = can be non-secure and proceed with a solution.=C2=A0

<= /div>
3.2 Orthogonal work to add security on top of a non-secure channe= l (second-factor or other methods). =C2=A0


If we assume invite_channel to be secure (option #1 in the poll), I= =E2=80=99m not sure why orthogonal work would be required.=C2=A0
=

What's the meaning of secure here? I think based on= what EKR and
others have said on the list this makes sense to pursue first as mos= t
chann= els being proposed =C2=A0are secure in the relevant sense

In this context, secure =3D=3D = =E2=80=9Cinvitation is delivered to only the recipient selected by share in= itiator=E2=80=9D.=C2=A0

Hence non_secure would mea= n that someone else besides the selected recipient has access to the invita= tion.



2. address invitation channe= ls that are not fully secure in a way that
is orthogonal to the solution= s the WG decides to pursue for the core
protocol.
=
This, I suspect, would be = a useful work item that could be pursued outside of this working group as i= t is generally applicable and I don't think is covered by our charter a= nd I don't think it would be the best use of resources to narrowly tail= or such a solution to the tigress use case.

I suspect that orthogonality is tricky to= actually achieve here.

Please respond with your support and/or disagreement. If you= disagree
please provide whatever insights you are able to.

Also = please indicate your willingness to eventually implement and/or
support = the results of (1) and (2).

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Best R
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Leif & Prachi
--
Tigress mailing list
Tigress@ietf.org
https://www.ietf.org/mailman/listinf= o/tigress



--=C2=A0<= /span>
Astra m= ortemque praestare gradatim

--=C2=A0
Tigress mailing list
Tigress= @ietf.org
https://www.ietf.org/mailman/listinfo/tigress

--
Tigress mailing list
Tigress@ietf.org<= br> https://www.ietf.org/mailman/listinfo/tigress
--0000000000007665ac060b29925a--