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

Martin's text contradicts the AD's decision ...

Pasi wrote:
> - There was some discussion on whether to add the magic cipher suite
> to patched renegotiation ClientHellos (in addition to the extension),
> too. I believe rough consensus is not to do this.

In addition, the logic of not permitting RI unless some other extension
is used is dubious.  A client with no need to cater to servers that are
both broken and unpatched should not be forced to gin up some other
extension just so it will be allowed to send an empty RI.

Put me down in favor of the existing text:

>    TLS clients which support this draft MUST generate either the
>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>    cipher suite with every ClientHello.

... with possible addition of "or both" just to be perfectly clear that
"either" means or, not exclusive-or.

Dave

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Marsh Ray
Sent: Wednesday, December 16, 2009 1:42 PM
To: mrex@sap.com
Cc: tls@ietf.org
Subject: [POSSIBLE SPAM] Re: [TLS] draft-ietf-tls-renegotation: next
steps
Importance: Low

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls