Thanks for the update. A few more minor comments on -04:
Section 4.1: "TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to support ECC." This is only true absent an application profile defining something else. The UTA group has just adopted a WG item that defines such a profile. Hence, I suggest to add the remark about the profile. Something like "In the absence of an application profile standard specifying otherwise, a TLS 1.3-compliant application must support ECC." 4.2. Updating TLS and EAP-TLS Code Why are you calling the section "updating code"? The suggestion in 4.2.1 does not require code update and whether something requires a code update depends what you have in the code already. Maybe you just need to enable the feature. Updating the code is also a negative aspect because you are likely going to update the code on a regular basis anyway to fix bugs and to support new algorithms. Luckily TLS has the extension negotiation built-in and hence you can detect and negotiate new features on the fly. 4.2.4. Caching Certificates "The extension however necessitates a successful full handshake before any caching." This is not true. The spec defines a way to populate the cache by running a full handshake. However, you could also populate the cache by out-of-band means, for example by pre-distributing certs. The mechanism to re-run the handshake to populate the cache is, however, a safe fallback in case configuration changes and the pre-distributed certs become invalid. It is better to have a fallback. I thought I made that comment before. 4.2.3. Compact TLS 1.3 You are still stating "This naturally means that cTLS is not interoperable with previous versions of the TLS protocol." cTLS is a compression of TLS, which means that you can fall-back to TLS, if the other peer does not support cTLS. As mentioned in my previous email, I don't understand why you are mentioning this aspect at all given that this document is about certificate size reduction. Raw Public Keys I wonder whether you should mention the possibility to use RPKs (https://tools.ietf.org/html/rfc7250) in Section 4.1.2 because those would be a fairly obvious choice in EAP-TLS given that we are talking about a nailed up connection between the EAP peer and the EAP server. This would obviously reduce the overhead associated with certificates considerably. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
