RE: QUIC ossification

[Mike Bishop <[e-mail]>]

As Roberto said, that’s a threat model question.  I wouldn’t call that “obfuscation”; it’s simply ossification.  TLS 1.3 was able to observe that middleboxes were looking at the (second) version field, and decided to abandon it and create a third version field.  Eventually, something will be updated to look at that field, and some future version of TLS will quite possibly require a fourth version field while retaining the first, second, and third as fixed values for all time.

This brings to mind Raymond Chen’s articles about the layers of undocumented regkeys that can’t be modified because someone took a dependency; so they create a new one, and then someone takes a dependency on that; and so forth with a new iteration in each release of Windows.

From: QUIC <[e-mail]> On Behalf Of Martin Duke
Sent: Friday, March 1, 2019 10:21 PM
To: Roberto Peon <[e-mail]>
Cc: Jana Iyengar <[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>; Kazuho Oku <[e-mail]>
Subject: Re: QUIC ossification

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..

On Mon, Feb 25, 2019 at 10:27 AM Roberto Peon <[e-mail]<mailto:[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]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

    2019年2月24日(日) 8:37 Jana Iyengar <[e-mail]<mailto:[e-mail]>>:
    >
    > On Sat, Feb 23, 2019 at 10:21 AM Martin Thomson <[e-mail]<mailto:[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