Make TLS Optional #4260
Comments
|
The QUIC working group is chartered 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. |
|
Why are you people asking for suggestions to the Quic 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. Please stop closing tickets without addressing why we need this. Storage appliances, for instance could benefit from not having to re-encrypt packets from disk. Low power devices could relay streams with a different application controlled / network controlled access mechanism. Plus, when there is already an encryption overhead in tunneled networks, why should endpoints enforce TLS when they can instead spend that effort doing other things? There is a version field of 0x00000001 to specify when using TLS. Why not define an unmapped version for non-TLS, and possibly 2, 3, 4 etc. for specifying the newer better handshakes? |
|
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. |
|
@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. |
|
@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). Non-TLS can lead to true zero RTT updates, suitable for some embedded devices with low ROM footprint and power transmission. If someone needed any encryption, they could move it to the payload than the transport. The original HTTP design had both, and I'd like this to be considered duly. I thank you for spending some time on this ticket. I apologize if any of my comments sounded prudish, I thought this was the right place to ask for it and my rationale is as stated. |
|
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 < ***@***.***> 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)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4260 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKVXZEC6NHR7B3TR6TXDJDSMCMFZANCNFSM4S3UOF6A>
.
|
|
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 7 load balancers and reverse proxies 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 innumerous 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 on them, and 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. This protocol works well for long term traffic, and not necessarily short term busty traffic (1 RTT now becomes 3) 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 an extensibility/way to define this mechanism in the wire, preferably bypassing the TLS requirement as needed. -Karthik |
|
This thread is outside the scope of the QUIC WG. I'm now locking it. |
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.
The text was updated successfully, but these errors were encountered: