Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[Marsh Ray <[e-mail]>]

A few little suggestions, mostly wording.

The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG 
> (tls) to consider the following document:
> 
> - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
>    <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard

http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01

[Page 3]
>    renegotiation handshakes to the enclosing TLS channel, thus allowing
>    the server to differentiate renegotiation from initial negotiation,
>    as well as preventing renegotiations from being spliced in between
>    connections.  

"spliced in between sessions."

[Page 5]
>    o  For ClientHellos which are renegotiating, this field contains the

"the renegotiated_connection field contains"

[Page 6]
>    Both the SSLv3 and TLS 1.0/TLS1.1 specifications require
>    implementations to ignore data following the ClientHello (i.e.,
>    extensions) if they do not understand it.  However, some SSLv3 and
>    TLS 1.0 implementations incorrectly fail the handshake in such case.
>    This means that clients which offer "renegotiation_info" may find
>    handshake failures.  In order to enhance compatibility with such
>    servers, this document defines a second signalling mechanism via a
>    special TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST", with code
>    point 0xNN, 0xMM.  This cipher suite has exactly the same semantics
>    as an empty "renegotiation_info" extension.  Because servers
>    ordinarily ignore unknown cipher suites, this cipher suite can be
>    added safely on any initial handshake, including SSLv2 backward
>    compatibility handshakes.
> 
>    Servers MUST treat receipt of TLS_RENEGO_PROTECTION_REQUEST exactly
>    as if the client had sent an empty "renegotiation_info" extension and
>    respond with their own "renegotiation_info" extension.  This is an
>    explicit exception to the RFC 5246 Section 7.4.1.4 prohibition on the
>    server sending unsolicited extensions and is only allowed because the
>    client is signaling its willingness to receive the extension via the
>    the TLS_RENEGO_PROTECTION_REQUEST cipher suite.  TLS implementations
>    MUST continue to comply with 7.4.1.4 for all other extensions.
>    Servers MUST NOT select this cipher suite in any handshake, as it
>    does not correspond to any valid set of algorithms.
> 
>    Because this cipher suite is equivalent to an empty
>    "renegotiation_info" extension, only renegotiation_info" may be used
>    rehandshakes.
> 
>    Note that a minimal client which does not support renegotiation at
>    all can simply use this cipher suite in all initial handshakes.  Any
>    compliant server will reject any (apparent) attempt at renegotiation
>    by such a client.  Clients which do support renegotiation MUST
>    implement Section 3 as well.

I suggest we replace all uses of "cipher suite" in this section with the
term "cipher suite value", and we add explicit wording "The
TLS_RENEGO_PROTECTION_REQUEST cipher suite value is just a flag, it does
not actually a refer to a set of cryptographic algorithms that could
ever be used for data transmission."

This might seem obvious to all of us, but this wording change could
conceivably speed review and fend off questions by some review board.

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

Can they generate both?

If not, what does the server do if he receives both?

>    Existing implementations which do not support this extension are
>    widely deployed and in general must interoperate with newer
>    implementations which do support it.  This section describes

s/must/need to/ to avoid confusion with MUST.

>    If a client offers the "renegotiation_info" extension or the
>    TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server does not
>    reply with "renegotiation_info" in the ServerHello, then this
>    indicates that the server either does not support secure
>    renegotiation or is unwilling to use it.

Is it allowed for a patched server to be "unwilling"?

If not, drop the "or is unwilling to use it" lest it give the impression
that such behavior is condoned.

>    If the client does not offer the "renegotiation_info" extension or
>    the TLS_RENEGO_PROTECTION_REQUEST cipher suite then this indicates
>    that the client does not support secure renegotiation or is unwilling
>    to use it.  However, because the above attack looks like two

Again, is it allowed for a client to be conformant to this spec and
still not send either the extension or magic cipher suite value?

- Marsh