Re: 回复: A non-TLS standard is needed
Paul Vixie <paul@redbarn.org> Wed, 29 April 2020 05:01 UTC
Return-Path: <paul@redbarn.org>
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 B7A2D3A03F8 for <quic@ietfa.amsl.com>; Tue, 28 Apr 2020 22:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2QpPEVil0aCd for <quic@ietfa.amsl.com>; Tue, 28 Apr 2020 22:01:21 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026913A03F2 for <quic@ietf.org>; Tue, 28 Apr 2020 22:01:20 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D3F59B074A; Wed, 29 Apr 2020 05:01:20 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: quic <quic@ietf.org>, 援北斗兮酌桂浆 <cang.mang@foxmail.com>
Subject: Re: 回复: A non-TLS standard is needed
Date: Wed, 29 Apr 2020 05:01:19 +0000
Message-ID: <5192634.PfBDN8BmjF@linux-9daj>
Organization: none
In-Reply-To: <tencent_A9C74BB466C7C73F64A1C54012D66E1FA706@qq.com>
References: <tencent_458BB4AFD3E32DBAAEA3F09FAEF063800605@qq.com> <2208100.KEu4SK8F6j@linux-9daj> <tencent_A9C74BB466C7C73F64A1C54012D66E1FA706@qq.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Fif7a4aEcb1VY-rjagBKdExBBP8>
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: Wed, 29 Apr 2020 05:01:24 -0000
On Wednesday, 29 April 2020 03:31:29 UTC 援北斗兮酌桂浆 wrote: > The plaintext-QUIC is not used between human beings under the same > sub-network. It is used between server-machines. > Server-machines for solving same service in the same equipment room needn't > encryption while communicating between each other. If we use QUIC for > these machines communicating between each other, a non-TLS standard is > needed. so, i happen to agree, but i also understand very deeply why others disagree. first, it's assumed that you have some control over how your servers behave, and can program or configure them to use HTTP over TCP, with no TLS or UDP. you don't need and won't miss the advantages of QUIC in a pure LAN environment. second, it's widely known that nation-state attackers, mostly domestic but also some foreign, will be able to tap into your LAN if they see a need to do so, and that this will create risk for all of your counterparties, and for you also. the risk to your counterparties is seen as a public digital health risk; if your LAN is tapped by some attacker, it could hurt entire economies or even the entire world. the injury would be small, but can be like a thousand stings. this community believes it is acting in the public's interest, and has reached a consensus that creating new ways to communicate non-secretly is not in the public's interest. such non-secret methods are available now, and can still be used by any operator who prefers them. i was in the minority on these decisions, so please don't shoot the messenger. (my reason for disagreement has to do with hypervisors and sea level rise; to be detailed over beer if i'm ever able to see any of you in person again.) -- Paul
- A non-TLS standard is needed 援北斗兮酌桂浆
- Re: A non-TLS standard is needed Lars Eggert
- Re: A non-TLS standard is needed Salz, Rich
- Re: A non-TLS standard is needed Paul Vixie
- Re: A non-TLS standard is needed Töma Gavrichenkov
- Re: A non-TLS standard is needed Paul Vixie
- Re: A non-TLS standard is needed Salz, Rich
- Re: A non-TLS standard is needed Lars Eggert
- Re: A non-TLS standard is needed Mirja Kuehlewind
- Re: A non-TLS standard is needed Roberto Peon
- Re: A non-TLS standard is needed Paul Vixie
- Re: A non-TLS standard is needed Stephen Farrell
- Re: A non-TLS standard is needed Matt Joras
- Re: A non-TLS standard is needed Lucas Pardue
- Re: A non-TLS standard is needed Paul Vixie
- Re: A non-TLS standard is needed Paul Vixie
- 回复: A non-TLS standard is needed 援北斗兮酌桂浆
- Re: A non-TLS standard is needed Mark Nottingham
- Re: 回复: A non-TLS standard is needed Paul Vixie