Subject: [TLS] I-D Action:draft-mrex-tls-secure-renegotiation-01.txt

From: [email-masked]
Date: Wed, 25 Nov 2009 17:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Transport Layer Security (TLS) Secure Renegotiation
	Author(s)       : M. Rex
	Filename        : draft-mrex-tls-secure-renegotiation-01.txt
	Pages           : 16
	Date            : 2009-11-25

A protocol design flaw in the TLS renegotiation handshake leaves all
currently implemented protocol version of TLS (SSLv3 to TLSv1.2)
vulnerable to Man-in-the-Middle (MitM) attacks where the attacker can
establish a TLS session with a server, send crafted application data
of his choice to the server and then proxy an unsuspecting client's
TLS handshake into the TLS renegotiation handshake of the server. 
Many applications on top of TLS see the data injected by the attacker
and the data sent by the client as a single data stream and assume
that an authentication during the TLS renegotiation handshake or
contained in the client's application data applies to the entire data
stream received through the TLS-protected communication channel.

This document describes a protocol change for all protocol versions
of TLS plus SSLv3 that will fix this vulnerability for all
communication between updated TLS clients and updated TLS servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mrex-tls-secure-renegotiation-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Nov 2009 03:36:26 +0100 (MET)

> 	Filename        : draft-mrex-tls-secure-renegotiation-01.txt

This is only a cleanup of the description in the document,
the design has not changed so far.

If we send anything data back S->C trailing the ServerHello instead
of modifying existing fields, then this _ought_ to be encoded like
a real TLS extension (though SSLv3 Server might be stuffing it in
as a fixed blob.

C->S signaling with magic ciphersuite and
S->C signaling with an empty extension RI on initial and renegotiation
handshake and allowing (but _not_ requiring) extension RI in ClientHello
when other extensions are sent is something I could live with.

I would really appreciate feedback from implementors, in particular
those who haven't been actively participating this discussion (yet),
whether/where they see problems with their installed base on these
questions:

  ?  issue with TLS extensions in ClientHello (renegotiation handshake)
  ?  issue with (single) TLS extension in ServerHello
  ?  issue with TLS extensions in general

Anyone whos making SSL-aware loadbalancers/NATs or SSL accelerators?

Or stuff similar to the JetDirect network print server -- very little
of such equipment ever sees a firmware update in its lifetime.

-Martin