Subject: [xmpp] #7: text on SRV Security Checks is unclear

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 14 Jun 2010 16:16:32 -0000

#7: text on SRV Security Checks is unclear
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Reported by Dave Cridland:

 The text is unclear in Section 3.2.4 (SRV Security Checks).

 "I'm unclear on precisely what this means. Is this saying that if I lookup
 cridland.net and find that it's hosted at Google, then I should ask my
 user about this? Why?"

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 18:59:48 -0600

> #7: text on SRV Security Checks is unclear

Because a malicious attacker with access to the DNS server data, or able
to cause spoofed answers to be cached in a recursive resolver, can
potentially cause the initiating entity to connect to any XMPP server
chosen by the attacker.

(Yes, I borrowed that text from draft-daboo-srv-email-04.)

Peter

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

---

From: "xmpp issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 04:02:43 -0000

#7: text on SRV Security Checks is unclear
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

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

Comment:

 Provisionally resolved with this text:

 3.2.4.  SRV Security Checks

    A malicious attacker with access to the DNS server data, or able to
    cause spoofed answers to be cached in a recursive resolver, can
    potentially cause the initiating entity to connect to any XMPP server
    chosen by the attacker.  Therefore, in the absence of a secure DNS
    option (e.g., as provided by [DNSSEC]), the initiating entity SHOULD
    check that the target domain name returned in the SRV record matches
    the origin domain that was queried.  If the target domain name is not
    within the trust boundaries of the origin domain, the connecting
    application SHOULD verify with the human user (if any) that the SRV
    target domain name is suitable for use before executing any
    connections to the IP address of the XMPP service.

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

---

From: Kevin Smith <[email-masked]>
Date: Fri, 25 Jun 2010 08:14:35 +0100

>    connections to the IP address of the XMPP service.

It's not clear to me that this is a problem that needs solving -
doesn't TLS solve this for us? This wording seems to make life
unnecessarily hard when the server that your client is protecting you
from could be willing to present a valid TLS cert for the desired
domain.

If we say elsewhere that we SHOULD be checking the identity of the
server with certs (and I think we are), that seems to be a much better
idea than this.

/K

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 25 Jun 2010 09:53:39 +0200

> from could be willing to present a valid TLS cert for the desired

Especially since this is trivial to avoid for the attacker by not 
changing the target domain name but the ip address for the target domain 
name.

In the case of jabber.org the malicious attacker would change the result 
of the hermes.jabber.org A / AAAA lookup such that it returns his chosen 
XMPP server.

I think that subsection is not needed at all.

philipp

---

From: Matthew Wild <[email-masked]>
Date: Fri, 25 Jun 2010 12:06:37 +0100

On 25 June 2010 08:53, Philipp Hancke <[email-masked]> wrote:

> Especially since this is trivial to avoid for the attacker by not changing
> the target domain name but the ip address for the target domain name.
>
> In the case of jabber.org the malicious attacker would change the result of
> the hermes.jabber.org A / AAAA lookup such that it returns his chosen XMPP
> server.
>

I think I'm of the same opinion.

Matthew

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Jun 2010 10:37:06 +0100

> > #7: text on SRV Security Checks is unclear

Right, so what we're saying is that if an attacker spoofs the SRV  
record, we'll protect against that by moaning anytime the SRV record  
looks dodgy, but if the attacker spoofs the A record, we'll never  
notice.

This suggests that we'll be generating noise in many cases which will  
be ignored by users, and attackers will simply spoof the more  
sensible record to subvert the traffic leaving users unawares.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 13:07:02 -0600

> I think I'm of the same opinion.

I hear the sweet sound of consensus. :)

Furthermore, the section to be removed overlaps with Section 13.9.2 in
the Security Considerations. Incorporating the feedback from this
thread, I have just rewritten that section a bit, as follows:

###

13.9.2.  Use of DNS

   XMPP typically relies on the Domain Name System (specifically
   [DNS-SRV] records) to resolve a fully qualified domain name to an IP
   address before a client connects to a server or before a peer server
   connects to another server.  Before attempting to negotiate an XML
   stream, the initiating entity MUST NOT proceed until it has resolved
   the DNS domain name of the peer server as specified under Section 3
   (although it is not necessary to resolve the DNS domain name before
   each connection attempt, because DNS resolution results can be
   temporarily cached in accordance with time-to-live values).  However,
   in the absence of a secure DNS option (e.g., as provided by
   [DNSSEC]), a malicious attacker with access to the DNS server data,
   or able to cause spoofed answers to be cached in a recursive
   resolver, can potentially cause the initiating entity to connect to
   any XMPP server chosen by the attacker.  Deployment and validation of
   server certificates helps to prevent such attacks.

###

Peter

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