On Sat, Jul 09, 2022 at 02:32:07PM -0700, internet-dra...@ietf.org 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
