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

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
>	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

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