From: ben Date: Fri, 28 Jan 2005 13:47:37 +0000 (+0000) Subject: Split discussion of diabling rekeys between time-based and data-based, since X-Git-Url: https://git.distorted.org.uk/~mdw/sgt/putty/commitdiff_plain/a43586048d46d09572107edcd8aed455e0e132d5 Split discussion of diabling rekeys between time-based and data-based, since disabling the former is much more useful, and much safer, than disabling the latter. The new wording on data-based rekeys might need some polishing. git-svn-id: svn://svn.tartarus.org/sgt/putty@5222 cda61777-01e9-0310-a592-d414129be87e --- diff --git a/doc/config.but b/doc/config.but index 8fb87988..9ba5f37e 100644 --- a/doc/config.but +++ b/doc/config.but @@ -2205,6 +2205,20 @@ allowed to elapse before a rekey is initiated. If this is set to zero, PuTTY will not rekey due to elapsed time. The SSH-2 protocol specification recommends a timeout of at most 60 minutes. +You might have a need to disable time-based rekeys completely for the same +reasons that keepalives aren't always helpful. If you anticipate +suffering a network dropout of several hours in the middle of an SSH +connection, but were not actually planning to send \e{data} down +that connection during those hours, then an attempted rekey in the +middle of the dropout will probably cause the connection to be +abandoned, whereas if rekeys are disabled then the connection should +in principle survive (in the absence of interfering firewalls). See +\k{config-keepalive} for more discussion of these issues; for these +purposes, rekeys have much the same properties as keepalives. +(Except that rekeys have cryptographic value in themselves, so you +should bear that in mind when deciding whether to turn them off.) +Note, however, the the SSH \e{server} can still initiate rekeys. + \b \q{Max data before rekey} specifies the amount of data (in bytes) that is permitted to flow in either direction before a rekey is initiated. If this is set to zero, PuTTY will not rekey due to @@ -2224,22 +2238,13 @@ used: } -PuTTY can be prevented from initiating a rekey entirely by setting -both of these values to zero. (Note, however, that the SSH -\e{server} may still initiate rekeys.) - -You might have a need to disable rekeys completely for the same -reasons that keepalives aren't always helpful. If you anticipate -suffering a network dropout of several hours in the middle of an SSH -connection, but were not actually planning to send \e{data} down -that connection during those hours, then an attempted rekey in the -middle of the dropout will probably cause the connection to be -abandoned, whereas if rekeys are disabled then the connection should -in principle survive (in the absence of interfering firewalls). See -\k{config-keepalive} for more discussion of these issues; for these -purposes, rekeys have much the same properties as keepalives. -(Except that rekeys have cryptographic value in themselves, so you -should bear that in mind when deciding whether to turn them off.) +Disabling data-based rekeys entirely is a bad idea. The integrity, +and to a lesser extent, confidentiality of the SSH-2 protocol depend +in part on rekeys occuring before a 32-bit packet sequence number +wraps around. Unlike time-based rekeys, data-based rekeys won't occur +when the SSH connection is idle, so they shouldn't cause the same +problems. The SSH-1 protocol, incidentally, has even weaker integrity +protection than SSH-2 without rekeys. \H{config-ssh-auth} The Auth panel