[Standards] ProtoXEP: SRV records for XMPP over TLS

[Travis Burtrum]

This proposal defines a procedure to look up _tls SRV records in
addition to _tcp and mix weights/priorities.

Rendered version can be found at https://burtrum.org/xeps/tls-srv.html

This discussion was already started on a github pull request here:
https://github.com/xsf/xeps/pull/116
but was requested to be brought up on this list.

I do have a POC implementation written up for Conversations here:
https://github.com/siacs/Conversations/pull/1371

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Travis Burtrum]

Hello Peter,

On 11/05/2015 01:27 PM, Peter Saint-Andre wrote:
> I haven't yet had time to look at your proposal in detail. However,
> there is no _tls Protocol name in RFC 2782 or RFC 6335. It seems strange
> for us to be the only ones using that non-standard value.

At least Microsoft Lync and *I think* SIP (though I can't find a
reference right now) use 'tls' for the Protocol value as well.  Also RFC
2782 does not define values for it, leaving it to be any 'defined name'.

This was discussed on the github pull request, and Dave Cridland wrote,
in part:
> I wasn't sure, either, about the use of _tls; so I asked Arnt
> Gulbrandsen (author of RFC 2782) - his opinion was that using _tls,
> and intermixing the _tcp proto records, was perfectly acceptable. His
> concerns were actually that he felt that ALPN should be made mandatory.

Thanks,
Travis

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Peter Saint-Andre]

On 11/5/15 10:45 AM, Travis Burtrum wrote:

This proposal defines a procedure to look up _tls SRV records in
addition to _tcp and mix weights/priorities.


I haven't yet had time to look at your proposal in detail. However, 
there is no _tls Protocol name in RFC 2782 or RFC 6335. It seems strange 
for us to be the only ones using that non-standard value.


And there might be better ways to approach this problem, but I need to 
think about it more before I post about that...


Peter

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Georg Lukas]

* Travis Burtrum  [2015-11-05 18:45]:
> This proposal defines a procedure to look up _tls SRV records in
> addition to _tcp and mix weights/priorities.

One point that stood out to me is this:

6. Client or server SHOULD set SNI TLS extension to the host in the SRV record.

Is that a deliberate decision or just inappropriate wording?

While I can see the use case of a large XMPP hoster (*cough*gmail*cough*)
that hosts many domains without actually having their respective
certificates, this introduces a huge security issue:

An attacker could poison/redirect a domain's SRV record to his own
server (let's call it mallory.example), and a TLS-client would happily
connect, request mallory.example's TLS certificate via SNI and
successfully validate it, providing PLAIN credentials to the evil
server. The attacker could even pass them on to the official server,
making the connection seamless.

While DNSSEC aims to solve this kind of attacks, it doesn't look like
it's there yet - or should be relied upon.


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: Digital signature

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Philipp Hancke]

Am 05.11.2015 um 11:51 schrieb Travis Burtrum:

Hello Peter,

On 11/05/2015 01:27 PM, Peter Saint-Andre wrote:

I haven't yet had time to look at your proposal in detail. However,
there is no _tls Protocol name in RFC 2782 or RFC 6335. It seems strange
for us to be the only ones using that non-standard value.


At least Microsoft Lync and *I think* SIP (though I can't find a
reference right now) use 'tls' for the Protocol value as well.  Also RFC
2782 does not define values for it, leaving it to be any 'defined name'


turns out I was wrong about Lync which uses
   _sipfederationtls._tcp
to achieve this.

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Travis Burtrum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Georg,

On 11/05/2015 02:21 PM, Georg Lukas wrote:
> 6. Client or server SHOULD set SNI TLS extension to the host in the
> SRV record.
> 
> Is that a deliberate decision or just inappropriate wording?

That was a deliberate decision on my part, and does not affect
security in the way you mentioned because I explicitly state:

> TLS certificates MUST be validated the same way as for STARTTLS.
(ie, as specified in XMPP Core).

In other words against the domain part of the JID, so if DNS was
maliciously poisoned, the certificate would not validate and the
connection would be aborted.  I suppose the wording could be changed
to make that more clear.

The reason I chose to do it that way is so the server operator could
instead multi-plex multiple protocols in TLS by looking at the SNI
name instead of ALPN. SNI is old and well supported by every TLS
library, ALPN is new and barely supported anywhere.  My server is an
example, burtrum.org:443 is HTTPS, but xmpp.burtrum.org:443 is
XMPP-over-TLS, decided based on the SNI name.  (sslh and stunnel both
have support for this)

Thanks,
Travis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQQcBAEBCgAGBQJWO7TPAAoJEOy5uMuqxowDS44f/1LTpHIBihh87qUZpcottbq+
C4O4biwv3EhC8ul3r2/dAIA/go4VcojVmURSNvVHvH1yYWg6MEWu8Ec6nsYB0Kiu
loElUt5B4ybM36vxXedfuu59Ot6blA4GDpUEvcVzz/5rK6LIPi0fzUbCZ24RpG4O
RHNgkjsX0CEY5q6A4VqTHp1JSp8fcxgWgSa2mGMfxKkI5nDs8aTOaIM0SUmpxwcI
RROcBiargetYP6Gthyfd/XGYy8Vh71LRlLNrGCZxEPJRV5s3f2cMJLVrbpXNsrQ+
PEgq6YsjEbjd9yUmO245vTCMIZKykcYWtpXkL9g9VXKQfWEcKpajLuQRg2DhOyly
9sxs4ym6PpwoLIkH52ZsK+Nzcm8u3AvLfEhFhvFJwZrIlQwp5LP2nF1Lovm3q6S2
V4nsq2t9BQZ6DlDKDdfvUkhVSL6l3gzkoqyGdi1CQoxtrDjz08xKxUbtOlzY47in
Z8ZAOrMVoLczICD4J6Bh5VOwJYXbz/Bz+fiyeBri1E0m8pu+VHVoULWxqX74tMeY
VWSkTfDfcDKT++spF+MEIaK01YyR40hmIgzlyyoAw0p4UOCy9VFue/Jn/I/q4bTh
/bW34pxZfj9vySoe04xEl5lfu/X0X+9VDQtcANU/5bkKSI3slYfbD6MbR/+79Fxn
pSCfItWLq8LmyXa/YiAm3We2ccRvHAqe8hAfftvXyAKRIcF8Tkq+3v7nQf1MiRJr
N73is272lSXLAiw+Uv+aNnHgLANXN5Um7tK2ImjJU0SuDOS9cSk90IYPMolXltFO
bTAMGxSeR54gPp7OUCv11t0xCJAl6j1OW6XznSEH5ekOtzI7rEGEJotwL8GrYqLI
W1Ksz7RidTrhPV8su+NQ11oXKM9zbEe7a5TIkedZ7QRoqGMAcoxTB7924hEp9RJL
R5cB5Y/7rv/zPJ2Nj+MOtRFS9q/xrlMhvpnqHUjoRHgQWnL+LN8dKz6MV0xL6QiG
v/T7mewiTXhs/kCy8w7M0nraGRAlWfSb8Bb3gNzufEnjbzIRcF0jDZENQltJAr8N
VtMd96Gj+1PI4xyhUIXkBZBrM6Mv6wute7JJuw00V2KLfiL4CarGMcNfSheJ8GFd
dDbLwrfMnWkdr344VNP5rY2V56MEbH3mFGMmuAabSG10n5IQpRbVxwyKRn+YVcWF
PYK8+mGN0CWVZNB2foY+k17xyW0igJ7Jea8lSwHwJ78QzknIY/I7gTySEyIrtnAt
vRFquBpI7lw5SReUxAiWSrPQb9+OzTpDUziWCVXCuONqQydA6VFhwqNvQnSNX1p7
pc6QQUqqGP1JLZV0czer+CxY+d/qGyLMqAY5mVH+DWWGvPIZ4cv/3OlKtwNLkuM=
=IrCC
-END PGP SIGNATURE-

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Peter Saint-Andre]

On 11/5/15 5:34 PM, James Cloos wrote:

"EK" == Evgeny Khramtsov  writes:


EK> SIP doesn't have _tls as well. It uses _sips._tcp for this
EK> as described in RFC3263.

That might be in the rfc, but most clients seem to look for _sip._tls.


True.

However, just because the SIP community embraced this hack doesn't mean 
we need to. The IANA registrations show no usage of any proto except tcp 
and udp:


http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

But, as I said, I need to look at this proposal in more detail...

Peter

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[James Cloos]

> "EK" == Evgeny Khramtsov  writes:

EK> SIP doesn't have _tls as well. It uses _sips._tcp for this
EK> as described in RFC3263.

That might be in the rfc, but most clients seem to look for _sip._tls.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Travis Burtrum]

On 11/05/2015 03:02 PM, Philipp Hancke wrote:
> turns out I was wrong about Lync which uses
>_sipfederationtls._tcp
> to achieve this.

It looks like lync uses both _sip._tls and _sipfederationtls._tcp:

https://technet.microsoft.com/en-us/library/gg412787%28v=ocs.15%29.aspx

On 11/05/2015 03:55 PM, Evgeny Khramtsov wrote:
> SIP doesn't have _tls as well. It uses _sips._tcp for this
> as described in RFC3263.

I found a reference to that as well:
https://support.counterpath.com/topic/sip-tls-and-dns-srv-records-on-bria-iphone

Either way I really don't think it matters at all, I'm fine with either:

_xmpp-client._tls
_xmpp-server._tls

or:

_xmpps-client._tcp
_xmpps-server._tcp

or even:

_xmpp-tls-client._tcp
_xmpp-tls-server._tcp

It doesn't matter at all to me. :)

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Travis Burtrum]

Hello Dave,

On 11/05/2015 04:09 PM, Dave Cridland wrote:
> 2) I'm a little concerned that this may be somewhat out of scope for the
> XSF; in particular, it might be better discussed within the IETF and
> reformulated as an Internet Draft (and ultimately an RFC). I can tell
> you how to go about that if you like.

Hmm, I really didn't consider that at all.  Other methods of discovering
XMPP servers like using TXT records are defined in XEP-0156, but the
original usage of SRV methods for discovery is in the original XMPP RFC.
 I don't know who would/should decide that?  I don't mind waiting on the
XMPP council to reconvene or anything.

Thanks,
Travis

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Dave Cridland]

Four comments:

1) Council is currently in haïtus until a new Council is elected in a week
and a bit, so this cannot be adopted as a XEP quite yet.

2) I'm a little concerned that this may be somewhat out of scope for the
XSF; in particular, it might be better discussed within the IETF and
reformulated as an Internet Draft (and ultimately an RFC). I can tell you
how to go about that if you like.

3) While I don't have any objection to _tls (in fact, I think it'd be
cleaner) it looks like current protocols have used variants on the "_sips"
naming instead. RFC 6186 is another case in point that I'd forgotten about
until I looked. So while I think this is probably the better design, I
think it'd be better to match other protocol usage.

4) I'm not entirely sure about the recommended usage of SNI and ALPN here;
I need to think about that one. I appreciate the SNI hack, but it *is* a
hack... And my internal jury is still out on ALPN.

On 5 November 2015 at 17:45, Travis Burtrum  wrote:

> This proposal defines a procedure to look up _tls SRV records in
> addition to _tcp and mix weights/priorities.
>
> Rendered version can be found at https://burtrum.org/xeps/tls-srv.html
>
> This discussion was already started on a github pull request here:
> https://github.com/xsf/xeps/pull/116
> but was requested to be brought up on this list.
>
> I do have a POC implementation written up for Conversations here:
> https://github.com/siacs/Conversations/pull/1371
>

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Olle E. Johansson]

> On 05 Nov 2015, at 20:51, Travis Burtrum  wrote:
> 
> Hello Peter,
> 
> On 11/05/2015 01:27 PM, Peter Saint-Andre wrote:
>> I haven't yet had time to look at your proposal in detail. However,
>> there is no _tls Protocol name in RFC 2782 or RFC 6335. It seems strange
>> for us to be the only ones using that non-standard value.
> 
> At least Microsoft Lync and *I think* SIP (though I can't find a
> reference right now) use 'tls' for the Protocol value as well.  Also RFC
> 2782 does not define values for it, leaving it to be any 'defined name’.
SIP uses _sips._tcp for SIP over TLS.


> 
> This was discussed on the github pull request, and Dave Cridland wrote,
> in part:
>> I wasn't sure, either, about the use of _tls; so I asked Arnt
>> Gulbrandsen (author of RFC 2782) - his opinion was that using _tls,
>> and intermixing the _tcp proto records, was perfectly acceptable. His
>> concerns were actually that he felt that ALPN should be made mandatory.

I think the DNS directorate in the IETF should be consulted here. SIP has had
a lot of discussions of using “TLS” as the name of a transport. The URI 
parameter
“;transport=tls” was deprecated (but is still used as it’s the only option). 
The SIPS:
URI scheme is more or less deemed useless and we recommend it not to be used.
The Via: headers use TLS as a transport name though, so it’s confusing and not
clear whether “tls” used as a transport is ok or not. With DTLS it becomes more
confusing.

Just to be a bit more confusing, the use of “_sips” in SRV has no connection to
the “SIPS:” uri which is quite often an assumption of developers.

SIP doesn’t have STARTTLS support. We do use DNS NAPTR for service discovery,
so a service can request or recommend use of TLS by adding SRV names to the 
NAPTR
records.

I’ve been trying to stir up some interest for clearing up this mess in the 
SIPCORE
IETF wg, but has had no luck so far. 

/O

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

[Thijs Alkemade]

> On 5 nov. 2015, at 20:52, Georg Lukas  wrote:
> 
> My gut feeling is that really restrictive firewalls will either
> completely block the ALPN extension (breaking SPDY as well), or
> implement ALPN parsers and whitelist HTTP only.
> 
> This will probably only be solved by TLS1.3, which is still three major
> protocol meltdowns away (TLS1.0, 1.1 and 1.2 ;-))

While SNI/ALPN encryption for the ClientHello was discussed for TLS 1.3, I
think it was ultimately dropped as it added too much extra complexity (but
maybe there's someone here who follows the TLS WG more closely).

Encryption of the server's extensions is still supported, though, so the
selected ALPN protocol can be hidden.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail