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

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.

-- Kurt
> 
> 
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp