Re: [Tigress] post-118 direction

In the context of Tigress, secure invite_channel implies the following:

1. The {invitation} goes from initiator (A) to selected Recipient (B) with integrity protection.
2. {invitation} only goes to B and no one else has access to it while it’s in flight. 

That means only end-to-end encrypted channels can be considered secure. Channels like email or sms have well known design flaws and should be considered as non-secure.

In building a Tigress solution, we are not restricting the invitation channel to only end-to-end encrypted channels. We want to allow existing channels like email, sms.

As far as I can recall, in 118  the orthogonal option was introduced as an alternative to the not-secure. I align with the idea to acknowledge that not all invite_channels are secure.  

Our path forward should be with base assumption that invite_channel is not-secure. 

It would be good if more members send their opinions here.

There were fair amount of people at the mic who voiced against making base assumption that invite channels are secure.

Thanks,
Yogesh

> On Nov 30, 2023, at 10:30 AM, Prachi Jain <prachi.jain1288@gmail.com> wrote:
> 
> 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 AM Leif Johansson <leifj@sunet.se <mailto:leifj@sunet.se>> wrote:
>> On Tue, 2023-11-28 at 20:27 -0800, Eric Rescorla wrote:
>> > 
>> > 
>> > On Thu, Nov 23, 2023 at 6:01 AM Leif Johansson <leifj@sunet.se <mailto: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
>> > > 
>> > 
>> > 
>> > 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 <mailto:Tigress@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tigress
> -- 
> Tigress mailing list
> Tigress@ietf.org
> https://www.ietf.org/mailman/listinfo/tigress