Re: [Standards] resurrecting Hop Check (XEP-0219)
On 6 June 2013 21:12, Kurt Zeilenga wrote: > I personally think trying to answer of a question about user-to-user security > when security relies on non-E2E security mechanisms is a futile exercise. > But I do think my cringe can largely be dealt with through appropriately > stated security considerations. Absolutely, and I think we all agree on that. That's why the XEP failed the last time around. However the mechanism it provides is still useful, as long as we don't pretend it's trying to solve anything security-wise. Regards, Matthew
Re: [Standards] resurrecting Hop Check (XEP-0219)
On Jun 5, 2013, at 7:14 PM, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I've been thinking I'd like to resurrect the Hop Check proposal > (because after further reflection I think it would be useful, even if > not perfect): > > http://xmpp.org/extensions/xep-0219.html This XEP makes me cringe. :-) My main problem is that it leaps from a user's desire to know whether their communications with another user is secure with whether encryption is being used at various hops. The user is asking an end-to-end question. If they were using end-to-end security mechanisms, a reasonable answer to their question can be given. But if they are relying on hop to hop security mechanisms, it becomes very difficult to usefully answer the question. For instance, the XEP seems all about letting the user know which hops are "encrypted" but a hop which is encrypted is not necessary secure by any reasonable definition of the user. Some TLS encryption ciphers are little better than the null cipher. And even if the cipher was reasonably strong, there's the question of authentication. And then the XEP has a very simplistic view of the communication path. First, there could be a MUC service in the path. Second, there could be clustered XMPP services, application level gateways, TLS concentrators, and all kinds of other bizarre devices. While such devices are out of scope of the XMPP standards in general, they exist in real world and hamper the ability to figure out which links and/or devices are the weakest links in the path. I personally think trying to answer of a question about user-to-user security when security relies on non-E2E security mechanisms is a futile exercise. But I do think my cringe can largely be dealt with through appropriately stated security considerations. -- Kurt > > Before I post an updated version, does anyone have requests for data > they'd like to see included in the data format? > > Thanks! > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRr/BwAAoJEOoGpJErxa2pHR0P/0jTB9b8UTCUJOnmRfPyACF9 > 7FI++aJ7a1woKFMnH5Tt0JnZ28SzFed3o9XkusUoC5PFbUiTSNcCRTHvCFeiGozE > vLY3yXwQuZiUc0fEuwWRrhfgodkSyRrP9vtSax56BWbHMFvrslcbDBPPkQazW79A > fZq9b1bF3df4aPX8L2RGNPTpeb/wCqjacznNEfQ093ZsBrVvZ3xTwxJQKLMdOG9s > ElckIiTKqdSvepHzq9f0wmngsPEbkxALM6m/WvDFZeLhm+UCkwvvPLv5EngCLIj1 > K9SAfpbgHirO007s5iyPgwJiAqcZecJ8alC8u435h3wc85Zs4S0Z9ZYBLus+jrnr > RKeSSDSYXLcz+jomk13BIw77a+izFysj9kPljPEgEBH8lqzflGrFKl/r6/kbtnVn > P9MeaOspoXLgz+NHXw0qhvjjtvpN+T8x1pJdyL9dTsrPmMDjaBfQVX784R9PcY6r > 980BGm6nRf89raPHLzKaj4/uGyMOub0wyFGW2sQHdBHpr4ln4MQGyiv+qNa0w1Aq > pUB610h41uf/3M7ifXlxv1HhNZxf2+Gj3n3E/RnP+4toK1h4PPWNJvpBuI3f7UBa > nEETd19/UBxlNVA7WelNzaWVA/K6WoQDiiH1hfZmKALfQu+yystGaM0gY8Ulw3dt > C/igyQGvxz28GvQxUb3y > =wbXd > -END PGP SIGNATURE-
[Standards] XEP tagging idea..
Hi Guys, Today I had an idea about our XEPs (http://xmpp.org/xmpp-protocols/xmpp-extensions/) Have anyone ever thought about making search easier in our extensions? I was wondering why we do not have any searchable tags on the different XEPs. I would be easier to find what you are looking for. So for example http://xmpp.org/extensions/xep-0166.html could have tags like: jingle, video, conference, peer-to-peer, signalling etc. I mean most of us can mostly find what we are looking for there, but beginners that are searching for stuff, might find it hard to find what they are looking for? -Just an idea and my 50 cent! :-) -- Venlig hilsen / Best regards Steffen Larsen, Founder & CEO Mobile: +45 51 94 33 33 BrainTrust / http://www.braintrust.dk
[Standards] XEP-0327: Rayo
It's been one month since 327 (http://xmpp.org/extensions/xep-0327.html) was published, and some further work on the spec has been done. Progress since then can be seen as a diff here: https://github.com/rayo/xmpp/compare/730f5f85e755cfa2d040c7455fa6b01e0c747c3e...rayo We still have a collection of outstanding issues on our issue tracker: https://github.com/rayo/xmpp/issues, and I am sure there are issues with the spec that we have overlooked, or things that would be more satisfactory to the XSF. I would love to hear feedback that anyone could share either here or as issues on our tracker, along with any suggestions for improvement. This is the first XEP that I've written and it's a big one... Regards, Ben Langfeld
Re: [Standards] resurrecting Hop Check (XEP-0219)
On 6 June 2013 10:21, Simon Tennant wrote: > End to end encryption is a worth goal. This is very cool for getting > information on the s2s connection. Perhaps on first sight. However this kind of usage is exactly why the XEP died last time around. It isn't suitable for anything except purely informational/debugging purposes. This is because the link can change - it might be encrypted when you check it, and then reconnect unencrypted without you knowing. Also, malicious entities can always lie. Regards, Matthew
Re: [Standards] resurrecting Hop Check (XEP-0219)
End to end encryption is a worth goal. This is very cool for getting
information on the s2s connection.
XEP-0219 makes a lot of assumptions about the network topology always
involving the traditional c2s design.
How might this XEP report meaningful information back to the user in the
following situations:
- cleartext BOSH inside SSL terminated HTTP session?
- cleartext on loopback to new c2s services like XMPP-FTW or the
buddycloud-api?
- websockets?
S.
On 6 June 2013 09:56, Dave Cridland wrote:
> On Thu, Jun 6, 2013 at 6:11 AM, Philipp Hancke
> wrote:
>
>> I've been thinking I'd like to resurrect the Hop Check proposal
>>> (because after further reflection I think it would be useful, even if
>>> not perfect):
>>>
>>
>> for debugging/support? +1
>>
>>
> I've not checked back to see whether I liked this or not before, so I
> don't know whether now deciding it'd be a good thing would be an
> embarrassing U-Turn or not...
>
> But FWIW, when this was proposed, I think it was suggested as a "is my
> end-to-end path secure?" - to which the answer is "not if you had to ask" -
> rather than as a debugging protocol.
>
>
>> [...]
>>
>> Before I post an updated version, does anyone have requests for data
>>> they'd like to see included in the data format?
>>>
>>
>> A bidi flag (for s2s) and the raw certificate data for both dialback and
>> external auth. Probably also whether an SRV record was resolved or the A
>> fallback is used.
>>
>> And keep in mind that most s2s connections still aren't bidi, see the
>> list archives from 2007 for some discussion ;-)
>>
>
> 1) I'd suggest for most things we just stuff features into the thing if
> they've been used, maybe?
>
> So for XEP-0138, we'd see something like:
>
>
>
>
>
> This'd hold for SASL auth, too:
>
>
>
>
>
>
>
> 2) I know that having the certificate chain would also be useful, as well
> as any reasoning for trusting it - or not trusting it, perhaps even more
> important. There are many times I'd have dearly loved to have been able to
> tell why a certificate wasn't trusted by the peer in ways that didn't
> involve trying to parse other people's logs, so the reasoning here is more
> useful that the certificate chain to me.
>
> 3) I'd also point out that while it'd be very useful to know how your
> victim authenticates, having this as a mandatory feature seems like a
> security issue. ("Oh, he authenticates using PLAIN without TLS, does he?
> Oh, goody!")
>
> 4) Some links - S2S, for instance - have have different characteristics on
> the return path than the forward path - XEP-0219 never addressed this. I've
> a feeling this one came up at the time.
>
> 5) Currently, this protocol is framed such that each hop is mandated to
> ask the next. It might be useful for this to be reframed as an end-to-end
> protocol, so that Juliet asks her server, then Juliet asks Romeo's server,
> then (possibly) Juliet asks Romeo.
>
> So, erm, basically that's close to a complete rewrite, I think. :-)
>
> Dave.
>
--
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP
Re: [Standards] resurrecting Hop Check (XEP-0219)
On Thu, Jun 6, 2013 at 6:11 AM, Philipp Hancke wrote:
> I've been thinking I'd like to resurrect the Hop Check proposal
>> (because after further reflection I think it would be useful, even if
>> not perfect):
>>
>
> for debugging/support? +1
>
>
I've not checked back to see whether I liked this or not before, so I don't
know whether now deciding it'd be a good thing would be an embarrassing
U-Turn or not...
But FWIW, when this was proposed, I think it was suggested as a "is my
end-to-end path secure?" - to which the answer is "not if you had to ask" -
rather than as a debugging protocol.
> [...]
>
> Before I post an updated version, does anyone have requests for data
>> they'd like to see included in the data format?
>>
>
> A bidi flag (for s2s) and the raw certificate data for both dialback and
> external auth. Probably also whether an SRV record was resolved or the A
> fallback is used.
>
> And keep in mind that most s2s connections still aren't bidi, see the list
> archives from 2007 for some discussion ;-)
>
1) I'd suggest for most things we just stuff features into the thing if
they've been used, maybe?
So for XEP-0138, we'd see something like:
This'd hold for SASL auth, too:
2) I know that having the certificate chain would also be useful, as well
as any reasoning for trusting it - or not trusting it, perhaps even more
important. There are many times I'd have dearly loved to have been able to
tell why a certificate wasn't trusted by the peer in ways that didn't
involve trying to parse other people's logs, so the reasoning here is more
useful that the certificate chain to me.
3) I'd also point out that while it'd be very useful to know how your
victim authenticates, having this as a mandatory feature seems like a
security issue. ("Oh, he authenticates using PLAIN without TLS, does he?
Oh, goody!")
4) Some links - S2S, for instance - have have different characteristics on
the return path than the forward path - XEP-0219 never addressed this. I've
a feeling this one came up at the time.
5) Currently, this protocol is framed such that each hop is mandated to ask
the next. It might be useful for this to be reframed as an end-to-end
protocol, so that Juliet asks her server, then Juliet asks Romeo's server,
then (possibly) Juliet asks Romeo.
So, erm, basically that's close to a complete rewrite, I think. :-)
Dave.
