Re: QUIC ossification

["Martin Thomson" <[e-mail]>]

Leaving the specifics of the proposal aside for the moment, the problem here is that we have no shared context AND we want to ensure that legitimate endpoints don't have to go to extreme measures to get the information they need.  A little obfuscation might get us somewhere (esp. if we are willing to burn either more octets or part of our existing space), but let's try to focus on what we think we're going to achieve by doing something here.

Funny that TLS are concurrently talking about hiding the existence of ESNI, which has so many of the same constraints: you have to standardize the semantics so that it can be decoded, but you would rather that only the intended recipient was able to read it.  In both cases, the answer is that you lose because you have no shared keys that would enable the only thing that we know works (crypto).  (I haven't ingested Stephen's long email there, maybe he has a brilliant idea for breaking the deadlock, but I doubt that it will help us here, because at least with ESNI you *maybe* have a key and it seems to be using crypto.)

On Fri, Feb 22, 2019, at 13:35, Roberto Peon wrote:
>  
> This would be “fun” (i.e. somewhat hard) to attempt to match via simple 
> filtering rules :
>  When expressed in-the-clear, version is expressed as two var-ints, 
> which are summed and modulo 2^16
> 
>  
> i.e.
>  version = (decodeVarInt() + decodeVarInt()) % (1 << 16) 
>  -=R
> 
>  
>  
> 
>  
>  
> *From: *Erik Kline <[e-mail]>
>  *Reply-To: *"[e-mail]" <[e-mail]>
>  *Date: *Thursday, February 21, 2019 at 10:02 PM
>  *To: *Jana Iyengar <[e-mail]>
>  *Cc: *"Brian Trammell (IETF)" <[e-mail]>, QUIC WG 
> <[e-mail]>, Roberto Peon <[e-mail]>, Martin Thomson 
> <[e-mail]>
>  *Subject: *Re: QUIC ossification
> 
>  
>  
>  
>  
> 
>  
>  
>  
>  
>  
> 
>  
>  
>  
> 
>  
>  
>  
> On Thu, 21 Feb 2019 at 20:24, Jana Iyengar <[e-mail]> wrote:
> 
>  
>   
> >  
> > Brian, 
> 
> >  
> >  
> >  
> 
> >  
> >  
> >  
> > I agree that there are potentially other models as well, but the one we know from experience is the naive one. We should at least protect against the one model we know, naive or not. I'll note that it quickly gets difficult to come up with measures if we assume a smarter ossifier.
> 
> >  
> >  
> >   
>  
>  
> 
>  
>  
>  
> You would pretty much have to move version negotiation bits (and 
> subsequent protocol differences) to underneath the crypto umbrella, 
> wouldn't you? Negotiating a newer version would have to be like 
> negotiating some extensions, or something, I would think...
> 
>  
>  
>  
>  
> 
>  
>   
> >  
> >  
> > - jana
> 
> >  
> >  
> >  
> >  
> 
> >  
> >  
> >  
> > On Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) <[e-mail]> wrote:
> 
> >  
> >   
> >> (oops, hit send too soon...)
> >>  
> >>  > On 20 Feb 2019, at 07:58, Brian Trammell (IETF) <[e-mail]> wrote:
> >>  > 
> >>  > hi Jana,
> >>  > 
> >>  > The middlebox adaptation model that this proposal addresses seems limited to middleboxes built based on naive traffic analysis and pre-QUIC assumptions about wire images. This is admittedly the model behind one of Google's experiences with QUIC middlebox breakage, and the one we seem most concerned with because by definition we cannot fix it by writing things in documents.
> >>  
> >>  I don't think these are the only things we're concerned about though. Concerns about partitioning VN space have a less naive model in mind: here we think more about default-deny firewalls that have been told that some versions of QUIC are okay but all others are not. As noted before I personally cannot think of a reason an operator would want to do this -- if you've already decided to allow a protocol with low observability and built-in extensibility as a design goal on your network, does the exact flavor really matter all that much? -- but it's a checkbox on the firewall feature list so yeah, I suppose someone will ship it.
> >>  
> >>  Are there other middlebox adaptation models we are concerned about here?
> >>  
> >>  Cheers,
> >>  
> >>  Brian
> >>  
> >>  
> >>  >> On 20 Feb 2019, at 00:17, Jana Iyengar <[e-mail]> wrote:
> >>  >> 
> >>  >> Roberto -- yes, that's basically what I'm proposing too, just one variant of how to go about doing it dynamically over time.
> >>  >> 
> >>  >> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon <[e-mail]> wrote:
> >>  >> As others have intimated in some form or another, you can also use multiple numbers to express “version 1”.
> >>  >> 
> >>  >> 
> >>  >> For instance, pick 64 (or some similar constant) random numbers, and call them all version 1.
> >>  >> -=R
> >>  >> 
> >>  >> 
> >>  >> 
> >>  >> From: QUIC <[e-mail]> on behalf of Jana Iyengar <[e-mail]>
> >>  >> Date: Tuesday, February 19, 2019 at 3:10 PM
> >>  >> To: Martin Thomson <[e-mail]>
> >>  >> Cc: QUIC WG <[e-mail]>
> >>  >> Subject: Re: QUIC ossification
> >>  >> 
> >>  >> 
> >>  >> 
> >>  >> On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <[e-mail]> wrote: 
> >>  >> 
> >>  >> I don't think that there is much value in using two version numbers to refer to the same protocol. But even if we did, as long as we didn't establish any pattern in doing so, that couldn't be used against us. So I might tentatively agree that 0x1 == 0x2 would be inadvisable, there is no strong need to do anything special with the first version. Any attempt to profile QUIC will be done with full knowledge of the version number we pick, so randomness doesn't serve any real purpose. Subsequent versions might need to use a randomized value, but we can make that decision then.
> >>  >> 
> >>  >> 
> >>  >> 
> >>  >> I figured that making all version assignments random instead of special-casing 0x1 made it simpler to reason about and uniform to code for, but I actually don't care about the IANA assignment for v1 for the reason you note. v1 will be one specific bit-pattern on the wire to start of with, and that can just as well be 0x1. It still does segregate the space, but we can't do anything about it anyways - it'll be 0x1 or some other random number getting special treatment.
> >>  >> 
> >>  >> 
> >>  >> 
> >>  >> The problem of course being that as long as v1 remains, we might find places that no other version does. The QUIC "magic number" will be whatever we pick, and we can't prevent someone from fixating on that.. We'll convince those people in the same way they will be convinced to open up UDP for QUIC version 1: by making a QUIC version 2 worth enabling.
> >>  >> 
> >>  >> 
> >>  >> 
> >>  >> That was the entire point of having alternate and preferred versions to 0x1. If we have downgrade protection in place, and if there are those who try alternate version numbers for v1, that gives us what we need at the endpoints. I believe that there would be interest at some major vendors to do this at some endpoints. Presumably, we can convince Google to do something, since it has been bit by mbox ossification in the past. I am operating on the premise that we have buy in from a few major providers.
> >>  >> 
> >>  >> 
> >>  >> 
> >>  >> IANA is for me a publication venue where these alternate versions are published and other clients/servers interested in keeping the ecosystem from ossifying can use these alternate versions as well.
> >>  >> 
> >>  >> 
> >>  >> 
> >>  >> I completely get the don't segregate thing. But to - I think - Mikkel's point about experimentation without permission, I do think that squatting is a perfectly sound approach in a space this big. TLS people do it in a much smaller space. As long squatters pick random values, they do so infrequently, and they get IANA registrations for codepoints relatively soon afterwards, the risk of collision is low. Randomness here is useful - but primarily as a collision-avoidance technique. The TLS extension codepoint 26 is a great example of why. Keeping the bar on registrations low (FCFS is a reasonable policy) would also have the effect of making the pool of apparent versions larger, which might be more effective than any other strategy we might employ.
> >>  >> 
> >>  >> 
> >>  >> 
> >>  >> I'm totally fine with experimentation without permission, and using random to avoid collision. My point was entirely about using alternate on-wire version numbers for v1. Nothing here about new or experimental versions.
> >>  >> 
> >>  >> 
> >>  >> 
> >>  > 
> 
> >>   
> >   
>  
>  
>