Draft Review (draft-ms-emu-eaptlscert-02) Title: Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods URL: https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02
Description: The draft talks about large TLS certificates with long certificate chains. This may result in fragmentation into smaller packet as EAP fragment size is typically is just 1000-1500 bytes. The fragmentations could cause latency and in some cases EAP authenticator implementations may drop the EAP session after 40-50 packets. The draft gives an overview of methods and tools for overcoming the deployment challenges induced by large certificates. Review: Section 3 talks about various reasons for a certificate being large. Subject Alternative Name field is typically used for multi-domain or wildcard certificates (fb.com, *.facebook.om, facebook.net, messenger.com) where all domains are protected by same certificate. I doubt that SAN will be a reason in IoT world for larger certificate. Similarly key size and signature field is in bits (e.g. 2048 bit key, 2048 bit signature, 224 bit key if ECC is used). So this also shouldn't contribute to a larger certificate. The same can be said about OID and user groups. Key usage is limited to digital signature (80) [just one usage] in an end device certificate. Section 4.1 claims RSA key sizes and digital signature size to be 384 bytes which is wrong. The RSA key size is 1K to 4K (1024 bit to 4096 bit) practically and corresponding ECC key will range from 160 bits to 256 bits. The size mentioned by the authors is the size of the entire certificate. Authors may refer ( <https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptogr aphy-standards/documents/presentations/session2-ford-warwick.pdf> https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptogra phy-standards/documents/presentations/session2-ford-warwick.pdf) for further optimizations pertaining to ECC adoption. Section 4.1.1 talks about shortening or avoid certain fields in the certificate. Mostly the changes are marginal and the authors have not presented quantitatively, how much saving in certificate size could be achieved with it and will it be sufficient. Section 4.2.1 talks about pre-distributing and omitting CA certificate. It will require constant update of CA certificates whenever new CAs are licensed or license of existing CA is revoked. Large chain validation can be avoided by using cross CA validation also instead of hierarchical validation. A common certificate repository (like Google Certificate Transparency <https://transparencyreport.google.com/https/certificates?hl=en> https://transparencyreport.google.com/https/certificates?hl=en) could also be used and chain validation may not be required in this case. Section 4.2.2 will only work if at least one successful authentication has occurred. If any certificate change happens (expiry, revocation, key change), then again this method will fail. Section 4.2.3 talks about compressing the certificate. This is achievable, however the capability to compress, decompress and performing ECC certificate validation within a small IoT device is questionable. P.S: In EAP-TLS, isn't there clear direction on how many packets exchange are allowed before dropping EAP session. Why do some implementations drop session after 40-50 packets itself? In the standard of EAP-TLS, can the no. of exchange packets be increased? If yes, apart from latency, what other impact could it have? Regards, Anoop Kumar Pandey Principal Technical Officer C-DAC Bangalore India ------------------------------------------------------------------------------------------------------------ [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
