Re: Historic TLS Discussion

[Jana Iyengar <[e-mail]>]

Hello Nicholas,

On reasoning for why we have TLS, I'll add a few points to the discussion:

Encryption is not an option anymore if you want to see anything deployed
and continue to evolve on the Internet. It hasn't been for decades now, and
there's tons of evidence for this that I won't go into here. The QUIC wg
accepted this premise very early on, and it was in the charter early as I
recall.

We tried to keep the crypto part of it "pluggable". Early versions of the
QUIC transport draft had "Crypto Requirements" as sort of an API, that
would be met by the QUIC-TLS mapping document. Our initial thinking was to
keep TLS as much out of the QUIC transport as possible... but at some point
it became too unwieldy. It became clear that without another clear mapping
to another handshake, it was going to also possibly be the wrong
abstraction. Additionally, we had the HTTP use case as the primary one that
drove the work of the wg, so it was clear that TLS was going to be it for
now. We'd figure out other mappings as they became useful/necessary. As
Lucas noted, there is at least one other mapping, so there is existence
proof, but none has been standardized yet.

QUIC used QUIC-Crypto while at Google, but some of us spent a considerable
amount of time figuring out how to map from what was already there to a
nebulous TLS1.3 back in 2015-2016, before the BoF. Martin's talk at the BoF
covers this, and Adam Langley did a talk at SAAG in 2015 alluding to this
expected transition from QUIC-Crypto to TLS (link
<https://www.ietf.org/proceedings/92/slides/slides-92-saag-5.pdf>).

To the question of what happens if TLS moves to 1.4 (or god forbid, 4), I
expect the path would be that we'd consider the implications of the
changes, and issue a new QUIC-TLS document making QUIC work with TLS-1.4,
as anyone would for any new crypto protocol that needs to be used with QUIC.

- jana

On Thu, Jan 25, 2024 at 2:05 PM Nick Harper <[e-mail]> wrote:

>
>
> On Thu, Jan 25, 2024 at 3:29 AM Ted Hardie <[e-mail]> wrote:
>
>> On Thu, Jan 25, 2024 at 7:58 AM Mikkel Fahnøe Jørgensen <
>> [e-mail]> wrote:
>>
>>> As to why TLS 1.3 specifically, I recall early on asking for schemes
>>> that were more IoT friendly.
>>>
>>>
>> You may recall that Google QUIC did not use TLS.  If memory serves me
>> correctly that was partly because Google wanted 0-RTT resumption and a few
>> other capabilities that TLS did not provide at the time.  When those
>> facilities were added to TLS in TLS 1.3, it made sense to re-use TLS rather
>> than maintain a separate crypto stack.
>>
>
> This is my recollection as well. The Google QUIC crypto handshake protocol
> was designed knowing that it would be replaced. The doc (
> https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?tab=t.0)
> calls out that the protocol was destined to die. It was created because
> there wasn't something that did 0-RTT at that point, but it would be a
> feature of TLS 1.3.
>
>>
>> I no longer work for Google, so I don't have access to my notes on this;
>> you may want to confirm with Ian Swett or one of the folks who was both
>> there at the time and is still a Googler.
>>
>> regards,
>>
>> Ted
>>
>>
>>
>>> The consensus at the time was that encryption is important for
>>> ossification prevention and non-encryption was a deal breaker, as has been
>>> explained in this thread. However, there was nothing preventing other
>>> encryption schemes than TLS and this could be added in other later QUIC
>>> versions separately, but for QUIC 1.0, IoT would not be a priority in part
>>> to get something out of the door to finalize 1.0, and in part because TLS
>>> 1.3 allows for negotiation in case some encryption turns out weak.
>>>
>>> As to network transparency for troubleshooting, various tooling has been
>>> mentioned but there are header bits explicitly exposed to measure pacing
>>> and roundtrip of encrypted packets modulating a signal that can be
>>> observed, which was deemed sufficient after some testing, although there
>>> was a push for more insight operator side of things.
>>>
>>> QUIC load balancing protocol was also discussed, partly in order to
>>> avoid early TLS termination. LBs requires access to some confidential
>>> information in order to route packets correctly. I have not studied this
>>> closely, but I guess one could introduce a load balancer to gain more
>>> insights?
>>>
>>> Mikkel
>>>
>>>