IETF Logo Mail Archive

Re: QUIC Version Negotiation Extension

David Schinazi <dschinazi.ietf@gmail.com> Mon, 04 November 2019 22:45 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC291207FC for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 14:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_kLlZRAigpo for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 14:45:49 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9177E12022E for <quic@ietf.org>; Mon, 4 Nov 2019 14:45:48 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id j5so13514835lfh.10 for <quic@ietf.org>; Mon, 04 Nov 2019 14:45:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CAPDSy+4wrhqejh9k8=G7W267EgcT5Z2sDK7ZBGKtNn5kkbXGfg@mail.gmail.com> <CAN1APdcZv-MtwRT77++r6EKdzJUc1NKEJfY4CZeOSaK50nPZYg@mail.gmail.com> <CAPDSy+5obMbiLDKYKXXg1ZthoMqyg60KD+6HR69CQqiEHb6W7g@mail.gmail.com> <aa6be7bc-e4c3-e14f-8064-f511e8fbfb70@huitema.net>
In-Reply-To: <aa6be7bc-e4c3-e14f-8064-f511e8fbfb70@huitema.net>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 04 Nov 2019 14:45:35 -0800
Message-ID: <CAPDSy+6rW=rr7R_0Qa_41t3cAe9D-ctzz60Au-jO0-Er1mr5Yg@mail.gmail.com>
Subject: Re: QUIC Version Negotiation Extension
To: Christian Huitema <huitema@huitema.net>
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, QUIC <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000095ed6505968d134c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eyglPdgO0otIUWFc-zRsGD-dyW4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 22:45:55 -0000

On Mon, Nov 4, 2019 at 2:33 PM Christian Huitema <huitema@huitema.net>
wrote:

> - 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.

v2.23.0 | Report a Bug | By Email