Subject: [xmpp] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt

From: Matt Miller <[email-masked]>
Date: Wed, 6 Jun 2012 09:39:48 -0600

FYI

Begin forwarded message:

> From: [email-masked]
> Date: June 6, 2012 09:37:12 MDT
> To: [email-masked]
> Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Using DNSSEC and DANE as a Prooftype for XMPP Delegation
> 	Author(s)       : Matthew Miller
>                          Peter Saint-Andre
> 	Filename        : draft-miller-xmpp-dnssec-prooftype-00.txt
> 	Pages           : 6
> 	Date            : 2012-06-06
> 
>   This document defines a model for securely delegating an XMPP service
>   for a domain to a host associated with a different domain.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-00.txt
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 06 Jun 2012 19:14:58 +0200

[...]
[4.  Use of DNSSEC]
seems to be mostly applicable to the case of the s2s tls server also. 
Reversed roles, but that is not different from 6125.
The only difference is that you can skip steps 4+5 then because you're 
not (at this point) establishing a tcp connection.

[5.1.  No Delegation]
 > a port of 5222 for client-to-server streams  (e.g.
 > "_5222._tcp.im.example.com") or 5269 for server-to-server streams
 > (e.g.  "_5269._tcp.im.example.com").

Does that apply even if a SRV record exists and the port is different 
from 5222/5269? When using DANE to verify the certificate on an incoming 
s2s connection (acting as a TLS server), what port am I supposed to use 
when verifying the sender domain (220 terminology)

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jun 2012 11:28:19 -0600

On 6/6/12 11:14 AM, Philipp Hancke wrote:

<snip/>

> when verifying the sender domain (220 terminology)

In TLSA records, the port number is the one most closely associated with
the application protocol. As far as I understand DANE, you could host an
XMPP service at another port and put that port number in the prepared
domain name. Matt also indicated to me that it's possible to leave off
the port entirely, although I'm not fully convinced of that yet. :)

Peter

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

---

From: Matt Miller <[email-masked]>
Date: Wed, 6 Jun 2012 11:59:25 -0600

> the port entirely, although I'm not fully convinced of that yet. :)

<caveat-emptor>I should have noted this document might have dependencies on another "federation framework" document</caveat-emptor>

I'll add this to the list of things to cover.

In my opinion, for XMPP server-to-server, the receiving server would need to perform SRV lookups of the initiating entity's source domain to determine the derived domain + port, so that the TLSA records can be properly located.

From my reading of DANE, it *appears* one could have TLSA records for the domain only (e.g. "hosting.example.net"), but accept I could have read it incorrectly (-:

- m&m

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 06 Jun 2012 20:22:40 +0200

> In my opinion, for XMPP server-to-server, the receiving server would need to perform SRV lookups of the initiating entity's source domain to determine the derived domain + port, so that the TLSA re…

I'd prefer to avoid that.
I liked the usage of srv records at the end of
http://www.ietf.org/mail-archive/web/xmpp/current/msg02617.html
but seem to be issues with dane+srv, see
http://trac.tools.ietf.org/wg/dane/trac/ticket/28

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jun 2012 12:27:20 -0600

On 6/6/12 12:22 PM, Philipp Hancke wrote:
>> In my opinion, for XMPP server-to-server, the receiving server would
>> need to perform SRV lookups of the initiating entity's source domain
>> to determine the derived domain + port, so that the TLSA records can
>> be properly located.
> 

Creating TLSA records under _xmpp-server._tcp.capulet.lit would, I
think, require a new DNS resource record type (you could think of it as
"TLSS", parallel to "TLSA" for A/AAAA records). Personally I'm hoping to
avoid that.

> http://trac.tools.ietf.org/wg/dane/trac/ticket/28

Oh yes, there are issues. :)

Peter

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

---

From: Matt Miller <[email-masked]>
Date: Wed, 6 Jun 2012 13:54:48 -0600

> "TLSS", parallel to "TLSA" for A/AAAA records). Personally I'm hoping to

I also think this becomes an operational nightmare for the source domain admin.  Unless the there is not derived domain, the source domain admin would need to maintain constant vigilance of the derived domain's certificates to ensure their "TLSA for SRV" records are current against the derived domain's.

> Oh yes, there are issues. :)

I think it's best to leave that bear un-poked (-:

- m&m

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jun 2012 13:57:11 -0600

On 6/6/12 1:54 PM, Matt Miller wrote:
>>>> In my opinion, for XMPP server-to-server, the receiving
>>>> server would need to perform SRV lookups of the initiating
>>>> entity's source domain to determine the derived domain +
>>>> port, so that the TLSA records can be properly located.
>>> 
>>> I'd prefer to avoid that. I liked the usage of srv records at
>>> the end of 
>> think, require a new DNS resource record type (you could think of
>> it as "TLSS", parallel to "TLSA" for A/AAAA records). Personally
>> I'm hoping to avoid that.
>> 
> 
> I also think this becomes an operational nightmare for the source
> domain admin.  Unless the there is not derived domain, the source
> domain admin would need to maintain constant vigilance of the
> derived domain's certificates to ensure their "TLSA for SRV"
> records are current against the derived domain's.

Right. Furthermore, I don't think it's necessary. The DANE spec
describes the first "field" in the prepared domain name as follows:

   1.  The decimal representation of the port number on which a TLS-
       based service is assumed to exist is prepended with an underscore
       character ("_") to become the left-most label in the prepared
       domain name.  This number has no leading zeros.

Notice the "assumed to exist". We could interpret that as assuming the
normal port, e.g., 5269 for XMPP s2s (since that's the port registered
with IANA).

Peter

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

---

From: Matt Miller <[email-masked]>
Date: Thu, 7 Jun 2012 11:42:47 -0600

On Jun 6, 2012, at 13:57, Peter Saint-Andre wrote:

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

I think that would be fine for TLSA.  However, with "just" DNSSEC, I don't see how the skeptical domain avoids the SRV lookup.  The signing of the records is what proves (or disproves) the chain of trust.

DANE is some (potentially tasty) icing atop the DNSSEC cake, but you still need the cake (-:

- m&m

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 07 Jun 2012 20:33:17 +0200

> I think that would be fine for TLSA.  However, with "just" DNSSEC, I don't see how the skeptical domain avoids the SRV lookup.  The signing of the records is what proves (or disproves) the chain of…

You can't avoid them because you need it to get the derived domain name.
That is given for c2s or s2s client at the point when you're already 
connected but an extra step for the s2s server (it might be good to 
ignore s2s in this document and focus on c2s...).
Incidentially that gives us the port number and answers my initial question.

 > DANE is some (potentially tasty) icing atop the DNSSEC cake, but you

No, those are different cakes.

In section 4

    7.  For each address record answer that is a provably secure, the TLS
        client SHOULD consider a connection to that derived domain as
        securely delegated;

This step is building the list of acceptable reference identifiers.

        when verifying the certificate (as described
        in [RFC6125]),

That is the match-seeking step.

        the TLS client SHOULD do so against the derived
        domain but MAY also verify the certificate against the source
        domain.

and this is again fiddling with the list of acceptable reference 
identifiers.

Now what DANE does is replacing the concept of reference identifiers and 
presented identifers by the concept of the certificate association. 
Which of course can be considered as a different kind of reference 
identifiers and presentend identifiers, but that's a different cake.

Speaking of which...

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 14:18:24 -0600

On 6/7/12 12:33 PM, Philipp Hancke wrote:
>> I think that would be fine for TLSA.  However, with "just" DNSSEC, I
>> don't see how the skeptical domain avoids the SRV lookup.  The signing
>> of the records is what proves (or disproves) the chain of trust.
> 

Yes. I find it helpful to think in terms of reference identifiers (what
the initiating entity expects the server to be) and presented
identifiers (what the server claims to be in its certificate), but then
again I co-authored RFC 6125. :)

> identifiers and presentend identifiers, but that's a different cake.

Right: the term "certificate association" is another way to says that
the TLS client has been able to match its reference identifier(s) with
the TLS server's presented identifier(s). Or so it seems to me.

Peter

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