Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification.
We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = Extensions and message reuse = We were sorry to find that some TLS 1.2 extensions were reused with a different meaning, or that some TLS 1.3 extensions were context dependent, which does not allow for a clear separation between the parsing step (which might lead to a decode_error alert) and the message validation step (which might lead to an invalid_parameter alert). It is especially disappointing since the choice made for the ciphersuites is a very clean one. The first example of such a problem is the signature_scheme and signature_algorithms enums. In practice, the signature_algorithm must contain information valid for TLS 1.2 and TLS 1.3, but the exact meaning is not the same in both cases. It would be cleaner to have a new, separate extension called signature_scheme, defining the new enum. This way, a TLS 1.2/1.3 client implementations would send both extensions. We would spend 10 bytes on the wire, but it is not that important for the first message which can be kept reasonably long (and which is sometimes padded via the corresponding extension...) Another example is the key_share extension: it is in fact made of three different extensions, depending on the message where it is included. It would be simpler for a (almost-)stateless parser* to either use three different extensions or to use the same content each time. In the second case, the extension would each time consist of a list of (group + optional keyshare). The advantages of such a unified keyshare extension would be: - stateless parsing* - no reuse of supported_groups which can be merged with key_share - no more validation complexity since higher-level checks were already required (the groups sent by HRR did not came with a key share for example). The major con one might see is that the server can not advertise its supported groups in an encrypted manner anymore (since supported_groups is not used anymore). However, we do believe simplifying the implementation is worth it. * Of course the parser still has to use the extension id to know how to parse the value, but it would not need to have broader context (the message where the extension is included). In other words, we would like select syntax in structs to only use local information. I can try and propose a PR for each extension if there is an interest in the WG. Olivier Levillain _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
