[Emu] Review of draft draft-ms-emu-eaptlscert-02

["Anoop Kumar Pandey" <[e-mail]>]

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.
------------------------------------------------------------------------------------------------------------