Subject: [xmpp] #45: causes for STARTTLS failure

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 00:37:51 -0000

#45: causes for STARTTLS failure
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  trivial             |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 5.3.2.2 (which covers failure cases for TLS negotiation) contains
 the following informational note:

 > STARTTLS failure is not triggered by TLS errors such as bad
 > certificate or unknown certificate authority; those errors are
 > generated and handled during the TLS negotiation itself as
 > described in [TLS].

 Philipp Hancke commented: "This is not true for the majority of deployed
 servers which let the TLS handshake succeed in any case and then do
 dialback after starttls."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/45>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Jun 2010 14:49:12 -0600

> #45: causes for STARTTLS failure

I think you have misunderstood the text of this informational note (and
it is informational). When you say "this is not true...", you are saying
that failure of the STARTTLS can in fact be triggered by TLS errors,
which is false. What you seem to be claiming is that most servers do not
terminate the TCP connection on TLS errors, which is quite a different
claim.

Peter

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

---

From: "xmpp issue tracker" <[email-masked]>
Date: Wed, 23 Jun 2010 21:16:41 -0000

#45: causes for STARTTLS failure
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  trivial             |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  invalid           
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => invalid

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/xmpp/trac/ticket/45#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 24 Jun 2010 08:57:02 +0200

Peter Saint-Andre schrieb:
> which is false. 

No, "this is not true" applies to "those errors". Your choice of error 
examples is very unfortunate, since it is implying that the "correct" 
behaviour when encountering a unknown certificate authority is to send a 
unknown_ca TLS errror alert.

What about:
STARTTLS failure is not triggered by TLS errors such as bad_certificate 
or handshake_failure; those errors are generated and handled during the 
TLS negotiation itself as described in [TLS].

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 20:27:08 -0600

> TLS negotiation itself as described in [TLS].

Yes, handshake_failure is a better example than unknown_ca. Fixed in my
working copy.

<tangent>

Probably it would be good to reference Section 7.2 of RFC 5246 somewhere
from 3920bis, but this informational note is not the place. Consider the
first three paragraphs of Section 7.2.2:

   Error handling in the TLS Handshake protocol is very simple.  When an
   error is detected, the detecting party sends a message to the other
   party.  Upon transmission or receipt of a fatal alert message, both
   parties immediately close the connection.  Servers and clients MUST
   forget any session-identifiers, keys, and secrets associated with a
   failed connection.  Thus, any connection terminated with a fatal
   alert MUST NOT be resumed.

   Whenever an implementation encounters a condition which is defined as
   a fatal alert, it MUST send the appropriate alert prior to closing
   the connection.  For all errors where an alert level is not
   explicitly specified, the sending party MAY determine at its
   discretion whether to treat this as a fatal error or not.  If the
   implementation chooses to send an alert but intends to close the
   connection immediately afterwards, it MUST send that alert at the
   fatal alert level.

   If an alert with a level of warning is sent and received, generally
   the connection can continue normally.  If the receiving party decides
   not to proceed with the connection (e.g., after having received a
   no_renegotiation alert that it is not willing to accept), it SHOULD
   send a fatal alert to terminate the connection.  Given this, the
   sending party cannot, in general, know how the receiving party will
   behave.  Therefore, warning alerts are not very useful when the
   sending party wants to continue the connection, and thus are
   sometimes omitted.  For example, if a peer decides to accept an
   expired certificate (perhaps after confirming this with the user) and
   wants to continue the connection, it would not generally send a
   certificate_expired alert.

You are saying that many XMPP implementations behave as described in the
last sentence: they ignore certain errors in the TLS negotiation and
continue the connection (e.g., this is the case with TLS+dialback). Such
cases are mentioned in RFC 5246, but perhaps we need to call them out
more clearly in 3920bis.

</tangent>