Re: Questions about Version Negotiation Concerning Possible Handshake Interruption

Christian Huitema <huitema@huitema.net> Sat, 10 February 2018 06:25 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 DA1EB1241F8 for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 22:25:06 -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 8CPecPpRRe_2 for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 22:25:04 -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 9E3361241F3 for <quic@ietf.org>; Fri, 9 Feb 2018 22:25:03 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ekOan-00086I-FF for quic@ietf.org; Sat, 10 Feb 2018 07:24:58 +0100
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ekOak-00078q-9m for quic@ietf.org; Sat, 10 Feb 2018 01:24:55 -0500
Received: (qmail 17383 invoked from network); 10 Feb 2018 06:24:44 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <martin.thomson@gmail.com>; 10 Feb 2018 06:24:44 -0000
To: Lingmo Zhu <zlm2006@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
Cc: "quic@ietf.org" <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net>
Date: Fri, 09 Feb 2018 20:24:42 -1000
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: <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption
X-Originating-IP: 168.144.250.223
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.30)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5imXPLxlWTMvok0sQ9ot8bAXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fu6v+gany42dBpcnupRv2zDB98yDTitFWvbHwz9vKZpm3I5 mq5AFk9iXeoOoZGPBgSZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyZFjIToX6GLbbHCBsyyfoCLFQwbgMCItJaYYOhQRv6/ UGvez0tiveIVkxvydwTaUEvh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3Goyp65o39wd3xyIqswrw4YJnHEeB4hpRrmo/duzUUp/Le F+ZXED8J4mkrkZhP7Gp/UG6J3KZkZnCUxiuNwn8fB3LYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+0EF5F4XJDGest21JnLKg8Ij2lB9TLiDMfXuvSrucRXpoVg5fOhUS7LnGpWowDQkTpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pqk3vYf_TbTL2Yylt2CQPekYxWk>
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: Sat, 10 Feb 2018 06:25:07 -0000


On 2/9/2018 3:06 PM, Lingmo Zhu wrote:
>
> IMHO we can see that such interference is pretty easy to be used and
> it could leading to aborted QUIC connection and probably a fallback to
> any old approach for higher level protocol. Even virus targeting home
> routers could do that, without gov involved. For what outcome, I think
> it's pretty simple: forcing higher level protocol fallback to other
> transport protocol. Since QUIC has been designed much more secure than
> older protocols, it could be hard to do some eavesdropping or
> hijacking. But if fallback happens, it would be another story.
> Considering DNS over QUIC, a virus-infected home router could
> interfere with QUIC handshake cause fallback to TLS, then RST may
> cause fallback to clear text, which is easy to be hijacked and leads
> client to some phishing site.
>

In theory, it should be possible to protect against "man on the side"
attacks. Do some kind of speculative execution on the first packet that
you receive, but also keep the context available for some time in case a
"better" packet comes later. With that approach, the attacker could not
just inject a "packet of death"; they will also need to suppress the
correct response from the actual server. That's an interesting idea.
Have you tried some experiments?

-- Christian Huitema