From ykarandikar@apple.com Mon Nov 27 14:04:42 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 665BCC15152B for ; Mon, 27 Nov 2023 14:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=apple.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 2754zevGitye for ; Mon, 27 Nov 2023 14:04:38 -0800 (PST) Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) (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 84B9DC15108F for ; Mon, 27 Nov 2023 14:04:38 -0800 (PST) Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma-mailsvcp-mx-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S4S00UQHYNMJR10@ma-mailsvcp-mx-lapp02.apple.com> for tigress@ietf.org; Mon, 27 Nov 2023 14:04:37 -0800 (PST) X-Proofpoint-GUID: 6oc3eEcpDJQr7Q3S0720JTiW4eYBx0UI X-Proofpoint-ORIG-GUID: 6oc3eEcpDJQr7Q3S0720JTiW4eYBx0UI X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.987 definitions=2023-11-27_19:2023-11-27, 2023-11-27 signatures=0 X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 bulkscore=0 suspectscore=0 malwarescore=0 adultscore=0 spamscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311270153 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=j26h2/+RrQLj1Q4Vwelh++DV3P68qHtiALdN6fR772Q=; b=IRwP6QKf7dY1LKrcuM5Axzin5k/e7m9fEPOSchPWcNnN1BWEQA1lssEki/vBPahe1PYo fiop56asVy44Gt7K/UVIMZaWbTSLoOPEhyJXbmnD1KMl3oXb7/856uV6RJe3QABu6hjX fMlqstbXXi09p5SIdEDmZWIN4m6fDSGibvBUSbEPssDoXvSVr886rSLyiaHk0h/jnQgm LuNkQ+uc+MAcDvZlyusaR3mqFZbwCPBj5UNXPD9xM/3+aAGpNPE0f3B+5ln6n/kJtFbt 4x9QWKsBmUgEqQ4DSkSj1+t5iNL20/GgeDfBuzmZtpta7sJIu5aENR5jEWNwv71VE/dd jQ== Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S4S00QVPYNMUN50@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 27 Nov 2023 14:04:34 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S4S00N00YGXYJ00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 27 Nov 2023 14:04:34 -0800 (PST) X-Va-A: X-Va-T-CD: 5a79c165eae7bca3e214413a625caeec X-Va-E-CD: 60e4ac9ef907b233e025adc6af3950b8 X-Va-R-CD: 64f3965d4ce02af6bc89898784174812 X-Va-ID: d98bebfb-b895-49c2-9aa4-a24112f3a8a4 X-Va-CD: 0 X-V-A: X-V-T-CD: 5a79c165eae7bca3e214413a625caeec X-V-E-CD: 60e4ac9ef907b233e025adc6af3950b8 X-V-R-CD: 64f3965d4ce02af6bc89898784174812 X-V-ID: e1f92fe4-e663-4ea8-9fac-ce7a0bda833d X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.987 definitions=2023-11-27_19:2023-11-27, 2023-11-27 signatures=0 Received: from smtpclient.apple ([17.11.39.155]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S4S00V3PYNLR300@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 27 Nov 2023 14:04:34 -0800 (PST) From: Yogesh Karandikar Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_04A52D7C-B0D6-4DED-865C-EBEC3C93E0D6" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Date: Mon, 27 Nov 2023 14:04:23 -0800 In-reply-to: Cc: Leif Johansson , tigress@ietf.org To: Watson Ladd References: <866c814027bb35ad96524dd451eaa837d3318a61.camel@sunet.se> X-Mailer: Apple Mail (2.3774.200.91.1.1) 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:04:42 -0000 --Apple-Mail=_04A52D7C-B0D6-4DED-865C-EBEC3C93E0D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Replies inline. Thanks, Yogesh > On Nov 27, 2023, at 10:35=E2=80=AFAM, Watson Ladd = wrote: >=20 > On Thu, Nov 23, 2023 at 9:01=E2=80=AFAM Leif Johansson > wrote: >>=20 >>=20 >> Folks, >>=20 >> The chairs have conferred and we recognize the following consensus: >>=20 >> 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 >=20 I thought the orthogonal option (#3) in the poll meant:=20 3.1 assume the invite channel can be non-secure and proceed with a = solution.=20 3.2 Orthogonal work to add security on top of a non-secure channel = (second-factor or other methods). =20 If we assume invite_channel to be secure (option #1 in the poll), I=E2=80=99= m not sure why orthogonal work would be required.=20 > 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 = the recipient selected by share initiator=E2=80=9D.=20 Hence non_secure would mean that someone else besides the selected = recipient has access to the invitation. >=20 >>=20 >> 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. >=20 > I suspect that orthogonality is tricky to actually achieve here. >>=20 >> Please respond with your support and/or disagreement. If you disagree >> please provide whatever insights you are able to. >>=20 >> Also please indicate your willingness to eventually implement and/or >> support the results of (1) and (2). >>=20 >> Best R >> Leif & Prachi >>=20 >> -- >> Tigress mailing list >> Tigress@ietf.org >> https://www.ietf.org/mailman/listinfo/tigress >=20 >=20 >=20 > --=20 > Astra mortemque praestare gradatim >=20 > --=20 > Tigress mailing list > Tigress@ietf.org > https://www.ietf.org/mailman/listinfo/tigress --Apple-Mail=_04A52D7C-B0D6-4DED-865C-EBEC3C93E0D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Replies =  inline.


Thanks,
Yogesh

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

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


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 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 the 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.

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<= br>



-- 
Astra mortemque praestare = gradatim

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

= --Apple-Mail=_04A52D7C-B0D6-4DED-865C-EBEC3C93E0D6--