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

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

On 7/6/10 10:09 AM, Peter Saint-Andre wrote:
> On 7/4/10 6:44 AM, Simon Josefsson wrote:
>> 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.
> 
> Thanks for the clarifications. I agree that it would be good to explain
> the reasoning in more detail, so I'll add some text about that to the
> next version of the spec.

How is this for proposed text in Section 5.2.5? (The first paragraph is
unchanged; I've included here only to provide context.)

###

5.2.5.  Renegotiation

   XMPP entities MUST NOT attempt TLS renegotiation, and if either party
   to a TLS-protected stream detects a TLS renegotiation attempt it MUST
   immediately close the underlying TCP connection without returning a
   stream error (since the violation has occurred at the TLS layer, not
   the XMPP layer; see Section 13.3).

      Security Note: There are some rare cases in which TLS
      renegotiation might be justified, such as (1) refreshing
      encryption keys, (2) wrapping the TLS sequence number as explained
      in [TLS], and (3) protecting client credentials by completing
      server authentication first and then completing client
      authentication over the protected channel.  In the first two cases
      it is preferable to use an XMPP stream reset instead of performing
      TLS renegotiation.  The third case has slightly improved security
      characteristics when the TLS client (which might be an XMPP
      server) presents credentials to the TLS server, however that
      slight benefit is outweighed by the complexity of requiring
      implementations to support TLS renegotiation.

###