-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23-02-15 17:28, David Sommerseth wrote: > On 23/02/15 17:18, Gert Doering wrote: >> On Mon, Feb 23, 2015 at 04:51:34PM +0100, Daniel Kubec wrote: >>> Keying Material Exporter [RFC 5705] Patch rebased to actual >>> master branch. > >> There definitely needs to be much(!) more documentation about >> this, maybe an extra .txt file under doc/ - I still(!) have *no* >> idea what this is useful for, or how to use it, so right now this >> is "extra code complexity with no well-explained gain" to me. > >> I understand that David understands this, but we really really >> need to have documentation understandable to non-crypto-geeks >> about it before it can go in. > > Fair enough. > > Daniel, would it be possible to add some docs and possibly a very > simple tool + plugin which could be used to demonstrate this > feature? API docs should go into the docs/ sub-folder and the demo > code into sample/sample-plugins/. > > I suggest this comes as a separate patch, for patch > maintainability. Will probably be a good idea to even split docs > and demo/sample code into separate patches too? (I'm not too keen > on big patches doing several things)
Agreed that a bit more documentation would make this patch a lot more useful. - From a crypto perspective I think the codes is good. I do have a few practicals nits though: 1) Instead of using just M_DEBUG in dmsg(), please add a log level. Since you are printing derived key material, I think a rather high log level like D_TLS_DEBUG, or perhaps D_TLS_DEBUG_MED would make sense. 2) ekm_used in struct tls_options is equivalent to (ekm_size > 0). You could just get rid of this extra variable. 3) tls_binding_key might not be the best env var name. That name hints at the use case you have in mind for this mechanisms, but it does not cover all use cases, nor does it easily match to the 'keying-material-exporter' name of the option you introduce. Something like 'exported_keying_material' might me more appropriate. 4) We might want to enforce a minimum length for the exported keying material. How about 128 bits / 16 bytes? Just to prevent a user making a typo from ending up with ridiculously small keys. - -Steffan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU7k8PAAoJEJgCyj0AftKIWBUIAJPG7+nbNS9dRbwDzOA8NpBU d0ueiNskJ5gGTfeUoRZwPK/wSlxPtRP0j1wKg7ltwJOvgJM7MCewI2KNxobPE/BF PptAzH8PU2X8YHMRhbgfcER4CyvTlg/KUW5PEieL7c1zAjq5pkQJMqTNIToq51Wo bUmQOEdtPuY5J3PF/06NpnKr9ZigM2FiIpx+M+GOietav8MX7a4OrGQVPnaZQo6E rtwCfhVTAxeaitRsWiJjuvg5tJOCqbs7uC8imjNNM6kCZzSpfJkC1nDDP6g+JAOa mTKgrbKS1HWYDlsE8kaSg8LLADWFix8Q2lTtGeXGUlbITtHYEE2n3DEAXqtgr4I= =vOYB -----END PGP SIGNATURE-----
