Re: RSET command - possible security loophole

[ned+ietf-smtp@xxxxxxxxxxx]

> --On Tuesday, May 31, 2011 11:19 -0400 Keith Moore
> <moore@xxxxxxxxxxxxxxxxxxxx> wrote:

> > My impression is that the behavior of RSET has never been
> > defined with respect to authentication, and that the Right
> > Thing for RSET to do with respect to authentication is
> > absolutely nothing.
> >
> > A separate question is whether RSET affects anything in an
> > SMTP extension.  It's easy to say that RSET doesn't affect
> > extensions, but I doubt that's the right tack.  RSET should
> > definitely affect CHUNKING, for instance.  But I think RSET
> > should only affect the current message being sent.

> Keith,

> I think you are right, but that your formulation above is
> backwards.  As I read 5321, the semantics of RSET are completely
> clear and actually quite precise: It clears the mail transaction
> state and all the data that go with it; it does not clear the
> session state.  It is also clear that an extension could modify
> those semantics or even add arguments to RSET.  Possibly not a
> good idea, but very clearly possible in terms of how 5321 (and
> its predecessors) define the extension model.

Very nicely put. I agree 100%.

> The place where "backwards" comes in is the place where I think
> Hector has uncovered a problem, even though it is not the
> problem his initial note was about.   I think that, as we are
> checking extensions that  set data that needs to be carried from
> one command to others, we should be checking to be sure that
> action is either explicitly bound to either session or
> transaction state or that new states are clearly defined.

Well, to be fair, I think it's pretty obvious in most cases whether a given
extension involves session (e.g., AUTH), transaction (e.g., DSN), or no state
at all (e.g., PIPELINING). But having said that, it certainly would not hurt to
be specific about this, and may help.

> Such
> a clear definition would properly include a statement about what
> RSET (and EHLO and completion of the DATA command) does to the
> state and/or data.   That is a requirement on the relevant
> extension specification.

Sounds like a good plan moving forward.

> We may not have been clear enough
> about that requirement to be diligent and consistent about
> insisting on it -- in retrospect, it might even have been useful
> to put something about state or data retention in the template.
> But, at least modulo the possibility of tuning the template, it
> isn't a 5321 problem because 5321 does exactly what it should do
> -- defines the behavior in the absence of extensions and
> specifies that extensions can change that behavior.  As far as
> the existing extensions are concerned, the problem is much more
> likely "incomplete spec" than, e.g., "error in protocol".

+1

> > With respect to authentication, it's arguable that there
> > should be some way to "logout" without ending the current TCP
> > session.   But that would have to be a separate SMTP extension.

> Right.   Or part of a particular authentication extension.

I think defining an UNAUTHENTICATE/LOGOUT/whatever-you-want-to-call-it
extension would be a great idea, but it's definitely a separate effort from
any of this

				Ned