Re: [quicwg/base-drafts] Make TLS Optional (#4260)

Karthik Kumar Viswanathan <notifications@github.com> Thu, 22 October 2020 22:40 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AAC3A08AE for <quic-issues@ietfa.amsl.com>; Thu, 22 Oct 2020 15:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 Wx5-mRHEu9Z8 for <quic-issues@ietfa.amsl.com>; Thu, 22 Oct 2020 15:40:30 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE1C3A0832 for <quic-issues@ietf.org>; Thu, 22 Oct 2020 15:40:30 -0700 (PDT)
Received: from github.com (hubbernetes-node-f674994.ac4-iad.github.net [10.52.122.35]) by smtp.github.com (Postfix) with ESMTPA id 7F0146008C6 for <quic-issues@ietf.org>; Thu, 22 Oct 2020 15:40:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1603406429; bh=XQrbeOGw1u5SqYWTsWqqRndA5f4ZIwd3lEmm7wk8kKo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zg2HZedEgSW/CM83dRUcf1Hf8fHQlg03uHfe7Lxr4onWX7JoYvY2bS/YTv+R23IM+ PQFyFXzrDMcU7NepfA0fPOxOMpxqOkTxKIgVN2kyIKvaYgzpuq3Sr6eKS2nDsrkjXZ UoW7yZ643HPm9Bes+dh2x0lmGgplHozphYX76ZF8=
Date: Thu, 22 Oct 2020 15:40:29 -0700
From: Karthik Kumar Viswanathan <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYIZEPIXSJSLT5CUAF5TXVV3EVBNHHCWX2XSI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4260/714801719@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4260@github.com>
References: <quicwg/base-drafts/issues/4260@github.com>
Subject: Re: [quicwg/base-drafts] Make TLS Optional (#4260)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f920a5d7b6cf_5019b4210034"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: guilt
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/jMwwf0wB87Av87OUcMp7AOvL2Qk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2020 22:40:32 -0000

Hi Ted,

Thank you for the explanation. I just felt that the points on having middle systems and proxies currently exists today, with edge devices, CDNs, layer 7bload balancer and reverse proxies, and only ends up adding a layer of encryption and decryption at each step. While this is perfect for secrecy, it fails to account for the I numerous websites powering our internet, which are not single monolithic systems by themselves.

Besides, TLS itself relying on trusting the certificates of many providers including the government and some ISPs still makes it easier for a rogue actor to snoop on one's privacy today.

The other factors to ideally consider would be the time needed to recieve multiple wireless packets over the wire and enable decryption them, preferably with quantum resistant curve algorithms (or some such) which only amplifies the amount of money thrown at the problem, not necessarily enabling more people to use this otherwise well engineered protocol.

Hence I made the suggestion was to make it optional, and that the people who will perform the complete deployment of a system may choose the right points to enable the usage of such privacy, as need rises.

 I know this wasn't the original design goal, hence I request the folks to consider,possibly for the future, having a way to define this mechanism in the wire.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4260#issuecomment-714801719