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.
- Questions about Version Negotiation Concerning Po… Lingmo Zhu
- Re: Questions about Version Negotiation Concernin… Mikkel Fahnøe Jørgensen
- Re: Questions about Version Negotiation Concernin… Martin Thomson
- Re: Questions about Version Negotiation Concernin… Mikkel Fahnøe Jørgensen
- Re: Questions about Version Negotiation Concernin… Lingmo Zhu
- Re: Questions about Version Negotiation Concernin… Mikkel Fahnøe Jørgensen
- Re: Questions about Version Negotiation Concernin… Kazuho Oku
- Re: Questions about Version Negotiation Concernin… Mikkel Fahnøe Jørgensen
- Re: Questions about Version Negotiation Concernin… Lingmo Zhu
- Re: Questions about Version Negotiation Concernin… Christian Huitema
- Re: Questions about Version Negotiation Concernin… alexandre.ferrieux
- Re: Questions about Version Negotiation Concernin… Martin Thomson
- Re: Questions about Version Negotiation Concernin… Kazuho Oku
- Re: Questions about Version Negotiation Concernin… alexandre.ferrieux
- Re: Questions about Version Negotiation Concernin… Lingmo Zhu
- Malicious Version Negotiation Handling (Was: Ques… Lingmo Zhu
- Re: Malicious Version Negotiation Handling (Was: … Mikkel Fahnøe Jørgensen
- Re: Malicious Version Negotiation Handling (Was: … Eric Rescorla
- Re: Malicious Version Negotiation Handling (Was: … Lingmo Zhu
- Re: Malicious Version Negotiation Handling (Was: … Eric Rescorla
- Re: Malicious Version Negotiation Handling (Was: … Subodh Iyengar
- Re: Malicious Version Negotiation Handling (Was: … Lingmo Zhu
- Re: Malicious Version Negotiation Handling (Was: … Eric Rescorla
- Re: Malicious Version Negotiation Handling (Was: … Christian Huitema
- Re: Malicious Version Negotiation Handling (Was: … Eric Rescorla
- RE: Malicious Version Negotiation Handling (Was: … Lubashev, Igor
- Re: Malicious Version Negotiation Handling (Was: … Christian Huitema
- Re: Malicious Version Negotiation Handling (Was: … Mikkel Fahnøe Jørgensen
- Re: Malicious Version Negotiation Handling (Was: … Spencer Dawkins at IETF