IETF Logo Mail Archive

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

"Lubashev, Igor" <ilubashe@akamai.com> Mon, 19 February 2018 13:26 UTC

Return-Path: <ilubashe@akamai.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 E209412783A for <quic@ietfa.amsl.com>; Mon, 19 Feb 2018 05:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 KvJYHlMQVdF3 for <quic@ietfa.amsl.com>; Mon, 19 Feb 2018 05:26:46 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 B89C71242F7 for <quic@ietf.org>; Mon, 19 Feb 2018 05:26:46 -0800 (PST)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1JDQfbZ029798; Mon, 19 Feb 2018 13:26:41 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=alzQaKE0EXPgKe+h0SoEhsiKYus3DDdep5oGHr5IqnE=; b=I/j6FWDK+i4/QIfBKnTiuj5CbmJvWbdMB5VQxUX15Z/yVGpXIO+0GiRr7UArWd56Pjtf pQT8v8cO8uvpEdVz/ofViJxh1h1lIairThJkjqHGCFGPZ9pvJdrjq6a7kYdpZEATiT26 1DUayx3/t4tCwNE4Pbww0K/gL4WBhiWIioYmvAmPh1zhqzuFuMij3ylEDijXtSAz7r4s VYF0xWRV4n8C7MA0nee6OrcaX2dTO//aGV0fB+EWX3yKrt0STjpVu525yIIHDw1mv1de spbWCQ7a6TTIDi03p63z8rO0v9aJNKb1omwOP+MF+C5HBdl+Jqg4b8ViAD+lNsfOBYQ3 9w==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2g6chqeheu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 13:26:40 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1JDQ7Gw000538; Mon, 19 Feb 2018 08:26:39 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2g6gky5g43-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 08:26:39 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Feb 2018 05:26:38 -0800
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Feb 2018 08:26:38 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Mon, 19 Feb 2018 08:26:38 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "ekr@rtfm.com" <ekr@rtfm.com>, "huitema@huitema.net" <huitema@huitema.net>
CC: "quic@ietf.org" <quic@ietf.org>
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/vqBxMeas2KEOHAIur8pl8/aOqvTUAgACSqgCAAAyYgIAADLoAgAAO/ACAAAHdAIAAAi4AgAABXwCAADtTFQ==
Date: Mon, 19 Feb 2018 13:26:37 +0000
Message-ID: <6ec913dc5ecd494eb951ac716e87d40e@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <1d386744-c46a-842a-b172-24e290e03668@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> <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>
In-Reply-To: <CABcZeBN1hYug-0_VEVyGPRgG0=zHzJazcSo9=WdR09yk9WDO4Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_6ec913dc5ecd494eb951ac716e87d40eusma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190168
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190168
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Yh6AbO0T1J_C6h9aOCWbV6aHMcE>
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 13:26:48 -0000

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.

-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
Received: Sunday, 18 Feb 2018, 11:55PM
To: Christian Huitema [huitema@huitema.net]
CC: IETF QUIC WG [quic@ietf.org]
Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)



On Sun, Feb 18, 2018 at 8:49 PM, Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>> wrote:
On 2/18/2018 8:41 PM, Eric Rescorla wrote:

> I don't think increasing the on-path attacker's marginal difficulty
> from not requiring any crypto to requiring simple crypto in order to
> mount a DoS attack is worth changing the protocol for.

Changing the protocol, probably not. But Lingmo's suggestion is one of
the several steps that we could take against hardening against a man on
the side attack. And it is a very simple one: if you receive a VN that
does not contain any acceptable option, just ignore it. If this was
legit, the connection will actually break after a short timer. If it was
not, the next received message will be a Server Hello, and the
connection will progress. Sounds like a reasonable trade-off.

I think it's fine if people do this. I don't think it's worth requiring in the spec given the existence of other trivial man-on-the-side attacks.

-Ekr


-- Christian Huitema

v2.23.0 | Report a Bug | By Email