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

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

On 7/6/10 12:31 PM, Kurt Zeilenga wrote:
> 
> On Jul 6, 2010, at 9:54 AM, Peter Saint-Andre wrote:
> 
>> 
>> 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.
>> 
>> ###
> 
> I think MUST NOT here is too strong.   I would rather say that while
> XMPP entities generally SHOULD NOT attempt TLS renegotiation, when
> they do, they MUST implement and make use of the TLS Renegotiation
> Extension [RFC5746].  Additionally, it would be good to note that no
> entity is required to support TLS renegotiation.
> 
> That is, while it reasonable not to require entities implement TLS
> Renegotiation, it not reasonable in my opinion to preclude those who
> find value in TLS Renegotiation from using the TLS Renegotiation
> Extension with peers who implement it.

I'd be amenable to that. Basically: support for renegotiation is
strictly optional, and you really shouldn't use it unless you know what
you're doing.

Here is adjusted text:

###

5.2.5.  Renegotiation

   The TLS protocol allows either party in a TLS-protected channel to
   initiate a new handshake that establishes new cryptographic
   parameters.  There are some rare cases in which such a TLS
   renegotiation might be justified, including (1) refreshing encryption
   keys, (2) wrapping the TLS sequence number as explained in Section
   6.1 of [TLS], and (3) protecting client credentials by completing
   server authentication first and then completing client authentication
   over the protected channel.  In XMPP, for the first two cases it is
   preferable to use an XMPP stream reset (as described under
   Section 4.6.3.15) 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 in general outweighed by
   the complexity of supporting TLS renegotiation.

   Therefore:

   1.  Support for TLS renegotiation by XMPP implementations is strictly
       OPTIONAL.
   2.  If an XMPP implementation supports TLS renegotiation, it MUST
       implement and make use of the TLS Renegotiation Extension defined
       in [TLS-NEG].
   3.  XMPP entities SHOULD NOT attempt TLS renegotiation.
   4.  If a party that does not support TLS renegotiation detects a TLS
       renegotiation attempt, it SHOULD 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).

###