Re: Version Ossification: Intended Scope for QUICv1

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

Why can't servers just bake the "keys" into binaries?  I mean, that's not something that is likely to get lost.  And it isn't really the case that keys need to be secret, they just have to change often enough to frustrate attempts to fixate on them.

On Sat, Nov 2, 2019, at 03:13, Mike Bishop wrote:
>  
> The fundamental problem in all this is what happens when a server is no 
> longer in possession of the mapping it sent to the client. One option 
> is to say that servers simply MUST persist this, and if they don’t, 
> handshakes will fail – we tried that with HSTS, and we found that 
> servers don’t like things that can leave the site broken. I don’t think 
> that’s a good path. Either it will break things, or servers won’t use 
> this mechanism, or more likely both in sequence.
> 
> 
> The next obvious solution, sending a VN packet telling the client to 
> come back to v1 and the spec-defined salt, contains a simple version 
> downgrade attack by a middlebox. There are possible mitigations – the 
> client could continue presenting the token, meaning the server would be 
> able to tell whether a downgrade “actually happened” or not. (I.e. 
> whether it could still have parsed the version associated with the 
> token) If the downgrade was illegitimate, that could be communicated. 
> However, that likely means figuring out QUIC’s own version negotiation 
> story and downgrade mitigation and just using that.
> 
> 
> We could also try to build something like ESNI’s recovery path, where 
> the information includes what has to be demonstrated for a recovery 
> value. The trouble is that, while TLS can transfer a certificate and 
> rely on PKI as that recovery path, we’re in a little bit more uncharted 
> territory. The only ready solution I see in this space is some kind of 
> longer-lived keypair that the server is somehow “less likely” to lose, 
> but if you can persist that key, you can probably also persist the 
> original configuration. (Plus, you don’t want to be doing asymmetric 
> crypto before you’ve even decided whether to process the handshake.)
> 
> 
> I remain a little uncomfortable that we entirely punted our version 
> negotiation story from v1, and I think the cleanest solution is to 
> bring it back in support of #3166. However, that has both schedule and 
> security implications – we don’t want to get this part wrong.
> 
> 
> *From:* QUIC <[e-mail]> *On Behalf Of * Kazuho Oku
> *Sent:* Thursday, October 31, 2019 5:34 PM
> *To:* David Schinazi <[e-mail]>
> *Cc:* QUIC <[e-mail]>
> *Subject:* Re: Version Ossification: Intended Scope for QUICv1
> 
> 
> Hi David,
> 
> 
> Thank you for summarizing the high-level options. I think it's very 
> useful to have this discussion.
> 
> 
> Please see my comments below.
> 
> 
> 2019年11月1日(金) 6:13 David Schinazi <[e-mail]>:
> 
> > Hi folks,
> 
> 
> > The conversation around version ossification has been really interesting since Cupertino. But at least for me it's reached a level of complexity that warrants taking a step back and looking at what we're trying to solve. Here's my understanding of where we are:
> 
> 
> > 1) In Cupertino there was consensus in the room to do something to mitigate ossification of QUICv1.
> 
> 
> > 2) The solution that folks liked was to have a concept of alternative versions and alternative salts that act like QUICv1 but are encoded differently over the wire.
> 
> 
> > 3) A concrete proposal for (2) was for servers to have their own set of (alternative_version, alternative_salt) pairs, then transmit a random pair from that set to each client (i.e. via transport parameters). The server can then reconstruct the alternative_salt just by seeing the alternative_version.
> 
> 
> > 4) Kazuho proposed a solution (#3166 <https://github.com/quicwg/base-drafts/pull/3166>) that was both more powerful and more complex: tie the (alternative_version, alternative_salt) pair to NEW_TOKEN frames, to allow servers to generate a unique alternative_salt per client and encode it in the token.
> 
> 
> I dispute the argument that #3166 is more complex. My view is that 
> #3166 is more powerful and simpler than (3) (the PR being #2573).
> 
> 
> Reasons:
> 
> * For a server associating one initial salt with one alternative 
> version, #3166 and #2573 are identical with the exception being how the 
> information is carryied (i.e. TP vs. NEW_TOKEN).
> 
> * For a client, bundling the alternative seeds in a NEW_TOKEN makes 
> things simpler, as clients are not required to have a new state that 
> has to be retained across multiple connections.
> 
> 
> 
> > 5) After some interesting back and forth on that PR, it became clear that this is a hard problem to solve: this could cause failures if servers forget their token keys, and mitigations for that problem can become downgrade attack vectors
> 
> 
> The proposal for 3 has this problem. It leads to a failure when a 
> server forgets the alternative initial salts.
> 
> 
> 
> > 6) While there was clear WG appetite for (1), I'm not sure we have consensus to build a more powerful solution like (4)
> 
> 
> > I fear that solving (5) could take some time, which would delay QUICv1. Instead I'd like to propose the following plan:
> 
> > a) we take the simpler solution (3) and add that to the spec
> 
> > b) we take the more powerful/complex solution (5) a turn it into a QUIC extension
> 
> 
> > That would allow us to ship QUICv1 with some level of ossification mitigations without delay.
> 
> 
> As stated, the proposed solution for (4) is simpler than (3), can be 
> used to implement (3), and also provides a stronger protection for 
> servers certain that they can retain the token unprotection keys.
> 
> 
> I agree that solving (5) for all parties might be hard, and that we 
> might want to punt that to v2. But, I think we should adopt (4) than 
> (3) due to the aforementioned reasons.
> 
> 
> 
> > Thoughts?
> 
> 
> > David
> 
> 
> 
> 
> 
> 
> -- 
> 
> Kazuho Oku
>