Re: rfc2487bis-04: Failed negotiations & virtual hosting

[Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Oct 17, 2000 at 11:01:22AM +0200, Lutz Jaenicke wrote:
> On Thu, Oct 05, 2000 at 05:55:26PM -0700, Gregory Neil Shapiro wrote:

>> 2. As Paul Hoffman and I discussed at IETF, there may be a virtual hosting
>>    problem that will necessitate a change.  For example, smtp.gshapiro.net
>>    does virtual hosting for about 50 domains.  If a client expects the
>>    certificate CN and the hostname to match, there needs to be some way to
>>    communicate that information.  HTTP has HTTP/1.1 or the Server: line to
>>    indicate the requested server.  SMTP will need the same if the server is
>>    to be able to determine which certificate to send.

[...]
> For a client to indicate the requested server I don't think this is
> possible within the existing protocol. At the time the STARTTLS command
> is issued, the server has not yet received a "RCPT TO:" command, so that
> this information cannot be used. An "easy" way to do it would be to 
> extend STARTTLS to "STARTTLS required_target", but this would in fact
> change the protocol. And it would give away some of the privacy obtained
> as an eavesdropper could derive information about the email being sent.
> Unfortunately, no "required target" feature was designed into the TLS
> protocol...

A "required target" feature in TLS wouldn't help a lot: By the time
the client reveals the name of the host that it wants to talk to, it
must already have authenticated that host, or it couldn't rely on the
target name staying confidential.  The feature could provide security
against passive eavesdroppers, though.

Since a "required target" request would look differently depending on
the application protocol (DNS hostnames aren't the only thing that may
be relevant), this is probably better left to the application
protocol.  There's always the possibility to initiate a re-negotation,
but this is bad for efficiency -- it would be nice to have a
lighter-weight handshake protocol that merely adds a certificate
verification to an existing session.  (I guess this should be possible
for both client and server verification.)


-- 
Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036