ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2024-12-24 07:06:41 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

clean up description of certificate validity period

Browse Source
This commit is contained in:
Jean-Paul Calderone 2018-05-22 09:00:30 -04:00
parent ab37b5eabb
commit 504452f1fd
1 changed files with 22 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
docs/proposed/http-storage-node-protocol.rst
View File

@ -373,20 +373,29 @@ Just like the immutable version.
.. [#] .. [#]
The security value of checking ``notValidBefore`` and ``notValidAfter`` is not entirely clear. The security value of checking ``notValidBefore`` and ``notValidAfter`` is not entirely clear.
There is an argument to make that letting an existing TLS implementation which wants to make these checks just make them reduces overall complexity The arguments which apply to web-facing certificates do not seem to apply
(and, at least in general, reducing complexity is good for security). (due to the decision for Tahoe-LAFS to operate independently of the web-oriented CA system).
On the other hand, checking the validity time period forces certificate regeneration.
A possible compromise is to recommend very long-lived certificates There is an argument to make that complexity is reduced by allowing an existing TLS implementation which wants to make these checks make them
(many years, perhaps many decades?). (compared to including additional code to either bypass them or disregard their results).
"Recommend" may be read as "provide software encouraging the generation of". Reducing complexity, at least in general, is often good for security.
But what about key theft?
On the other hand, checking the validity time period forces certificate regeneration
(which comes with its own set of complexity).
A possible compromise is to recommend very certificates with validity periods of many years or decades.
"Recommend" may be read as "provide software supporting the generation of".
What about key theft?
If certificates are valid for years then a successful attacker can pretend to be a valid storage node for years. If certificates are valid for years then a successful attacker can pretend to be a valid storage node for years.
An introducer *might* eventually recognize such a node as an attacker and blacklist their announcements... However, short-validity-period certificates are no help in this case.
It's likely not all clients configured to use compromised storage server identities will be updated The attacker can generate new, valid certificates using the stolen keys.
(if only because there are many of them
but possibly also because there is no automatic mechanism for fixing this state). Therefore, the only recourse to key theft
Such clients may go on placing shares on an attacker's storage server for a long time. (really *identity theft*)
Would short-validity-period certificates with automatic certificate renewal not be better? is to burn the identity and generate a new one.
Burning the identity is a non-trivial task.
It is worth solving but it is not solved here.
.. [#] .. [#]
More simply:: More simply::