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

[Ilari Liusvaara <[e-mail]>]

On Sat, Jul 09, 2022 at 02:32:07PM -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
>                           Benjamin M. Schwartz
>   Filename        : draft-ietf-tls-ctls-06.txt
>   Pages           : 24
>   Date            : 2022-07-09

Reviewing this (again after version update):


1) Section 1. Introduction:

> More compact encodings, for example point compression.

I think it would be better to define compact versions of NIST curves
(and maybe Brainpool curves too) and register those into supported
groups registry (where those could also be used in (D)TLS).


2) Section  2.1. Template-based Specialization:

> OPEN ISSUE: Is it really worth converting snake_case to camelCase?
> camelCase is slightly more traditional in JSON, and saves one byte,
> but it seems annoying to implement.

I think both are equally bad choices, with implementation complexity
dominated by having table mapping names to codepoints.

And I remember many TLS 1.2 implementations using nonstandard forms of
ciphersuite names in ciphersuite configuration (e.g., OpenSSL).


3) Section 2.1.1. Initial template elements 

I think the following should be added:

- More efficient ECDSA signature encoding. Right now, ECDSA signatures
  use ASN.1 encoding, which is very inefficient in communication-
  constrained environments. Using simple concatenate-raw-r-and-s
  encoding would be more efficient.
- Option to force extension blocks on any chain certificates to be
  empty. Those are very rarely used for anything.


4) Section 2.1.1.5. signature_algorithm 

This should presumably omit CertificateVerify.algorithm, and make
CertificateVerify.signature a static vector if signature has constant
length (e.g., EdDSA, concatenate-r-and-s encoding of ECDSA).


5) Section 2.1.1.6. random 

> OPEN ISSUE: Karthik Bhargavan suggested the idea of hashing ephemeral
> public keys and to use the result (truncated to 32 bytes) as random
> values. Such a change would require a security analysis.

Another idea: If using ephemeral public keys, just set random=0 (as
the random field was not actually doing anything anyway). However,
if not using ephemeral public keys, repeating a random value is very
bad idea (on server side it is bad to repeat random value pair), let
alone setting random=0.


6) Section 2.1.1.8. client_hello_extensions, server_hello_extensions,
   encrypted_extensions, and cert_request_extensions 

In client_hello_extensions, extension 41 needs special handling, as
the corresponding extension is magic in TLS 1.3 (it has to be the last
extension).


7) Section 2.1.1.10. handshake_framing 

This section does not seem to handle the case of SEQPACKET transport:
Ordered, reliable and packetized. Such transport is neither stream nor
datagram transport. However, it should be treated like stream transport
here (that is, use ScTLS).

This seems to have further problem of being the only place that selects
between ScTLS and DcTLS. I would expect this to be in some more central
place than discussion of some (bit obscure) knob.

Then I don't see anywhere that DcTLS presumably uses the whole ACK
machinery from DTLS, but ScTLS does not.


8) Section 2.2. Record Layer

This gets the SEQPACKET case right: !stream and reliable/ordered gives
desired properties (allowing omitting lengths and no sequence numbers).


9) Section 2.2. Record Layer 

The E bits should presumably be hardwired to zero on reliable/ordered
transports. As reliable/ordered corresponds to TLS 1.3, and TLS 1.3
has no equivalent of E bits (as it never needs to handle out-of-order
key update).


10) Section 2.3.2. The Transcript layer 

If one has many clients using client certificate authentication in
communication-constrained environment, one likely wants to use per-
client profile. This avoids blowing up client storage and updates with
client certificates. The server is likely much better equipped to handle
the storage demands.

(Took me far too much time to come up with this.)


11) Section 3.3. HelloRetryRequest 

> OPEN ISSUE: Does server_hello_extensions apply to HelloRetryRequest?

The format of extensions in server_hello and hello_retry_request is
not even the same:

- tls_cert_with_extern_psk, pre_shared_key and connection_id are only
  valid in server_hello.
- cookie is only valid in hello_retry_request.
- key_share only has the key_exchange field only in server_hello.
- (I can't make heads or tails about what is going on with Dragonfly).


12) Section  5. Security Considerations 

> Transcript expansion also needs some analysis and we need to
> determine whether we need an extension to indicate that cTLS is in
> use and with which profile.

Wasn't transcript expansion removed?



-Ilari