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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/7/10 11:54 AM, Kurt Zeilenga wrote:
> 
> On Jul 7, 2010, at 8:10 AM, Peter Saint-Andre wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 7/7/10 9:02 AM, Simon Josefsson wrote:
>>> Kurt Zeilenga <[e-mail]> writes:
>>> 
>>>> 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.
>>> 
>>> I also dislike going into details about non-recommended
>>> approaches.  I prefer MUST NOT over SHOULD NOT if we cannot think
>>> up at least one use-case when the SHOULD NOT recommendation isn't
>>> followed.  Especially since if a use case appears for TLS
>>> renegotiation, use of it (and what it means for XMPP) can be
>>> described in a separate document.
>> 
>> Further: do we have a use case *now*? If not, why leave the door
>> open?
> 
> One could argue that via the update specification approach, the door
> is always open.
> 
> I prefer the door to be a bit more open than that.  That is, a SHOULD
> NOT instead of MUST NOT.  But it's not all that big of a deal.
> 
> As far as use case, I simply note that personally prefer
> authentication mechanisms which do not require me to expose user
> information to a server which I have yet to authenticate.  I prefer
> this sufficiently to actually design and implement mechanisms which
> allow me to authenticate the server before authenticating exposing
> user information.  I suspect I'm not the only person with this
> preference.

Sigh. I see your point. :)

I think we're going to be stuck with something like this:

###

5.2.5.  TLS Renegotiation

   The TLS protocol allows either party in a TLS-protected channel to
   initiate a new handshake that establishes new cryptographic
   parameters (see [TLS-NEG]).  The cases most commonly mentioned are:

   1.  Refreshing encryption keys.

   2.  Wrapping the TLS sequence number as explained in Section 6.1 of
       [TLS].

   3.  Protecting client credentials by completing server authentication
       first and then completing client authentication over the
       protected channel.

   Because it is relatively inexpensive to establish streams in XMPP,
   for the first two cases it is preferable to use an XMPP stream reset
   (as described under Section 4.7.3.15) instead of performing TLS
   renegotiation.

   The third case has improved security characteristics when the TLS
   client (which might be an XMPP server) presents credentials to the
   TLS server.  If communicating such credentials to an unauthenticated
   server might leak private information, it can be appropriate to
   complete TLS negotiation for the purpose of server authentication and
   then attempt TLS renegotiation for the purpose of client
   authentication with the TLS server.

   However, the third case is sufficiently rare that XMPP entities
   SHOULD NOT blindly attempt TLS renegotiation.

   If an entity that does not support TLS renegotiation detects a
   renegotiation attempt, then 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).

   If an entity that supports TLS renegotiation detects a TLS
   renegotiation attempt that does not use the TLS Renegotiation
   Extension [TLS-NEG], then 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).

   Support for TLS renegotiation is strictly OPTIONAL.  However,
   implementations that support TLS renegotiation MUST implement and use
   the TLS Renegotiation Extension [TLS-NEG].

###

If we're going to say it's OK to support TLS renegotiation then I think
it's incumbent on us to describe what that means, thus the somewhat
lengthy text.

Can we put this to bed now?

Peter

- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw0yHgACgkQNL8k5A2w/vwgmgCfYwjFlC4bK+j0NZWS2Y4uFq1w
wDoAniTm6B2o/sTwnbXtAtag9S9o1xO9
=YqXd
-----END PGP SIGNATURE-----