Subject: [quicwg/base-drafts] Unknown transport parameters cannot be ignored if no length is provided (#1661)

From: mirjak <[email-masked]>
Date: Tue, 14 Aug 2018 06:51:22 -0700

Sec 6.6.3 of the transport draft says:
"An endpoint MUST ignore transport parameters that it does not support."

However, the length of the parameter value is implicitly defined by the parameter type. If the parameter type is unknown, the length if unknown is well. Without knowing the length one cannot jump to the next value. What do i miss?

To be honest I also don't find it very intuitively to use the TLS presentation language here as it just introduced a "dependency" on TLS. However, for TLS this is only an additional data blob that is does not need to understand. Therefore I would prefer to "just" use some TLV encoding here.

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Aug 2018 16:53:32 +0000 (UTC)

What you missed is that the TLS presentation language makes length prefixes implicit.  The generic definition for a TransportParameter is:

```
   struct {
      TransportParameterId parameter;
      opaque value<0..2^16-1>;
   } TransportParameter;
```

That means that `value` is a sequence of bytes with a two-byte length prefix.  Everything else defines the content of `value` for particular values of `parameter`.

Separately, while I agree that there's a dependency on the TLS *document* for the definition of the presentation language, there's actually no dependency on TLS *libraries* for generating this sequence of blobs.  It's a convenient notation for a binary structure, just as ABNF is a convenient notation for a text structure.  I'm with you that I wish it were a separate RFC rather than being a section in a TLS draft, but that's not the province of this WG.

-- 
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/1661#issuecomment-412941132

---

From: mirjak <[email-masked]>
Date: Tue, 14 Aug 2018 13:09:28 -0700

Ah, right. Now I remember that I looked it up (and then forgot again). Maybe worth explicitly mentioning (instead of "just" point to the TLS RFC).

-- 
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/1661#issuecomment-412999010