IETF Logo Mail Archive

Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)

Lingmo Zhu <zlm2006@gmail.com> Mon, 19 February 2018 02:10 UTC

Return-Path: <zlm2006@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 0D827127076 for <quic@ietfa.amsl.com>; Sun, 18 Feb 2018 18:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 2h8nPuZU9UKF for <quic@ietfa.amsl.com>; Sun, 18 Feb 2018 18:10:47 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 52967126FDC for <quic@ietf.org>; Sun, 18 Feb 2018 18:10:47 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id j24so640911pff.12 for <quic@ietf.org>; Sun, 18 Feb 2018 18:10:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sYaQq025cKswDc6N/ODTI7c3ctJzNIKquiqZKKT4QSE=; b=fFuKzhzKlXctDc983q8v7zMfgVypOPcKhChPtKlIhtMXBsvVPj/EMelFG5UzF0TDED xnsv9NdH/R1XPIwuZS6LwoxkxeKe1lGTpEdUgQjVfGwCEdJwgX61csDEhuA3fZBZsEdB 6AqTAkZTjJGQ7rGElkuhueqt1fnMDDspG+6xXtvV4Al8yJL9m4SDhOagrNM9CkFEABVF ipEdUbktQ65Gf3ox6KFBSg4xJke8cq5Llgkz/MJeIRPKjpgdsG/15uO6wqe20qt2/e15 LrjUqrSS0CEAF8ZyhUAog272ku49V8HSX01woG0odgnGnT+WVFY3i4i13XJC+cTzMtQd 5QSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sYaQq025cKswDc6N/ODTI7c3ctJzNIKquiqZKKT4QSE=; b=OXf3jvxTuIUeieXTNTLhJaHlgnU5W02Cia7qUzzBi9D8MQH8TypTY2jKU58ho39NuV 2jkQULvfWcRrsGtJxsvRRlRqrvAtZCtCl+O2GdQSgzVSn775FdaCZNMyDepa/3o/QVih q2SWKJcv2Ap5k7G2lDXADmGrlDeC7DWBDykvpztVbUlMQcdSXtcXiO7f2t5oIXbIMcGO Pq/z1JjS3F9GGaOabsVqqXdKIgUb4+mkCwcISaF5zH4/VAhBmwkZiKbwCMOpAGkWwkbh 3yc7zVMkjPmr+xYwtu3Tt9rkY5Li49aolNMscVN6cOeuCcp9ni9s4EenTkPH/zqmMX4V 8ekA==
X-Gm-Message-State: APf1xPD7/Ri/sFJ97eS5HVIpqCCM64LlGwKhpGJvWPEF1SyHBqmHyvze tBcJ0jcRsA9iwUCdvnxTowQ=
X-Google-Smtp-Source: AH8x2266+ivbwtF2TkiGO8H4o0IsC+AER7yaNJJXiu11IGbGXE1bIuWbSWWs7Uq0j/FvZVgHvvvWeA==
X-Received: by 10.101.82.198 with SMTP id z6mr2684597pgp.41.1519006246645; Sun, 18 Feb 2018 18:10:46 -0800 (PST)
Received: from Justins-MacBook-Pro.local (ik1-330-25108.vs.sakura.ne.jp. [153.126.188.112]) by smtp.gmail.com with ESMTPSA id 64sm24976691pgj.39.2018.02.18.18.10.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 18:10:46 -0800 (PST)
Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)
To: Eric Rescorla <ekr@rtfm.com>
Cc: Kazuho Oku <kazuhooku@gmail.com>, alexandre.ferrieux@orange.com, Christian Huitema <huitema@huitema.net>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "quic@ietf.org" <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <CABkgnnVRn+1sNZQFB8BZc4VyzN5usLmYJ3xLo+p2uTeW_0Ji_Q@mail.gmail.com> <CAN1APdfpJ0rYPPiOgfcdDRx3noh+YYvJatP0MYTqRRXMBwF6pA@mail.gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <CANatvzzZEuJ3TY=+0BMLqbBE5mScG_Jnrypg3xkciykOX78G8A@mail.gmail.com> <CAN1APdfov8Q3E+5NkT5pmMeU=eB=fsnDFe_=BK7TDE0TpXD3yA@mail.gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <CANatvzz_2BeRns5E-OO=CKKwK66LgMd=3vVCM84_+OAxj8CutQ@mail.gmail.com> <d3c8688a-3f01-30b1-a3de-1300a43c1d99@gmail.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> <CABcZeBOHgM1xnvmx=CWEEeLnU9bO3DuFCYzbk6m2Kg=sxbYZYA@mail.gmail.com>
From: Lingmo Zhu <zlm2006@gmail.com>
Message-ID: <efc46f51-41ff-f69c-d627-f6d585013b1e@gmail.com>
Date: Mon, 19 Feb 2018 10:10:40 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBOHgM1xnvmx=CWEEeLnU9bO3DuFCYzbk6m2Kg=sxbYZYA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/0ceqeqHLOkLPNOaQu58gyHRM6v4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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, 19 Feb 2018 02:10:48 -0000


On 2018/02/19 1:25, Eric Rescorla wrote:
> 
> 
> On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <zlm2006@gmail.com 
> <mailto:zlm2006@gmail.com>> wrote:
> 
>     Hi all
> 
>     After some discussion with Kazuho and thanks to his help, I want to
>     propose that for Version Negotiation handling, "a client MAY wait for a
>     handshake packet after receiving a Version Negotiation packet".
> 
> 
> Can you describe the precise attack you are concerned about? The VN packet
> contains the client's randomly chosen CID, so only an on-path attacker can
> forge a VN, but such an attacker can also generate a bogus ServerHello or
> other messages that would cause the QUIC negotiation to fail.
> 
> -Ekr
> 
> 

It's an attack that generates VN packets with no acceptable version, on 
path. Of course such an attacker can generate other messages to 
interfere QUIC but utilizing VN packets needs no knowledge other than 
CID and no encryption, or only CID needs to be changed from a template. 
If other cleartext packet with wrong or no AEAD encryption described for 
the TLS handshake would be just ignored, those other messages should at 
least be encrypted, which costs much more and more complex to be 
implemented.

Lingmo Zhu

v2.23.0 | Report a Bug | By Email