Re: [Taps] How to handle Protocol stacks that are not equivalent

> On 23. Jul 2019, at 17:56, Max Franke <mfranke@inet.tu-berlin.de> wrote:
> 
> Good point, I guess this might be true for other things as well. 
> Take SCTP for example, you might not know if it is multistream or not until after it has already been raced and the association has been established. 
> So for some transport properties you might have to race protocols before you can determine if two protocol stacks are equivalent or not. 

No! - That is exactly the reason why we need to clarify that “equivalent” actually means “satisfies requires/prohibits set by the application/profile” – that means setting all to ignore will make all protocols equivalent!

> 
> Best 
> Max
> 
> Am 23.07.2019 17:30 schrieb Theresa Enghardt <theresa@inet.tu-berlin.de>:
> Hi, (trimmed Cc list)
> 
> On 23.07.19 16:53, Anna Brunström wrote:
> Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent
> 
>  
> Yes, that's correct. My interpretation is that being in the candidate set already requires equivalence.
> 
>  
> Same here, seems we all agree on this.
> 
> Agreed.
> 
> However, the equivalence question becomes way more interesting once you're adding security.
> 
> TLS 1.2 is not equivalent to TLS 1.3, therefore you can't race them, the Architecture clearly says so and I agree. 
> 
> As the application probably never asked for any specific version -- What if our TCP stack only supports TLS 1.2 but our QUIC stack offers basically TLS 1.3? We always take the better version and then fall back in case this fails? But wouldn't that be racing?
> 
> I think this is also an interesting question for the Implementation draft.
> 
> Best,
> Theresa
> 
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/