[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Changes after IETF last call for 2487bis
There were two significant commments that came out of the IETF last call.
The first was a disagreement from Keith Moore (with agreement from
Ned Freed) about the addition of the text that described
interoperating with earlier versions of SSL. In retrospect, I agree
that the text that was added didn't help an implementor create an
interoperable system and in some ways made it harder. Thus, I have
removed that paragraph from the document. Of course, this does not
prevent client and server implementations from recognizing multiple
versions of SSL/TLS during the SSL negotiation.
The second was about security considerations wording in 2487 about
preventing man-in-the-middle attacks. Ned suggested alternate wording
that is much more amenable to servers turning TLS on and off. The new
A man-in-the-middle attack can be launched by deleting the "250
STARTTLS" response from the server. This would cause the client not
to try to start a TLS session. Another man-in-the-middle attack is
to allow the server to announce its STARTTLS capability, but to
alter the client's request to start TLS and the server's response.
In order to defend against such attacks both clients and servers MUST
be able to be configured to require successful TLS negotiation of
an appropriate cipher suite for selected hosts before messages can
be successfully transferred. The additional option of using TLS when
possible SHOULD also be provided. An implementation MAY
provide the ability to record that TLS was used in communicating
with a given peer and generating a warning if it is not used in a
Please give me comments in the next few weeks if you have an
objection to these two changes. I'll turn in the next draft after
London and ask the ADs to move the document to the IESG.
--Paul Hoffman, Director
--Internet Mail Consortium