Re: STARTTLS & EHLO: Errata text?

[[e-mail]]

> > 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.

Very clever - it focuses on the real issue and avoids the slippery slope. . I
like it a lot. This is definitely the way to go.

> > 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.

My understanding is there's an API for it in NSS, but for various reasons it's
effectively unusable. (Something about use of it not playing nice with how this
stuff interfaces with the cert db.) This is not something I code myself so I
don't know all the ins and outs of it, but what I do know is that the people
who do deal with this say it's a nonstarter given the present state of play of
existing TLS libraries.

All things being equal I would much rather see this dealt with at the TLS
layer. But that's not the current situation and I am unconvinced that it's
going to change faster than we could get an extension deployed.

				Ned