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

[Ilari Liusvaara <[e-mail]>]

On Sun, Apr 26, 2020 at 02:10:02PM -0700, [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-00.txt
> 	Pages           : 17
> 	Date            : 2020-04-26
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-ctls-00
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-00

First impressions:

- I think this protocol should use different label in key derivations
  from the "tls13" label used by TLS 1.3. I do not see any fundamential
  reason why transcripts could not collide with TLS 1.3 ones.

- It seems not be possible for server to support multiple profiles at
  once. This could be useful for things like updating clients to use
  better algorithms.

- It probably makes sense to support the case where client profile has
  incomplete list of certificates. E.g., some IoT client only knows its
  own and server certificates, whereas the server knows all
  certificates.

- If one wanted dual TLS 1.3/cTLS server, one would presumably have to
  define TCP mapping.

  Simplest one that might work: Connection starts with fixed byte
  (which should not be 20-126 to be able to tell the thing apart from
  both TLS 1.x and HTTP), followed by sequence of records, where each
  record is prefixed with varint length. Application data records
  transport application data.

  However, cTLS is not quite "TLS 2.0", as that would presumably move
  some important extensions into top-level messages. Especially stuff
  like supported_groups, key_share and pre_shared_key.

- There is one special case where epoch is not clear: alert mesages in
  response to server handshake. These can be unprotected despite being
  in position where protected record is possible.

  It is possible to tell apart unprotected alerts from everything else
  by size. Unprotected alerts are 2 bytes (if the useless severity field
  is stripped out), and no protected record can be that small.

- Just blindly switching all integers to varints does not work, as there
  are integer fields that can legimately have integer values >=2^22.

  TLS 1.3 spec itself has two of those: PskIdentity.obfuscated_ticket_age
  and NewSessionTicket.ticket_age_add. And with those two, it is not
  even possible to just take modulo 2^22, as the time unit is
  milliseconds, so that would limit the ticket age to just ~70 minutes.

  Some extensions have more integer fields that can be >=2^22, but none
  that I can find where limiting to 2^22-1 would be a significant issue.

- Strict ascending extension sort probably does not work, as extension
  41 is magic due to having to be last in client hello. If there is
  strict extension sort, most straightforward fix would be to make the
  order 0,1,2,3,4,..,39,40,42,43,,..,65534,65535,41.

- Some ways to eke a few more bytes out of profiling:

  * If group is specified, move key share out of extensions.
  * If group is specified to something with fixed length, omit the 
    group length.
  * If using uncompressed P-x keys, strip the 04 prefix (does not work
    with X25519 nor X448, as there is no prefix).
  * If using compressed P-521 keys, stuff the sign bit into unused bit
    of the x coordinate field (does not work with P-256 nor P-384 as
    there are no unused bits in x coordinate field, nor with X25519 nor
    X448 as there is no sign bit).
  * If signature algorith is specified, omit the signature algorithm.
  * If EncryptedExtensions is empty, omit it (can tell if it is there
    from type sequence).
  * Re-encode ECDSA signatures to raw form (can also be done without
    profiling; does not work with Ed25519 nor Ed448 as the signatures
    are already in raw form).
  * If signature algorithm has fixed signature length, omit it in
    signatures (e.g., Ed25519 and raw form ECDSA/P-256 are always
    64 bytes; can also be done without profiling).

- The example in A.1 looks suspect:

  * Why is client_shares.length encoded as 2 bytes? it is vector
    length <128, so should be 1 byte?
  * Why is KeyShareEntry.group encoded as 2 bytes? It is enumeration
    value <128, so should be 1 byte? (Both in Client Hello and Server
    Hello).
  * Why is length of KeyShareEntry.key_exchange encoded as 2 bytes?
    It is vector length <128, so should be 1 byte? (Both in Client
    Hello and Server Hello).
  * Why does the signature start with 4047? The signature should be
    71 bytes, so should be 47? (Both in server and client flights).

- And example in A.2 has this:

  * Server hello has 18 bytes = RANDOM(16) + 2 ... Those 2 are
    presumably  overhead?
  * Client Flight: 1 byte = Overhead(3) ... Should presumably be
    1 byte of overhead.
  

-Ilari