From prachi.jain1288@gmail.com Thu Nov 30 10:51:09 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 7D932C14F75F for ; Thu, 30 Nov 2023 10:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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] 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 HdsvP8dLFFts for ; Thu, 30 Nov 2023 10:51:08 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 C8418C14F74A for ; Thu, 30 Nov 2023 10:51:08 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-50bc21821a1so1803804e87.0 for ; Thu, 30 Nov 2023 10:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701370267; x=1701975067; 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=sKG+hEXmWjQqLf+eVwmbD463aVAg4YwSZ2OaN4ib5Vw=; b=CsFdtuqX+TuvZw3GhqlG9NqzSH9+2bZrPvpdqrLQ11nqlj/0WMVgXvuhF+q4XDOOhY zk9ezB8hz0lR846575HyCuY+MNBGaCmA7C6f7WOaYfyGPieTl5v9upJz1nEtu8524DBe d/pilZvA0uLvufWm9dDy8Mf4GIa4kztmPdYguazBxAfjJus+eo/dE38/qgbVs4Vlz54e eCZMj9PTTLG6AQXQmy4EuM0HqUsPJz/j3vBQAonnCGMqdtAwvJSdDAOaCzeWtvUdKIYR YvTcvoh2bsgzns86+iuSESE5dSdGeek2OPt5bMZ47gOgct8wTwdZwicYwnTc8UNBqDRb tgQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701370267; x=1701975067; 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=sKG+hEXmWjQqLf+eVwmbD463aVAg4YwSZ2OaN4ib5Vw=; b=Vnx5NeFBchvrOAhp1Xs9zjJqNdM23M4lsQlEMgubZTqHLsZzvOy8iserxKwRiq1ge4 2kQYhDNxaYxgXTq2zC4D3VSKYUOOijTCYBP380pkrRROjA+a+OXD5KSI2DAJyD0pftsT sQtZ3zla+hzY2GTpEfRY1de2xnTJg4xlUkIX1F2li0hGjblxKK0vcIj4cKGwTNGLs1E5 WV/pXiDKSEnG+3xOCICYXkuah2cWXW0soxnjPTbZVhUzbWIu9PmJpYBWGj4FH6iyHU4H XuWOZkdPQH1bkRpuSa05kAKqR6BscJLbsgfQjcMx1GVfnYy43lFoDGIMDI1mhUweFtO+ 1lhQ== X-Gm-Message-State: AOJu0Ywt9HR1W95Jjw5GIU4bIvlhqjKyQpkXzEzK7KSC8rX9jFZdv7ly 0L6kJqkQezG0TFS9NgFm9eSNc4Fm3inc3TZ3nWIoX7ej X-Google-Smtp-Source: AGHT+IEoJBLmXtp+Y7mJMcGXMZRmmXUU9Y06q78H2rgFf2znkr/D9qXjrmobgatD4UogHgS/6fCI5MF7hX038AhTTqk= X-Received: by 2002:a2e:2e0b:0:b0:2c9:d872:abd6 with SMTP id u11-20020a2e2e0b000000b002c9d872abd6mr9984lju.84.1701369040072; Thu, 30 Nov 2023 10:30:40 -0800 (PST) MIME-Version: 1.0 References: <866c814027bb35ad96524dd451eaa837d3318a61.camel@sunet.se> <6e11be7cac39b5f6907d4255fe09e2c8113a1a4c.camel@sunet.se> In-Reply-To: <6e11be7cac39b5f6907d4255fe09e2c8113a1a4c.camel@sunet.se> From: Prachi Jain Date: Thu, 30 Nov 2023 12:30:28 -0600 Message-ID: To: Leif Johansson Cc: Eric Rescorla , tigress@ietf.org Content-Type: multipart/alternative; boundary="00000000000043f322060b62d98e" 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: Thu, 30 Nov 2023 18:51:09 -0000 --00000000000043f322060b62d98e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable WG, Chairs would like to hear from more of you. Please reply to this email with any feedback you have. -Prachi On Wed, Nov 29, 2023 at 3:14=E2=80=AFAM Leif Johansson wro= te: > On Tue, 2023-11-28 at 20:27 -0800, Eric Rescorla wrote: > > > > > > On Thu, Nov 23, 2023 at 6:01=E2=80=AFAM Leif Johansson > > 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 > > > > > > > > > This seems fine. And I think we should identity that consensus sooner > > rather than later. > > > > > > > 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 don't understand what this means and I'm not sure that it will > > work. > > Depending on what assumptions you make about the system it may > > or may not be possible to address this problem independently. > > > > I am merely trying to reflect what was said in the room at 118. > > Several folks expressed an interest in trying to find mitigation for > *some* situations where you want to use an invitation channel that > doesn't fulfil security requirements. > > This I hope also answers Yogesh question: The assumption that the > invitation channel is secure only means that if you want to use some > channel that doesn't fulfil the security assumptions, you need to add > protection either to the message layer or to the channel itself (eg > adding TLS). > > Point (2) in our consensus summary just means that the chairs heard > that some folks expressed an interest to work on certain solutions for > adding security independently from the protocol itself. This may or may > not be relevant work for TIGRESS. > > Cheers Leif > > > -Ekr > > > > > > > > > > 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 > --00000000000043f322060b62d98e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
WG,=C2=A0
Chairs would like to hear from more of you. P= lease reply to this email with any feedback you have.=C2=A0

-Prachi<= /div>
O= n Wed, Nov 29, 2023 at 3:14=E2=80=AFAM Leif Johansson <leifj@sunet.se> wrote:
On Tue, 2023-11-28 at 20:27 -0800, Eric Re= scorla wrote:
>
>
> On Thu, Nov 23, 2023 at 6:01=E2=80=AFAM Leif Johansson <leifj@sunet.se>
> wrote:
> >
> > Folks,
> >
> > The chairs have conferred and we recognize the following consensu= s:
> >
> > 1. assume that the invite channel is secure and adjust proposals<= br> > > accordingly - at some point we need to identify what (if any)
> > consensus
> > exists within the WG to pursue a solution
> >
>
>
> This seems fine. And I think we should identity that consensus sooner<= br> > rather than later.
> =C2=A0
>
> > 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 don't understand what this means and I'm not sure that it wi= ll
> work.
> Depending on what assumptions you make about the system it may
> or may not be possible to address this problem independently.
>

I am merely trying to reflect what was said in the room at 118.

Several folks expressed an interest in trying to find mitigation for
*some* situations where you want to use an invitation channel that
doesn't fulfil security requirements.

This I hope also answers Yogesh question: The assumption that the
invitation channel is secure only means that if you want to use some
channel that doesn't fulfil the security assumptions, you need to add protection either to the message layer or to the channel itself (eg
adding TLS).=C2=A0

Point (2) in our consensus summary just means that the chairs heard
that some folks expressed an interest to work on certain solutions for
adding security independently from the protocol itself. This may or may
not be relevant work for TIGRESS.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

> -Ekr
>
> =C2=A0
> >
> > 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 Best R
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif & Prachi
> >

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