IETF Logo Mail Archive

Re: A non-TLS standard is needed

"Salz, Rich" <rsalz@akamai.com> Sun, 26 April 2020 16:42 UTC

Return-Path: <rsalz@akamai.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 0E3F33A0B3B for <quic@ietfa.amsl.com>; Sun, 26 Apr 2020 09:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 H09Iji5s4Ner for <quic@ietfa.amsl.com>; Sun, 26 Apr 2020 09:42:51 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 DC1F33A08B3 for <quic@ietf.org>; Sun, 26 Apr 2020 09:42:50 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03QGgFoV006945; Sun, 26 Apr 2020 17:42:46 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ONPCQMRbbsQ7rwWHcBRir7wm9ebZ4ZYmeQb1eoVRst8=; b=SKBOFE0K4X8Nop3UsFCSinjHWNaMbBXaEfPQmYg9eRxTffWd/mXAEFXu7xTncO6PboQ6 r1by3Iy8Om+wsNfvfF6ULFSv6dTlgyoe9ZA1YtbsIXkYj/MELnBwopgqd4wSyoTmYXuE 6WeiBiZO3bcsXRO5YuvijqUu2npFA8T0NGlV/4u4vDXwDCJOwmfL5kgX1ULviGJHlUO5 GsXcSZAv3kP7HT5ETWkLumZTYSGBck4EasBptUNnvR+hkKqzsTTCUCbcp/Hor8u7hftl rzMe5b8T9odDLrhpaTvuoZn4rpMQcsH34i3a2YrGYkToghQf2dc4iGFxFS0BlG2v2WI0 1w==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 30mcuwn6bk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Apr 2020 17:42:46 +0100
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 03QGHFZt015494; Sun, 26 Apr 2020 09:42:45 -0700
Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint5.akamai.com with ESMTP id 30mk68bkq9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 26 Apr 2020 09:42:45 -0700
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 26 Apr 2020 11:42:10 -0500
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Sun, 26 Apr 2020 11:42:12 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: 援北斗兮酌桂浆 <cang.mang@foxmail.com>, quic <quic@ietf.org>
Subject: Re: A non-TLS standard is needed
Thread-Topic: A non-TLS standard is needed
Thread-Index: AQHWG6JXgAPb0XzmNU6JO/Y+zcPC8aiLrOcA
Date: Sun, 26 Apr 2020 16:42:11 +0000
Message-ID: <7C5E535B-FA7B-4039-A286-7393C3B232CE@akamai.com>
References: <tencent_458BB4AFD3E32DBAAEA3F09FAEF063800605@qq.com>
In-Reply-To: <tencent_458BB4AFD3E32DBAAEA3F09FAEF063800605@qq.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.112.195]
Content-Type: multipart/alternative; boundary="_000_7C5E535BFA7B4039A2867393C3B232CEakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-26_06:2020-04-24, 2020-04-26 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=688 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004260151
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-26_06:2020-04-24, 2020-04-26 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 adultscore=0 clxscore=1011 mlxlogscore=669 spamscore=0 impostorscore=0 priorityscore=1501 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004260154
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Tyo2qTWx5LldgmRstgNfznGhC-0>
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: Sun, 26 Apr 2020 16:42:53 -0000

  *   Currently QUIC has a TLS layer, and it defines a security standard. But we also have inner reliable network, in such network, every host knows each other, so encryption is not necessary. If we use QUIC in such network, the TLS layer will waste much CPU time. So I think QUIC need a standard of non-TLS.

Lars already mentioned the charter, which is the description of what the QUIC WG works on.  Adding plaintext QUIC would require revising that, and it would be surprising to me if there were consensus to do this.

There are also technical problems with this. For example, how does the protocol library “know” that it’s on a secure network? How does it know that node C isn’t trying to read messages that A sends to B? How do you negotiate between encrypted-quic and plaintext-quic, without being “tricked” into downgrading to plaintext over the public Internet, for example?  These are hard problems.

v2.23.0 | Report a Bug | By Email