Subject: Re: [Tigress] post-118 direction

From: Leif Johansson <[email-masked]>
Date: Wed, 29 Nov 2023 10:14:32 +0100

On Tue, 2023-11-28 at 20:27 -0800, Eric Rescorla wrote:
> 
> 
> On Thu, Nov 23, 2023 at 6:01 AM Leif Johansson <[email-masked]>
> 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
> >