Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

From: Martin Rex <[email-masked]>
Date: Wed, 2 Dec 2009 04:29:22 +0100 (MET)

Kyle Hamilton wrote:
> 
> What I'm seeing here:
> 
> An implementation continues to be conformant to TLS even if the RI
> isn't sent.  If a client doesn't send the RI (either cipher suite flag
> or extension), the server can't send the RI extension back (as it's a
> violation of TLS 1.2 for a server to send an unsolicited extension).
> If a client does send the RI cipherflag or extension, the server may
> send back the RI reply, or (if its security policy prohibits
> renegotiation -- to reduce the possible impact of large numbers of
> reneg's overwhelming any crypto implementation, or because it's known
> that client certificates are never going to be solicited by the
> server, to name a couple of possible reasons) it may choose not to
> reply with the extension.

It has been previously mentioned: this is likely an insufficiently
clear wording of the spec.

The TLS_RENEGO_PROTECTION_REQUEST cipher suite value is _not_
a means to request secure renegotiation (for the TLS extension RI,
only the extension containing the verify_data is such a request).

The purpose of the magic cipher suite is a request for protection
from the _INsecure_ or "old" renegotiation.

The spec should explicitly say that every updated/conforming client
MUST add that cipher suite value into every ClientHello handshake
message that it sends out, and that includes clients that do not
implement renegotiation or have it disabled.  That decision MUST
be free from policy and configuration.

In the attack scenario depicted in the document, the client only
sees an initial TLS handshake an no renegotiation.

The same applies to the servers.   The document should explicitly
say that servers MUST return the empty TLS renegotiation when
the client requested it (by including the magic cipher suite value
in the ClientHello).  That includes servers that do not implement
renegotiation or have it disabled.  That decision MUST be free
from policy and configuration.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 01 Dec 2009 22:04:41 -0600

> clear wording of the spec.

It sure sounds wrong that a implementation could become conformant with
no discernible change on the wire.

> from the _INsecure_ or "old" renegotiation.

Good point.

> implement renegotiation or have it disabled.

It must add the MCSV and/or the extension.

> That decision MUST

I understand the sentiment, but that wording doesn't make sense to me.
To the extent that we're defining a wire protocol rather than certifying
specific implementations, restrictions like that don't belong. After
all, what stops them from adding a configuration switch to enable or
disable support for the draft altogether?

Seems like any arguments in support of that wording would also apply to
every other usage of 'MUST' in every RFC. Which is a pretty good reason
not to include it.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 01:57:42 +0100 (MET)

> I understand the sentiment, but that wording doesn't make sense to me.

my bad.

The inclusion of the MCSV MUST NOT be subject to policy about
the support or non-support renegotiation.

If a careful/conservative supplier/vendor makes it configurable
(which might be a sensible thing to do if theres a significant
 installed base), then it might require much more changes
(potentially to the app) rather than only to the TLS implementation.

A vendor like Microsoft might decide to make it configurable
through a registry setting (something that might not need
app changes) rather than a setting in the Advanced Tab
of the Internet Options applet of the control panel (which
likely requires UI changes of _some_ app coding outside of
the TLS implementation).

-Martin