Re: [TLS] draft-ietf-tls-renegotation: next steps

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> 
> One possible semantic that would address my technical issues
> would be along these lines:
> 
>    All conforming Clients MUST include the cipher suite value
>    TLS_RENEGO_PROTECTION_REQUEST in the cipher_suites list of _every_
>    ClientHello handshake message they send.  This includes clients that
>    do not implement renegotiation or have it disabled.  This cipher
>    suite value MAY appear anywhere in the cipher_suites list.
> 
>    Conforming clients that compose an initial ClientHello handshake
>    messages with other TLS extensions, MAY additionally include
>    an empty TLS extension "renegotiation_info".

Current wording http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01
>    TLS clients which support this draft MUST generate either the
>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>    cipher suite with every ClientHello.

I expect it will be reiterated in the next revision.

How does this not address the fundamental issue?

(Other than it doesn't provide assistance to an implementation which
chooses to conduct an insecure negotiation and subsequent insecure
renegotiation with an old unpatched extensions-intolerant server).

And if not, does anyone propose wording that substantially improves it
without changing the current cryptographic computations (e.g., the PRF
inputs)?

Short and to the point please!

- Marsh