Re: [xmpp] #39: prohibition on TLS renegotiation

[Simon Josefsson <[e-mail]>]

Peter Saint-Andre <[e-mail]> writes:

> On 6/21/10 6:11 PM, xmpp issue tracker wrote:
>> #39: prohibition on TLS renegotiation
>> --------------------------------+-------------------------------------------
>>  Reporter:  stpeter@…           |       Owner:  stpeter@…         
>>      Type:  defect              |      Status:  new               
>>  Priority:  minor               |   Milestone:                    
>> Component:  3920bis             |     Version:                    
>>  Severity:  In WG Last Call     |    Keywords:                    
>> --------------------------------+-------------------------------------------
>>  Regarding Section 5.2.5, Matthew Wild commented: "is it really desired to
>>  put a complete ban on any renegotiation?"
>
> Based on my conversations with TLS mavens and discussion in the TLS WG
> during the interminable threads on the renegotiation vulnerability, I
> would say: yes, it really is desired to put a complete ban on any
> renegotiation.
>
> Can you make an argument for why TLS renegotiation should be allowed in
> XMPP applications?

I would not argue for permitting TLS renegotiation, but there ARE some
reasons for permitting TLS renegotiations:

* Protect client credentials, i.e., first do server-authentication and
  then do client authentication in the protected channel.

* Support sequence number wrapping (unlikely).  From 5246:

   sequence number
      Each connection state contains a sequence number, which is
      maintained separately for read and write states.  The sequence
      number MUST be set to zero whenever a connection state is made the
      active state.  Sequence numbers are of type uint64 and may not
      exceed 2^64-1.  Sequence numbers do not wrap.  If a TLS
      implementation would need to wrap a sequence number, it must
      renegotiate instead.  A sequence number is incremented after each
      record: specifically, the first record transmitted under a
      particular connection state MUST use sequence number 0.

* Refresh encryption keys.

On the whole, I would agree that these small use-cases do not outweigh
the complexity in permitting renegotiation and that it is the right
decision.  But I wouldn't agree that it is a clear-cut obvious decision,
it is a careful trade-off.  Documenting why the decision has been made,
and its pros and cons, is useful.

/Simon