--On Monday, 11 December, 2006 10:07 +0000 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Arnt Gulbrandsen wrote:
Alexey Melnikov writes:
It is, but I would rather avoid specifying any limit in the
document, because it is likely to be exceeded in the future.
If it's big enough, I'm sure you can say "may be exceeded,
although unlikely".
But I guess the document can specify an absolute minimum and
allow implementations to support bigger line lengths.
Isn't that what RFC 1869 section 4.1.2 does?
I would like to see text saying something like "no
implementations are known to support line lengths greater
than 12288
That is not true, Isode's implementation allows for 98304 :-)
and it is thought unlikely that any SASL mechanisms will ever
require longer line lengths".
I've just reread the text already in the document:
Note that these [BASE64] strings can be much longer
than
normal SMTP commands. Clients and servers MUST be
able to
handle the maximum encoded size of challenges and
responses
generated by their supported authentication
mechanisms. This
requirement is independent of any line length
limitations the
client or server may have in other parts of its
protocol
implementation.
and I think it is good enough. If an implementation only
supports CRAM-MD5, there is no reason to have 12K buffer for
it, 1K would be sufficient.
Alexey,
This works for me iff,
(i) The description of every SASL method describes the maximum
length string that can be used.
(ii) We agree (presumably with the Security Area) that, when the
base SASL document is next revised, it contain an explicit
requirement that new SASL methods document the maximum possible
string length.
If people insist, I can add something like the following:
At the time of writing of this document, 12288 is
considered to be
sufficiently big line length limit for handling of
deployed authentication
mechanisms.
I think this would be useful in addition to the above. The
combination of a long history of SMTP implementations truncating
at some implementation-specific limit and, as others have
pointed out, attacks based on buffer overflows, make me very
uncomfortable about text that implies "try to make the buffer as
long as possible (or as long as you think sensible)".
john