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

Christian Huitema <huitema@huitema.net> Mon, 19 February 2018 04:49 UTC

Return-Path: <huitema@huitema.net>
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 CCAE512711A for <quic@ietfa.amsl.com>; Sun, 18 Feb 2018 20:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 rXEbcaCq9G1T for <quic@ietfa.amsl.com>; Sun, 18 Feb 2018 20:49:36 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 3A0B41201FA for <quic@ietf.org>; Sun, 18 Feb 2018 20:49:36 -0800 (PST)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1endOP-0002gQ-IA for quic@ietf.org; Mon, 19 Feb 2018 05:49:34 +0100
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1endOL-0003if-RM for quic@ietf.org; Sun, 18 Feb 2018 23:49:30 -0500
Received: (qmail 15739 invoked from network); 19 Feb 2018 04:49:29 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.184]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 19 Feb 2018 04:49:29 -0000
To: quic@ietf.org
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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net>
Date: Sun, 18 Feb 2018 20:49:24 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBPBZBaYigxNdbBq3=JtKuz8wN-WhNBwsxTdAtS=uJv2Rw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.60)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5k8cc+0QaAHBx/LLXRnjrI1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi9dljkJhM8zlg7/e1ZqbQ3M7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB+FWCyy3VMwU/Tu6lpkyLYh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYZsb471zK7fbW8hSVMoqp pS0tFl0bR3sce73Q9OxrVmUKTJV3uvxSzcg5tzcc78AIyWXkWx9Oc6FsxfRE8LUCq9m1LR/Rkhms gi1bNni1Nx10xK5dOvm4pbg8CBiJcsFLIaKLZaIWHErhz1UEr981hLCx4eCSemGsHMs75OfoLqeq 613YX/JpkaqfAljBKlD3pyI1J519bLUrM3neslGWzg/CXrvYZfaN8BpCoaqUuMDouROe77KOt1v8 CMoiiVQVf/qOH8le3Zo2iD646pXyZ/CbKTDA0CdqvvZLVqfbRAUKcZIuviiTlhP5iKsKcxHR/WRb dco3pKNX9x7s84ASzjoUd/Fji/4E0A1Wfl7CNnoniG/Mx18wh299NVDnPvmw8t3Xj/LzZ5s/OJg1 L2asZ1FPmtYUPwECbZov76lmox9FrrkXXOH9yk2+X2eiUHXZfks5suSVIgIg9uJ3gfzn7g==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/MDP_xLJ5qglgcZqUoNUzziWVZCA>
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 04:49:38 -0000

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.

-- Christian Huitema