Re: QUIC Version Negotiation Extension

Christian Huitema <huitema@huitema.net> Mon, 04 November 2019 22:33 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 7596F120A9F for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 14:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 66syWbSS8bUz for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 14:33:00 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 8AA45120127 for <quic@ietf.org>; Mon, 4 Nov 2019 14:33:00 -0800 (PST)
Received: from xse187.mail2web.com ([66.113.196.187] helo=xse.mail2web.com) by mx65.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iRkuA-0000Rc-4B for quic@ietf.org; Mon, 04 Nov 2019 23:32:58 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 476SFT2jCcz2xg7 for <quic@ietf.org>; Mon, 4 Nov 2019 14:31:25 -0800 (PST)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iRksf-0002OU-8k for quic@ietf.org; Mon, 04 Nov 2019 14:31:25 -0800
Received: (qmail 18369 invoked from network); 4 Nov 2019 22:31:24 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.152]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 4 Nov 2019 22:31:24 -0000
To: David Schinazi <dschinazi.ietf@gmail.com>, =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= <mikkelfj@gmail.com>
Cc: QUIC <quic@ietf.org>
References: <CAPDSy+4wrhqejh9k8=G7W267EgcT5Z2sDK7ZBGKtNn5kkbXGfg@mail.gmail.com> <CAN1APdcZv-MtwRT77++r6EKdzJUc1NKEJfY4CZeOSaK50nPZYg@mail.gmail.com> <CAPDSy+5obMbiLDKYKXXg1ZthoMqyg60KD+6HR69CQqiEHb6W7g@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Subject: Re: QUIC Version Negotiation Extension
Message-ID: <aa6be7bc-e4c3-e14f-8064-f511e8fbfb70@huitema.net>
Date: Mon, 4 Nov 2019 14:31:25 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <CAPDSy+5obMbiLDKYKXXg1ZthoMqyg60KD+6HR69CQqiEHb6W7g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------BC2EC1221426F0E13FCBD6B9"
Content-Language: en-US
X-Originating-IP: 66.113.196.187
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.187/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.187/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ftnAcGotDcF23HNAfAuOcqIU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5aB4itzNZ07CdqP+KMfGjQUz0sPgnpAk2KA2vJwMd1uY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm3OZmI6+6AcH EU4XbMnrDarMCwbYZSDsvW0enk+rZHRdlv0GJCQopQ9KJL0fDLG3h96m3sWV/ImezRNfIOqOPfQM 7OYFXYdC3tRq275m/U3VpR20WA4qxE8HEf6BOpfbvrdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1Lx5YQ3PLxPZj1HhRc9GBo2V2jZAOanSBpz6Rja2u/0jJEd39dY9VDdK4BT5IQDl1l2Pw9 G+41ufxzuq6KbIukdfysta6u1iHEyuS7GD1uvcrX/ngr5O18X2gUzhLy4NGZJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Dhg5sUnHwLmrPWG58ZeqWzSpRIw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 04 Nov 2019 22:33:02 -0000

On 11/4/2019 2:09 PM, David Schinazi wrote:
> Thanks for reading Mikkel! Responses inline.
>
> On Mon, Nov 4, 2019 at 1:47 PM Mikkel Fahnøe Jørgensen
> <mikkelfj@gmail.com <mailto:mikkelfj@gmail.com>> wrote:
>
>     (reposting on proper topic)
>
>     Some random observations reading through the document
>
>     - Is the order relevant in the receiver version list?
>
>
> Yes all lists of versions are ordered.
>  
>
>     - It is tempting to just hash the received version list, but that
>     requires agreeing on an algorithm, unless the algorithm is stated
>     to be specific to that version, which is complicated.
>
>
> Which list are you referring to? For all the ones in the draft, the
> peer needs access to all the elements so I don't think a hash would help.
>  
>
>     - VERSION_NEGOTIATION_ERROR vs drop - I’m not sure it is a good
>     idea to close the connection. The initials are public so it is
>     possible to inject false versions. There are probably many other
>     similar attacks we don’t bother with, but still …
>
>
> Once we're this far in the handshake, we cannot recover from this
> error. Dropping the packet will only make things worse..

Can we think about that some more?

It is true that there are many ways to wreck a connection if the
attacker can freely tweak bits in the client hello. There is no need to
mess with transport parameters -- just changing the value of the client
Random will do that. The server will create a connection context and
send a reply, but the client won't compute the proper handshake key and
the connection will fail.

An attacker on path can kill all packets and close the connection, but
an attacker on the side can only inject "magic" packets. The VN could
become one such magic packet. Can the man on the side send the VN
quickly, so the client sends a "VN inspired" client hello? What would it
take to ensure that the connection is robust against such attacks?

-- Christian Huitema