Re: QUIC ossification

[Mirja Kühlewind <[e-mail]>]

Hi all,

please see below.

> Am 02.03.2019 um 07:21 schrieb Martin Duke <[e-mail]>:
> 
> When starting this thread, I wasn't thinking so much about Jana's unfortunate experience, so much as the fact that TLS 1..3 pretends it's TLS 1.2. I don't know the details of that process, but wonder if there's something the TLS designers might have done differently. The idea of a "security" device rejecting TLS versions that presumably provide more security is even more perverse than blocking future QUIC versions.
> 
> Interestingly, a little obfuscation (hiding TLS version later in the hello) seems to have solved this problem. So I think there's a case that obfuscation isn't worthless. The logical end of the "obfuscation is worthless" case is that we should just get rid of the version field and design something buried in the TPs or something..
> 
I think this only worked because the ossification was already deployed and there it was „easy“ to design a work-around to a known problem.If you design something with such a hack in the first place it will however ossify around that approach.

Coming back to a point Jana made earlier, I think keeping version numbers dynamic is a good thing to do and I don’t think we need encryption for this. Best would be to deploy multiple versions at once. The only question from my side is how big of a time span „at once“ can be. I'm actually (at least a bit) optimistic that we could publish another version of quic relatively soon, if we concentrate on a small change only. However, others might call me naive…

Mirja




> On Mon, Feb 25, 2019 at 10:27 AM Roberto Peon <[e-mail]> wrote:
> You'd certainly get agreement that the only way to prevent things from reacting/recognizing to something is to make it unrecognizable as that something.
> 
> So, in the long-term we want some combination of encryption (bytes unrecognizable) and pattern/timing obfuscation. I'm sure we'd all be happy if we could have this tomorrow and thus apply to V1, but it seems unlikely.
> 
> If that is true, then for V1 the question is what potentially imperfect thing could we do that gives us the breathing room to get to V2, which could/should have the more perfect and more robust (likely encryption-based) solution?
> 
> The answer to that depends on our shared understanding of the threat model.
> 
> My understanding is that we're worried about accidental pattern-matching based "threats"-- i.e. protecting against assumptions that a particular range of bits in a particular place indicate the presence of QUIC.
> 
> -=R
> 
> On 2/23/19, 5:27 PM, "QUIC on behalf of Kazuho Oku" <[e-mail] on behalf of [e-mail]> wrote:
> 
>     2019年2月24日(日) 8:37 Jana Iyengar <[e-mail]>:
>     >
>     > On Sat, Feb 23, 2019 at 10:21 AM Martin Thomson <[e-mail]> wrote:
>     >>
>     >>
>     >> On Fri, Feb 22, 2019, at 19:03, Christian Huitema wrote:
>     >> >
>     >> > Martin, you seem uncharacteristically restrained today. How about, "If
>     >> > it is not encrypted, middle boxes will ossify, and pathetic efforts at
>     >> > obfuscation are not going to save you?"
>     >>
>     >> That is what I typed first... Maybe if we all agree on this point,  we can move on.
>     >
>     >
>     > I've seen and worked through one ossification case with QUIC so far, I can say that making versions dynamic in any way would have helped us. This is after talking to the middlebox vendor, and understanding their process.
>     >
>     > I think I've made my case -- that there's value in making the on-the-wire version more dynamic. If there is a proposal to encrypt version number, I'm all ears. This conversation is premised on not having encryption to save us. Without a proposal that encrypts version numbers, it does not make sense to say that encryption is the only solution.
>     >
>     > It is counter-productive to argue that nothing should be done in any situation when encryption is not available as a solution.
> 
>     Yeah. And IIUC encryption cannot be a solution for QUIC v1.
> 
>     To be precise, encryption can be a solution for QUIC v1 only when we
>     can assume that ESNI (or something other that allows the endpoints to
>     negotiate shared knowledge) gets deployed along with QUIC v1 by a
>     significant portion of the endpoints.
> 
>     I'd be very happy to see that happen, but I am skeptical if it would.
> 
>     -- 
>     Kazuho Oku
> 
> 
>