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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 19 February 2018 18:42 UTC

Return-Path: <mikkelfj@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 1E28B1241F5 for <quic@ietfa.amsl.com>; Mon, 19 Feb 2018 10:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 m35L2n2gCkqs for <quic@ietfa.amsl.com>; Mon, 19 Feb 2018 10:42:11 -0800 (PST)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 C30A51204DA for <quic@ietf.org>; Mon, 19 Feb 2018 10:42:11 -0800 (PST)
Received: by mail-it0-x22f.google.com with SMTP id a203so3269940itd.1 for <quic@ietf.org>; Mon, 19 Feb 2018 10:42:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/ZS1bh1tUAZn+Dt0FqZInOH9SvSZenkEzDtsluNCsds=; b=uis2c13kX0lGz1LPnmE9cEXLRT//+RAAtYReimuGLaR+iytg0M5GiXmx4P+5FvCYBe Fre795BXGYI5V7w8Nba6WSBB3O6bf5v/xWDMyU44dMKWGXMOazhU2zZ15C69TNH6jlD1 AuDlq6ASeQ7N956SuuvWl/aNIAUMrad9HaOHRYKOr/S/QXf7yKhzcU/QY3oyOUb6yy4r SOammZtWSu9SfPT1Ft4aeSRiJyR/nLsuFKyARc/yTKbuS8/vxDovE9lbfExTyGwhjnHw ZlvvjKfjQDdfEqSDj9gCydZO5/JII7gKRCOTt5WDWZ5tdmeYCgBKlv1hLgWGGgFOhZCS WdSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/ZS1bh1tUAZn+Dt0FqZInOH9SvSZenkEzDtsluNCsds=; b=HgqWluHtZrk4wlUGTrrGFDNPICvSchOIZXf8aCkOjPz1brqs0xVkINt2LyH+qlpH+4 RDEBsys8c4ZNB5AC0X0tcr55Q8TnGyJ9rXxg19m1Sch5yl1EjSGhUjKDwkiCLNnj4fym TRle2SQRD+xz5jB7nY7wwo2c5P+Ic9CeylCip+IROSKjozkaXYEejTP1uZqdJnGcBwcT L5VQ7sr/QzSYiT9fqZKFCcJ3Ry/l3KObQ4E3+5kIe1qfsIlmAeCTL2xmQq2SMeLXURVT bJhxdwO5i/qY1WVjg57N8ViCg1eVWLOU12UKBe87TqlB+uNoRXw8gd8Z5G/W5bRF7HIM YeWw==
X-Gm-Message-State: APf1xPBa94P1I8Zm1vMuUnnHIXCg/ctb4Hv704g0867HKGfpvmzJQ/AL JO5XmAoxoQ1hyTAxrXH2/rM0rSvDzNt2m9Ph7sc=
X-Google-Smtp-Source: AH8x2265FElEVy0OGeOi8gbITR7w5fvMBk40c4Vt5AKFrKaFu6e9ZD7r7tD9NChCvn+/dR+yMu+AlcImYsj/t9nRVfc=
X-Received: by 10.36.123.198 with SMTP id q189mr21428532itc.118.1519065731159; Mon, 19 Feb 2018 10:42:11 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 19 Feb 2018 10:42:10 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <459f4622-bab0-6bdc-8b6c-70e87a0efb97@huitema.net>
References: <1d386744-c46a-842a-b172-24e290e03668@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> <efc46f51-41ff-f69c-d627-f6d585013b1e@gmail.com> <CABcZeBO4OHJDtFkjcCwRFNL_mU5QzOGBcC-zMJPHStJq090gzw@mail.gmail.com> <MWHPR15MB182101493383DBBDD889B6C7B6C80@MWHPR15MB1821.namprd15.prod.outlook.com> <ae2d881a-1966-dc9a-f69a-44d13ad3d2e8@gmail.com> <CABcZeBPBZBaYigxNdbBq3=JtKuz8wN-WhNBwsxTdAtS=uJv2Rw@mail.gmail.com> <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net> <CABcZeBN1hYug-0_VEVyGPRgG0=zHzJazcSo9=WdR09yk9WDO4Q@mail.gmail.com> <6ec913dc5ecd494eb951ac716e87d40e@usma1ex-dag1mb5.msg.corp.akamai.com> <459f4622-bab0-6bdc-8b6c-70e87a0efb97@huitema.net>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 19 Feb 2018 10:42:10 -0800
Message-ID: <CAN1APdeRjBKcUKnh1snnbMNLjGpR-+=pmS4oe7HzkRUGbyLf4g@mail.gmail.com>
Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)
To: "Lubashev, Igor" <ilubashe@akamai.com>, Christian Huitema <huitema@huitema.net>, "ekr@rtfm.com" <ekr@rtfm.com>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114760b24bdd300565950db3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/zhHu4RsGcPIi7nNsqsC18nStbPI>
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 18:42:13 -0000

Two factor hasn't been mentioned at all - and at first sight it might seem
a bit off.

However, considering the availability of both auth apps and Fido HW
authentication devices, this could be built into the early handshake as an
option.


On 19 February 2018 at 19.32.46, Christian Huitema (huitema@huitema.net)
wrote:

On 2/19/2018 5:26 AM, Lubashev, Igor wrote:

For clients that have a tcp fallback, this kind of an attack mitigation
would need to be done together with some happy eyeballs race. Otherwise,
waiting for a timeout on VN has a real performance cost to the user in case
there is no attack happening. So if this kind of an artificial delay in VN
is mentioned, starting the fallback would need to be mentioned as well. All
this seems like it could belong to an
optimization/applicability/happy-eyeballs-for-QUIC draft, if it belongs
anywhere at all, but not the transport draft.


That's reasonable. Several people have expressed concerns about
man-on-the-side attacks. We have heard various proposals for hardening the
initial handshake. The typical concern is an adversary "that taps optic
fiber at an internet distribution node", to use Mikkel's words, although we
may also be concerned by an on-link attacker in an Ethernet or Wi-Fi
network. The adversary gets a copy of packets, parses them, and finds a
pattern that triggers an attack. The adversary then sends a forged packet
to one end of the connection or another, with a goal of causing either a
connection failure or a security downgrade.

Lingmo Zhu is concerned with a specific variant of this attack, sending a
forged version negotiation packet. I think that's a valid concern, but only
one of many. We should be equally concerned with forged stateless reset
packets, or forged handshake packets: anything that happens before
protection is negotiated can be forged.  I would support writing a draft
that enumerates these attacks, and proposes plausible defenses.

-- Christian Huitema

--