Hi Hannes,Thanks for the follow up. I have submitted a new version which should address your concerns. Here is a diff for your convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05
Please see in-line for details. I believe that the draft is now ready for publication. --Mohit On 6/10/20 12:02 PM, Hannes Tschofenig wrote:
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."
Done!
I agree that all code indeed should be updated to fix bugs and vulnerabilities. However, updating applications and certificates is certainly different from updating the underlying TLS library and EAP implementation. Administrators in enterprise environments (where EAP-TLS is widely used) have great control over when and how the server and client updates are rolled out. The categorization in section 4 should help administrators to decide how to avoid the fragmentation problem. Whether it is issuing new certificates, updating the access points, or updating the TLS and EAP-TLS implementation. Nonetheless, I have added the following text: "This section discusses how the fragmentation problem can be avoided by updating the underlying TLS or EAP-TLS implementation. Note that in many cases the new feature may already be implemented in the underlying library and simply needs to be taken into use."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.
You had raised this issue before and I had responded to you before. Here is the response again:
Where does RFC 7924 (https://tools.ietf.org/html/rfc7924) talk about populating the cache with an out-of-band mechanism? The text in Section 1 of RFC 7924 clearly states that: "This specification defines a TLS extension that allows a client and a server to exclude transmission information cached in an earlier TLS handshake.". Notice the "earlier TLS handshake" part. I certainly refuse to add or describe new functionality which isn't discussed in the original RFC.
I understand your desire of making cTLS look good. I am not sure how hiding the information that cTLS doesn't interoperate with older versions of TLS helps. Anyhow, I have removed that sentence since progressing the draft at this is stage is more important than arguing over one sentence.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.
Added a new sub-section.With this, I believe that all issues are resolved and the document is ready for publication.
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
