Subject: [TLS] presentation language description is not great

From: Stephen Checkoway <[email-masked]>
Date: Wed, 26 Jul 2017 10:59:05 -0500

Stepping back a bit from my previous messages on `select`, I took a broader look at how the presentation language (PL) is used to define the bits that get sent over the wire. In essence, the presentation language defines types and encodings of types.

At a high level, there are 46 types that are defined in Appendix B which break down as follows.

- 1 type alias
- 2 fixed-length vector types
- 2 variable-length vector type
- 9 enumerated types
- 32 structure types

The description of the PL, given in Section 3, fails to give meaning to 27 of these definition. Now the draft has gone through 2 WGLCs and if perhaps nobody cares at this point in which case I'll drop it, but I find this situation faintly ridiculous.

The 4 fixed- and variable-length vector type definitions
    opaque Random[32];
    uint8 CipherSuite[2];
    opaque PskBinderEntry<32..255>;
    opaque DistinguishedName<1..2^16-1>;
and the 9 enumerated type definitions appear to be correct according to the PL.

The type alias
    uint16 ProtocolVersion
has an obvious meaning, but type aliases don't appear in the PL.

Only 5 of the 32 structure types (two of which are empty) are described by the PL. In fact, two of the example structures given in Section 3 don't fit the description for a structure which appears just before the examples. The two main problems with structures are (1) fixed- and variable-length vector fields aren't allowed (the PL only defines fixed- and variable-length _type definitions_); and (2) most of the uses of variants (`select`) don't match the PL as I described in great detail in my previous thread.

The PL has a few additional quirks that would be nice to fix as well.

- Anonymous structures are allowed, but unused. They should be removed from the PL.
- Variants have an optional field label that is used once (for `Handshake`) but that use serves no purpose. The optional label should be removed from the PL.
- One of the predefined types, `uint64`, isn't used. It could be removed.
- Constants should be restricted to numeric and enumerated types, since otherwise the PL would need a syntax for other types and we don't need it.

My motivation for all of this is it would be nice to have a clean PL that is easily machine parsable. This would enable ensuring that future changes to TLS (e.g., extensions) use a consistent syntax. It would also enable (at least in theory) parsers generated directly from  the standard.

(As an aside, while writing this email, I noticed another issue with `TLSCiphertext`, the first field (a constant) should be `ContentType opaque_type = application_data;` and not `ContentType opaque_type = 23; /* application_data */`. I'll create a PR to fix that after lunch.)

-- 
Stephen Checkoway

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Jul 2017 11:51:01 -0500

> My motivation for all of this is it would be nice to have a clean PL that is easily machine parsable. This would enable ensuring that future changes to TLS (e.g., extensions) use a consistent synta…

It would.  It would also be nice to actually get the spec out the door,
a spec that has already made it through two WGLCs, no less.

TLS presentation language is (basically) only used to specify TLS, TLS
implementors are largely familiar with its quirks already, and it
doesn't seem like a good use of the WG's time to try to change it for
TLS 1.3.  Which is not to say "don't try", but I don't see how this is
worth delaying the publication of TLS 1.3.

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 26 Jul 2017 18:56:34 +0200

I agree with Ben. It is too late

On 07/26/2017 06:51 PM, Benjamin Kaduk wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Jul 2017 10:03:47 -0700

I don't think it's useful to rework the PDUs significantly. That's a great
way to really mess things up.

If you think that there are changes to the *description* of the language
that would make it easier
to read that description and then read the PDUs, PRs might be useful. Also,
very small tweaks
to the actual PDUs might be useful, but a total rework is out of scope.

-Ekr

On Wed, Jul 26, 2017 at 9:56 AM, Hannes Tschofenig <
[email-masked]> wrote:

> >> My motivation for all of this is it would be nice to have a clean PL
> that is easily machine parsable. This would enable ensuring that future
> changes to TLS (e.g., extensions) use a consistent syntax. It would also
> enable (at least in theory) parsers generated directly from  the standard.
> >