Re: STARTTLS & EHLO: Errata text?

Hi Ned,

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

> > Hi Tony,
> > Some of the text in this message is from from RFC 3207.
> > At 09:04 29-01-2009, Tony Hansen wrote:
> > >If we were to write an Errata against RFC 3207, I'd suggest text 
> > such as
> > >the following (in Errata format):
> > >
> > >Section:
> > >    4.2 Result of the STARTTLS Command
> > >
> > >Old text:
> > >    The server MUST discard any knowledge obtained from the client, 
> > such
> > >    as the argument to the EHLO command, which was not obtained from 
> > the
> > >    TLS negotiation itself.
> > >
> > >New text:
> > >    The server MUST discard any knowledge obtained from the client that
> > >    was not obtained from the TLS negotiation itself. The server state
> > >    is otherwise as if the connection had just been opened.
> > >
> > >Reason:
> > >    The example is misleading and has lead some people to think that
> > >    knowledge of an EHLO having been sent previously should be
> > >    remembered.
> > Quoting the entire paragraph from the RFC:
> >    "Upon completion of the TLS handshake, the SMTP protocol is reset to
> >     the initial state (the state in SMTP after a server issues a 220
> >     service ready greeting).  The server MUST discard any knowledge
> >     obtained from the client, such as the argument to the EHLO command,
> >     which was not obtained from the TLS negotiation itself.  The client
> >     MUST discard any knowledge obtained from the server, such as the 
> > list
> >     of SMTP service extensions, which was not obtained from the TLS
> >     negotiation itself.  The client SHOULD send an EHLO command as the
> >     first command after a successful TLS negotiation."
> > Updated text:
> >     Upon completion of the TLS handshake, the SMTP protocol is reset to
> >     the initial state (the state in SMTP after a server issues a 220
> >     service ready greeting).  The server MUST discard any knowledge 
> > obtained
> >     from the client, such as command verbs and their arguments, that was
> >     not obtained from the TLS negotiation itself.  The client MUST 
> > discard any
> >     knowledge obtained from the server, such as the list of SMTP 
> > service extensions,
> >     which was not obtained from the TLS  negotiation itself.  As the 
> > server state is
> >     as when a SMTP session is initiated, the client SHOULD send an 
> > EHLO command as the
> >     first command after a successful TLS negotiation.
> While I have no objection to making this change, I note in passing 
> that quite a
> few servers, ours included, violate the "the server MUST discard any 
> knowledge
> obtained from the client" part of this and will continue to do so no 
> matter
> what is written in any standard.
>
> The reason for this is simple: Limits used in controlling spam and DOS 
> attacks.
> Servers impose limits on all sorts of things, including but not 
> limited to the
> number of transactions in a session, the total number of recipients, 
> the total
> time a session has taken, and so on. If a server follows this MUST it 
> turns
> STARTTLS into a one time "reset all my rate limits" pass. That's 
> simply not
> acceptable in today's email climate.
Good point.

> Please note that I am not arguing that such limits are effective in 
> controlling
> spam or deflecting DOS attacks. (Nor am I arguing that they aren't.) 
> My point
> is rather that mail system administrators insist on having these sort 
> of limits
> available as part of their security toolbox. If they aren't available 
> or are
> there in a form that can easily be bypassed they will run a different 
> mail
> server product instead.
>
> The simplest fix to bring this text in line with reality is to change 
> the MUST
> into a SHOULD. Beyond that lies a slippery slope where we attempt to 
> categorize
> what sorts of information a server can or cannot retain. I really 
> don't think
> we want to go there.
I would like suggest an alternative: how about saying

   The server MUST NOT trust any information obtained
   from the client, such as command verbs and their arguments, prior to 
the TLS negotiation.
   The client MUST NOT trust any information obtained from the server,
   such as the list of SMTP service extensions,
   prior to the TLS negotiation.

This avoid the whole issue of what the client/server must and must not 
remember.
[...]

> > >Section:
> > >    4. The STARTTLS Command
> > >
> > >Old text:
> > >    The format for the STARTTLS command is:
> > >
> > >    STARTTLS
> > >
> > >    with no parameters.
> > >
> > >New text:
> > >    The format for the STARTTLS command is:
> > >
> > >    STARTTLS
> > >
> > >    with no parameters.
> > >
> > >    Because the server state machine is reset to an initial connection
> > >    state after negotiating TLS, and any modifications to the server
> > >    state will be lost, the client SHOULD NOT issue any MAIL
> > >    FROM or RCPT TO commands prior to using the STARTTLS command.
> > Agreed.
> While this clarification exercise is all well and good, if we're 
> actually going
> to issue a revision to RFC 3207 we should consider fixing its most 
> serious flaw
> (IMO) - the lack of a domain parameter on the STARTTLS command, in 
> order to
> allow a single SMTP server to provide "virtual hosting" support for 
> multiple
> domains.
This is an interesting issue, because it affects pretty much any 
application protocol that have STARTTLS command or similar.
While I agree that this functionality is needed, I came to conclusion 
that this change at the application layer is not needed, as there a TLS 
extension for doing exactly that (RFC 4366, section 3.1). It might even 
be supported by OpenSSL.
But lack of APIs for controlling this in TLS libraries might be a problem.

> This would have to be done by advertising a separate extension, say
> STARTTLSDOMAIN, which if present says the STARTTLS command accept a 
> single,
> optional parameter specifying the domain associated with the 
> certificate the
> client would like to see the server assert. Text for this can be 
> adapted from
> section 6 of RFC 3887.
>
> As things stand now these sorts of virtual hosting setups require the 
> use of
> multiple separate ports or IP addresses (usually the latter given how 
> many
> clients don't support alternate ports). That's fine and dandy when 
> you  have
> two or three domains, but unacceptable when you're hosting thousands 
> of them or
> more.