Re: Questions about Version Negotiation Concerning Possible Handshake Interruption

Lingmo Zhu <zlm2006@gmail.com> Sat, 10 February 2018 01:06 UTC

Return-Path: <zlm2006@gmail.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 887C4126CBF for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 17:06:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DngvVI0F-DZj for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 17:06:43 -0800 (PST)
Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF3B124F57 for <quic@ietf.org>; Fri, 9 Feb 2018 17:06:43 -0800 (PST)
Received: by mail-pl0-x22f.google.com with SMTP id t4so2250616plo.0 for <quic@ietf.org>; Fri, 09 Feb 2018 17:06:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=IXrD3roRNq/PryUMIfenCL6iguOUR6/KKDPkJnwX+10=; b=TTmg6XQ8oQfsAYyu1QLTzl7x6+AccOJ3QAS4xuOkE3r5JbNsls3MUTgZQDQjmg4nIw TDr3iI3KusqWJ7SR6MODQhyBAwK5EWLKQWEpIsQCw/PXdMOwKwVazL7R3ZCE3Ocf/I3h 2V/Cmu26iAbCftrqDYA04bXDv9tzMbikfSZaLHW2/yYtTVHcvuw1eVF3KedNrcqlVozO Efr4XWkY6JUyucuez0mXNVRO0KdimH2Vl+kpgCGZApBb1cmCx/qqTpV5GDZoJe+CLq7/ IftkbtY/4H1oEHdD2rTwPScBQVTgoI/OA9wKjY8prsvmcdfQ2p9EBWHziTnyTaxMVYIq iJxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IXrD3roRNq/PryUMIfenCL6iguOUR6/KKDPkJnwX+10=; b=YWX+G0XHCksFX1vGwRGYeFR6sijKw9uS2nQQ4EJP0C1Bn8R/w+purAMF+NU8fgpnsx VF6VlshJ+PrXRlk9e3MAnjmyQ5FUtIYTucVltEYsGJJTqGxWeBh3QaVWnoYimUYO0X7r vXhc8vH0/Dad5mVPJsBnYsCsk9/NH+g3M5Wq8HjIBPyQtDwRD+otYIf9KwLB845KJWqQ /5dXY207JNMzSO9yAjtZFxH+5q14LH12KVFxo0ah39lzFlsRw0ghcjAqVi+Ja8Yghcnw lJmqd7pkf0vTvhoM0UFghkgcMkgnNelLX6oEUSvaKyuFV34yC9/1fMPpargFye5HyNDG RdVA==
X-Gm-Message-State: APf1xPCk7175EcbHWYK3T9cbyv1NSWerB5CwXgvYMjwKLF/StOXomn1F MSvCwgEjY5W3+5XXukhiKNXtNZ9EKQo=
X-Google-Smtp-Source: AH8x226GKpLhwgXjIwKODe4MMjVZj9oqq+5RSOtZKzHcUPy0W/UfsnLAV5ip8mc2LlPG4MQgvcMWiw==
X-Received: by 2002:a17:902:7486:: with SMTP id h6-v6mr4271756pll.236.1518224803028; Fri, 09 Feb 2018 17:06:43 -0800 (PST)
Received: from Justins-MacBook-Pro.local (tk2-262-40902.vs.sakura.ne.jp. [160.16.241.156]) by smtp.gmail.com with ESMTPSA id z125sm8055502pfz.27.2018.02.09.17.06.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2018 17:06:42 -0800 (PST)
Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "quic@ietf.org" <quic@ietf.org>
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>
From: Lingmo Zhu <zlm2006@gmail.com>
Message-ID: <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com>
Date: Sat, 10 Feb 2018 09:06:38 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAN1APdfov8Q3E+5NkT5pmMeU=eB=fsnDFe_=BK7TDE0TpXD3yA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------C161A067F8A746B5DFD645AE"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/BiZFuTAGTAT0Cs68A8Xu9cBd4Ao>
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 01:06:45 -0000

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.


On 2018/02/09 19:56, Mikkel Fahnøe Jørgensen wrote:
> A realistic on-path attack involves a government body that taps optic 
> fiber at an internet distribution node. The original intention behind 
> the construct may be to trigger an alarm whenever the string “dirty 
> bomb” appears in a protocol RFC 821 message (such as this one), and 
> subsequently for logging purposes to monitor traffic directed towards 
> bulk fertiliser suppliers. It is not possible to drop packets both due 
> to the mechanical construct, due to legislation, and because it might 
> be too obvious. However, having a datacenter with optic fibre near 
> said access point gives excellent insights into early handshakes 
> including IP, port, connection ID, and possible even a profile of the 
> PRNG being used at some endpoint.
>
> This makes it very simple to spoof and inject packets into handshake 
> with a good chance of winning any race. More difficult, but possible, 
> it could also observe packets and inject packets closer to the 
> endpoint, for example using long distance point to point radio 
> communication to race the ordinary packet stream.
>
> Any argument about friendly gov is void because the internet travels 
> across multiple regions that each with near certainty have taps as 
> those described above making it a prime target in cyber warfare.
>
> The question is then to what extend such a position can be utilised to 
> interfere with the handshake and what the outcome of such interference 
> would be, rather than a discussion of how plausible such an attack is, 
> because it is probably a 99% given if feasible.