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

From: Karthik Kumar Viswanathan <[email-masked]>
Date: Thu, 22 Oct 2020 12:37:33 -0700

I want to indicate the presence of TLS as optional, especially for public / relay broadcast devices which do not require privacy as much as they could use lower power. Plus, there must be a way to let QUIC use an alternative as opposed to TLS, where need be.

-- 
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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Oct 2020 12:43:46 -0700

Closed #4260.

-- 
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#event-3910850035

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Oct 2020 12:43:46 -0700

The QUIC working group is [chartered](https://datatracker.ietf.org/wg/quic/about/) to specify an always-encrypted protocol, and TLS1.3 is our default way to do so. There has been research work on replacing the TLS handshake with something else, but no standards work is chartered on that at the moment.

-- 
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-714720108

---

From: Karthik Kumar Viswanathan <[email-masked]>
Date: Thu, 22 Oct 2020 12:46:54 -0700

Why are you people asking for suggestions to the WG filed as issues if you are not open to the simplest possible way to implement UDP based transport? 

This is being asked for the IETF formalization and QUIC has, IMO, a real issue. Stop closing tickets without addressing why we need this.

-- 
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-714721700

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Oct 2020 12:49:32 -0700

The working group **cannot** do standards work outside its charter. You are welcome and start a discussion on the mailing list on a potential recharter effort; a GitHub issue is not the place for this.

-- 
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-714723015

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Oct 2020 13:44:36 -0700

@guilt The first 6 documents forming the core of QUIC and HTTP/3 are in IETF last call. This is near at the end of the publication process. The WG has done its work and designed a protocol and written its specification and thinks it is ready for publication. So the IETF last call is to determine the IETF consensus to publish the written specification and identify any remaining issues and determine if they required to be addressed now or not. 

As @larseggert said what you are proposing are outside of the charter. Yes, future versions of QUIC can be defined. But such work in IETF will require new chartering and establishment of sufficient interest in doing that standardization work. 

-- 
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-714751171

---

From: Karthik Kumar Viswanathan <[email-masked]>
Date: Thu, 22 Oct 2020 13:58:08 -0700

@gloinul @larseggert Thank you for that explanation, I didn't realize that this was off the charter. However, I found that this was the only thing that could require worthwhile investigation. 

I always thought TLS was backported IMO based on its mandation in HTTP/2, and before the finalization, felt Quic could fix that problem by making sure the transport isn't enforced. I knew some people who had configured TLS_NULL_WITH_NULL_NULL to get around some of these issues and I didn't want things like that to get repeated, hence wanted a clear inversion of control: either always encrypted (privacy) or free (replay and stream broadcast)

-- 
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-714758052

---

From: hardie <[email-masked]>
Date: Thu, 22 Oct 2020 14:26:40 -0700

Hi Karthik,

The history is somewhat different, and you may find it useful to refer to
some of the original design rational:
https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit
.  As it notes, one of the key desires was to encrypt as much as possible:

Experience with SPDY development has taught us that the only way to prevent
> middleboxes from maligning a new protocol built atop UDP or TCP (e.g.,
> misconstruing it for a “known” protocol, and making “less than helpful”
> changes), is to encrypt as much of the payload and control structure as
> feasible.
>

So the choice not to provide an unencrypted variant goes back quite a long
way and was justified by arguments for privacy, data integrity, *and a
desire to avoid network-hosted middleboxes attempting to adjust the
protocol state machine*.

regards,

Ted Hardie

On Thu, Oct 22, 2020 at 1:58 PM Karthik Kumar Viswanathan <
[email-masked]> wrote:

> @gloinul <https://github.com/gloinul> @larseggert
> <https://github.com/larseggert> Thank you for that explanation, I didn't
> realize that this was off the charter. However, I found that this was the
> only thing that could require worthwhile investigation.
>
> I always thought TLS was backported IMO based on its mandation in HTTP/2,
> and before the finalization, felt Quic could fix that problem by making
> sure the transport isn't enforced. I knew some people who had configured
> TLS_NULL_WITH_NULL_NULL to get around some of these issues and I didn't
> want things like that to get repeated, hence wanted a clear inversion of
> control: either always encrypted (privacy) or free (replay and stream
> broadcast)
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/4260#issuecomment-714758052>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAKVXZEC6NHR7B3TR6TXDJDSMCMFZANCNFSM4S3UOF6A>
> .
>

-- 
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-714771584

---

From: Karthik Kumar Viswanathan <[email-masked]>
Date: Thu, 22 Oct 2020 15:40:29 -0700

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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 22 Oct 2020 15:49:51 -0700

This thread is outside the scope of the QUIC WG. I'm now locking it.

-- 
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-714804688