1 / 12

XMPP DNA

XMPP DNA. Outline. What’s the problem here? DNSSEC is the solution … ? If not DNSSEC, then … ? Where do we go from here?. XMPP Server Authentication. _ xmpp -server._ tcp.B.com SRV c.com. A. C. ClientHello SNI= b.com. b.com ? c .com ?. Current Requirements.

winter
Télécharger la présentation

XMPP DNA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XMPP DNA

  2. Outline • What’s the problem here? • DNSSEC is the solution … ? • If not DNSSEC, then … ? • Where do we go from here?

  3. XMPP Server Authentication _xmpp-server._tcp.B.com SRV c.com A C ClientHello SNI=b.com b.com? c.com?

  4. Current Requirements • “The server certificate MUST be checked against the hostname as provided by the entity (client or server), not the hostname as resolved via the Domain Name System” • Hosting providers can’t hold customer certs • Too much responsibility; not allowed • Two different channels for each src-dst pair • 10k domains on each side => 200M sockets

  5. Basic problem • Requirement to authenticate “human-entered” domain because redirect isn’t authenticated • Don’t know that B.com actually sent you the SRV, as opposed to some attacker • Need a way for B.com to sign a statement of the redirection

  6. DNSSEC! • SRV is a DNS resource record • DNSSEC is the way to sign DNS RRs • If a client sees a signed SRV RR, then it is safe to authenticate the target domain

  7. DNSSEC solution • On establishing a connection: if ((dNSName == srcName) ||(dnssec && (dNSName == dstName))) { /* SUCCESS */ } else { /* FAIL */ } // Establish TLS, looking for authName • Connection reuse: If we get a second redirect to the same name, re-use the connection

  8. Mutual Authentication

  9. DNSSEC challenges • Need DNSSEC chains to trust anchors • Root now signed, com coming in March 2011 • 45% of gTLDs, 18.5% of ccTLDs • Also have alternative trust anchors • Customers have to provision DNSSEC

  10. If not DNSSEC, then what? • draft-barnes-xmpp-dna • How do you encode the delegation? • DNS record, X.509 attribute cert, text, JSON, … • How do you find the delegation? • DNS, HTTP, XMPP, … • How do you trust the signing key? • DNSSEC, X.509, …

  11. Non-DNSSEC Challenges • Encoding: Either you have to use the signed thing for redirection or you have to compare across encodings • Use DNS record or re-invent SRV • Discovery: When in the connection process do you find the signed delegation? • Keys: Use domain certs?

  12. What now? • Does DNSSEC solve the problem? • Probably need to update RFC 3920 either way • Is DNSSEC a practical solution? • Not deployed across all TLDs • Provisioning constraints • If not DNSSEC, then what?

More Related