Re: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one
Palmer, Thomas <thomas.palmer@...>
Jiaxin / Qin,toggle quoted messageShow quoted text
I'm unaware of what criteria is required for a cipher to be in this TlsCipherMappingTable. I had presumed that it would be b/c UEFI supported the cipher for TLS operation. If unsupported ciphers are allowed ... then logically wouldn't we need to add all ciphers? What advantage do we gain by having an entry in this table but not actually use the cipher in communication?
Currently TlsGetCipherString is the only means we have to validate the cipher string. If a cipher is in the table but not in OpenSSL lib, then we will provide imperfect feedback if the unsupported cipher is buried in a list of supported ciphers. OpenSSL will simply use only the ciphers it supports and quietly drop the unsupported cipher. A user that inspects the list of set ciphers would be curious why a certain cipher was being "dropped" / "filtered". However, if TlsGetCipherString sees that the cipher is not in our mapping table the TlsSetCipherList function will return immediate feedback.
I'm not enthralled with supporting weak/idea ciphers either. I would vouch for us removing those ciphers from TlsCipherMappingTable. It is not our responsibility to document the IANA/Description string description in code.
This document (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf) would be a good list for initial cipher support. We have some of the ciphers on the list already. Here is the sorted list:
From: Long, Qin [mailto:email@example.com]
Sent: Sunday, July 31, 2016 8:48 PM
To: Wu, Jiaxin <firstname.lastname@example.org>; Palmer, Thomas <email@example.com>; firstname.lastname@example.org
Cc: Ye, Ting <email@example.com>; Fu, Siyuan <firstname.lastname@example.org>; Gao, Liming <email@example.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one
I personally prefer to keep the current supported cipher suite for our UEFI-TLS enabling. We can have the full RFC definitions, and platform specific cipher sets for validation now. It's better to maintain one minimal scope in this phase.
"enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the recommendation for hardening SSL communications.
For other ciphers (idea, dsa, etc), we can enable them step-by-step depending on the real requirements.
Best Regards & Thanks,