IETF Logo Mail Archive

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

Subodh Iyengar <subodh@fb.com> Mon, 19 February 2018 03:41 UTC

Return-Path: <prvs=5588f83ffc=subodh@fb.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 4D7741201FA for <quic@ietfa.amsl.com>; Sun, 18 Feb 2018 19:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Xg6vPdzC; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TYt2qr5r
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 G-ZC_qT-b4if for <quic@ietfa.amsl.com>; Sun, 18 Feb 2018 19:41:48 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBC21200C1 for <quic@ietf.org>; Sun, 18 Feb 2018 19:41:48 -0800 (PST)
Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1J3dsjU023904; Sun, 18 Feb 2018 19:41:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=IhjPBoXVyFZEUWuJhXWD3K3YlpmLD9+kzDCETcXRBps=; b=Xg6vPdzCWyjIkM7ynhZ/5DA6ADDzn9G1cwqt0qlqMsovcaI1AjkA/upWLU0RVHhJXRr0 qTF31T3NVeVi2GSqSwtTr7ugPUOV5wSQ5piM0FetPHzAIYE/ZebdFo30Mzt7n9deQIFp Sp486q/IvyBVZxPN4X/TAtxW+vA5M6xkGzg=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2g7a3ycu5p-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Feb 2018 19:41:41 -0800
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 18 Feb 2018 19:41:39 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IhjPBoXVyFZEUWuJhXWD3K3YlpmLD9+kzDCETcXRBps=; b=TYt2qr5roIiGcfxVgbHhIT4FLfVI6ds+iUJhZ4Op6kgYTuPA0qrKbYiFxWVFU8lpDNNIBz3+fyLZ3HP2vkFN3hVfnddD9GQBxeBzd7Tlw6JJRNfEh0ZveDlDvDwjZrmC8na+edf/VnT9g6TidsbJVAREwd/6aD3+zsM/RSkdv8U=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1584.namprd15.prod.outlook.com (10.173.235.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 03:41:18 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::b054:d63c:f848:809d]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::b054:d63c:f848:809d%17]) with mapi id 15.20.0506.023; Mon, 19 Feb 2018 03:41:18 +0000
From: Subodh Iyengar <subodh@fb.com>
To: Eric Rescorla <ekr@rtfm.com>, Lingmo Zhu <zlm2006@gmail.com>
CC: "alexandre.ferrieux@orange.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>, Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)
Thread-Topic: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)
Thread-Index: AQHTqM/yy1tJknD/DUC51fVp8eT3K6OqaWMAgACSqgCAAAyZgIAADCUC
Date: Mon, 19 Feb 2018 03:41:18 +0000
Message-ID: <MWHPR15MB182101493383DBBDD889B6C7B6C80@MWHPR15MB1821.namprd15.prod.outlook.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> <efc46f51-41ff-f69c-d627-f6d585013b1e@gmail.com>, <CABcZeBO4OHJDtFkjcCwRFNL_mU5QzOGBcC-zMJPHStJq090gzw@mail.gmail.com>
In-Reply-To: <CABcZeBO4OHJDtFkjcCwRFNL_mU5QzOGBcC-zMJPHStJq090gzw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c090:180::e2a7]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1584; 7:n0vvNzj4B+oryPVtrAMhg1DWU5qnYZPEw8yvRsoTg+yL9TVmRZYDjjMbfaxM1csUfItYX0W7CkM2b8vB3TflS+ySZ19ltuLZq3p/yKFDXKn0USPJsX7Xd8cw/MW2zUBjyLBGeXxs0shihjFXd4fKncwnkABQsXiJaeRzKiCXnoGKun3ghb4IqzwjrZSXXTZJYPp0xygYsguf2eJFX7vnoHpri8oLXVnFhh5Bvscz1QmZ008MLYbKfUohJbHVV9gW; 20:8k5l5LlC8WWE6rxU0thBT+S8OsU5KdUgxM6D1okjcDcUrejTW8kQJZkDUTDjMl3xL+FnsMOJH0DCK70EQUBB1YJCnKxl3xwtY7PxVHlWChmH83/ldppzjIzfNUhLU0kB783VPCH0VGhBY7uamxQNvrEckTZCWetKCYKad17V+/w=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: df4661ab-3c91-4487-834e-08d5774aa2ce
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR15MB1584;
x-ms-traffictypediagnostic: MWHPR15MB1584:
x-microsoft-antispam-prvs: <MWHPR15MB1584EA07B1A152C613A08F25B6C80@MWHPR15MB1584.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(85827821059158)(18271650672692);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(11241501184)(944501161)(3002001)(6041288)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR15MB1584; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1584;
x-forefront-prvs: 0588B2BD96
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(366004)(39380400002)(189003)(199004)(51914003)(53754006)(2950100002)(5250100002)(2900100001)(33656002)(6606003)(5660300001)(478600001)(55016002)(2906002)(14454004)(6246003)(54896002)(53936002)(236005)(97736004)(9686003)(6116002)(106356001)(229853002)(6436002)(19627405001)(186003)(86362001)(316002)(99286004)(68736007)(4326008)(3660700001)(7696005)(93886005)(25786009)(8676002)(8936002)(110136005)(81156014)(76176011)(54906003)(81166006)(105586002)(3280700002)(39060400002)(74316002)(102836004)(6506007)(7736002)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1584; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: x8ErYOkRenKHosTuofrDS8ddn9HT24w/PJ6zKKmV0Ewz84ZER0paQrZsMpfY+mVBBRTjAi6iXxctqQ0yaBpTlK08Y0K/TS+IYjDsiM6BHRP7OUZzpLdVJz+Gal+o/KwFemQS869pJ9K6WMN2Oi3Mj33RSeIs3i5swFE+p81PGpQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB182101493383DBBDD889B6C7B6C80MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: df4661ab-3c91-4487-834e-08d5774aa2ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 03:41:18.4271 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1584
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_02:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Icvm5xzruSAJqtZ0Zh2w1xApbaA>
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 03:41:50 -0000

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

I agree with ekr, a TLS alert is similar and does not require knowledge of any state, knowledge of the cid gives you the ability to craft a packet that will be accepted by the client (even Handshake packets).


Subodh

________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Sunday, February 18, 2018 6:55:45 PM
To: Lingmo Zhu
Cc: alexandre.ferrieux@orange.com; Christian Huitema; Mikkel Fahnøe Jørgensen; quic@ietf.org; Martin Thomson; Kazuho Oku
Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)



On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu <zlm2006@gmail.com<mailto:zlm2006@gmail.com>> wrote:


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

Thanks for the explanation. I don't consider this a significant difference in attacker capabilities.

-Ekr



Lingmo Zhu

v2.23.0 | Report a Bug | By Email