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

From: Simon Josefsson <[email-masked]>
Date: Sun, 04 Jul 2010 14:44:49 +0200

Peter Saint-Andre <[email-masked]> 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.

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 10:09:27 -0600

> 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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 10:54:15 -0600

> 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.

###

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 6 Jul 2010 11:31:30 -0700

>      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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 13:04:34 -0600

On 7/6/10 12:31 PM, Kurt Zeilenga wrote:
>> 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).

###

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 6 Jul 2010 12:58:19 -0700

> strictly optional, and you really shouldn't use it unless you know what

'strictly optional' != 'shouldn't', which means you Therefore needs some word smithing.  I suggest:

  1.  XMPP entities SHOULD NOT attempt TLS renegotiation.
  2.  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).
  3.  If a party that does support TLS Renegotiation Extension [TLS-NEG] detects a TLS
      renegotiation attempt not using the TLS Renegotiation Extension, 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).
  4.  This specification does not require any implementation to support
      TLS Renegotiation.  However, implementations that support TLS Renegotiation
      MUST implement and use the TLS Renegotiation Extension.  

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 14:00:42 -0600

On 7/6/10 1:58 PM, Kurt Zeilenga wrote:
> 'strictly optional' != 'shouldn't', 

Implementations MAY support it.

Deployments SHOULD NOT use it.

No contradiction there.

> which means you Therefore needs some word smithing.  I suggest:
> 

Other than the wishy-washy phrase "not require", that's a bit better. I
would still change "not require" to "MAY".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 07 Jul 2010 16:27:15 +0200

> 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.

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 7 Jul 2010 07:43:50 -0700

> 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.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 07 Jul 2010 17:02:33 +0200

Kurt Zeilenga <[email-masked]> 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.

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Jul 2010 09:10:22 -0600

> 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?
As Simon says, we can always write a spec that updates 3920bis with
recommedations about using TLS renegotiation in XMPP. If we don't need
it now, I'd stick with MUST NOT.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Jul 2010 10:38:19 -0500

On Jul 7, 2010, at 10:10 AM, Peter Saint-Andre wrote:

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

[as individual]

I concur. Keep it simple an unambiguous.  With out a strong articulable reason to do it, let's not put in a loophole for implementations to do something we'd rather them not do anyway.

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 7 Jul 2010 10:54:21 -0700

> 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.

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Jul 2010 12:33:28 -0600

On 7/7/10 11:54 AM, Kurt Zeilenga wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>>> 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.
>> 
> 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/