ietf-nntp AUTHINFO SASL protocol choices

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:

> 1.  Do we want to instruct/permit servers to limit the amount of data
>     sent in this fashion?  (Chris is concerned with denial of service,
>     as the clients are completely unauthenticated at this point; we
>     certainly can't expect servers to buffer an arbitrary amount of
>     data from anybody who opens a connection.  If we don't address
>     the issue here, we'll have to expect programmers to hardcode some
>     limit and just close the connection, I think.)

>     It sounds like the SASL spec will put a hard limit on this, which
>     is great.  Then for AUTHINFO SASL we just have to decide what the
>     appropriate action when that limit (with base64 expansion) is
>     reached.

>     But what is it we should do in this case?  I don't see how we
>     have any option except to close the connection, actually.

I'm comfortable with just closing the connection.  This isn't a unique
problem; the server has to deal with this in POST as well.  And I don't
see a problem with a hard-coded limit that may be different in each
server; as long as it's larger than the largest SASL exchange supported by
that server, it shouldn't matter.  And if it isn't, then by and large that
will get found quickly during testing, so it's an easy to find and easy to
fix bug.

> 2.  We define (in the base spec) the existence of single- and multi-
>     line server responses.  Should we do something similar for the
>     client commands?  The TAKETHIS extension uses this method (in
>     which the client sends a command and then a multi-line chunk
>     of data, without waiting for a go-ahead from the server) as
>     well.

I'm not sure if it's good to define a multiline client command in the base
spec when there aren't any such commands in the base spec, but if it's a
short mention, it may be worthwhile.  It would keep all the descriptions
in one place.

> 3.  Do we want to continue with any line-length changes, as part of the
>     base spec, even if there is no pressing need for them?  Personally,
>     I'd like to see at minimum:

>     - A statement about how servers are to handle lines which are too
>       long.

>     - A note that the 512 limit may be changed by an extension, even
>       if no details at all about this are agreed on now.

I agree with both of these.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>