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

[Bodo Moeller <[e-mail]>]

On Nov 30, 2009, at 4:37 PM, 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
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [e-mail] mailing lists by 2009-12-14.

I support the move, contingent to two clean-ups to specified behavior:


1. Section 3 specifies "For ClientHellos which are renegotiating, this  
field contains the verify_data from the Finished message sent by the  
client on the immediately previous handshake", and "For ServerHellos  
which are renegotiating, this field contains the concatenation of the  
verify_data values sent by the client and the server (in that order)  
on the immediately previous handshake."

There is no good reason for this asymmetry of having just the client's  
verify_data in the client's message, but both the client's and the  
server's verify_data in the server's message -- the latter is pure  
overhead, both in the specification and in the on-the-wire protocol.   
To remove the overhead from both, the second sentence should be  
saying, "For ServerHellos which are renegotiating, this field contains  
the verify_data sent by the server on the immediately previous  
handshake" (according changes to dependent parts of the specification  
then should be made).

For earlier Internet Drafts in the series preceding draft-ietf-tls- 
renegotiation-01.txt (draft-rescorla-tls-renegotiation.00.txt, etc.),  
a reason to keep the current text would have been to maintain  
compatibility with early implementations of those Internet Drafts.   
However, draft-ietf-tls-renegotiation-01 has a newer  
TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks  
compatibility with those early implementations anyway.

(This means that now, changing the ServerHello extension definition as  
suggested above gives the beneficial side-effect of exposing premature  
implementations, besides merely avoiding overhead.  Those incomplete  
implementations will be more obviously incompatible because they'd  
still be using the protocol variant with overhead, instead of just  
differing subtly in the behavior if faced with  
TLS_RENEGO_PROTECTION_REQUEST.)


2. The Security Considerations section of draft-ietf-tls- 
renegotiation-01.txt (section 7) includes language that unnecessarily  
restricts the flexibility that the TLS protocol specifically provides  
for, regulating areas that the TLS standard intentionally does not  
specify (RFC 5246 section 1) -- the current Internet Draft says:

"By default, TLS implementations conforming to this document MUST  
verify that once the peer has been identified and authenticated within  
the TLS handshake, the identity does not change on subsequent  
renegotiations. For certificate based cipher suites, this means  
bitwise equality of the end-entity certificate. If the other end  
attempts to authenticate with a different identity, the renegotiation  
MUST fail. If the server_name extension is used, it MUST NOT change  
when doing renegotiation."

There is no security reason for this restriction.  This sounds like a  
bad and incomplete workaround for certain problems with TLS that the  
updated protocol does not need a workaround for at all, because the  
protocol update is all about properly *solving* those problems.

Keeping this language in the specification would have the weird  
implication that applications that *need* the flexibility provided by  
the TLS protocol (e.g., to allow renegotiation handshakes to switch to  
a different ciphersuite, which may require a different certificate)  
would have to to *skip* implementing the protocol update, and thus  
stay vulnerable.

The new restriction that draft-ietf-tls-renegotiation-01.txt tries to  
sneak in thus seems harmful both for interoperability and for  
security.  I haven't seen any signs of working group consensus on  
including this new restriction.


Bodo