Re: QUIC Version Negotiation Extension

David Schinazi <> Mon, 04 November 2019 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EC291207FC for <>; Mon, 4 Nov 2019 14:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4_kLlZRAigpo for <>; Mon, 4 Nov 2019 14:45:49 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9177E12022E for <>; Mon, 4 Nov 2019 14:45:48 -0800 (PST)
Received: by with SMTP id j5so13514835lfh.10 for <>; Mon, 04 Nov 2019 14:45:48 -0800 (PST)
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=mu4rdKK2D25XV4Y79uMK1+yTAAuBlifVvw9S5klDuHg=; b=Ej8wAqbxfrwXYXiEfkOMKoOZoYiJFF20gtbFTU4dcFYOPL6UnPlOjEvrJbnp6TEUP9 SyaYElDxaCYKf/LZn6WlH4x2wyzht3tXCEcjFEtgFUJ4GSy+W7O1K8XeFl7iH+PQ55p3 L54oS2z8VkJ+wiFhhUSs4nd8n84faaxBqez/5freTcfBpTJzPHpkFkCwbL0YS4qn0Q8F SUdpyAjukJCXE9IUV+YUhxPwoE/uhu6wS9E9oUNUF8zdX5r134prfwKkg/P402UU3QPD dxh7pQG3JVj7j2xCVhvpRkH/fX0YNY6R0QFTbEhcRn0hfpQbrDMcKHBkQzox/fioIvEZ rObA==
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=mu4rdKK2D25XV4Y79uMK1+yTAAuBlifVvw9S5klDuHg=; b=hNoKivlhcG9Up7Pnf/vN6e3jetako7WD3z28fOS5HzoKPdDtPy0j2SO2In3eZspJuE 3WrwDreBbcFYQlXDqxH4eFRY1o6VO7PmhkWTUv8WywQx9Oj8MqSoipuQq3k8g6ajX84p xakMIbkTC7eOLBryqvhIubWKip8n8CXLeW6jyS4xtYKE2D4dvkGBuP/X2ITDgIr+SiuF 96TFq7+zX4Sfsh0pxewTRf3JsFvN3QwknQhlIFuLReOazQw3iDGeE+cfrv4bIAO2aJ+0 cByMGTkfKBCEDKxvWsKlnHDZfmDpI3YIXOTy8fCI+6kEzUByv4p2di2jr0GXeJFCVBKG cplA==
X-Gm-Message-State: APjAAAUZzng32HcFI4zDrw2AiPKH/XUsBl3BW/46hDwWX13DPYxzth6c TogRkyqsvLlrJexfJwSK3dgOgRr565dkIgGSaAQ=
X-Google-Smtp-Source: APXvYqyyQTbGp/xqcu56q6VXWkUwnoQ8/2gV/Z/SJw5siFLadTywPc4MPugFXoQIFJGZtF6D2r1OgyxY9DoyoMXPJP8=
X-Received: by 2002:a19:3f0a:: with SMTP id m10mr18775116lfa.67.1572907546699; Mon, 04 Nov 2019 14:45:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Mon, 4 Nov 2019 14:45:35 -0800
Message-ID: <>
Subject: Re: QUIC Version Negotiation Extension
To: Christian Huitema <>
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>, QUIC <>
Content-Type: multipart/alternative; boundary="00000000000095ed6505968d134c"
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: Mon, 04 Nov 2019 22:45:55 -0000

On Mon, Nov 4, 2019 at 2:33 PM Christian Huitema <>;

> - VERSION_NEGOTIATION_ERROR vs drop - I’m not sure it is a good idea to
>> close the connection. The initials are public so it is possible to inject
>> false versions. There are probably many other similar attacks we don’t
>> bother with, but still …
> Once we're this far in the handshake, we cannot recover from this error.
> Dropping the packet will only make things worse..
> Can we think about that some more?
> It is true that there are many ways to wreck a connection if the attacker
> can freely tweak bits in the client hello. There is no need to mess with
> transport parameters -- just changing the value of the client Random will
> do that. The server will create a connection context and send a reply, but
> the client won't compute the proper handshake key and the connection will
> fail.
> An attacker on path can kill all packets and close the connection, but an
> attacker on the side can only inject "magic" packets. The VN could become
> one such magic packet. Can the man on the side send the VN quickly, so the
> client sends a "VN inspired" client hello? What would it take to ensure
> that the connection is robust against such attacks?
While I agree it would be nice to prevent these attacks, I don't think it's
an achievable goal in QUICv1 at this point. The injection-only attacker can
already break the connection by sending a forged ServerHello, Version
Negotiation doesn't really change that. I'm not coming up with an easy way
to remove this issue.