Re: [TLS] I-D Action: draft-ietf-tls-ctls-01.txt

[Ilari Liusvaara <[e-mail]>]

On Mon, Nov 02, 2020 at 10:14:48AM -0800, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
>         Title           : Compact TLS 1.3
>         Authors         : Eric Rescorla
>                           Richard Barnes
>                           Hannes Tschofenig
> 	Filename        : draft-ietf-tls-ctls-01.txt
> 	Pages           : 19
> 	Date            : 2020-11-02

Some comments:

- Section 3.1.  Varints:

  Using varint encoding is problematic for PskIdentity.obfuscated_ticket_age
  and NewSessionTicket.ticket_age_add, since these are actually
  cryptographic values, and cryptography and variable-length do not
  mix. RFC8446 defines these to be uint32_t, so they would get caught
  by the varint rule.

- Section 3.2.  Record Layer:

  How are alerts represented? Some TLS alerts are in plaintext.
  Especially:

  * Server puking on something in client hello.
  * Client puking on something in server hello.

  And some TLS libraries have more cases:

  * Failing to decrypt first encrypted server record.
  * Client puking on anything in EE..serverFinished.

- Section 3.2.  Record Layer:

  Could be useful to divide transports into three classes (these classes
  are isomorphic to socket types in Linux):

  * DGRAM: Packet-oriented, unreliable (e.g., UDP)
    + Length: OPTIONAL
    + Sequence numbers: REQUIRED
  * STREAM: Byte-oriented, reliable (e.g., TCP)
    + Length: REQUIRED
    + Sequence numbers: OPTIONAL
  * SEQPACKET: Packet-oriented, reliable (apperntly SCTP can do this)
    + Length: OPTIONAL
    + Sequence numbers: OPTIONAL

- Section 5.  Template-Based Specialization:

  I fear that having specialization work without modifying transcripts
  leads to prohibitive complexity. Especially considering that cTLS
  seems to be aimed at (semi-)constrained environments.

  Being able to directly work with on-wire specialized represenations
  would be much simpler code-wise. And I would guess that to make that
  safe, one would only need to inject the profile hash into handshake
  (as sythetic message, in style of how first ClientHello is bound
  on restart in TLS 1.3).

  This would require being able to canonically serialie profiles, which
  would have implications as detailed below.

- Section 5.1.  Specifying a Specialization:

  If this is ever serialized, entiere use of JSON needs to be dumped.
  The reason for this is that it is not dictionaries (objects) are the
  problem in canonicalizing JSON, it is numbers that are the problem.

  There exists CBOR, which is essentially binary encoding of mildly
  extended version of JSON. The main differences:

  * There is octet string type.
  * Dictionaries can also be keyed by integers and octet strings (and
    one can mix-and-match the types in the same dictionary).
  * Integer range is limited to -18446744073709551616 to
    18446744073709551615 (superset of interoperable JSON).
  * Canonicalization is easy.

- Section 5.1.  Specifying a Specialization:

  suppressSequenceNumber seems to only make sense if DGRAM transports
  are supported. And in that case, one needs mechanism to retransmit
  lost handshake messages.

  And considering apperant itended scope, the DTLS 1.3 mechanism looks
  to be way too complex.

- Section 5.1.  Specifying a Specialization:

  dhGroup could also save some more bytes (3?) by having key_share
  encode the raw share, and then reconstruct one-element list from that.

- Section 5.1.  Specifying a Specialization:

  signatureAlgorithm could save 2 bytes by having it also automatcally
  encode the signature algorithm value in server CertificateVerify
  message.

- Section 5.1.  Specifying a Specialization:

  Some more ideas for specializations:

  * Server signature size (saves 1 byte)
  * ECDSA signature compression (saves ~7 bytes).

  (note that uncompressed ECDS signatures do not have constant size,
  but compressed ones do).

- Section 5.1.1.  Requirements on the TLS Implementation:

  Ascending order will not work with extension 41, as it is magic and
  needs to be last. 0 to 40, 42 to 65535 and 41 would work.

- Section 6.  Examples:

  Why is that '"named_groups": 29' there?

- Section 6.  Examples:

  Why is the ALPN extension encoded as "030016832"? That doesn't even
  seem to be of integral number of octets. I get that the value should
  be "03026832".
   
- Section 7.  Security Considerations

  On transcript expansion, suppressSequenceNumber looks to make any
  sense only if DGRAM transports are also supported, and it is not
  obvious to me that uncompressing to TLS 1.3 is possible in such
  cases.

  It is also not obvious to me that explicit transcript expansion can
  be implemented with acceptable complexity, especially considering
  the apparent intended scope.



-Ilari