Greetings Steffan, David and Gert Thank you very much for your comments.
1) log level switched to D_TLS_DEBUG_MED 2) ekm_size removed, ekm_size != 0 condition is used instead. 3) changed to: exported_keying_material 4) minimum set to 16 bytes and maximum set to 4095 bytes. Added 2 patches related to [RFC-5705] (code + docs). Regards Daniel On 25 February 2015 at 23:39, Steffan Karger <stef...@karger.me> wrote: > -----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----- > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
openvpn-rfc5705.patch
Description: Binary data
openvpn-rfc5705-doc.patch
Description: Binary data
