Subject: [ietf-tls] Fwd: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 19 Jun 2001 16:15:02 -0700

>To: IETF-Announce: ;
>From: The IESG <[email-masked]>
>SUBJECT: Last Call: SMTP Service Extension for Secure SMTP over TLS to
>	Proposed Standard
>Reply-to: [email-masked]
>Date: Tue, 19 Jun 2001 16:35:16 -0400
>Sender: [email-masked]
>
>
>The IESG has received a request to consider SMTP Service Extension for
>Secure SMTP over TLS <draft-hoffman-rfc2487bis-05.txt> as a Proposed
>Standard.  This has been reviewed in the IETF but is not the product of
>an IETF Working Group.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by July 19, 2001.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-hoffman-rfc2487bis-05.txt

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Pete Chown <[email-masked]>
Date: Wed, 20 Jun 2001 11:17:29 +0100

Paul,

I wonder if the part about backwards compatible client hello messages
would benefit from clarification.  Perhaps I'm missing something but
I'm not quite sure what you mean -- a server is required to understand
a backwards compatible client hello but is not required to offer it?
I don't understand what the distinction is here, or what is meant by a
server "offering" a client hello.

-- 
Pete

---

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 20 Jun 2001 14:59:29 +0200

> server "offering" a client hello.

The wording indeed is a little confusing:

   Servers MUST be able to understand backwards compatible SSL Client
   Hello messages (provided that client_version is TLS 1.0 or later),
   and clients MAY use backwards compatible Client Hellos messages. 
   Neither clients or servers are required to actually offer Client
   Hello messages for anything other than TLS 1.0.

Servers never "offer" Client Hello messages, so this probably should
be phrased differently.

The intention is as follows:

We do not want to stand in the way of clients who want to tolerate
SSL-only servers.  Such servers violate the STARTTLS specification,
but interoperability is still a good idea.  So clients are allowed to
use a Client Hello format suitable for connecting to such servers.
However, the client is required to offer TLS 1.0 in this Client
Hello message; client trying to negotiate SSL 2.0 or SSL 3.0 are not
allowed by the specification.  (Note the difference between the
format of the Client Hello message and the client_version
value given in this message: Clients can request TLS 1.0 in SSL 2.0
or SSL 3.0 compatible format, and they will be able to request
TLS 1.1 in SSL 2.0, SSL 3.0, or TLS 1.0 format.)

For interoperability with such backwards-compatible clients, we
require servers to understand Client Hello messages using a
backwards-compatible format.  But the server is only required
to be able to handle this if the client supports TLS 1.0.
If the client tries to negotiate a protocol earlier than TLS 1.0,
this is out of the scope of the specification.

-- 
Bodo Möller <[email-masked]>
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

---