Subject: [TLS] New draft: Pseudorandom cTLS

From: Ben Schwartz <[email-masked]>
Date: Fri, 29 Oct 2021 09:47:22 -0400

Hi TLS,

As discussed during the meeting at IETF 111, we’ve been working on an
extension to cTLS that transforms the record layer into a pseudorandom
bitstream on the wire, and it’s ready for its first review.

https://datatracker.ietf.org/doc/html/draft-cpbs-pseudorandom-ctls-00

Please review and send comments.  We’ll also be presenting an overview of
this draft at the upcoming TLS session.

This proposal depends heavily on the details of the cTLS headers, so it
will have to evolve as cTLS changes.  Part of the reason to develop it now
was to offer feedback on the cTLS design.  After developing this draft, we
offer the following suggestions and requests for cTLS proper.

 * Clarify extensibility rules.  cTLS enumerates keys in the template, but
does not explain how templates can be extended.
   - Suggestion: Clients must reject the whole template if it contains any
key they do not understand.  The “optional” key holds a map of optional
extensions that are safe to ignore.

 * Discuss encoding of Alerts.  It’s currently not clear how plaintext
Alerts are represented.
  - Suggestion: content_type = ctls_alert

 * Discuss fragmentation of handshake messages in cTLS/UDP.  The current
text doesn’t mention this, although it seems relatively clear how it’s
expected to work (using the DTLS Handshake struct).

 * Make fragmented handshake messages self-delimiting in cTLS/TCP so that
recipients can detect the end of a handshake message from the CTLSPlaintext
header alone.
   - Suggestion: Senders set content_type = ctls_handshake_end for a
message’s final fragment.

 * Make header size less variable.  For cTLS/TCP, the headers could all be
the same size.  For cTLS/UDP, the header sizes could be made predictable.
   - Suggestion: Always suppress sequence numbers and disallow connection
IDs in cTLS/TCP.  Move profile_id into ClientHello.  Always include the
connection ID and sequence number in the first record of a cTLS/UDP
datagram, and never in subsequent records.

Thanks,
Ben Schwartz, Chris Patton