Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)

[MikkelFJ <[e-mail]>]

As to the opposing views: how likely is it that the majority of the
transport parameters would be the same for a QUIC version that does not
rely on TLS, for example a version optimized for constrained IoT devices?

I’d argue that most parameters would be the same and further, that it is
likely that a server would then have to deal with both a TLS version and a
non-TLS version.

In this light, coupling TP close to TLS appears sub-optimal.

Mikkel

On 16 December 2019 at 02.03.48, Martin Thomson ([e-mail])
wrote:

The question here is to what extent we consider the TP encoding to be part
of the QUIC stack as opposed to the TLS stack. One school treats the
transport parameters as an opaque carrier of bits, leaning on the abstract
interface we have defined between transport and TLS. The other says that
implementation strategy might differ and the similarities with TLS can be
exploited in some implementations.

The parallel drawn to the KDF function TLS provides is clearer - at least
in my mind - about this distinction. TLS provides a KDF in the form KDF(secret,
label, output_length) that QUIC uses. We did at various points in the
process consider modifications to that KDF, but the current form is very
clear about leaving the KDF function unmodified.

I think are more pertinent questions here is the relative cost change
against the improvements that might be gained. The advantage of retaining
the current form is that it can be more tightly integrated into a TLS
stack. The advocates for change see the potential for removing a single
instance of bespoke encoding from the QUIC stack, plus a modest reduction
in handshake size.

We've heard that at least one implementation would find changes to be
disruptive. I might separately observe that disruption to an existing
implementation is not a great motivation for opposing a change on its own,
because we all knew the risks when we decided to build to a draft
specification.

If we were to make arguments from some principled basis, I would say that
the bag of bits view holds: QUIC is responsible for constructing and
consuming transport parameters as an opaque blob. But that's not really a
useful basis for making a decision when there are more substantive matters
at stake.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/quicwg/base-drafts/issues/3294?email_source=notifications&email_token=AABPGNY3QHHKT57CZC5OK6DQY3HXHA5CNFSM4JYYCAEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG5HKAA#issuecomment-565867776>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABPGN32TGIJVVQ4YMRINDTQY3HXHANCNFSM4JYYCAEA>
.


-- 
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/3294#issuecomment-565997951