Re: Analysis of version negotiation

Kazuho Oku <> Wed, 21 April 2021 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78C753A1E92 for <>; Wed, 21 Apr 2021 03:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZMWLPeKMLIyY for <>; Wed, 21 Apr 2021 03:12:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B20D3A1E90 for <>; Wed, 21 Apr 2021 03:12:32 -0700 (PDT)
Received: by with SMTP id e7so48578893edu.10 for <>; Wed, 21 Apr 2021 03:12:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dlbiM0xwUSaFpZELGmPoNEKlSMBYi2AQUjAegxB0GJ0=; b=gSuYSFqQAIKnSpJbIAPu3xLmUUiK8VoAQ/BqxEzqPh1Myl4xrTJ2nbWeh1KWppz7Oc Hg6YK9/I7to0iBtDAHi4OmHo17zTubffXXO9l+4O38AhAo55oWTs6GnQJ5S32gsOyxiQ EyZg7zhwrGkg4Fmq7YMnxwnaQQXzMBhTioQXl6xNwJHsVbHpAZ/A/lz0vyD3vzVsrelC dNrJfOrq9TpQP7hpn3suc467zOp313GG1a0mA+Uv+a9Y85JvrohXkv354pAUYnOorLq8 NnEGXbdczYpRzRlPuCMCokncxV1EOGEI7mh/odOYoXUzjgyJr5t7AHkifaL40+CiEC4+ noWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dlbiM0xwUSaFpZELGmPoNEKlSMBYi2AQUjAegxB0GJ0=; b=W7fd/pd+zo0vH0u7xr1PUjTpB5PzEdlNfya23VlHeObYShXCf9pqPnbejcVERWQY9C sQJt7/teYTRQBy7VyBtw5P78RToiUyfy6FNSguBkZ72rRRjjQrC91moPivZQjsXuUOYE YMZOCb3gGQ+Gva19POEfakwXedYi7YlH+uqaxdh5bT3UNw0l/KYx6NuLOZVX4ZfSZ+Ft b888pbaysuFe9S4MJqdmmOakp5bUHb/+22PSGraySrEGE4PiyLZhOSxIKygdufjMS9+C cq6sIRYLX9Xb/jCiUc7pqNlD6oub7TfgZuKoxpPqzWt7GjH46kzUsDymnXz6LZngDTKt KRWg==
X-Gm-Message-State: AOAM533WIMER7+xhSTDBc8dVS7gspqH4WcWcliafQ2nm3T6Trjn7O/Ln Iufueklq4O7MNHtBiVIuASQsz/hZ0jpo0D0Y6e04Ue9ZS5w=
X-Google-Smtp-Source: ABdhPJxOBH4w2CHKMDNzTBtelxDwdT+i+JBz87uhxUs8wpgVCGSOkYqvVjOiik5ZSC0+a8XTbntel4vyFVFGMELsKEA=
X-Received: by 2002:a05:6402:1c84:: with SMTP id cy4mr25273452edb.260.1618999950325; Wed, 21 Apr 2021 03:12:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Kazuho Oku <>
Date: Wed, 21 Apr 2021 19:12:19 +0900
Message-ID: <>
Subject: Re: Analysis of version negotiation
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000ee3b5105c078cc5f"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Apr 2021 10:12:38 -0000

2021年4月21日(水) 16:38 Martin Thomson <>:

> Hey folks,
> I spent a few minutes and updated this document.  Part of that involved
> removing another field (the most tricky one).
> The resulting protocol can be very simple in the end:
> A simple transport parameter is needed for each endpoint with a list of
> values:
>   the client sends all compatible versions, with its chosen version listed
> first
>   the server sends all versions (optionally excluding compatible versions,
> and always excluding versions that aren't fully deployed at the server)
> Validation/negotiation is:
>   the server verifies that the first version listed by the client is the
> version that was used by the client
>   the server then chooses its most-preferred compatible version from the
> set provided by the client
>   the client verifies that it wouldn't have chosen something different
> from the set provided by server
> This is at least as simple as the design Christian describes.  I believe
> that the analysis supports the conclusion that this is secure (but it's
> amateur work so it's not worth much).
> What I find encouraging is that this design is very flexible in terms of
> being able to support both compatible and incompatible negotiation while
> allowing progressive rollout (or rollback) of new versions.  That might
> mean we don't have to sacrifice flexibility or use cases at all.

Hi Martin,

Thank you for your analysis.

While I’m not sure if I understand your design, I assume you are correct to
point out that there would be a simple, flexible model that supports both
compatible and non-compatible version negotiation. IMO, it’s about how much
we can reduce from a simple model, that requires each endpoint to
retransmit / verify all information that it has previously exchanged.

That said, I’m not sure if that means that we can support both compatible
and no-compatible version negotiation without extra cost.

That’s because in case of compatible version negotiation, all the message
sent by peer is implicitly validated by the TLS handshake transcript.
There’s no necessity to require QUIC stacks to detect MITM attacks. In
contrast, incompatible version negotiation involves VN packet that is not
covered by the TLS handshake transcript, therefore, at least the server is
required to explicitly validate what it has sent in VN.

The other point is the moment when the version changes.

In case of compatible version negotiation, depending on the design, it
could happen during the handshake then be retroactively verified when the
handshake concludes, or could happen when the endpoints start sending /
receiving 1-RTT packets. But regardless, it is going to happen

Whereas in case of non-compatible version negotiation, switch between the
versions happen _before_ the transport machinery and the TLS handshake

To summarize, how and when things can be verified is different between
compatible and non-compatible version negotiation. And therefore I’m afraid
that supporting both would cost us more than just supporting one.

I prefer choosing just one. And regarding which, as I’ve stated in my other
mail, I’m not sure if there’s much value in supporting compatible version
negotiation [1]. I prefer doing minimal things. Therefore, I’m inclined to
say that we might just design non-compatible version negotiation and call
it done (assuming that we have to, IIRC that was the sense of the room when
we were designing V1), or not do anything at all if there’s no need for
non-compatible version negotiation.


> On Wed, Mar 24, 2021, at 14:25, Martin Thomson wrote:
> > Hey everyone,
> >
> >
> is my crude attempt at an analysis of the security of the version
> negotiation draft, including some suggestions that might make the protocol
> more efficient.
> >
> > I will you reach your own conclusion, but I found some cuts that can be
> > made in the design.  Not as many as I expected originally though.  I
> > did just realize that an entire component can come out, but I haven't
> > edited it out yet; I'll leave that in case others disagree with my
> > assessment there.
> >
> > It's long and complicated, sadly.  That's the one thing that I might
> > regret most about the decision to defer solving this problem properly
> > in the first place.  In any case, I hope that this is a useful
> > contribution to the discussion.
> >
> > Cheers,
> > Martin

Kazuho Oku