Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)
Lingmo Zhu <zlm2006@gmail.com> Sun, 18 February 2018 15:48 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 0A984126C0F for <quic@ietfa.amsl.com>; Sun, 18 Feb 2018 07:48:29 -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 8bNhJqQKrnDm for <quic@ietfa.amsl.com>; Sun, 18 Feb 2018 07:48:27 -0800 (PST)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 B11C8126B6E for <quic@ietf.org>; Sun, 18 Feb 2018 07:48:27 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id i3so1229493pfe.5 for <quic@ietf.org>; Sun, 18 Feb 2018 07:48:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=q7YdlC3VcC2joKXGwruBrKq5o9qtHfBYJalw8l1dqi8=; b=tAkicdDY+tawJz/d85CrOQ8F12azeessXTrLXoRdl9fK7shrTHMjYt1xrU+0tRUiRC +sVY77XtUZ74d5OFVlQkh3z+IPa0iQThMbOGrx7JwpW2ACfC3K79i22ZZw5qzGcmrKhI 2dP+1RnizojY4xpjEQJeACnWlbusLCq0whQhyZOxJCH2tTme5nfaYgKSvF/BvrW6ZWw8 7VXhPjJIyMQg8Mam38Hih2qx7BWHGLxmCSWSTrPyNaqtq33aJR34j4cTAvNTQSnjnZEc CGjP+/Mx8CO/KAJ1ikfkLaaKNlswwaPmlKww2W7SGj01MoPbqPlMymSPzG+MY7CLUufQ J5Pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q7YdlC3VcC2joKXGwruBrKq5o9qtHfBYJalw8l1dqi8=; b=ZE+KDIJ8NL+3uuz1wu9KApqSIZmGhBgIW7brfIYsGpHusWsj94IH4A7ihFFWdPSz3t z0gHx6WN3DYxqxR3JxFkKuLP4IRDrVBZ0nIsqcPYvlkqffiHG9vYgkLxV9sXAmEFIbLr a4CCgpmi7z+Yu+5y17mTuHdTDof461Vs8xOfp1kuyl4AZRdWMgcbOxd3NuihxsBVkR6L TUa3EXWOQgQtujGAx0twRxICkfru95Agb8exPRzICytQNc2xq3fpWpUqFKuw2fHazvvk PuBq7907FtPl52Q2ijWpJLAoCp6GzpVFYZNcMkYmGw4Ecn9mmqe+J207dCBx1QSdEpFZ appw==
X-Gm-Message-State: APf1xPArtfWfO9wc0NxNqIo7g7gBlvDvz1xsaUW+WMYdG332YZoYxqF7 psaC6TQZixv1aRk6bAT+1sk=
X-Google-Smtp-Source: AH8x226ZIxAa63uobg3vFTJWs8YyADIlfdtavSpIiO1rjAwWWU7wVMVclA35j6/s0MzH6tlJzDKPwA==
X-Received: by 10.98.160.90 with SMTP id r87mr10552554pfe.151.1518968907133; Sun, 18 Feb 2018 07:48:27 -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 k3sm1165213pgn.27.2018.02.18.07.48.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 07:48:26 -0800 (PST)
Subject: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)
From: Lingmo Zhu <zlm2006@gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>, alexandre.ferrieux@orange.com, Christian Huitema <huitema@huitema.net>
Cc: 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>
Message-ID: <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com>
Date: Sun, 18 Feb 2018 23:48:21 +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: <d3c8688a-3f01-30b1-a3de-1300a43c1d99@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/XM7Ik5HM_YN-LE19DkVjG3p993I>
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: Sun, 18 Feb 2018 15:48:29 -0000
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". The attack utilizing fake Version Negotiation is too cheap and easy to be performed (due to no encryption exists) and would be harmful (even stopping the establishment of connections) so should be mitigated. The attack that means to make the client abort QUIC connection could be easily performed with small footprint but also could be mitigated by simply ignoring those unacceptable Version Negotiation packets in my rough experiment (if could be called so). Some possible approaches might be considered: * A timer could be set after Initial packet sent (might be combined with one used for re-transmit) for waiting ServerHello. If a Version Negotiation is received but totally unacceptable, just ignore it. If the received Version Negotiation is acceptable, it could be considered after the timeout instead of handled immediately. If a fake packet with ServerHello received, it should be rejected by TLS so not considered here. * When a Version Negotiation is received, instead of handling it within the same connection, handle it as another connection and remain the original connection context. If then the ServerHello packet is received, the new connection context could be dropped and the original connection would be used following up. This approach might be more difficult to be implemented than the previous one. The approaches above are both covered by the statement to be proposed but not exhaustive. This should be a handling for client side so server side would have no modification. Due to different implementations of different clients, it could not be ensure that those approaches are simple enough to be applied but those malicious Version Negotiation packets should be properly handled. Also, the scenario where fake Version Negotiation packets are triggered by each outgoing QUIC (Initial) packet should also be considered. For why those Version Negotiation attack would be utilized by malware, I think they could pretend as server side problem then attract less attention. If simply dropping packet or faking ICMP host unreachable are utilized, it would be considered as an issue on route configuration so more likely a client-side problem thus more attention. Lingmo Zhu
- Questions about Version Negotiation Concerning Po… Lingmo Zhu
- Re: Questions about Version Negotiation Concernin… Mikkel Fahnøe Jørgensen
- Re: Questions about Version Negotiation Concernin… Martin Thomson
- Re: Questions about Version Negotiation Concernin… Mikkel Fahnøe Jørgensen
- Re: Questions about Version Negotiation Concernin… Lingmo Zhu
- Re: Questions about Version Negotiation Concernin… Mikkel Fahnøe Jørgensen
- Re: Questions about Version Negotiation Concernin… Kazuho Oku
- Re: Questions about Version Negotiation Concernin… Mikkel Fahnøe Jørgensen
- Re: Questions about Version Negotiation Concernin… Lingmo Zhu
- Re: Questions about Version Negotiation Concernin… Christian Huitema
- Re: Questions about Version Negotiation Concernin… alexandre.ferrieux
- Re: Questions about Version Negotiation Concernin… Martin Thomson
- Re: Questions about Version Negotiation Concernin… Kazuho Oku
- Re: Questions about Version Negotiation Concernin… alexandre.ferrieux
- Re: Questions about Version Negotiation Concernin… Lingmo Zhu
- Malicious Version Negotiation Handling (Was: Ques… Lingmo Zhu
- Re: Malicious Version Negotiation Handling (Was: … Mikkel Fahnøe Jørgensen
- Re: Malicious Version Negotiation Handling (Was: … Eric Rescorla
- Re: Malicious Version Negotiation Handling (Was: … Lingmo Zhu
- Re: Malicious Version Negotiation Handling (Was: … Eric Rescorla
- Re: Malicious Version Negotiation Handling (Was: … Subodh Iyengar
- Re: Malicious Version Negotiation Handling (Was: … Lingmo Zhu
- Re: Malicious Version Negotiation Handling (Was: … Eric Rescorla
- Re: Malicious Version Negotiation Handling (Was: … Christian Huitema
- Re: Malicious Version Negotiation Handling (Was: … Eric Rescorla
- RE: Malicious Version Negotiation Handling (Was: … Lubashev, Igor
- Re: Malicious Version Negotiation Handling (Was: … Christian Huitema
- Re: Malicious Version Negotiation Handling (Was: … Mikkel Fahnøe Jørgensen
- Re: Malicious Version Negotiation Handling (Was: … Spencer Dawkins at IETF