Document tls-crypt security considerations in man page
PATCH 1/1 Document tls-crypt security considerations in man page
The tls-crypt commit message contained an elaborate discussion on the function's security properties. This commit adds the gist of that discussion, "rotate keys periodically" to the man page.
(The 'real' solution will follow later: add support for per-client tls-crypt keys. That will make tls-crypt useful for VPN providers too.)
---
Note to non-crypto-geek reviewers: please verify that this text is clear enough to explain you when you need to replace tls-crypt keys.
Note to crypto-geek reviewers: please check the numbers - see the --tls-crypt commit message (c6e24fa3) for details.
doc/openvpn.8 | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
doc/openvpn.8 +22 -0
@@ -5090,6 +5090,28 @@ In contrast to .B \-\-tls\-crypt does *not* require the user to set .B \-\-key\-direction\fR. + +.B Security Considerations + +All peers use the same +.B \-\-tls-crypt +pre-shared group key to authenticate and encrypt control channel messages. +To ensure that IV collisions remain unlikely, this key should not be used +to encrypt more than 2^48 client-to-server or 2^48 server-to-client +control channel messages. A typical initial negotiation is about 10 packets +in each direction. Assuming both initial negotation and renogatiations are +at most 2^16 (65536) packets, and (re)negotiations happen each minute for +each user (24/7), this limits the tls\-crypt key lifetime to 8171 year divided +by the number of users. So a setup with 1000 users should rotate the key at +least once each eight years. (And a setup with 8000 users each year.) + +If IV collisions were to occur, this could result in the security of +.B \-\-tls\-crypt +degrading to the same security as using +.B \-\-tls\-auth\fR. +That is, the control channel still benefits from the extra protection against +active man-in-the-middle-attacks and DoS attacks, but may no longer offer +extra privacy and post-quantum security on top of what TLS itself offers. .\"********************************************************* .TP .B \-\-askpass [file]
Signature · 1 line
2.7.4
Hi Steffan
Non-crypto geek here, comments inline.
doc/openvpn.8 In contrast to
Quoted 4 lines · Steffan Karger
doc/openvpn.8 +4
-0+control channel messages. A typical initial negotiation is about 10 packets +in each direction. Assuming both initial negotation and renogatiations are +at most 2^16 (65536) packets, and (re)negotiations happen each minute for +each user (24/7)
Does 10 and 65536 represent the same actual thing here, where 10 is a practical real-world estimate, and 65536 is an extremely conservative estimate? Or does it mean that each user will cause a total of 65536 (re)negotiation packets in his lifetime? I think using a conservative estimate is a good idea, but the large difference is somewhat confusing (and I'm not entirely sure I get the correct meaning myself).
Quoted 1 line
this limits the tls\-crypt key lifetime to 8171 year divided
8171 years (just a typo I suppose, but it's significant to the meaning of the sentence).
/Magnus
Hi,
Quoted 11 lines · Magnus Kroken
Non-crypto geek here, comments inline.
doc/openvpn.8 In contrast to
Quoted 4 lines · Steffan Karger
doc/openvpn.8 +4
-0+control channel messages. A typical initial negotiation is about 10 packets +in each direction. Assuming both initial negotation and renogatiations are +at most 2^16 (65536) packets, and (re)negotiations happen each minute for +each user (24/7)Does 10 and 65536 represent the same actual thing here, where 10 is a practical real-world estimate, and 65536 is an extremely conservative estimate?
Exactly.
Quoted 4 lines
Or does it mean that each user will cause a total of 65536 (re)negotiation packets in his lifetime? I think using a conservative estimate is a good idea, but the large difference is somewhat confusing (and I'm not entirely sure I get the correct meaning myself).
Good point, I'll try to make this more clear.
Maybe useful as background information: I am really trying to keep this section short, because I fear otherwise people will just "TL;DR" and skip it. But that does result in a high information density.
Quoted 4 lines
Quoted 1 line
this limits the tls\-crypt key lifetime to 8171 year divided
8171 years (just a typo I suppose, but it's significant to the meaning of the sentence).
Ah, yes. This is a Dutch-English mixup - the Dutch (mostly) don't use plural for more-then-one years. Will fix too.
-Steffan
PATCH v2 1/1 Document tls-crypt security considerations in man page
The tls-crypt commit message contained an elaborate discussion on the function's security properties. This commit adds the gist of that discussion, "rotate keys periodically" to the man page.
(The 'real' solution will follow later: add support for per-client tls-crypt keys. That will make tls-crypt useful for VPN providers too.)
Note to non-crypto-geek reviewers: please verify that this text is clear enough to explain you when you need to replace tls-crypt keys.
Note to crypto-geek reviewers: please check the numbers - see the --tls-crypt commit message (c6e24fa3) for details.
---
v2: clarify that 2^16 packets is a conservative estimate, use plural year*s*
doc/openvpn.8 | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)
doc/openvpn.8 +23 -0
@@ -5090,6 +5090,29 @@ In contrast to .B \-\-tls\-crypt does *not* require the user to set .B \-\-key\-direction\fR. + +.B Security Considerations + +All peers use the same +.B \-\-tls-crypt +pre-shared group key to authenticate and encrypt control channel messages. To +ensure that IV collisions remain unlikely, this key should not be used to +encrypt more than 2^48 client-to-server or 2^48 server-to-client control +channel messages. A typical initial negotiation is about 10 packets in each +direction. Assuming both initial negotation and renogatiations are at most +2^16 (65536) packets (too be conservative), and (re)negotiations happen each +minute for each user (24/7), this limits the tls\-crypt key lifetime to 8171 +years divided by the number of users. So a setup with 1000 users should rotate +the key at least once each eight years. (And a setup with 8000 users each +year.) + +If IV collisions were to occur, this could result in the security of +.B \-\-tls\-crypt +degrading to the same security as using +.B \-\-tls\-auth\fR. +That is, the control channel still benefits from the extra protection against +active man-in-the-middle-attacks and DoS attacks, but may no longer offer +extra privacy and post-quantum security on top of what TLS itself offers. .\"********************************************************* .TP .B \-\-askpass [file]
Signature · 1 line
2.7.4
Hi,
Looks good except for some typos:
Quoted 37 lines · Steffan Karger
The tls-crypt commit message contained an elaborate discussion on the function's security properties. This commit adds the gist of that discussion, "rotate keys periodically" to the man page.
(The 'real' solution will follow later: add support for per-client tls-crypt keys. That will make tls-crypt useful for VPN providers too.)
Note to non-crypto-geek reviewers: please verify that this text is clear enough to explain you when you need to replace tls-crypt keys.
Note to crypto-geek reviewers: please check the numbers - see the --tls-crypt commit message (
c6e24fa3) for details.Signed-off-by Steffan Karger <[email protected]...>---
v2: clarify that 2^16 packets is a conservative estimate, use plural year*s*doc/openvpn.8 | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)doc/openvpn.8 +6
-0@@ -5090,6 +5090,29 @@ In contrast to .B \-\-tls\-crypt does *not* require the user to set .B \-\-key\-direction\fR. + +.B Security Considerations + +All peers use the same +.B \-\-tls-crypt +pre-shared group key to authenticate and encrypt control channelmessages. To
doc/openvpn.8 In contrast to · line 5100
Quoted 2 lines
doc/openvpn.8 +2
-0+ensure that IV collisions remain unlikely, this key should not be used to +encrypt more than 2^48 client-to-server or 2^48 server-to-client control
+channel messages. A typical initial negotiation is about 10 packets in
Quoted 4 lines
each
+direction. Assuming both initial negotation and renogatiations are at most
"negotiation", "renegotiations"
Quoted 3 lines
+2^16 (65536) packets (too be conservative), and (re)negotiations happen each
"to" instead of "too"
Quoted 14 lines
+minute for each user (24/7), this limits the tls\-crypt key lifetime to 8171
+years divided by the number of users. So a setup with 1000 users should rotatedoc/openvpn.8 +8
-0+the key at least once each eight years. (And a setup with 8000 users each +year.) + +If IV collisions were to occur, this could result in the security of +.B \-\-tls\-crypt +degrading to the same security as using +.B \-\-tls\-auth\fR. +That is, the control channel still benefits from the extra protectionagainst
doc/openvpn.8 In contrast to · line 5118
Quoted 5 lines
doc/openvpn.8 +2
-0+active man-in-the-middle-attacks and DoS attacks, but may no longer offer +extra privacy and post-quantum security on top of what TLS itself offers. .\"********************************************************* .TP .B \-\-askpass [file]
Reads well otherwise. So ACK assuming typos will be fixed :)
Selva
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Fixed a few typos during commit time, as pointed out by Selva. The changes are:
-direction. Assuming both initial negotation and renogatiations are at most +direction. Assuming both initial negotiation and renegotiations are at most
-2^16 (65536) packets (too be conservative), and (re)negotiations happen each +2^16 (65536) packets (to be conservative), and (re)negotiations happen each
Your patch has been applied to the following branches
commit 5806f66eb927a6a698c0f067f563d7bc2203a376 (master) commit 9444506e45df86e6c8fbabfbf4a97c538cd971f4 (release/2.4)
Author: Steffan Karger Date: Tue May 9 20:42:48 2017 +0200
Document tls-crypt security considerations in man page
Signed-off-by: Steffan Karger <[email protected]...>
Acked-by: Selva Nair <[email protected]...>
Message-Id: <[email protected]...>
URL: https://www.mail-archive.com/[email protected]/msg14610.html
Signed-off-by: David Sommerseth <[email protected]...>- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCAAGBQJZEiOhAAoJEIbPlEyWcf3yy3kP/0SpNIeLUVRcGg/oHClYoM5y UvSU4oJ2KCLssliNC66RwoFg+q2A0+oAl1p6z2AIXt4VBgkRxm5VZsd9lMZX0JAs i6hV7EGoF1Fl0/9PYp6zNyNHspe2qQT3x1NNEHYHK91w3aUwXMlarJEfV2lmFoy9 cRbsBzQSK4o71on9EsFnNxLDFJrr2gBqM80AYu1JsT3DeWIHRyC+QFWX8qqmC4YX 80TSqWFkH90BA+qJypdaEizw0nTJWZjkFmRIN/Qa/0hXwtlUJToAbI9uL4W+oo5h ZLD8WFCeM6PtTGX411uN/uU1Ky/cME61/CNJyd7/qIMDKQcU2+a0kxC5XsPRlaXD d/WR06ruWFU34pLqwU6VJnwsKL841NQCASuYMDddzpULbYmuyLgLrkbQZ69Wgv+z t91LpQAjoMQ6wkXpXq6175smypjvIUVfktUP9g/UnPDVPIdJmdMIDkf4I9zVYOtP cW2DTOlnaBH7hEdwZCZmVSts/uu3b1eXowDlFTppO2914+g6tTs4aBzzYnkYdCcL XpA3+zPNuXhgspRQ/q47e8EsMraSrV8zIRu27B1CowjwnFrBe9Z6oOzI9SH23Nzg lkvvY1drp5EZm+Ewoomi5kLeUOb4SgDT+0ud2vsl3lFNUV5D9NQXQruVpScu+8sF UgFuGmnlmWm+S8lkSxrP
=erjH
-----END PGP SIGNATURE-----