Subject: Re: QUIC ossification

From: Martin Duke <[email-masked]>
Date: Fri, 1 Mar 2019 22:21:25 -0800

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 <[email-masked]> 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" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     2019年2月24日(日) 8:37 Jana Iyengar <[email-masked]>:
>     >
>     > On Sat, Feb 23, 2019 at 10:21 AM Martin Thomson <[email-masked]>
> 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
>
>
>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 4 Mar 2019 10:27:51 +0100

Hi all,

please see below.

> Am 02.03.2019 um 07:21 schrieb Martin Duke <[email-masked]>:
> 
> 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

> 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?
> 
> 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" <[email-masked] on behalf of [email-masked]> wrote:
> 
>     > On Sat, Feb 23, 2019 at 10:21 AM Martin Thomson <[email-masked]> wrote:
>     >>
>     >>
>     >> > Martin, you seem uncharacteristically restrained today. How about, "If
>     >> > it is not encrypted, middle boxes will ossify, and pathetic efforts at
>     >> 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.
>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 4 Mar 2019 19:01:32 +0000

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 <[email-masked]> On Behalf Of Martin Duke
Sent: Friday, March 1, 2019 10:21 PM
To: Roberto Peon <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: QUIC ossification

On Mon, Feb 25, 2019 at 10:27 AM Roberto Peon <[email-masked]<mailto:[email-masked]>> 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.

-=R

On 2/23/19, 5:27 PM, "QUIC on behalf of Kazuho Oku" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    2019年2月24日(日) 8:37 Jana Iyengar <[email-masked]<mailto:[email-masked]>>:
    >
    > On Sat, Feb 23, 2019 at 10:21 AM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
    >>
    >>

    --
    Kazuho Oku

---

From: Martin Duke <[email-masked]>
Date: Mon, 4 Mar 2019 14:58:32 -0800

Posted Issue #2496 on this subject:
https://github.com/quicwg/base-drafts/issues/2496

On Mon, Mar 4, 2019 at 11:01 AM Mike Bishop <[email-masked]> wrote:

> 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 <[email-masked]> *On Behalf Of * Martin Duke
> *Sent:* Friday, March 1, 2019 10:21 PM
> *To:* Roberto Peon <[email-masked]>
> *Cc:* Jana Iyengar <[email-masked]>; QUIC WG <[email-masked]>; Martin
> Thomson <[email-masked]>; Kazuho Oku <[email-masked]>
> *Subject:* Re: QUIC ossification
>
>
>
> unfortunate experience, so much as the fact that TLS 1..3 pretends it's TLS
> 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