[Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

[Travis Burtrum]

Turns out tls-unique is *additionally* broken by 
https://www.mitls.org/pages/attacks/SLOTH found a few months after the release 
of RFC7627 that tried to fix it:

> If your TLS application relies on the tls-unique channel binding to prevent 
> credential forwarding, you need to redesign your application.
> Our attack on the tls-unique channel binding affects application-level 
> protocols that rely on this channel binding to prevent credential forwarding 
> attacks. In general, all uses of tls-unique are suspect, but the following 
> are known to be specifically affected:
> * SCRAM is used in SASL and GSSAPI and relies on tls-unique for channel 
> binding. SCRAM is the default authentication protocol for XMPP. ___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

[Travis Burtrum]

Hi all,

On 5/6/24 1:21 PM, Daniel Gultsch wrote:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?


No. And in fact it opens gaps.


2. Does the specification solve the problem stated in the introduction
and requirements?


It enables negotiating a feature meant to prevent/detect MITMs with the 
MITM themselves.



3. Do you plan to implement this specification in your code? If not,
why not?


MITM attack mitigation via public key pinning and tls-exporter? Yes. 
This specification? No.



4. Do you have any security concerns related to this specification?


So many.

1. it gives a MUST for servers and SHOULD for clients to implement 
tls-server-end-point which is weak and likely shouldn't be implemented 
at all. Note TLS-intercepting-proxies can implement the strong 
tls-exporter just fine by simply passing the keying material to the 
backend server. See 
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/MBNEF3NMA3UDD4SKULEY7AZCA3TV4I5P/?sort=date 
for more discussion.


2. tls-unique is broken by https://www.mitls.org/pages/attacks/3SHAKE 
and "fixed" by https://datatracker.ietf.org/doc/html/rfc7627 *if* your 
client-side TLS library and config meets a ton of ifs.  It has to 
implement the extended master secret extension *and* the server has to 
negotiate this. (remember, the server here is the potential attacker, so 
it would just... not).


So to securely implement tls-unique a client would need to *require* 
negotiation of the extended master secret extension for TLS 1.2 
connections and fail to connect otherwise.  How many clients do this? 
How many clients have any idea whether their TLS lib supports or 
enforces this?  How many TLS libs even let you check this?


We must assume tls-unique is not to be trusted.

3. That leaves tls-exporter as the only secure channel binding method.

One method doesn't need negotiation.  A wise person recently said 
"parameterize of security protocols and algorithms are generally a bad 
idea as it adds complexity which reduces security." 
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/DFWL7RSQ4HY5CR66BS46SJ4GTS6D7BOF/


This spec in particular says to nicely ask the attacker if they support 
it before doing it... and the attacker will just say no.  The XEP 
handwaves this security destroying attack as a "well clients could pin 
channel bindings" not even a MAY, SHOULD, or MUST.  Do any 
implementations today do this?  If not it is just feel good security 
theater that gives absolutely no security against a MITM.



5. Is the specification accurate and clearly written?


See #4

In summary, a XEP to negotiate channel binding with the attacker isn't 
helpful.


The only security we can get from channel binding is by *requiring* 
clients to do only tls-exporter with only TLS 1.3 or QUIC. If this fails 
the client MUST pop up a warning similar to "this is an untrusted 
certificate, deny/allow".


If we want a XEP that suggests the above it should be clear in the 
security considerations what it prevents and what it doesn't, and how it 
compares to other things like public key pinning (DANE or '487), likely 
suggesting to do both. Roughly both public key pinning and requiring 
tls-exporter channel binding both protect against a jabber.ru style MITM 
where the MITM gets their own new certificate, but does not read the 
disk of the server they are attacking.  Neither public key pinning *nor* 
channel binding protect against a MITM where the attacker can read the 
disk of the XMPP server and take the public key (and/or cert) and 
password hashes to use for SCRAM authentication itself.


Thanks,
Travis
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Feedback requested: SVCB for XMPP

[Travis Burtrum]

Hi Dave!

I've only briefly reviewed this so far, so please forgive if I've missed 
things, but I have some early comments:


Major blocker I'm not sure can be addressed:

1.
This essentially re-introduces the major security flaw that was 
addressed in XEP-0156 by removing the TXT record, just with a warning.

Context:
* 
https://web.archive.org/web/20220828222121/https://mail.jabber.org/pipermail/standards/2022-February/038759.html

* https://github.com/xsf/xeps/pull/1158
* 
https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.html#(17)


But all those points still remain, most importantly:
* nearly no HTTPS clients/libraries/browsers actually support "connect 
me to domain X but send SNI Y and validate the cert against domain Y", I 
would argue it's too dangerous to even allow trying this


Things easily addressed:

1.
> "xmpps-server" and "xmpps-client" have a default port registered in 
this document.
I don't actually see these registered.  Also I'm generally opposed to 
this, because, whether we like it or not (and I know most of us do not, 
including me) it's 2024 and protocols are no longer multiplexed via 
port, but instead all go over 443 (TLS or QUIC) and are multiplexed via 
ALPN.  Soothe yourself to sleep at night with the fact that this, 
combined with ECH, is actually a huge win for both connectivity and 
privacy, as intermediaries can no longer guess or police which 
protocol(s) you can use.


2.
It mentions QUIC, and links to the XEP, but I don't see a way to 
indicate a QUIC connection?


3.
Needs ECH, with HTTPS this is on the HTTPS record, where can it go here? 
I consider this absolutely required.


4.
Semi-minor nit: StartTLS certainly doesn't preclude ALPN being sent, but 
I actually wouldn't define it at all here.  legacy clients that don't 
support DirectTLS won't support this spec, and will look up StartTLS the 
old way, and 0 servers have support for StartTLS but not DirectTLS. 
Unless I'm missing some reason to keep support?


5.
Ultra-minor nit: is BOSH needed or useful with websockets and upcoming 
webtransport? legacy clients that don't support either of those won't 
support this either, and will look up bosh the old way.


Thanks,
Travis
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

[Travis Burtrum]

Hi Dave!

On 12/27/23 04:12, Dave Cridland wrote:

I dislike this XEP intensely.

But... I think it's probably the most pragmatic solution that fits the 
existing standards space.


Honestly... Nice summary of my opinion too. :)  We need things, sadly we 
don't live in an ideal world, and this seems like the least bad way to 
get everything we need in the world in which we live. (without 
precluding improving it of course! And of course improving XMPP 
connectivity will do this in it's own way :))



Questions:
- Should we require this to always be hosted at the exact domain? Pretty 
much everywhere I've worked for has the primary website (AKA "the 
marketing site") distinct from any production services, whether internal 
("IT") or external ("Engineering") facing. Is it worth having a dummy 
website on a different domain that we can check, and stipulate that if 
both exist, they MUST be both identical? (Or we can set a priority, but 
my intent here is that both would be checked simultaneously).


No, that's what HTTP 301/302 redirects are for, I would have swore I 
mentioned these in the XEP but indeed I did not... Roughly it should say 
follow a sane number of redirects (10?), forbidding looping, and require 
that each hop is https (never http) or abort.


- While I sympathize with the view that StartTLS for C2S and indeed S2S 
should be moving towards deprecation, that flies in the face of the 
pragmatism otherwise on display here - they need to be added in I think 
as rel types.


My thought is roughly that anything that implements this will at minimum 
implement DirectTLS.  It can still advertise StartTLS ports via SRV for 
things that don't implement this, so everything, legacy and host-meta-2, 
still works seamlessly.  I'm not absolutely opposed StartTLS rel types 
mind you, but wanted to explain my reasoning, is there still a reason to 
support them here?


- The TTL thing... I agree it's an error in RFC 6415 et al, but I'm 
unconvinced it's one we should worry ourselves over too much within the 
XSF. I'd save yourself the effort and assume developers are sensible.


I assume you mean the TTL instead of Expires? I think this should be an 
absolute requirement, as the other would essentially require this file 
be dynamically generated which I think should be avoided.


- In general, I'm not sure that the JRD/XRD model allows that "xmpp" 
block; those might need to be distinct properties.
- In general, I understand the JRD/XRD concept to be tightly bound to 
RDF, so I think you'd need to add in attributes as properties, and those 
properties would need to be URIs.


Many of the above will make things uglier, but I think more in-line with 
the JRD concepts.


Finally, I think it's worth putting some consideration into handling 
this one in the IETF entirely - you may find support for extracting the 
PKP bits into a generic approach, and all sorts.


As an alternative to all that, it might be sensible to explore *not* 
using host-meta, and instead using a well-known JSON blob (I see Matrix 
does this for example).


Re-using and extending host-meta.json is essentially a 
trick(/optimization/hack) to avoid an additional https request when 
grabbing details both the old way and the host-meta-2 way. It's *nice*, 
but not *absolutely required*, so I think if we can without breaking 
anything we should, but if there's a risk, we can eat the extra https 
request and roll our own format.


That said, I seriously doubt anyone consuming the json is validating it 
in any way, JRD pre-dates actual efforts to validate json like 
json-schema by nearly a decade. I think JRD is defined only 
https://datatracker.ietf.org/doc/html/rfc6415#appendix-A , and 
explicitly says "The conversion of any other element is left 
undefined.", which I interpret to mean adding the 'xmpp' block and 
anything else is fine, clients that adhere to this will ignore it. 
"ignoring unknown fields" is also how every JSON parser I've seen in the 
wild works by default.


re: IETF, not opposed, but would prefer to prove it (one way or the 
other) as a XEP first.



Dave.


Thanks much for the review!

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

[Travis Burtrum]

Hi Fannys!

On 12/16/23 04:06, Fannys wrote:
As I said in the @xsf room the problem with this XEP is that the author 
is convinced that this is the one answer to everything and assumes a 
*lot* of stuff to get there. And besides the title obviously that is 
obvious in a few other places.


To try to quickly summarize, we need a lot of info to connect to XMPP 
servers, and need to get it in very specific (secure) ways.  I've 
thought about this a lot over the years, and (very much thanks to your 
and other's feedback) tried to explain the reason for every decision.  I 
am absolutely not married to one solution, but alternatives need to 
accomplish the same goals.  "I don't like this" isn't helpful without an 
alternative proposal that can actually be considered.



Specifically:


- It calls SRV records as legacy which is a pretty big departure from 
the status quo.


 > For the foreseeable future you will need to maintain legacy SRV 
records in addition to this file


Yes, because this document explicitly deprecates SRV records (while 
saying they need to be supported for the forseeable future).


- It effectively makes HTTP a hard requirement for all clients and 
servers on the network raising complexity significantly.


HTTPS already is a hard requirement, with POSH, with HTTP Upload which 
is currently the only way to share files in MUCs and with multiple 
clients / offline clients, and, for most servers, the way they get 
certificates from letsencrypt.  HTTPS is also a well established, fully 
open protocol with many independent implementations exactly like XMPP, I 
see no reason to avoid it. XMPP relies on many other standards, just as 
good or bad (depending on your POV), like DNS, IP, TCP, TLS, XML etc etc.


- Recommends that everything runs through port 443 which is in itself 
questionable for this.


Because it's most likely to work through real-world firewalls in 
real-world networks, what's questionable about this?


- Also it introduces a hard requirement for a JSON parser in all clients 
and servers which is another point that raises complexity.


Again, a JSON parser is already a hard requirement due to POSH.  I 
addressed further reasons I thought this was the best choice in the 
Rationale 
https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-hm-json , 
but, this is not an absolute hill for me to die on.  If the consensus is 
that XML is better here, I'm not opposed, but then it should be the 
XMPP-subset of XML so that we can actually use the same parser, and 
don't introduce the real security risk of requiring an XML parser that 
can parse not-XMPP-XML (just one real world example of this 
vulnerability in the wild is 
https://prosody.im/security/advisory_20220113/ ).


Please note this would introduce the following (imho, downsides):
1. we could not use host-meta.xml as that requires a not-XMPP-subset-XML 
parser supporting comments etc etc
2. that means an extra https request when trying to fetch host-meta-2 
along with legacy methods
3. so it'd require a new document definition, for a quick reference, it 
would look very similar to HACX 
https://xmpp.org/extensions/inbox/hacx.html#example-1


And I think the discussion about these items individually should have 
happened before. Especially since from the discussion in @xsf it seems 
that some of the alternatives like DNS were rejected on subjective 
opinions of the author.


I actually discussed this in xsf@ 21 months (damn I'm slow...) 
before submitting this ProtoXEP 
https://logs.xmpp.org/xsf/2022-03-17#2022-03-17-ead56d61d395a6b9


I hopefully explained my rationale re: DNS well 
https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-dns but 
please if you disagree and/or have alternatives do share.


My opinion is that HTTP and JSON shouldn't be requirements and i don't 
plan to use this XEP anywhere even if it gets voted in. We already have 
problems with ports and everything assuming HTTP and I don't want the 
problem to be worse. Plus I don't want the complexity at all.


So to summarize my current thoughts:
* I think HTTPS is likely to be a hard requirement for this, at least I 
can't think of an alternative that can accomplish the same goals
* JSON is *not* a hard requirement, and could be replaced, but has the 
downsides I layed out above and in the rationale



Fannys


I very much appreciate the detailed feedback, thank you!

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

[Travis Burtrum]

Apologies for the delay on this, but I finally have an update:

On 12/15/23 23:00, Travis Burtrum wrote:
Lastly I was asked to contact to XEP-0156 authors to see how they'd feel 
about this updating '156 instead of being it's own XEP


I emailed stpeter directly and he responded promptly, thanks for that! 
He asked me to convey his message and he'd respond with a +1 so I'm 
doing so here:


On 2/7/24 21:05, Peter Saint-Andre wrote:
> On 2/7/24 6:56 PM, Peter Saint-Andre wrote:
>> Hi Travis!
>>
>> On 2/7/24 5:37 PM, Travis Burtrum wrote:
>>> The council is blocking this pending an answer from '156 authors
>>> (which I think, of the people still around, is only you) as to
>>> whether you think this fits best as a new XEP or whether you'd be ok
>>> with this being an update to and mostly replacing '156?
>>
>> I thought I had replied in xsf@ at one point, but it might have been
>> lost in the noise.
>>
>> I'm A-OK with hostmeta-2 but I think it should be in a new XEP that
>> obsoletes 156, not an overwrite of the existing 156.

So I have created a PR (https://github.com/xsf/xeps/pull/1323) with 
feedback and rationale, will respond shortly to the 2 responses to my 
previous message (again, thank you, and apologies for delay) and would 
like to ask council to re-consider this as a new XEP given the response 
from stpeter.

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Travis Burtrum]

On 1/11/24 10:37, Dave Cridland wrote:



On Thu, 11 Jan 2024 at 12:39, Holger Weiß > wrote:


* Simon Josefsson mailto:si...@josefsson.org>>
[2024-01-11 13:10]:
 >I believe tls-server-end-point is generally best left unimplemented to
 >guide efforts towards supporting the stronger tls-exporter.

One use case I see for tls-server-end-point is that it allows for
supporting channel binding by setups where TLS is terminated by some
reverse proxy, thereby protecting against _some_ but not all attack
vectors that tls-exporter protects against.


I'm pretty sure this was a key reason we picked the approach. If TLS is 
terminated before the server ever sees it, the server can still be 
configured to handle tls-server-end-point.


Also the TLS terminating proxy can pass the required secrets for "real 
channel binding" to the backend XMPP server via extensions to the PROXY 
protocol.  I plan on adding support for this to xmpp-proxy soon.


___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

[Travis Burtrum]

Hi all,

Quick summary of this ProtoXEP: It's intended to be the single new 
de-facto way all servers and clients look up connection info to connect 
to servers.


It was clear from the feedback that this ProtoXEP needed an extensive 
rationale section explaining why other alternatives aren't sufficient 
and why certain decisions were made, I have added this and rendered it here:


https://www.moparisthebest.com/xeps/host-meta-2.html#rationale

(source @ 
https://github.com/moparisthebest/xeps/tree/task/host-meta-2-rationale )


I'd appreciate any feedback, here or in xsf@ .

Lastly I was asked to contact to XEP-0156 authors to see how they'd feel 
about this updating '156 instead of being it's own XEP, so I've CC'd the 
authors who's emails appear to still be valid here, if you could please 
have a look and let us know I'd really appreciate that too. :)


Thanks much,
Travis
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: NEW: XEP-0481 (Content Types in Messages)

[Travis Burtrum]

Jun 6, 2023 4:31:54 PM Dave Cridland :

>
> On Thu, 4 May 2023 at 15:06,  wrote:
>> Version 0.1.0 of XEP-0481 (Content Types in Messages) has been
>> released.
>
> This is weirdly horrible.

Me too, but it's not council's job to police the protocol, what gets widely 
used is decided by running code and consensus.

> * First and foremost, it falls into a general trap that's open to abuse by 
> malicious actors, by having a message whose content will be interpreted 
> differently by different clients. This has been used by spammers and as a 
> malware vector for decades.

So... Same as xml:lang in the RFC ? I don't like that either. :)

___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

Re: [Standards] Channel binding and token authentication

[Travis Burtrum]

Sep 26, 2022 7:42:48 AM Kevin Smith :

> -- Original Message --
> From: "Matthew Wild" 
> To: "XMPP Standards" 
> Sent: 26/09/2022 18:24:37
> Subject: [Standards] Channel binding and token authentication
>
>> Does anyone have objections to proceeding with the definition of one
>> or more HT-*-NONE mechanisms for token authentication?
>
> Seems entirely sensible to me.

I agree. (Selfishly, as the author of a proxy that would break channel binding)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Events

[Travis Burtrum]

I don't think we should be accepting XEPs without "Security Considerations" 
being filled in. Any chance that could be done before voting starts?

Sep 23, 2022 5:52:36 AM Jonas Schäfer (XSF Editor) :

> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Events
> Abstract:
> This specification describe how to handle events with XMPP.
> 
> URL: https://xmpp.org/extensions/inbox/events.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Travis Burtrum]

Hi all,

I went ahead and removed the DNS method from XEP-0156 instead, and 
updated the security considerations and business rules to explain that 
TLS should always be used and what to send in SNI and what to look for 
in the certificates.


Please let me know if anyone has concerns with this.

Thanks much,
Travis

On 2/13/22 15:52, Sonny Piers wrote:
Thanks you Travis for taking the time to make individual reports for 
each implementations. I fixed it in xmpp.js 0.13.1 .


If that works for everybody - I'm happy to remove BOSH / and XEP-0156 
from XMPP Compliance Suites 2022.


If someone disagree please come up with a different solution than 
obsoleting XEP-0156 all together .
BOSH without an endpoint discovery mechanism doesn't make sense in a 
compliance suite.



On jeu., févr. 10 2022 at 19:48:47 -0700, Peter Saint-Andre 
 wrote:
Co-author of XEP-0156 here. Thanks for raising this issue. I would go 
even farther and note that DNS TXT records were never a great idea for 
this functionality (they're actively discouraged in the DNS community 
for application-level uses like this). On 2/9/22 4:29 PM, Travis 
Burtrum wrote:


Hi all, The long story short (is outside of DNSSEC) it's
impossible to use _xmppconnect TXT records to securely connect to
BOSH or WebSockets. Every client I've been able to find that
supported this is vulnerable to trivial MITM (Man-In-The-Middle)
via DNS spoofing.  If you have a client that uses it, switch to
grabbing host-meta via HTTPS per [RFC-7395] immediately, maybe
grab a CVE if you wish. 

Sonny commented on your PR that "RFC 7395 doesn't define bosh 
lookups"; this might be true but that raises the issue of whether we 
should still recommend BOSH, since it was a pre-websockets workaround 
for long polling.


I propose we litter [XEP-0156] with warnings explaining why it's
insecure and should never be done, and obsolete it, instead
referring people to the single host-meta method that [RFC-7395]
defines, which provides secure delegation when grabbed over HTTPS. 

In general, +1 to what you propose. Peter 
___ Standards mailing list 
Info: https://mail.jabber.org/mailman/listinfo/standards 
<https://mail.jabber.org/mailman/listinfo/standards> Unsubscribe: 
standards-unsubscr...@xmpp.org <mailto:standards-unsubscr...@xmpp.org> 
___ 


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Danish chains too short

[Travis Burtrum]

On 2/12/22 08:02, Dave Cridland wrote:
On Thu, 10 Feb 2022 at 04:46, Travis Burtrum We should instead specify in a best practice document for DANE+XMPP

that
only DANE-EE(3) should be supported/used.
Because?


Because as you've pointed out DANE-TA(2) has numerous downsides and 
pitfalls, especially when it comes to the public federated XMPP network, 
and there is just no reason for it.


1. as you and [RFC-7672] explained, DANE-TA(2) requires the *entire* 
chain including the root to be served, which a) uses more bandwidth and 
therefore slows down handshakes and b) most servers (rightly) do not do, 
some can't even be configured to do this


2. It's an inevitable bomb with a long fuse, as [LE] explains, the 
intermediate or root that get pinned in DANE-TA(2) will one day expire, 
breaking anyone with that record.  On the public federated XMPP network 
this would be catastrophic, as all deployments would break at exactly 
the same moment, we should be forbidding this in standards, not 
encouraging it.


3. [RFC-7672] RECOMMENDS "DANE-EE(3) SPKI(1) SHA2-256(1)"

4. It's unclear to me with mandatory CAA records if, for example, "only 
trust my connection if I have a valid cert signed by LetsEncrypt" is 
even valuable at all if your CAA record already ensures no other CA can 
issue a cert for your domain without losing their entire business


[RFC-7672]: https://datatracker.ietf.org/doc/html/rfc7672#section-3.1
[LE]: 
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Travis Burtrum]

PR implementing my proposal https://github.com/xsf/xeps/pull/1158
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Danish chains too short

[Travis Burtrum]

On 1/30/22 11:38, Dave Cridland wrote:
But the default choice to maximize interop should be to include the 
trust anchor.


1) Do people agree?


No. Because...

2) If so, where on earth should we specify this? (A Best Practice doc on 
PKIX/DANE?)


We should instead specify in a best practice document for DANE+XMPP that 
only DANE-EE(3) should be supported/used.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Travis Burtrum]

Issues I know about right now:

https://github.com/processone/docs.ejabberd.im/issues/113
https://github.com/JustOxlamon/TwoRatChat/issues/2
https://github.com/poVoq/converse_wp/issues/2
https://github.com/BombusMod/BombusMod/issues/130
https://github.com/hesa2020/Twitch-To-League-by-Hesa/issues/1
https://github.com/xmppjs/xmpp.js/issues/933
https://github.com/tigase/tigase-http-api/issues/8
https://github.com/tigase/tigase-extras/issues/3

https://dev.gajim.org/gajim/python-nbxmpp/-/issues/124

Tigase devs confirmed sure.im is vulnerable

libpurple and therefore pidgin, adium, chatty, thunderbird, others? 
support BOSH and are vulnerable


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0156 _xmppconnect is vulnerable to MITM

[Travis Burtrum]

Hi all,

The long story short (is outside of DNSSEC) it's impossible to use 
_xmppconnect TXT records to securely connect to BOSH or WebSockets. 
Every client I've been able to find that supported this is vulnerable to 
trivial MITM (Man-In-The-Middle) via DNS spoofing.  If you have a client 
that uses it, switch to grabbing host-meta via HTTPS per [RFC-7395] 
immediately, maybe grab a CVE if you wish.


I propose we litter [XEP-0156] with warnings explaining why it's 
insecure and should never be done, and obsolete it, instead referring 
people to the single host-meta method that [RFC-7395] defines, which 
provides secure delegation when grabbed over HTTPS.


The long reason it's vulnerable is say you want to connect to 
example.org, _xmppconnect tells you to connect to wss://evil.com/xmpp, 
when you pass this to your websocket library, 100% of them will validate 
that the TLS certificate belongs to evil.com (NOT example.org, this is 
the bug) and proceed.  Now you *could maybe* hack your library to 
validate example.org instead, but in practice this isn't going to work 
because no web servers exist that will let you host evil.com but supply 
a certificate valid for example.org, in fact, this was later dubbed 
"domain fronting" and banned by google/amazon ( 
https://en.wikipedia.org/wiki/Domain_fronting ).


People unfamiliar with XMPP have asked why this doesn't affect regular 
SRV lookups, so that's worth explaining here too. That is because when 
you look up records for example.org, even if evil.com is returned, you 
validate it returns a certificate valid for example.org, and if it 
doesn't, you terminate the connection (and hopefully move to the next 
SRV record).


I'll be creating issues for all the clients I've found shortly, and will 
follow up with a list.


Thanks,

Travis

[RFC-7395]: https://datatracker.ietf.org/doc/html/rfc7395#section-4

[XEP-0156]: https://xmpp.org/extensions/xep-0156.html

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XEP-0060 Changes

[Travis Burtrum]

Hi all,

A change to XEP-0060 has been proposed: 
https://github.com/xsf/xeps/pull/1126/files


2 out of 3 parts are editorial in nature, the one part that is a 
potential concern takes the current sentence:


> After receiving the configuration form, the owner SHOULD submit a 
completed configuration form.


And appends the following to it:

> The submitted configuration form MAY contain a subset of possible 
configuration options. In that case, the service MUST only change the 
submitted configuration options.


The concern here is that adding a MUST where one didn't exist previously 
could make existing compliant implementations suddenly non-compliant.  I 
believe it was said in MUC discussions that prosody follows this anyway, 
can anyone chime in about other implementations they know about ?


It was also proposed that this MUST could be changed to a SHOULD, which 
would get around the protocol-breaking, but I'm not sure it adds a lot 
of value, since, if you can't be sure what the service will do, then you 
can never submit just a subset of config options and hope for the best.


Any input is appreciated.

Thanks much,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS

[Travis Burtrum]

On 2/11/20 11:29 AM, Jonas Schäfer (XSF Editor) wrote:
> 1. What software has XEP-0368 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.

Conversations and Dino both implement this as well.

> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0368? If so, please describe the problems and, if
> possible, suggested solutions
> 3. Is the text of XEP-0368 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

It seems many implementations have problems (library constraints) or
choose not to (simplicity) support the mixing behavior.  Conversations
is the only implementation I know of off the top of my head that does
implement it, I wrote that implementation before this XEP existed,
originally had it as a MUST, ended up changing it to a SHOULD, and now
it seems likely it should be changed to a MAY.

In practice, it doesn't matter, the server administrator can't actually
count on anyone accessing any of the SRV records in any specific order
because any network could have any types of blocks/constraints on it.
Therefore pending further comments here I'll submit a PR to propose
changing:

> Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record
with regard to connection order as specified by RFC 2782 [3], in that
all priorities and weights are mixed. This enables the server operator
to decide if they would rather clients connect with STARTTLS or direct
TLS. However, clients MAY choose to prefer one type of connection over
the other.

to something like this instead:

> Both 'xmpp-' and 'xmpps-' records MAY be treated as the same record
with regard to connection order as specified by RFC 2782 [3], in that
all priorities and weights are mixed. Otherwise clients MAY choose to
prefer one type of connection over the other.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2019-07-10

[Travis Burtrum]

On 7/19/19 7:52 AM, Florian Schmaus wrote:
> On 19.07.19 07:36, Travis Burtrum wrote:
>>> If the initiating party cannot connect via either SRV record, it
>> SHOULD perform A/ fallback to port(s) of it's choice (perhaps 443,
>> 5223, etc) because, in the absence of DNSSEC, SRV records cannot be
trusted.
>
> If in the absence of DNSSEC SRV records cannot be trusted, which is of
> course true, why should you trust A/ resource records?

That is a fair question, there are a few reasons I can think of, poorly
configured networks either intentionally or not, tor dns supports A/
but not SRV, maybe others?

But more importantly you aren't implicitly trusting them, only if the
TLS cert is valid do you connect, so I don't see the harm in attempting
to connect anyway, where as giving up early can cause harm in the form
of a user not being able to connect.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2019-07-10

[Travis Burtrum]

Hi all,

On 7/17/19 9:57 AM, Tedd Sterr wrote:

> *3b) PR #796 - XEP-0368: clarify what happens when a `.` target is
> published* - https://github.com/xsf/xeps/pull/796
> Jonas: +1
> Link: +1 (definitely!)
> Georg: +1 (this is just a clarification of RFC 2782)
> Dave: [pending]
> Kev: [pending]

Sorry I missed the vote on this but I could not disagree more on half of
this change.

I will review the 2 halves separately here.

Part 1:

> If the _xmpps-client (or _xmpps-server) target is set to . (dot), this
indicates as per RFC 2782 that the service is not provided for the given
domain. In this context, this means that Direct TLS is not supported. In
this case, the initiating party SHOULD look up _xmpp-client (or
_xmpp-server) records.

Part 1 is, as Georg put it "just a clarification of RFC 2782", I have no
problem with this.

Part 2:

> The initiating party MUST NOT perform A/ fallback as per RFC 6120
(since the service provider has already indicated that the SRV protocol
is supported).

Part 2 adds new MUST NOT normative language to a Draft XEP that simply
didn't exist before. Also in my opinion this language is just wrong, and
if I were to make a change to the XEP here it would be the opposite,
something like:

> If the initiating party cannot connect via either SRV record, it
SHOULD perform A/ fallback to port(s) of it's choice (perhaps 443,
5223, etc) because, in the absence of DNSSEC, SRV records cannot be trusted.

I went ahead and made a pull request with this text here:

https://github.com/xsf/xeps/pull/801

I also think just adding Part 1 and nothing else would be equally fine,
allowing client/server developers decide on their own if or how to
fallback, in practice they will anyway regardless.

Thanks much,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?

[Travis Burtrum]

On June 30, 2019 12:32:07 PM EDT, Ralph Meijer  wrote:
>Do you know which server implementations currently support both TLS and
>non-TLS (with STARTLS) on the same port?

If you put sslh in front of them, all servers do.  Try burtrum.org:443 for 
instance.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[Travis Burtrum]

On 3/13/19 12:55 PM, Ralph Meijer wrote:


On 13/03/2019 15.09, Travis Burtrum wrote:

On 3/13/19 3:40 AM, Philipp Hörist wrote:

Whats the use case for this XEP?
Until now i only needed DNS querys to connect to the XMPP Server, i 
see this XEP is not helping with that as it already needs an active 
connection to the XMPP Server.


Like DoH, where you hard-code an IP, port, path, and whether to query 
via POST or GET to bootstrap your first DNS queries, the same can be 
done here by hard-coding a IP, port, JID, password, and resolver JID.


The syntax I use for this in jDnsProxy is this:

xmpp://208.68.163.210:5222#user=any...@example.org/resolver;pass=y0urPa55W0rDHere;resolverJid=d...@moparisthebest.com/listener 



I haven't looked in-depth towards your proposal, but this is not
probably not a valid XMPP URI, or at least not how you think it is.
Oh it's certainly not a valid XMPP URI, just syntax I invented for my 
configuration format.  I mainly meant to convey to use DoX to bootstrap 
DNS you'd need to hardcode:


1. a JID + password to log in with
2. server IP + port to log in to
3. resolver JID to send DNS queries to

Not very different from the things that are hard-coded to use DoH:

1. server IP + port
2. path
3. POST vs GET
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[Travis Burtrum]

On 3/12/19 4:08 PM, Jonas Schäfer (XSF Editor) wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: DNS Queries over XMPP (DoX)

Thanks Jonas!

If anyone wants to poke at a JID running this feel free to send queries
to d...@moparisthebest.com/listener which is running code from here:

https://github.com/moparisthebest/jDnsProxy/tree/dox

If you are feeling extra XMPP-y set it up on your router and run all
your DNS queries over XMPP. (or run a resolver yourself)

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Agenda 2018-05-16

[Travis Burtrum]

Hi all,

On 05/15/2018 11:17 AM, Dave Cridland wrote:
> 3) Adopt Proposed new XEP: XMPP Connections across HTTPS (HACX)

FYI I have updated this here to address some early feedback:

https://github.com/xsf/xeps/pull/633
https://burtrum.org/hacx/

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Agenda 2018-05-09

[Travis Burtrum]

Hello,

On 05/09/2018 06:58 AM, Dave Cridland wrote:
> 3) Adopt Proposed new XEP: XMPP Connections across HTTPS (HACX)
> 
> Title: XMPP Connections across HTTPS (HACX)
> Abstract:
> This specification defines a procedure to look up various connection
> methods for an XMPP server over HTTPS, with a focus on censorship
> resistance.
> 
> URL: https://xmpp.org/extensions/inbox/hacx.html

So from the last email on that chain from MattJ I discovered that not
only HACX but also XEP-0368 is formatted incorrectly and has
mis-interpreted the Requirements section.  I plan to address this (at
least for HACX) and list out all of the alternatives considered and why
they were not sufficient, but haven't got to yet.

All that to say, I'm fine if you put off considering it until next week
when those issues are fixed.

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: XMPP Connections across HTTPS (HACX)

[Travis Burtrum]

On 05/03/2018 11:06 AM, Sam Whited wrote:
> On Thu, May 3, 2018, at 07:26, Jonas Wielicki wrote:
>> URL: https://xmpp.org/extensions/inbox/hacx.html
> 
> This appears to have significant overlap with the HTTP mechanism from 
> XEP-0156: Discovering Alternative XMPP Connection Methods, but I don't see 
> any mention of it. A brief discussion about what it provides on top of that 
> or why it's necessary to have another discovery mechanism might be useful.

I do mention it in Security Considerations, but in a different context:

https://xmpp.org/extensions/inbox/hacx.html#security

I agree it should mention what you said, briefly the reason is that can
only provide websocket/bosh, is not extendable as I read it (uses that
oasis namespace) and so cannot support priority/weight/sni/alpn.
Additionally, the business rules are in direct conflict with what HACX
is trying to do.

As a point of XEP authoring procedure, where would something like that
fit? Use Cases?

Thanks much,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

[Travis Burtrum]

Hi Jonas,

On 04/30/2018 07:20 AM, Jonas Wielicki wrote:
> What do you think about the independent extension to the text I proposed in  
> https://github.com/xsf/xeps/pull/625 ?

These two requirements:

  - Services SHOULD allow operators to delete all files of a specific user.
  - Services SHOULD delete all files uploaded by a user when the account
is deleted.

Require a server to track who uploaded what, which many implementations
don't do, and which I wouldn't want server to do.

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

[Travis Burtrum]

On 04/27/2018 02:39 AM, Jonas Wielicki wrote:
> On Freitag, 27. April 2018 04:59:25 CEST Travis Burtrum wrote:
>> Many implementations don't even track who uploaded what, isn't that
>> better?  No records, no problems?
> 
> No. It’s not about the association, it’s about the users data (the uploaded 
> files) which must be deletable. At least that’s my understanding of the 
> situation.

Proposed terms of service wording:

When you upload data, it's our data now, not yours.

Does that solve the problem?

If there must be a way to delete, I'd propose servers return a random
'deletion key' that clients can use at some future time, instead of
being forced to record what data belongs to what users.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

[Travis Burtrum]

On 04/26/2018 10:35 AM, Jonas Wielicki wrote:
> As it turns out, several implementations are making it not trivial for 
> operators to be GDPR compliant. One of the things definitely necessary (as 
> far 
> as our understanding goes) is that users must be able to have their data 
> deleted in a reasonable timeframe; it must also be possible to create a 
> bundle 
> of all data the service currently has from the user.


Many implementations don't even track who uploaded what, isn't that
better?  No records, no problems?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proper SRV Record Fallback

[Travis Burtrum]

Hi Jonas,

Thanks for resurrecting the thread.  And nice work with aioxmpp!

On 03/19/2018 03:24 PM, Jonas Wielicki wrote:
> - authentication failures are treated as fatal and abort everything 
> immediately.

You mean username/password errors?  Not TLS certificate authentication
errors, just to be perfectly clear.

But this is basically the same fallback behavior Conversations has
implemented since adding 368 in January 2016.

Would it be appropriate to put something like this in 368 as normative
language, ie, 'we expect clients/servers implementing 368 to fallback to
other SRV records like so...'?  Or should it be an informational XEP?
Some random place in the wiki or?  I'd vote in 368 because it affects
the way server administrators can set up records.

Also need to slightly adapt them for S2S.

Any thoughts?

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

[Travis Burtrum]

At which point it's no longer P2P and you might as well use https, which also 
works with multiple clients unlike P2P/turn.

On February 24, 2018 12:07:51 PM EST, Evgeny Khramtsov <xramt...@gmail.com> 
wrote:
>Sat, 24 Feb 2018 11:24:39 -0500
>Travis Burtrum <tra...@burtrum.org> wrote:
>
>> Unfortunately you also can't reasonably expect P2P to work today in
>> most cases because everyone is behind a NAT including most mobile
>> phone networks. So https is still your best bet, and since most
>> servers support http upload it's already done for you.
>
>This problem is solved already by TURN servers.
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

[Travis Burtrum]

Unfortunately you also can't reasonably expect P2P to work today in most cases 
because everyone is behind a NAT including most mobile phone networks. So https 
is still your best bet, and since most servers support http upload it's already 
done for you.

On February 24, 2018 3:12:30 AM EST, Goffi  wrote:
>Hello,
>
>currently thumbnails are transmitted using http(s) or BoB (XEP-0231).
>But 
>with resolutions we can have todays even on small screens, size of
>images 
>is growing. Transmitting them using BoB can block the connection and is
>a 
>useless waste of bandwidth. I'm thinking about P2P transmission, so
>http is 
>not an option here. As XEP-0234 is able to transmit several files in
>the 
>same session, it would be a good candidate for that.
>
>Doesn anybody see an issue with using XEP-0234 for that? If no I'll
>propose 
>the change on the XEP.
>
>Goffi
>
>
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proper SRV Record Fallback

[Travis Burtrum]

Hello,

My replies in-line as well.

On 01/10/2018 03:20 AM, Jonas Wielicki wrote:
> Hi Travis,
> 
> Notes inline.
> 
> On Montag, 8. Januar 2018 23:19:36 CET Travis Burtrum wrote:
>> First, what do docs say:
>>
>> RFC-6120[2] Section-3.2.1 #7 says:
>>> 7. If the initiating entity fails to connect using all resolved IP
>>>
>>>   addresses for a given FDQN, then it repeats the process of
>>>   resolution and connection for the next FQDN returned by the SRV
>>>   lookup based on the priority and weight as defined in [DNS-SRV].
>>
>> 'fails to connect' does this mean the TCP connection fails, or the XMPP
>> connection fails?
>>
>> #8 might leave a hint:
>>> 8. If the initiating entity receives a response to its SRV query but
>>>
>>>   it is not able to establish an XMPP connection using the data
>>>   received in the response, it SHOULD NOT attempt the fallback
>>>   process described in the next section (this helps to prevent a
>>>   state mismatch between inbound and outbound connections).
>>
>> This clearly says XMPP connection, but does it apply to #7 ?
>>
>> It is also clear I didn't think about this too hard when writing
>> XEP-0368, because I clearly (to me) assume SRV fallback 
> 
> The text you quote is *not* about SRV fallback. It refers to the fallback to 
> A/ records in the next section (3.2.2). (which, holy cow, we should 
> really 
> not ever ever do if we got SRV records.)
> 
> The only wording in the RFC for SRV iteration is #7 you quoted. So it is all 
> about the definition of "fails to connect". The elders may have information 
> on 
> what was originally meant by that and if there is some more wisdom on the 
> reasoning for this.

Yes I fully agree RFC-wise this all hinges on what 'fails to connect'
means, I quoted 8 because it was the only one that didn't use those
exact words and said 'XMPP connection' instead.  Whether that means
anything or not is up for interpretation.  I'd also vote since it's at
best ambiguous we just decide what the 'right' thing is anyway.

>> will happen if a
>> complete XMPP connection is not successful, because under Implementation
>> Notes I say:
>>> Server operators should not expect multiplexing (via ALPN) to work in
>>> all scenarios and therefore should provide additional SRV record(s)
>>> that do not require multiplexing (either standard STARTTLS or
>>> dedicated direct XMPP-over-TLS). This is a result of relying on ALPN
>>> for multiplexing, where ALPN might not be supported by all devices or
>>> may be disabled by a user due to privacy reasons.
>>
>> While I don't explicitly say it, if a port required ALPN to multiplex,
>> it will generally end up connecting you to a non-XMPP server without
>> ALPN, meaning you will get back invalid XML, other junk, and/or an
>> invalid TLS cert.
> 
> This definitely could use wording in '368.

Absolutely agree, however I'd like to wait to update it so I can also
note what we decide here, I think.

> While I’m at it, I am really uncomfortable with further supporting the "put 
> everything behind SSL on 443" and move the Deep-Packet-Inspection-war behind 
> the TLS, driving us to a world where we’ll everything on port 443, with ALPN-
> based multiplexing. But that’s kinda OT. (but this is why I’m hesitant with 
> making ALPN a MUST.)

Yea this has been addressed a few times over the course of this XEP and
while I agree with the sentiment, I'd prefer to connect by any means
possible than to stay unconnected knowing it's more 'pure' that way or
something. :) (though by all means, when you find evil networks, try to
get them to change)

>> Now that the docs are out of the way, on to the discussion:
>>
>> In my opinion, at least all of cannot-connect-to-port, non-XML,
>> not-proper-stream and invalid TLS cert should trigger a fallback to the
>> next highest priority SRV record.
> 
> Is there a guarantee or requirement that servers in two different SRV 
> priorities can be used at the same time? If not, it seems a bad I idea to 
> fall 
> back on them for purely application-layer reasons.

I believe so?  At least my understanding of SRV is that clients can end
up connecting to any at any time.

>> Everyone in the MUC seemed to agree
>> if authentication fails a fallback would be a bad idea.
>>
>> Sam Whited said that if a TCP connection is established fallback should
>> cease, that it shouldn't have anything to do with or any knowledge of
>> XMPP, and that it might have security implementations to do otherwise.
>> (please correct and forgi

Re: [Standards] Proper SRV Record Fallback

[Travis Burtrum]

On 01/10/2018 07:59 AM, Holger Weiß wrote:
> * Travis Burtrum <tra...@burtrum.org> [2018-01-09 21:28]:
>> Is there any reason why any client would rather fail and show a 'cannot
>> connect' to a user rather than actually allowing them to connect?
> 
> The standards@-relevant question would be whether there's a reason to
> mandate a certain behavior, i.e. whether there's an interop issue, like
> with the ALPN scenario.
> 
> Holger

Yes, I think there is, because it changes the way a server admin will
need to set up SRV records for the normal case.  And we probably want
connectivity everywhere we can get it securely.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proper SRV Record Fallback

[Travis Burtrum]

On 01/10/2018 01:34 AM, Evgeny Khramtsov wrote:
> Rephrasing, the question about what to consider a success connection.
> We have several phases of stream negotiation (not to mention mam or
> roster queries).

Ah right.  Well I think maybe the username+password step might be a good
cut-off for c2s, for s2s I'm not sure what the right answer is exactly,
possibly just after TLS authentication succeeds and a valid  is
started?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proper SRV Record Fallback

[Travis Burtrum]

On January 10, 2018 12:55:06 AM EST, Evgeny Khramtsov <xramt...@gmail.com> 
wrote:
>Tue, 9 Jan 2018 21:28:55 -0500
>Travis Burtrum <tra...@burtrum.org> wrote:
>
>> Is there any reason why any client would rather fail and show a
>> 'cannot connect' to a user rather than actually allowing them to
>> connect?  I can't actually think of one.
>
>You continue ignoring the question about all possible such scenarios.

Which question have I not addressed?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proper SRV Record Fallback

[Travis Burtrum]

On 01/09/2018 03:58 PM, Marcel Waldvogel wrote:
> Is there a mechanism a client can determine whether ALPN is needed for a
> particular SRV entry? (Besides guessing based on the port number)

No.  In fact it wouldn't even fit on a SRV record level.

For instance I have 1 SRV record pointing to xmpp.burtrum.org:443. If
you connect to that over IPv4, ALPN is required or you will end up
talking to nginx.  If you connect to it over IPv6 ALPN is not required.

I have 1 IPv4 IP and many millions of IPv6 IPs, I suspect many setups
are identical.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proper SRV Record Fallback

[Travis Burtrum]

On 01/09/2018 05:55 AM, Florian Schmaus wrote:
> On 09.01.2018 05:19, Travis Burtrum wrote:
>> It is also clear I didn't think about this too hard when writing
>> XEP-0368, because I clearly (to me) assume SRV fallback will happen if a
>> complete XMPP connection is not successful, because under Implementation
>> Notes I say:
>>
>>> Server operators should not expect multiplexing (via ALPN) to work in
>>> all scenarios and therefore should provide additional SRV record(s)
>>> that do not require multiplexing (either standard STARTTLS or
>>> dedicated direct XMPP-over-TLS). This is a result of relying on ALPN
>>> for multiplexing, where ALPN might not be supported by all devices or
>>> may be disabled by a user due to privacy reasons.
>>
>> While I don't explicitly say it, if a port required ALPN to multiplex,
>> it will generally end up connecting you to a non-XMPP server without
>> ALPN, meaning you will get back invalid XML, other junk, and/or an
>> invalid TLS cert.
> 
> If I understood correctly, then a basic example where a xep368 fallback
> after a TCP connection was established would be beneficial is, if there
> is a high priority SRV RR pointing to a ALPN required destination. And
> another SRV RR with a lower priority pointing to a non-ALPN destination.
> 
> A client supporting xep368 but not ALPN would, without fallback,
> immediately fail, neglecting the valid fallback position. You mention
> multiple ways in how the non-ALPN client connection to a ALPN-required
> destination could fail, (which appears to contribute to the confusion):
> - Invalid Cert
> - Invalid XML (how could that happen BTW?)
> - (are there more?)
> 
> I see the following options:
> 
> 1. xep368 provides an implementation hint that such a fallback would be
> a good idea.
> 2. xep368 makes ALPN mandatory
> 3. do nothing

I think a fallback is a good idea even without xep368, just with regular
SRV lookup even.

Made up scenario time!

1. The LetsEncrypt renewal bot on your primary server screws up and you
don't notice, your secondary (and third/fourth etc) have valid
certificates though.  Would you like to connect or fail after first attempt?
2. The country of Elbonia publishes bad BGP routes routing traffic to
your primary server through them, also they intercept all https traffic,
so despite having other servers, you can't connect because fallback has
ceased on invalid certificate. This has happened many times [1].
3. Your local coffee shop wants to put ads in your browser, the owners
nephew Timmy has heard of sslstrip and thinks it's cool and turns it on,
you cannot connect to XMPP. (even though a fallback to a non-443 port
would allow you)
4. Your only choice for ISP, Comcast, injects ads in your web browser
and mistakenly sees XML from 5222 and thinks it needs more javascript.
Not a made up scenario [2]. They are so proud of it they wrote RFC6108 [3].

Is there any reason why any client would rather fail and show a 'cannot
connect' to a user rather than actually allowing them to connect?  I
can't actually think of one.

As to making ALPN mandatory, it actually solves none of the above
scenarios, and reveals the underlying stream is XMPP which someone might
not want.

[1]: https://en.wikipedia.org/wiki/BGP_hijacking#Public_incidents
[2]:
https://forums.xfinity.com/t5/Customer-Service/Are-you-aware-Comcast-is-injecting-400-lines-of-JavaScript/td-p/3009551
[3]: https://tools.ietf.org/html/rfc6108
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proper SRV Record Fallback

[Travis Burtrum]

On 01/09/2018 05:03 AM, Dave Cridland wrote:
> On 9 January 2018 at 04:19, Travis Burtrum <tra...@burtrum.org> wrote:
>> In my opinion, at least all of cannot-connect-to-port, non-XML,
>> not-proper-stream and invalid TLS cert should trigger a fallback to the
>> next highest priority SRV record.  Everyone in the MUC seemed to agree
>> if authentication fails a fallback would be a bad idea.
> 
> What's the distinction between invalid TLS certificates and
> authentication failure?

Ah, so the proposed c2s vs s2s distinction makes more sense.  I was
thinking authentication as in c2s username/password authentication.  I'm
not sure at what step s2s fallback should cease, I guess it should cease
after you get a  ?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proper SRV Record Fallback

[Travis Burtrum]

Hi all,

I have not been able to find proper SRV record fallback behavior
documented, and could not come to a clear consensus in the XSF MUC
earlier, so I thought I'd bring the discussion on-list. (and hopefully
document it in implementation notes of XEP-0368[1])

The main question is when you should fall back to lower priority SRV
records and when should you give up and fail the connection.

First, what do docs say:

RFC-6120[2] Section-3.2.1 #7 says:

> 7. If the initiating entity fails to connect using all resolved IP
>   addresses for a given FDQN, then it repeats the process of
>   resolution and connection for the next FQDN returned by the SRV
>   lookup based on the priority and weight as defined in [DNS-SRV].

'fails to connect' does this mean the TCP connection fails, or the XMPP
connection fails?

#8 might leave a hint:

> 8. If the initiating entity receives a response to its SRV query but
>   it is not able to establish an XMPP connection using the data
>   received in the response, it SHOULD NOT attempt the fallback
>   process described in the next section (this helps to prevent a
>   state mismatch between inbound and outbound connections).

This clearly says XMPP connection, but does it apply to #7 ?

It is also clear I didn't think about this too hard when writing
XEP-0368, because I clearly (to me) assume SRV fallback will happen if a
complete XMPP connection is not successful, because under Implementation
Notes I say:

> Server operators should not expect multiplexing (via ALPN) to work in
> all scenarios and therefore should provide additional SRV record(s)
> that do not require multiplexing (either standard STARTTLS or
> dedicated direct XMPP-over-TLS). This is a result of relying on ALPN
> for multiplexing, where ALPN might not be supported by all devices or
> may be disabled by a user due to privacy reasons.

While I don't explicitly say it, if a port required ALPN to multiplex,
it will generally end up connecting you to a non-XMPP server without
ALPN, meaning you will get back invalid XML, other junk, and/or an
invalid TLS cert.

RFC-2782[3], defining SRV records, makes no mention of this.  Which
actually makes sense because it doesn't even define possible protocols,
UDP for example has no connection concept.

Now that the docs are out of the way, on to the discussion:

In my opinion, at least all of cannot-connect-to-port, non-XML,
not-proper-stream and invalid TLS cert should trigger a fallback to the
next highest priority SRV record.  Everyone in the MUC seemed to agree
if authentication fails a fallback would be a bad idea.

Sam Whited said that if a TCP connection is established fallback should
cease, that it shouldn't have anything to do with or any knowledge of
XMPP, and that it might have security implementations to do otherwise.
(please correct and forgive me if I misunderstood)  I disagree with
this, I think if Eve has control over DNS (and no DNSSEC) she can return
arbitrary records anyway so SRV fallback doesn't matter.  If Eve
controls a higher priority server, or the network between client and
that server, she can trigger fallback or not regardless of what we
decide.  The difference is if we decide not to fallback, then she can
effectively DOS us by messing with 1 server instead of all.

I think my proposal is even more generic than the above, I think
authentication-response should be the point when fallback ceases.
Regardless of what happens before that point, you fall back to the next
SRV record, and after authentication, whether it's successful or not,
you no longer fall back anymore.

As to what actual clients do in the wild, Conversations falls back
regardless of junk or invalid cert, dino does not.  I am unsure what
gajim does (though from talking to lovetox 1.0-beta might also not
fallback in all cases).

Depending what we decide, I plan to set up various domain/SRV record
combinations for testing, probably clients and servers both need this
type of testing, and I doubt it is done often.

Thanks,
Travis

[1]: https://xmpp.org/extensions/xep-0368.html
[2]: https://tools.ietf.org/html/rfc6120#section-3.2.1
[3]: https://tools.ietf.org/html/rfc2782
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Travis Burtrum]

On 09/22/2017 08:39 AM, Dave Cridland wrote:
> a) I query whether ALPN needs to be SHOULD rather than MAY,
> particularly for S2S cases.

That very well could be.  I'll give you the background, and the exact
wording can be discussed.

ALPN is only required for easy multiplexing multiple services on a
single TLS port.  On the server, it has the upside of being simple, a
standard, and easy to do.  On the client, it has the downside of
announcing to the network that you will be talking xmpp in this TLS
stream. (same as STARTTLS today)

So once firewalls start looking at and blocking connections based on
ALPN, clients need the option to try again without ALPN (or even to try
first without ALPN).

So MAY might be a better fit?  I just don't want to make it MUST.

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Travis Burtrum]

On 09/19/2017 12:04 PM, Jonas Wielicki wrote:
> Dear list,
> 
> With my XEP Editor hat on, we’d like to issue a Call for Experience for 
> XEP-0368. This is the step taken before proposing advancement of a XEP to 
> Final status to Council.
> 
> 
> During the Call for Experience, please answer the following questions:
> 
> 1. What software has XEP-0368 implemented? Please note that the protocol
> must be implemented in at least two separate codebases (at least one of 
> which must be free or open-source software) in order to advance from 
> Draft to Final.

Conversations has had support since before this became a XEP actually.

Everyone I know of has implemented the server-side of the c2s connection
either with a dedicated xmpp-over-TLS port, or using sslh to multiplex
on ALPN.  Debian even has an (unfortunately-named) section of their wiki
on installing prosody about it [1].

I also count 21 public servers on this test chart that have support [2].

> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0368? If so, please describe the problems and, if possible,
> suggested solutions.

ALPN support is still spotty, but getting better quick due to HTTP2
requiring it.

> 3. Is the text of XEP-0368 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

I thought so, but maybe providing some additional clarification re:
STARTTLS might be appropriate.

Thanks,
Travis

[1]: https://wiki.debian.org/InstallingProsody#XMPP_over_HTTPS
[2]: https://gultsch.de/compliance.html
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO (XEP-0384) Crypto Questions/Remarks

[Travis Burtrum]

On 03/30/2017 08:47 AM, Andreas Straub wrote:
> GCM also isn't
> quite as easily available on some platforms as we'd like, whereas CBC
> and HMAC are pretty much ubiquitous.

The HTTP/2 spec mandates support of
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [1] and I'd guess HTTP/2 is
already supported everywhere that any OMEMO client would live.

I'd rather see it use an AEAD algorithm than hold back due to outdated
reasons.

[1]: https://tools.ietf.org/html/rfc7540#section-9.2.2
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating Privacy Lists (again)

[Travis Burtrum]

Hi all,

On 03/22/2017 04:08 PM, Ruslan N. Marchenko wrote:
> List allows you creating overriding allow entry which will unblock
> single person while keeping the group blocked (order matters).

So does keeping the UI option to block a whole group, and then just
using the blocking command to individually block them all.  Then Sam's
hairy situation of wanting to talk to a single user becomes easy, you
just unblock that user.  Also this *just works* across all clients.

I've yet to see an upside of privacy lists.

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

On 02/15/2017 05:54 AM, Kim Alvefur wrote:
> As for security, I'm concerned that the added complexity of mixing
> STARTTLS and Direct TLS will lead to security problems. Doing it one way
> or the other has, as have been noted before, mostly equivalent security
> properties, but doing both seems to me like it gives us the most
> complexity. Making security related code more complicated for what
> amounts to an optimization does not strike me as the best idea.

Yes this is a fair point that I tried to address, and is why I specified:

"All security setup and certificate validation code SHOULD be shared
between the STARTTLS and direct TLS logic as well."

Because that's the most secure way to implement it, and how it is
implemented in Conversations.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

On 02/15/2017 02:48 AM, Ruslan N. Marchenko wrote:
> Ideally I'd like loadbalancer to offload both tls and stream
> negotiation, to filter out stream-flood (similar to syn-flood) - eg.
> pass/relay connection to the pool only once initial handshake is
> complete (stream/to + tls/SAN). That allows me to have farm behind
> focusing only on processing streams for my domains. (I'll probably even
> implement it for clustering perf/ha solution).

Isn't that exactly what direct TLS gives you?  You have the to (via
SNI), and you also know whether it's s2s or c2s traffic.  Oh also you
have actual tools written to use now that are proven to scale in
real-world use to far more connections than any XMPP server has, instead
of simple dreams of how you imagine a tool to be.

Point is STARTTLS is a relic from a darker time when SNI, SRV, and ALPN
were not a thing, it's simply not required any more.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

On 02/14/2017 02:00 PM, Ruslan N. Marchenko wrote:
> It has nothing to do with port reuse, rather service binding. When I'm
> thinking how many ports I need to open on firewall to allow simple mail
> exchange - it just makes me feel sad an sorry for all the people who
> developed those standards.

Really?  How many ports do you have to open?  I have port 25 for SMTP
delivery because that's a must, but then I simply have sslh listen on
port 443 and it sends http traffic to nginx based on sni or alpn and by
default, xmpp traffic to prosody based on alpn, imap traffic to dovecot
based on sni, smtp submission to postfix based on sni, vpn to ocserv
based on sni, irc to znc based on sni, and probably a few I don't
remember that right now.

So that's 2 ports, 99% of them TLS over 443 multiplexed with ALPN or SNI.

> Also one security drawback here - now to DoS by encryption abuse vector
> you need to negotiate stream before doing starttls - meaning you need to
> have handcrafted tool just for this protocol. With TLS on socket you can
> use anything which is able to open secure socket (probably related to
> the quote above?).

I'm pretty sure nginx and haproxy handle TLS and any type of TLS DoS far
better than any current XMPP server, sorry, that's just a much larger
segment of the web.

Don't get me wrong, I'd love it if all ports were open all the time and
such, but that's not the world we live in, and I can do nothing to
change 99% of it.  The fact is TLS over 443 is most likely to get
through, and I don't see any downsides to sending XMPP over it.  In fact
you already can now with BOSH or Websockets, but this is more
lightweight for non-web clients.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

On 02/13/2017 04:43 PM, Ruslan N. Marchenko wrote:
> Yes, and that's what written as XEP's use-case - how to abuse corporate
> firewall by masking im/p2p software to legitimate business traffic (https).
> This is not fair, and if I were CSO who found out such "use-case" in the
> network I'd just ordered to block pass-through TLS pushing people to use
> either explicit or implicit (transparent) proxy.

I wouldn't say it's purpose is to abuse corporate firewalls, maybe it
has a side-effect of doing that, but as you say if they (controlling all
devices) actually want to have control over what goes on inside a TLS
stream, they can by installing a CA and mitm'ing all traffic.

It's basically got 3 maybe 4 use cases, share ports with other TLS
services, enable connectivity from places with dumb firewall policies
(airports, coffee shops etc), save roundtrips.  And this is the maybe,
most TLS libs I've seen it's easier to establish a direct TLS connection
than xmpp's custom STARTTLS.

> With all due respect and honesty I thought times when there was separate
> port for encrypted/non-encrypted traffic are passed by replaced by
> start-tls concept.
>  starttls feature is quite transparent and flexible, if
> someone strips it - server just refuses progressing the handshake.
> I don't understand what do we need to hide here by summoning port 5223
> from the oblivion.

STARTTLS was a good idea when it was still acceptable to have both
unencrypted and encrypted connections, because port sharing is good? :)
It's no longer acceptable to have unencrypted connections which makes
STARTTLS quite useless, and TLS and ALPN allow us to not only port share
with other XMPP ports, but with any TLS port, port sharing is good right?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

On 02/13/2017 02:26 PM, Ruslan N. Marchenko wrote:
> So security here will be just in the sense "all or nothing" -
> either you pass through (non-paranoid) or not (paranoid).

That's not true though, there are firewalls in practice today that only
allow HTTP on port 80, and only TLS on port 443, but do not MITM TLS.

If TLS is MITM'd with a custom CA installed on your device then TLS
doesn't protect you from the MITM of course, and this won't address that.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

Boy am I glad you missed the last call deadline by a day so I don't have
to address your concerns. :)

On 02/12/2017 11:03 AM, Sam Whited wrote:
> A minor nitpick: The requirements section isn't really requirements,
> it's the actual main content of the spec.

Someone mentioned that before but didn't respond when I asked where they
should be, such as how it should be re-arranged.

> In the introduction and security concerns there are claims that this
> spec provides "perhaps increased security and privacy over using
> STARTTLS". These claims use both passive language ("perhaps"), and I
> don't think are actually true (it's only slightly less trivial to
> detect that not-HTTPS is most likely being transmitted, and lots of
> corporate firewalls do this). Since these are weak statements to begin
> with, I'd like to see them taken out in case they mislead users. I
> don't think it provides any value to the specification to include
> claims like this anyways, true or false.
> 
> It would be nice if these statements could be removed before the
> council votes; apologies for being late to the party in bringing this
> up again.

It's worded in a passive way because it depends on the choices you make
with regard to the spec.  If you send ALPN, well then that's not any
additional privacy over STARTTLS, you are still announcing to the middle
boxes you intend to talk XMPP over this TLS connection.  As discussed
before, if you enforce STARTTLS regardless of stripping, well then
direct TLS that has no plain fallback doesn't give you extra security.

Also it was previously noted in the absence of DNSSEC only allowing
xmpp-* records through instead of xmpps-* had a similar effect to
STARTTLS stripping, which is true, but also SRV records have a TTL that
a client could keep across different networks, so that could also remove
this possibility for a man in the middle with control over DNS right?
Again up to the server administrator how high they want to set their TTLs.

Lastly I could not disagree more with "it's only slightly less trivial
to detect that not-HTTPS is most likely being transmitted, and lots of
corporate firewalls do this", unless you mean detecting with ALPN, I
think analyzing traffic patterns of the stream underlying TLS to pick
apart XMPP vs HTTP vs anything else would be insanely difficult, surely
it'd make most HTTP sites fail too.  I doubt any corporations implement
anything like this currently, or honestly ever could.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

On 01/30/2017 12:43 AM, Daurnimator wrote:
>> 5. Is the specification accurate and clearly written?
> 
> No.
> 
> The stuff in 'requirements' are not requirements but implementation 
> instructions
> 
>> When ALPN is used protocol MUST be 'xmpp-client' where 'xmpps-client' is the 
>> SRV 'service'.
>> When ALPN is used protocol MUST be 'xmpp-server' where 'xmpps-server' is the 
>> SRV 'service'.

I guess those are both requirements and implementation instructions,
suggestions for different wording are welcome, but it seems clear to me.

> The phrase "is the SRV 'service'" seems confusing to me.

That's exactly the language the SRV rfc uses:

https://tools.ietf.org/html/rfc2782

   Here is the format of the SRV RR, whose DNS type code is 33:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target"

It goes onto explain what a Service is, so I believe I used the correct
terminology there.

> 
>> TLS provides AT LEAST the same level of security as STARTTLS, and more 
>> privacy without ALPN as using STARTTLS leaks that the underlying protocol is 
>> XMPP, while any TLS stream should be indistinguishable from any other TLS 
>> stream. TLS provides more security than STARTTLS if RFC 7590 [4]
> 
> This sentence is confusing and potentially misleading.

Yes we've discussed this sentence at length before, with people arguing
that is or is not completely correct.  I'm not sure how to concisely
word it (please, suggest!) but the points I was trying to make are:

1. 'Direct' TLS and STARTTLS after it's started are both identical, so
same level of security.
2. If ALPN is not used, STARTTLS leaks that the underlying protocol is
XMPP and 'Direct' TLS does not, it should look the same as HTTPS or
anything else.  If ALPN is used the fact that XMPP is going on under
this TLS stream is 'leaked' with 'Direct' TLS as well.
3. If RFC 7590 is not followed (summary: Send STARTTLS even if you don't
get an offer to combat STARTTLS stripping), then 'Direct' TLS is more
secure since it is not susceptible to STARTTLS stripping.

Maybe what should also be mentioned is:

4. Both 'Direct' TLS and STARTTLS are vulnerable to DNS tampering absent
DNSSEC.

> I think it should be noted how devices are expected to connect.
> e.g. should they do a SRV request for xmpps-client, and if that
> doesn't exist: try xmpp-client; and if that doesn't exist: use an 
> record. if that doesn't exist, use an A record?
> ==> can/should these dns requests be done in parallel? (perhaps see
> RFC 6555 Happy Eyeballs)
> It should cover desired behaviour if there is a xmpps-* record but no
> xmpp-* record

I think I did cover this in the requirements:

1. Treat both 'xmpp-' and 'xmpps-' records as the same record with
regard to connection order as specified by RFC 2782, in that all
priorities and weights are mixed.

so SRV already specifies all your other questions.  As to whether the
DNS requests can be done in parallel, yes they can of course, but that's
up to the implementer.

Thanks for the feedback!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

On 01/28/2017 01:21 PM, Evgeny Khramtsov wrote:
> I think the sentence:
> 
>> ALPN (RFC 7301) requires registration of the new Protocol IDs,
>> 'xmpp-client' and 'xmpp-server', specified in this document
> 
> is incorrect, because 'xmpp-client' and 'xmpp-server' are not Protocol
> IDs, but "Identification Sequences" in RFC7301 terminology. 

The registry I linked to:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

Is a registry of "Application-Layer Protocol Negotiation (ALPN) Protocol
IDs" so I think it makes sense to leave that sentence that way.

I agree spelling them out like that with their explicit Identification
Sequence is a good idea though.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Advance XEP-0368 to Proposed

[Travis Burtrum]

On 01/24/2017 10:20 AM, Sam Whited wrote:
> I agree with Zash, they're equivalant; 6120 says
> that even if STARTTLS isn't advertised you should attempt it, and this
> is the same thing. Falling back to plain is a bad idea, but it's a
> matter of client policy.

I still disagree, I know in the wild you will find poorly written
clients and servers that fall back to plain text when confronted with
STARTTLS stripping, but you will NEVER find software that falls back to
plaintext over direct TLS, because it's simply not possible.

Also I just realized the XEP already spells this out explicitly:

"TLS provides more security than STARTTLS if RFC 7590 [4] is not
followed, as it isn't subject to STARTTLS stripping."

Referring to where 7590 talks about stripping here
https://tools.ietf.org/html/rfc7590#section-3.1

Is that sentence as written not correct?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Advance XEP-0368 to Proposed

[Travis Burtrum]

On 01/24/2017 08:08 AM, Kim Alvefur wrote:
> On Thu, Jan 19, 2017 at 03:19:12PM -0500, Travis Burtrum wrote:
>> I am proposing advancing XEP-0368 from Experimental to Proposed, and the
>> XSF MUC said to do this by sending an email to the standards list.
>>
>> https://xmpp.org/extensions/xep-0368.html
>> Any thoughts?
> 
> 
>> TLS provides more security than STARTTLS if RFC 7590 [4] is not
>> followed, as it isn't subject to STARTTLS stripping.
> 
> I strongly object to this. "Direct" TLS and STARTTLS is exactly
> equivalent security-wise. In the absence of DNSSEC, you can just as well
> strip the SRV records that point to the "direct" TLS port, and you can
> attempt STARTTLS even if the advertising is stripped, or give up and
> throw a security exception.
> 
> I assert that this is only an optimization that lets you skip a few
> round trips.

Both are equally susceptible to DNS attacks in the absence of DNSSEC.

But you basically said it yourself, "Direct" TLS and STARTTLS are
equivalent security-wise ONLY IF you attempt STARTTLS regardless of
offer and give up with a security exception otherwise.  That behavior is
enforced with direct TLS, therefore they are not equivalent.

We could say something like that in there, but I'm not sure how to word it.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Advance XEP-0368 to Proposed

[Travis Burtrum]

Hello,

Thanks for the comments, I'll address these in-line:

On 01/19/2017 05:11 PM, Dave Cridland wrote:
> 1) SNI really needs to be a MUST rather than a SHOULD. It's the moral
> equivalent to having a "to" in the stream open for the pre-TLS
> STARTTLS case, which is also mandated as of RFC 6120.

That makes sense, I agree.

> 2) IANA registration is required for xmpps-client and xmpps-server SRV
> protocols.

Also registration of the ALPN protocol IDs is required also:
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

4 IANA registrations for 1 XEP, is that a new record? :)

> 3) Should we request IANA register 5223 and 5270 as default ports?

That's another issue I guess, this XEP at least doesn't have any concept
of default ports.

> 4) "TLS provides more security than STARTTLS", for example, in
> Security Considerations doesn't make sense - I think we need a term
> for immediate-mode TLS. What about "Immediate-mode TLS"?

That's as good as anything else I suppose, I might mention in a note
that this is 'like HTTPS' but otherwise I'm fine with that.

> 5) I think it'd be beneficial to point to RFC 2595 Section 7, and note
> that the rationales listed there have either become outdated, or else
> do not apply where SRV records are in use. For example, the URL issue
> is a non-issue with XMPP, where the URL scheme will not change
> irrespective of the record followed. (Also, it's always fun to cite
> any RFC mentioning ACAP, right?)

Yea I read through that and they indeed don't apply in this case at all.
 Where in the XEP should this be pointed out? and in how much detail?

> 6) Security Considerations should note that in the absence of DNSSEC,
> there is still a downgrade attack possible. (You can spoof the
> non-existence or incorrect Immediate-mode TLS records fairly
> trivially).

DNS spoofing/manipulation equally applies to regular STARTTLS SRV lookup
and this SRV lookup in the absence of DNSSEC, I suppose it wouldn't hurt
to mention it though.

> Incidentally, while I've coded up the S2S variant in Metre, I've not
> really tested it at all - if anyone else is up for implementing it
> than we can give it a bit of a whirl on interop.

Awesome! That's the first S2S implementation of this that I've heard of. :)

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Advance XEP-0368 to Proposed

[Travis Burtrum]

Hi all,

I am proposing advancing XEP-0368 from Experimental to Proposed, and the
XSF MUC said to do this by sending an email to the standards list.

https://xmpp.org/extensions/xep-0368.html

It's been a bit over a year, no one has suggested any changes to me.
There is at least one client implementation (Conversations), multiple
servers supporting it with C2S (using sslh it seems, mostly), and one
server supporting it for S2S (Metre).

What's the next step? Any thoughts?

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] JingleFT XEP encryption conflicts

[Travis Burtrum]

On 01/03/2017 06:19 PM, Lance Stout wrote:
> E2E security in Jingle can be negotiated in three different places:
> 
> 1) As part of the application
> 2) As part of the transport
> 3) As an additional layer between the transport and the application

So #3 has no currently defined XEPs or RFCs?  Someone said gajim
implements XTLS for this I think.

Which I think means WebRTC datachannels are the only secure way to
transfer a file with jingle currently?

Thanks for all the answers!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] JingleFT XEP encryption conflicts

[Travis Burtrum]

Hello all,

I noticed https://xmpp.org/extensions/xep-0234.html#security says:

In order to secure the data stream, implementations SHOULD use
encryption methods appropriate to the transport method being used. For
example, end-to-end encryption can be negotiated over either SOCKS5
Bytestreams or In-Band Bytestreams as described in XEP-0260 and XEP-0261.

Yet 260/261 both say:

https://xmpp.org/extensions/xep-0260.html#security-media

This specification, like XEP-0065 before it, does not directly support
end-to-end encryption of the media sent over the transport.

https://xmpp.org/extensions/xep-0261.html#security-media

This specification, like XEP-0047 before it, does not directly support
end-to-end encryption of the media sent over the transport.

So I at least am very confused, can anyone help? :)

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Images in chat

[Travis Burtrum]

Hello Peter,

Just pointing out that Conversations does encrypt the file before
uploading it to the HTTP server in a way that matches the encryption
being used in the current chat.  This keeps the trust in the HTTP server
the exact same as the trust in the XMPP server.

For example in a XEP-0027 OpenPGP chat, if you upload private.jpg,
private.jpg.pgp is uploaded to the server and the receiving client
downloads/decrypts/displays it.

Thanks,
Travis
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown in XMPP IM

[Travis Burtrum]

On 01/06/2016 08:00 AM, Peter Waher wrote:
> Sending markdown encoded as markdown has several benefits.

But also many downsides, there is not really such a thing as a markdown
standard.  There are different 'flavors', such as
github-flavored-markdown, and then there are just major/minor
differences in various markdown libraries.  A newish effort is
CommonMark[1][2], and it is strictly defined, but has only a few
implementations at last check.

Point being, you couldn't write a XEP talking about 'markdown' alone and
expect it to be very compatible across implementations.  I'd instead
suggest client-side support for markdown, but sending it as HTML with
the raw markdown as the text alternative.

[1]: http://commonmark.org/
[2]: https://xkcd.com/927/
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown in XMPP IM

[Travis Burtrum]

On 01/06/2016 12:53 PM, Ashley Ward wrote:
> text/x-markdown

Except markdown means nothing, there is no standard, and no common
implementation.

I love markdown, but just because your markdown converts with your tool
to a format you want, doesn't mean anyone else can get that same output
with any other tool.

I'd think to standardize this as a XEP you'd want to specify a specific
markdown standard, the only one I know of being CommonMark.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown in XMPP IM

[Travis Burtrum]

On 01/05/2016 10:49 AM, Peter Waher wrote:
> But instead of sending markdown as simple text in a normal
> message, I would like to mark it as such and provide an unformatted text
> version (with any markdown formats removed) as well, much like how
> HTML-IM works.

Isn't the point of markdown that it's perfectly readable as plain text,
ie that there is no markup?  I'd think sending straight markdown would
be just fine.

This could also be a client-side only feature, allowing input in
markdown, then converting it to HTML and sending it as HTML-IM I suppose?

Just some random thoughts, thanks,
Travis
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0368 (SRV records for XMPP over TLS)

[Travis Burtrum]

On 12/15/2015 03:58 PM, XMPP Extensions Editor wrote:
> URL: http://xmpp.org/extensions/xep-0368.html

I made the requested updates, sending the JID domain-part as the SNI
name, and changing the SRV names to _xmpps-*._tcp from _xmpp-*._tls.  I
also elaborated a bit more on the security/privacy differences between
this and STARTTLS.  And lastly I put in a blurb of interest to server
operators in the implementation notes about multiplexing.

If anyone is interested I also updated my Conversation's patch to
implement the latest version:
https://github.com/siacs/Conversations/pull/1371

Looking forward to more comments, thanks much!
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: SRV records for XMPP over TLS

[Travis Burtrum]

On 12/09/2015 05:58 AM, Dave Cridland wrote:
> - The SRV label form probably ought to follow the precedent set by RFC
> 6186, even though I think that's uglier.

I am fine with changing the SRV format from the current
_xmpp-client._tls/_xmpp-server._tls to
_xmpps-client._tcp/_xmpps-server._tcp instead.  That a single one is
chosen is really all that matters, we don't want a SIP scenario where
_sips._tcp is in the standard yet most clients look for _sip._tls so in
practice both have to be set...

I'm not sure if it's appropriate to mention in this XEP, but I'd prefer
it be explicit somewhere that SSL is not acceptable, only TLS is, and
*preferably* TLSv1.2+?  _tls kind of implied that, xmpps doesn't seem as
strong to me.

> - I'm not at all convinced by abusing SNI in lieu of ALPN.

I'm also fine with using the domain-portion of the JID for the SNI name
as well, in which case SNI is used solely to choose a certificate and
ALPN is used solely to multiplex based on protocol, as they were designed.

What this does, however, is effectively prevents multiplexing in the
near future until ALPN has more widespread client support (which http2
will ensure happens more rapidly than usual).  Also, while applications
exist for the server to multiplex based on SNI name (sslh, haproxy,
sni-proxy, stunnel), I know of none that currently support multiplexing
based on ALPN (though I'll eventually create and submit a patch to sslh
which supports it).

Therefore, I suppose this XEP should at least note that a server
operator should not expect multiplexing to work in all scenarios and
should provide additional SRV record(s) that do not require
multiplexing? (either standard STARTTLS or dedicated XMPP-over-TLS)

If those proposals sound fine to everyone I'll submit a pull request
with those changes shortly.  I'll wait a bit for some feedback before
getting started.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Travis Burtrum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/09/2015 06:20 PM, Tomasz Sterna wrote:
> Dnia 2015-11-09, pon o godzinie 17:33 -0500, Travis Burtrum pisze:
>> That seems like a ridiculous question to me.  If not, why even bother
>> with STARTTLS/TLS in the first place?  It *could* be used for
>> circumventing security policies after all.
>
> Your own words from the XEP:
> "at least equal and perhaps increased security and privacy over using
> STARTTLS. It also provides an easy way for clients to bypass
> restrictive firewalls that only allow HTTPS, and for servers to host
> multiple protocols/services on a single port"
>
> I'm pointing that:
> - designing to bypass security policies may not be a well received
> reasoning

That's just one example usage, both BOSH and XMPP-over-Websockets can
also be used the same way as they are also indistinguishable from
http-over-tls, yet they are approved XEPs.  You can't design new
features worrying about whether they might violate some administrator's
arbitrary rules, they almost certainly will, but that's the user's
problem.  Many administrators/companies have rules against chatting all
together, yet XMPP exists.

> - hosting multiple protocols on a single port is a job of protocol
> level multiplexer - standard _tcp records are just fine here

Multiplexing by sniffing the first few bytes of network traffic is
unreliable, a total hack, and completely impossible for some protocols
in which the server must speak first (like SMTP).  Where as using SNI is
foolproof, ALPN was actually built for this explicit purpose, and both
work regardless of the underlying protocol every time.

> - if your admin wants to block you on protocol level (not simple port
> blocking), it is just as "trivial" to target DNS, ALPN etc. as to
> target XMPP protocol blocking

There are as many ways to block internet access as there are ways around
those blocks, this proposal doesn't claim to be a solution for every
type of block, or really even any, it's simply another method of
discovering XMPP servers that both servers and clients must agree on
before use.

> Could you elaborate how TLS instead of STARTTLS may perhaps increase
> security, as this is not clear to me?

TLS can be more secure than STARTTLS because it isn't susceptible to
STARTTLS stripping[1], which actually happens on real ISPs. And it's
more private because it blends into all the other TLS protected traffic,
rather than announcing I'M CHATTING OVER XMPP to everyone who can listen.

In fact, STARTTLS's only purpose is so you can accept encrypted and
plain-text traffic on the same port, which is pretty useless considering
it's universally accepted now that XMPP should only ever operate over
encryption, right?  If the XMPP Core RFC was written today, does anyone
doubt it wouldn't just operate over TLS exclusively?  XMPP has never
been a protocol to stand still, and I hope this proposal is yet another
small way to move it forward.

[1] https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZBVpIACgkQF11X3nXPI/7FAACeK/Y8zK17zCpXY1x+2cSyk4Xj
SpsAniXof7I5sHPnay5N7WTaYgjQ1QDB
=peiu
-END PGP SIGNATURE-

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

[Travis Burtrum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/09/2015 02:46 PM, Tomasz Sterna wrote:
> Isn't smart proxy like sslh[1] better suited for the use case?
> 
> 
> [1] http://www.rutschle.net/tech/sslh.shtml

Which use case?  I actually do use sslh on my port 443, because I
wrote a patch to let it multiplex based on the TLS SNI name.  But
accepting raw xmpp along with https on 443 is not a good option
because it's obviously xmpp and can be trivially blocked, vs a TLS
stream that could be http-over-tls or xmpp-over-tls.

Now, you could also terminate TLS with something like stunnel, and
THEN multiplex http/xmpp with something like sslh since everything is
cleartext at that point, but it's a lot more complicated setup because
then prosody/nginx don't know if they are encrypted or not for
instance.  It's also not quite as fast (or maybe secure), and it won't
work with http2 which requires ALPN.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQQcBAEBCgAGBQJWQQIuAAoJEOy5uMuqxowDLL0f/11E2FQOZoBh3gipYAIVbWtN
9+1K/qPhiPgu87g6cXGLaA2MOAIrWDlY2uE59gLfb6o0TX0Uq9MlCah1O7s4CC7W
nJ8egjrVBGk3mVH13z7fsH5/MmiK2cJtiA6uOoZU7PV1aDFELywjTNnrUyn7VshD
SrEYcITZPsr8obIVg+W2d16kVTkH3r9BvsyE8yyiJyvRxA82RG5Xo4misOtQUBrp
zyIGCJXOeo/z/bZO1U1NU7BA3Eqny0kBBTjYT/a/7hM9zcBZ5srehd/2YBEqvzi9
isZPrkPPw3kjpj6ejFbTqqOuY7tG2JN92MTqQ/3t2InxfoqSfscJUagCOxA4AZnB
l7ubO2tt/C9o9/9P2/oTldjvt7Dc+LybEmEHIWxALlxV69Vq7/Ovhwdxkq+yqXs+
fKm4N1e36zxt9kdZNUxjKr0O82ssubuqrQoqV5A2S8GGS11I/gKuNj7n351DBg+L
oe7YB8OMEd4w4VnZDB+Vv4JNHpay3CPyCBxGWTdf5dg2nkJnIrPXPmg3OPs7awjg
j+MkkRxjUnipS/sNpsnbTEnmO5WE0YE3c/AzNhN+nMFdRJkLpPci9or8pxqyyAOv
zrJNIn3PFSHb0k8SlEF9vunLaqB48l9D9y2IjzIOcOOrvxv4Y5XzI2o9UYTsL+L5
ulavjeAZvul8SzBQbZdsXqD6v9sq5AXWEzfSOSF/PqJIY11A0DT7VHsc0GbgX+Ch
QRrCVZFSqfuqQ4VXa5C4UmhkQRxEzK2j5qPoTn5wX1ffxB2z12dqoSzJcxx0Bhex
i5fSMc6YmmuoJmTbK6oqscHfevfwz9L9NvGj5Io0iGlR5LFwje7QjOxbVWhcBbqW
ixuM3VHKbgZkW/u4biaO65VTdRL4hGkdjlzBd0g75Wz6UIhWHFSf5JNLdthSjC+M
kqQVUbICE6fc45lFVFUaAx8pBfABuNvPj0HT1ZoqHwndn9nwfU2HmhduSCPrF+Ok
J4ILKq4MpWU4YA4zoP91mGR9LWlo62wgej6ywIemUt7HGAAvEoB8k+isVAa3DmFM
oyWNrN1Am8NWmX37OmT8WQpq5Ke6bCHgJg1yEaqZq/z8AgAc+MKw+2VSpe3xZoDq
zmBo5VuxkPqftWsfDli/g8I7b+4+LSRtumHKVAXN4K/CHtZ/OWMyCgxl24JFfyxS
G1gWJoD3lh37B5agxRo9Yl5lU9q+Ep3wouwDibPcatCuObwlbs0BpxTXDJutWzZ6
bk2/YGTriPLErtZ+ETMBHSOubQVmcopoS20nxJwOEvR875GE+9k4iX2NQC8gWXlJ
788/lIPxaGvAlQlu24jWJ2VKmE5VJMp3e3uYv5BAPmKDktvtLrhnsCjaCiCyNnc=
=d2S8
-END PGP SIGNATURE-

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

[Travis Burtrum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/09/2015 05:22 PM, Tomasz Sterna wrote:
> Dnia 2015-11-09, pon o godzinie 15:29 -0500, Travis Burtrum pisze:
>> accepting raw xmpp along with https on 443 is not a good option 
>> because it's obviously xmpp and can be trivially blocked
> 
> Should XSF work on technologies targetted on circumventing
> security policies?

That seems like a ridiculous question to me.  If not, why even bother
with STARTTLS/TLS in the first place?  It *could* be used for
circumventing security policies after all.

And yes, SRV record resolution could be blocked too perhaps.

This proposal isn't specifically targeted at running
xmpp-over-tls-on-port-443, it's just generically
xmpp-over-tls-however-server-operators-would-like-to-implement-it, and
it has opportunities of implementing it different ways, like
multiplexing on the same port as other services if they would like, or
anything else.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQQcBAEBCgAGBQJWQR8eAAoJEOy5uMuqxowD5+8f/2fEc/qs4z+Pe6UvAeo1sIPA
fy/tni8rk7o1pTSzpHmcQ5NlbtnTwOxA5TEirlUNLPbjoBZ5tL5lossyHTi9RVav
m4MwgU//6KfVPpzAHkhKr0K7y+eEoGct5llmkQk3qbQEcrD/DpGNdNHvup36FjPC
VBp+oYv5NfTCQD8bE9bBt6DzGKks900EZP7U7i4HtNSKroj1GAQh3gijIfTgI7+I
/E1mJwQGLgldcsIOnYKAR9eGaJo27MJDqMlhHFmtFQKY6AbRaFcu0SI/H8xp2yVU
JM0rqTUlcnKUk0C9MUr8q7A2jGGYhj+8So7eI0bNpsUhfIEmd+ih1wXTmupJN1ya
gPPR3vkI2jLwH3cLWeJ82s8Vh1omcHjdRKwFB6FotEM8x0l/HCZ3+Gma3SRbEo9q
MSSnCv86E9FJxYSZTLBU9yTSA2Ad1De/pwHmVgzjcTxUIYIZyVUTdgvd/pnrDWVq
Biz500ocQH7/aUlOWWimWk7GFYpFTGtvdIYzRAcN8OkRCqjD/O26+iCqiRz9Lrrv
F6YDYH1qYiHtDBGLfcQCBWCPQtaAPqqO+AUMf20dqStcP/smLhy72HPGEDmPWQ2i
FAKfTjUn3ClqD+u2PXoz4S1Rd/4j07fBhnBfIRoADO0dk/5WfonIl3qmeUXs7ujn
XmKaplo030/+keGyc+Yz8dbN3UD9MjIovVWLBhLkqskS251NocfibI1mEtR/AKxB
FC6P86q6oBNxPJlwi+MRrJdX4adykFZPOAW6sav0KS8R4QH6VV0lFDVffSBZ//cz
gxq3sdSaGk3ZpLoCZnZK7D9vmI/9xbdePgEWSyfkuJOf7BcdeVItPGpr5jQwX820
C+2INDLyIRLXtSTok3rrh3qgOhnF1g/i9HcytXb51AVQTSQ0297XB8QlzDrzWAIq
vCaiIMBnaY3Y/3VS7akj3iIXoEqLV33fjV0zZzQ09/02MiumfS6OWRrQt3dzg5kX
Nqosm1popWenzVWcz02sKM4Y67z8SEp1zJNi0vQ4cLNEfFB7VHK3yLyRW2ProZNj
N+S66l/zFpHVE1WrhLgH1HIBV/xsoYoCMrOWmS9AfR0L+4/dPnVpMrWB0TPrA2Q3
R1H2gXVfaupDUmQgCiSDS7bIhrWXXXuP13/r7Br/g5usnpdXA8STjKXzAVsukBwA
bEbTzvfO5oTNseuHvIFZveIXYuT8v2XRj3C8hlNYe33L9VAIPgVlOE9NKlrk68rq
W+fxdbwO/gSZfbLa90QPRGCKl+BsO+9NrW3qvv4cE/D7X8tQH/Rfe/KapYkKPCVG
PDQq+TjC2yGMBjvd4eOAINPYGkCDDJUYbePfarDCVc/0FiwS/bGv1hX2zeVRwBg=
=4CD1
-END PGP SIGNATURE-

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

[Travis Burtrum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/06/2015 08:24 AM, Kim Alvefur wrote:
> On 2015-11-06 11:28, Georg Lukas wrote:
>> * Travis Burtrum <tra...@burtrum.org> [2015-11-05 20:56]:
>>> 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).
>> 
>> So lets assume I want to connect as ge...@example.com and the
>> SRV record is
>> 
>> _xmpp-client._tls.example.com. IN SRV 5 1 443 xmpp.example.com.
>> 
>> My client then makes a TCP connection to xmpp.example.com:443,
>> requests xmpp.example.com via SNI, and the server is expected to
>> return the certificate for example.com instead, which the client
>> verifies?
> 
> That's ... unpleasant.  At least Prosody has absolutely no idea
> what SRV targets point at it.  Suppose you could index all
> configured certificates on what names they claim.

Prosody doesn't support SNI for xmpp-over-tls at all currently, if
this XEP moves further along I was going to start writing patches for
that.

With my setup currently, sslh listens on port 443, if the SNI name is
xmpp.example.com the connection is sent to prosody, otherwise if it's
example.com/not set/something else the connection is sent to nginx.
You could also do this with at least haproxy and stunnel today with no
code changes to any underlying servers.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQQcBAEBCgAGBQJWPLE3AAoJEOy5uMuqxowDo7Af/2FQZyMOvviNsdXeqT7gpbgX
n5lNFfQ4pS+XKtJ9wZQ8DBpOfiBng9M7XImCe5AX9UMfCQ34N+Lsnb2IdG1Aj1cp
KRSaWFIH1qWfv8I23up8sQZhG7Xg6PuMyiXt6bpGw2iDsGxeRuzpCKeIxZYH+y2u
ErNrix5/ASatbCmzPMb/INxiNxuWD+XIKsZqs8bC5c5Nc4YCnAxPKyH2VZGohq2N
jh0hQtzdnbaZqLl+3QyoaRH7iZHxLH9aHq05bUSO+d9CKyFSGA5yyLVY+t+W92EX
zVTX130Q4YQ0QqqVaFqU12tkExQZdHy8JltkzmV8NNhb9sOaXY06TYpCAyz3TU1r
xzS7vFts4A+U/HAxSDSgUF/g7AHe4GEg5ji4o4DyeIzbcLrmdp1OP5c481tt8S6c
PIZjdsXuklH3uhKXflTPk/MaVG/X4MHLflKSj3JMxWPlfxUpcP4LNsB8MZOELHEj
fMZqUpkIrmaRYIjMWr6JagRFxWiCp3MGF2vKnTmdZs0IoCYd6lbA+p5SOECbRYB4
KDo3OGmzzqNwGQ4majDfVZjt9tiY4780SiAhGyEDnsxtvs37BMyr6Cw3QbQes67s
FuGZU32N4m08FaPimiOvDfA23YqgvII7Dix4qyr/Zg3BPULr/uK07PKbG2P/q7b9
aHiIK/dm5Vjzz8M71duveSOx+K8QySaCeIi8tQw0riaR/GIZcWoAF1VUc151dcpx
m1e88pF1minLB1X8KTxU9PiPZv18XxnDUJWSTak8P20LL/Il4ZeR512bO7wVM+Ga
Y84GaZoVy/gr0cGlCbj7F1EDAQFOPywR34MRUFeG7xrH4DEwWp6KcwRQbZ0NDpaV
g8F5OC4tx9tteA77PzHz1FsqHtpt+CoUuXX6oXw+c/HtjLSVnzVZsGtis//jaZLV
gvcEKw78D50SXRDBigy6tZSjr20X0IUOTjY3EVv0vQC9z26MgXxjYy3B/Mtf1Y6F
NhqlUpVJbI77Lp6638Yq2cBzSv5Owex+AXBuS6iLYJpbk9FSFM1KgeIJtqhIVNpw
C+/cR0fVhIiOsm6wYiGg/phegutVJW+hs9m5SNJVK30tIppKAa56Dx75ikBoVFZW
5PUVv7k0DBg6HmeYff/O0gXEuZVpSDrrhLo3RsU/mtUoW1PaY+dEebFwIEDnUgzs
rRom9ROx+pRsr3BEoHYa+Gk85wLZEiqarbd4T0beor5ng9ENFmDP2l+m8CnqXmCf
TWizkzpzypVRlA0d6112lAeS4rjKS35YXQulDaXayBQNjTFTTrS8hLiEKSoTXNA1
kvOcAdoNyBkH/J9KkD8ERj0nHr0/Dc/vQDwzBUDSytjDAIEkac35/lNjpNWYEU4=
=rs2h
-END PGP SIGNATURE-

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

[Travis Burtrum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/06/2015 05:28 AM, Georg Lukas wrote:
> So lets assume I want to connect as ge...@example.com and the SRV 
> record is
> 
> _xmpp-client._tls.example.com. IN SRV 5 1 443 xmpp.example.com.
> 
> My client then makes a TCP connection to xmpp.example.com:443,
> requests xmpp.example.com via SNI, and the server is expected to
> return the certificate for example.com instead, which the client
> verifies?
> 
> If this is the desired behavior, it must be stated VERY CLEARLY in
> the XEP, as it is very unintuitive.

Yes that's exactly how I intended it to work.  The server operator
would know which domain to serve which certificate for because they
set it up that way.  The plus side being this gives the server an easy
way to route traffic (as opposed to just example.com being sent) and I
can't see any negatives.

It would make sense to explain it better and more thoroughly.

Travis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQQcBAEBCgAGBQJWPKf3AAoJEOy5uMuqxowDG8kgAJWTJ3LhX0DbMQ4cQVSBbHhS
h5mCfY3ZDdNO5Q5UyIOJTEG7W6hcZ2KonfPVioyBqW8ojfyHjdxPSueE9gnqU3iB
yBbbBB7NVmhiRnKKt1p3A9XlVFBDbEroMlC34tAIFD+63x1rpmeWgLf+mnck29W6
wKEdXk03Kkj9IX/chqKavhFy8+/M0Lnc7FVzqi09wN7fMb0Y3jreha6EDhSko+Y1
JgPECEr/chkaqvgYVKkZ8t2q8xUrhdKRunurKePXx8pHohgPjNbICLkRHoHvon3l
1bt+rnLqn37eyxllu/1prRZ2MRQ+WAOwSyLEfpPr0e2SVgUVPJinfXvBv0lzwOma
NA+Bf7IGdHNYcUWecmwX1nhBeS9/k70TzzhvefE4Ovw0seCljyftsdr+j90q7D49
wzWKFUqrTvaWjuN03mY4jg0FzreuI5u6WChRXIZcwnRBcDCcBZRp1QpL4O+XDBdm
pDHkwk48AIggCyFr5uHou4U0lsExNlDQJtu+p4W3miDUe7R2wLWXMeNjue0v8doY
CesiH11A5n2oEAoxQ40elBB4XfyVT/fcHKbFlcjUDYyNJPIjVF8hcjYgQ2xCxGLz
uhnCXUHhRlJ5SQ3ngOgFrksQoGCXp2hhaYOBbLrHnh0+g00gqNLsAmT7f3eK/M2s
t422tBZeD00Q7cwlIDBLhS4qBfJCCELJC481spla/cdDCrM8SaSRFJsZOa+a7Bw5
w/yBniCqvtQMGEDFjf7Xb4TEWYfN7y+4gXZqUnZ6VLAByn/SMpftTTydvoG8e+hl
tO6tY/qbqpdqtpg3kxvY6ZEkoXpI+DTnVMPMKebMykzSvby/RcJv5vbZpgL2kAre
ndxkGhBmizGk9MO60DWh4S8zJMQ2vdcl9Wa8pIzyIqdQIaC6GgB0KZ8/tDyZx2Rb
LEK+hphHmXSQZlbX3g+0PZOH+Om1tLrHrvxqnN9jtg6xWwqj3eAZSC0sVO3YZIBX
dVBcZKOSJSLkBDrAmNxAyD1gJ9EQMcBkbI4KkAXLQWaxwpVWLpqB9cDoJ8luW7/m
gIBMKFPFQKR/1IKimK36IgWhB0fw5yCHmcqqEsF3M2qCUrpUt7hTXOEWY8t8dxqk
L6dIFwynVvxyDXyNdTtGx8Is3pMUfjY0pOBBqBPT/gOW2B67Hinsutu0uIWyDBuW
HMvwWrNLmseUAA4qbYVigu0LY4BG/hqRsBKyjIGw9qacmA1TbK3MDcGf7jvFZONW
svMd359fEKmUMkgF3hspd2Jdki2CJB/hD/Ics5pQyst26iIngXYjmfcUb9WVp+Me
iI+8d615KwH7WU5Hm4mW4hjOnJEPIYIAp+KhMwlKJ+YP+6lNN1+oBfo9OF73d8A=
=Ev6e
-END PGP SIGNATURE-

[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

[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

[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