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

[Kurt Zeilenga <[e-mail]>]

On Jul 7, 2010, at 7:27 AM, Simon Josefsson wrote:

> Peter Saint-Andre <[e-mail]> writes:
> 
>> 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.)
> 
> I like it.
> 
> I don't see what benefit there is in permitting TLS renegotiation, even
> with the TLS renegotiation extension, because it adds complexity to the
> XMPP specification, XMPP implementations (a SHOULD NOT requirement
> typically results in more code and trickier testing than a MUST NOT),
> and complexity for interop testing events.

I personally wouldn't have a problem with just saying "SHOULD NOT do TLS renegotiation".  That is, I don't see a particular need to detail how to implement a non-recommended capability.

> 
> If someone finds a compelling reason to use TLS renegotation, they can
> write a separate document (updating the XMPP specification) to describe
> how it should work.  That will likely result in better interop than with
> the compromise text that isn't sufficient for good interop of
> TLS+renegotiation.
> 
> However I don't care strongly; I think either text would be better than
> what is in many other protocols anyway.
> 
> /Simon
> 
>> 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.
>> 
>> ###
>> 
>> 
>> _______________________________________________
>> xmpp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xmpp
> _______________________________________________
> xmpp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xmpp