<title>Impact of TLS and DNSSEC on Dialback</title>
<abstract>This specification provides documentation how Server Dialback is used together with Transport Layer Security, and discusses how the security considerations of Dialback are changed by the introduction of TLS and/or DNSSEC.</abstract>
<p>Changed title and added more security considerations.</p>
</remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2013-11-13</date>
<initials>dwd</initials>
<remark><p>Added some narrative and a section on dwd.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-11-04</date>
<initials>ph</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>Although &xep0220; describes dialback as being run before any other negotiation, it is typically run over TLS where supported. This allows it to be used as a simple convenient fallback to X.509 Strong Authentication within the TLS layer, as described in &rfc6120;, and also affords greater protection to the exchange.</p>
<p>This document describes these practises, and also describes various functionally equivalent shortcuts to the protocol, including that known as "dialback without dialback".</p>
</section1>
<section1topic='Protocol'anchor='protocol'>
<section2topic='Dramatis Personae'>
<p>This document will tell a tale of two servers; orchard.capulet.example is trying to contact home.montague.example. Each server operates a single domain; these are capulet.example and montague.example respectively.</p>
<examplecaption="Receiving Server is Informed by Authoritative Server that Key is Valid (Step 3)"><![CDATA[
<db:verify
from='capulet.example'
id='D60000229F'
to='montague.example'
type='valid'/>
]]></example>
<examplecaption="Initiating Server Receives Valid Verification Result from Receiving Server (Step 4)"><![CDATA[
<db:result
from='montague.example'
to='capulet.example'
type='valid'/>
]]></example>
</section2>
<section2topic='Dialback without dialback flow'anchor='dwd'>
<p>If during the initial connection, home.montague.example is able to determine that the certificate presented is trustworthy, and authenticates orchard.capulet.example as authorized to offer the XMPP service for capulet.example, then the flow can be shortcutted heavily, allowing the entire Authoritative Server process to be elided.</p>
<p>This is particularly useful in cases where the dialback exchange is a subsequent exchange used in piggybacking, as it remains the only solution for piggybacking with strong authentication.</p>
<p>Note that having authenticated the certificate and found it authorized for capulet.example, montague.example has offered EXTERNAL above. It's not clear why capulet.example does not avail itself of the offer below; however it should be noted that EXTERNAL would not be available with piggybacking for example.</p>
<examplecaption="Initiating Server Sends Dialback Key (Step 1)"><![CDATA[
<p>Critically, it is at this point that home.montague.example both authenticates and checks authorization on the certificate, or at least ensure that the certificate presented at this stage matches that presented at the initial handshake.</p>
<examplecaption="Initiating Server Receives Valid Verification Result from Receiving Server (Step 4)"><![CDATA[
<p>If during the initial connection, the Receiving Server is unable to determine that the certificate presented is trustworthy but the Authoritative Server presents the same certificate as the Originating Server, the <db:verify/> step can be elided.</p>
<p>Note: the Receiving Server MUST still check that the hostname in the certificate matches.</p>
<p>Essentially, this replaces the Dialback Key Validation step from &xep0185; with the somewhat more elaborate proof of posession of the private key associated with the certificate.</p>
<code><![CDATA[
orchard.capulet. home.montague.
example example
(as Initiating) (as Receiving
Server) Server)
---------------- -------------
| |
| [if necessary, |
| perform DNS |
| lookup on |
| Target Domain, |
| open TCP |
| connection, |
| and establish |
| stream] |
| -----------------> |
| (ID D60000229F) |
| |
| send | capulet.example
| dialback key | (as Authoritative
| -----(STEP 1)----> | Server)
| | -----------------
| | [if necessary, |
| | perform DNS |
| | lookup on |
| | Sender Domain, |
| | open TCP |
| | connection, |
| | and establish |
| | stream] |
| | -----------------> |
| | [observe certificate is for
| | capulet.example and same as
| | used by orchard.capulat.example]
| report |
| dialback result |
| <-----(STEP4)----|
]]></code>
</section2>
<section2topic='XMPP Exchanges in Same Certifiate shortcut'anchor='samecert-stanzas'>
<p>This pattern involves the following protocol exchanges:</p>
<examplecaption="Initiating Server Opens Stream"><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
from='capulet.example'
to='montague.example'
version='1.0'>
]]></example>
<examplecaption="Receiving Server Responds with a stream header and advertises TLS feature"><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
id='D60000229F'
from='montague.example'
to='capulet.example'
version='1.0'>
<stream:features>
<starttlsxmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
</stream:features>
]]></example>
<examplecaption="Initiating Server Sends STARTTLS command"><