[OTR-users] Re: [OTR-announce] Flaw in OTR Protocol (with workaround!)

[Gregory Maxwell]

On 8/3/05, Ian Goldberg <ian at cypherpunks.ca> wrote:
> Having fragmentation work would simplify a number of things, so I think
> we might try again.  There's still the big issue of how to determine
> what the correct maximum packet size should be, and I don't know of a
> good way to do that (see the above thread).  Hardcoding some values
> is a kludgy workaround.  Making those values user-configurable at least
> allows user fixes if the networks change.  Any other suggestions?

*IF* we figure out how to survive the ratelimiting and if we are able
to catch rejected messages:
Path MTU discovery. 

We startout with a hard set maximum... as high as the network protocol
allows or ... just some very long limit presumed limit. When as small
message makes its way through, we increase our minimum guess MTU to
match that message size. Whenever a message is rejected due to being
too large, we reduce our presumed MTU to one under the rejected size,
then we fragment into midway between the know good size and the known
not good. If it passes we up our known good, if it fails we reduce our
presumed MTU and continue the process.

To make the process non painful for the user we'd need to be able to
intercept those errors on both sides.. and to make it work we need to
differentiate between 'too large' errors and other errors.

Thats about all I can guess, just beyond making it manual.. which
would also work (esp if we provided some sane defaults) and would not
require heroic coding.