Re: [Standards] resurrecting Hop Check (XEP-0219)
On 09/16/2013 02:43 PM, Peter Saint-Andre wrote: On 6/13/13 11:47 AM, Justin Karneges wrote: On 06/13/2013 10:18 AM, Peter Saint-Andre wrote: On 6/13/13 8:40 AM, Matt Miller wrote: I don't necessarily have a problem with this as a protocol-level diagnostic tool; it can help users (or rather, the developers of the client the user interacts with) and admins to troubleshoot. But the potential of abuse and over-interpretation is extremely high. Yes, that is true, and I too don't want people to read more into the results than is justified. I will keep that very much in mind as I work on the next revision. What I'd like to see is an extra attribute on each incoming stanza, indicating that it was received via a protected s2s connection. Since the attribute would be per-stanza, it doesn't have the race condition problem of the hop check. [...] Just one attribute is needed for this, stamped on by the receiving server. Perhaps it could be a SHIM header. Maybe this should be in a different spec than the hop check. I just wanted to bring up the idea here since I figure it fits the discussion. It would provide some amount of tangible security without having to go full-on e2e. Interesting. I definitely think that's worth pursuing, for the simple reason that it can indeed be stamped by the receiving server (and I can know whether my connection to the receiving server is encrypted). To kick things off: TLS We may also want a way to indicate that an outbound stanza should only be delivered securely: TLS It occurs to me that we'll need a stream feature too, otherwise the Security header could be spoofed and you have no way to know if the Security-Required header will be honored. S->C: If the client does not receive the above stream feature, then it MUST NOT process or provide stanza security headers. Justin
Re: [Standards] resurrecting Hop Check (XEP-0219)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [ old thread alert ] On 6/13/13 11:47 AM, Justin Karneges wrote: > On 06/13/2013 10:18 AM, Peter Saint-Andre wrote: >> On 6/13/13 8:40 AM, Matt Miller wrote: >>> >>> On Jun 12, 2013, at 8:41 PM, Peter Saint-Andre >>> wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/6/13 6:40 AM, Matthew Wild wrote: > 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. What I'd like is to know whether the connection from my personal IM server (stpeter.im) or my company's IM server (say, cisco.com) to a random server like prosody.im or jabber.ietf.org is encrypted. Sure, malicious entities can lie, but I try not to create accounts or authenticate with malicious servers. :-) Look, I need to have *some* level of trust in the server I authenticate with. I just want to know if the path from there to the next server is encrypted, too. If I'm a server admin presumably I have some kind of server-side tool I can use, but that's not the case if I'm not an admin. >>> >>> >>> I don't disagree that the user is trusting their server by >>> logging in. And if this check were to stop at "my.domain --> >>> other.domain", then I can see some confidence in the results >>> because of the trust. Changes in the state *could* be dealt >>> with by making this information available in a pubsub-like >>> manner (I sensed the collective shudder from some of our server >>> developers and operators before I even typed that sentence (-: >>> ). >>> >>> However, that trust doesn't carry over to the answer for >>> "other.domain --> contact@other.domain" which users will want >>> so very, very desperately. >>> >>> I don't necessarily have a problem with this as a >>> protocol-level diagnostic tool; it can help users (or rather, >>> the developers of the client the user interacts with) and >>> admins to troubleshoot. But the potential of abuse and >>> over-interpretation is extremely high. >> >> Yes, that is true, and I too don't want people to read more into >> the results than is justified. I will keep that very much in mind >> as I work on the next revision. > > What I'd like to see is an extra attribute on each incoming > stanza, indicating that it was received via a protected s2s > connection. Since the attribute would be per-stanza, it doesn't > have the race condition problem of the hop check. > > My use-case is I'm running a service that allows administration > via XMPP. Users may whitelist JIDs that should have access. The > current drawback with this approach is that it is not ultra secure. > Someone could conceivably make a dialback attack and act as someone > else. My plan is to add a checkbox to the administration config: > "Only allow administration from secure domains". The idea here is > that an incoming stanza would only be trusted if it was flagged as > having arrived via TLS-secured s2s, thus closing the dialback > security hole. True, this does not confirm that the user's client > is using TLS, but I don't think this is something I need to concern > myself with. It would be the user's responsibility to ensure nobody > else can hijack his account (by always using TLS, by using a good > password, and by trusting the admin of his server). > > Just one attribute is needed for this, stamped on by the receiving > server. Perhaps it could be a SHIM header. > > Maybe this should be in a different spec than the hop check. I > just wanted to bring up the idea here since I figure it fits the > discussion. It would provide some amount of tangible security > without having to go full-on e2e. Interesting. I definitely think that's worth pursuing, for the simple reason that it can indeed be stamped by the receiving server (and I can know whether my connection to the receiving server is encrypted). 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/ iQIcBAEBAgAGBQJSN3t5AAoJEOoGpJErxa2p8e4P/0SKb4zspDpOwGg0QM2n3HQd PCI6a5DZYfkao7hfu2BFzGooN35xVabV5+nHhGg4tkYdJ4teWXYJDCkJYCE99/Z1 2tPWNtz4SfN6AC+kc/zu8aqTCoDNzSV/c3c3ns+XeOO5xtSLuM3PlLW+XdX5Gd0r 09m+TELSIEZ2jccwexQajwO7QRP372yvLuF6Fxzn/DLMc15nJEoX0NAQoAaLo1MS wKXHZovUQMGRPRrcs6KKuXhqNq4LchQJWy9z8jtsQn20VOIjB+Dn731OB4DSZNhC HFiT/kWDXWgNfmNLCPywaP/inQylM3xJobnzNJ8REBBaXWEb2wR
Re: [Standards] resurrecting Hop Check (XEP-0219)
On 06/13/2013 10:18 AM, Peter Saint-Andre wrote: On 6/13/13 8:40 AM, Matt Miller wrote: On Jun 12, 2013, at 8:41 PM, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/6/13 6:40 AM, Matthew Wild wrote: 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. What I'd like is to know whether the connection from my personal IM server (stpeter.im) or my company's IM server (say, cisco.com) to a random server like prosody.im or jabber.ietf.org is encrypted. Sure, malicious entities can lie, but I try not to create accounts or authenticate with malicious servers. :-) Look, I need to have *some* level of trust in the server I authenticate with. I just want to know if the path from there to the next server is encrypted, too. If I'm a server admin presumably I have some kind of server-side tool I can use, but that's not the case if I'm not an admin. I don't disagree that the user is trusting their server by logging in. And if this check were to stop at "my.domain --> other.domain", then I can see some confidence in the results because of the trust. Changes in the state *could* be dealt with by making this information available in a pubsub-like manner (I sensed the collective shudder from some of our server developers and operators before I even typed that sentence (-: ). However, that trust doesn't carry over to the answer for "other.domain --> contact@other.domain" which users will want so very, very desperately. I don't necessarily have a problem with this as a protocol-level diagnostic tool; it can help users (or rather, the developers of the client the user interacts with) and admins to troubleshoot. But the potential of abuse and over-interpretation is extremely high. Yes, that is true, and I too don't want people to read more into the results than is justified. I will keep that very much in mind as I work on the next revision. What I'd like to see is an extra attribute on each incoming stanza, indicating that it was received via a protected s2s connection. Since the attribute would be per-stanza, it doesn't have the race condition problem of the hop check. My use-case is I'm running a service that allows administration via XMPP. Users may whitelist JIDs that should have access. The current drawback with this approach is that it is not ultra secure. Someone could conceivably make a dialback attack and act as someone else. My plan is to add a checkbox to the administration config: "Only allow administration from secure domains". The idea here is that an incoming stanza would only be trusted if it was flagged as having arrived via TLS-secured s2s, thus closing the dialback security hole. True, this does not confirm that the user's client is using TLS, but I don't think this is something I need to concern myself with. It would be the user's responsibility to ensure nobody else can hijack his account (by always using TLS, by using a good password, and by trusting the admin of his server). Just one attribute is needed for this, stamped on by the receiving server. Perhaps it could be a SHIM header. Maybe this should be in a different spec than the hop check. I just wanted to bring up the idea here since I figure it fits the discussion. It would provide some amount of tangible security without having to go full-on e2e. Justin
Re: [Standards] resurrecting Hop Check (XEP-0219)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/13/13 11:33 AM, Philipp Hancke wrote: > Am 13.06.2013 19:18, schrieb Peter Saint-Andre: >> Yes, that is true, and I too don't want people to read more into >> the results than is justified. I will keep that very much in mind >> as I work on the next revision. > > It seems that this could be easily achieved by splitting this up: > 1) a query for asking a remote server for it's opinion about the > s2s stanza that the stanza arrived on -- or possibly all the > connections from the originating domain. 2) a query for asking your > own server for it's opinion about the outgoing s2s connections to > some domain. ISTR that jabberd14 did something like this with > disco#info to the s2s component... that enabled you to browse the > s2s connections. Or: (2) a query to your own server about its stream to the remote server (3) a query to your buddy about its stream to the remote server and the remote server's stream to your own server 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/ iQIcBAEBAgAGBQJRugQbAAoJEOoGpJErxa2p6WIP/i8C+JhQZqrtBGA0U9BWDuqf HnWYc+3FQobyCvZ2x5TPgq7fLMzhLJxC+1BPGml5Qh88QqWc5yXoFJMT4fbocboV dCS+cV/qhqUpGnwVRTIVvzwmALyrMRm1Bv2T/Q2YEMd6hjGBa6pn2Mmkaws+/MyI mxouWaJhAvK2p7MuJTPZElgktvaW31J6cu9WQw7jzWBSATDHAh7htfYSRbvCUUkK K4rhP2lZy8iCz53Fc8dMKepVj7pZjVf0o6ZJL8riMyZJ/mMohTV+KrRF+0AFHeKF Dmxdw0/epfJkxH32dWShDxLVIF90Oa/m3G9SZoN7BDnb5vVcEKG6jD9QR4JnIbv/ iqezTcDg4eMN93YJONw4EchLFwMHWBwW4Dro+v5sQfhd9Fy/19ERlVOy/zL5xLI7 qFcJf2AdralKWv6DnDRawSLa13UmidGROsTCPsooe5wiN/cghti+M3vuusSa3doC KwbWBYVlZ22UNRLsmN1gjbjMW4b+izM32iHdQMjWemHDnz4W/7hSkcdRrK/NPKas upnpsjiFRd3WX4KKX5+0kJL4ZYHkuv5xP27Fe4WHTDdWnW05KbpaZYgcmMfRpmgo I3k3rdrNokdSfBrxWNTkXS59j+wECeWxRYmOXOcnDy3LrcA0Yy53NuXFlgvEjxBR uHtpo3sBn6F1+Afnne05 =P206 -END PGP SIGNATURE-
Re: [Standards] resurrecting Hop Check (XEP-0219)
Am 13.06.2013 19:18, schrieb Peter Saint-Andre: Yes, that is true, and I too don't want people to read more into the results than is justified. I will keep that very much in mind as I work on the next revision. It seems that this could be easily achieved by splitting this up: 1) a query for asking a remote server for it's opinion about the s2s stanza that the stanza arrived on -- or possibly all the connections from the originating domain. 2) a query for asking your own server for it's opinion about the outgoing s2s connections to some domain. ISTR that jabberd14 did something like this with disco#info to the s2s component... that enabled you to browse the s2s connections.
Re: [Standards] resurrecting Hop Check (XEP-0219)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/13/13 8:40 AM, Matt Miller wrote: > > On Jun 12, 2013, at 8:41 PM, Peter Saint-Andre > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 6/6/13 6:40 AM, Matthew Wild wrote: >>> 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. >> >> What I'd like is to know whether the connection from my personal >> IM server (stpeter.im) or my company's IM server (say, >> cisco.com) to a random server like prosody.im or jabber.ietf.org >> is encrypted. Sure, malicious entities can lie, but I try not to >> create accounts or authenticate with malicious servers. :-) Look, >> I need to have *some* level of trust in the server I authenticate >> with. I just want to know if the path from there to the next >> server is encrypted, too. If I'm a server admin presumably I have >> some kind of server-side tool I can use, but that's not the case >> if I'm not an admin. > > > I don't disagree that the user is trusting their server by logging > in. And if this check were to stop at "my.domain --> > other.domain", then I can see some confidence in the results > because of the trust. Changes in the state *could* be dealt with by > making this information available in a pubsub-like manner (I sensed > the collective shudder from some of our server developers and > operators before I even typed that sentence (-: ). > > However, that trust doesn't carry over to the answer for > "other.domain --> contact@other.domain" which users will want so > very, very desperately. > > I don't necessarily have a problem with this as a protocol-level > diagnostic tool; it can help users (or rather, the developers of > the client the user interacts with) and admins to troubleshoot. > But the potential of abuse and over-interpretation is extremely > high. Yes, that is true, and I too don't want people to read more into the results than is justified. I will keep that very much in mind as I work on the next revision. 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/ iQIcBAEBAgAGBQJRuf7mAAoJEOoGpJErxa2paL8P/1y9L4T1kmKoW5V1BXkK/gfK 3nUX3pQnbDm++KTKjhjOBmaVuj1TKIK4G2IzHRHt63fPBS9pPFoIQ7DLC+35DN7g qZ1yVekBnxMDwQ1shrHriNJCeCLp7fJ/IWCTb076ItEJvRE2w/OYCwDiNlL6rYky MQv3iDzBl8WqeqnwGypt8yLmbHKaPnMdHjmyVUq0QlZytAcDsOjtRl5ERi3Q5b8N JF+LKjTBjbvrNJsRbFTG/AFiNAJ9BiqJBVdcMNIRI8Z8gC1fLDpzS73WKm8JiJ6x /lMfhGS+0xOGzvIzT0AVsls1OZWBN/WqGPJWScEn5ptRKU9mMiU2FcyKgKH0WDN+ ZAD6MvOeiFjVZEv2mX2WYQUbvoQTT6JSS/c2Ld0d1nz+s+vHV2b9UM43DdgeWaH6 dP3z4uCWdMrph8aLmiljSsjGYFC0CLvexoH1BRr0hX6uV3xadLm/SixhBxlB2k+B 31EsjUSJZOd8TX3C83lWPL2x5d36E/xd39GPNDkL1bjtOtgecWl4OqC5NkBdh+eL MkLDaQkQTkKJWuB4Vh6NNNB0czVbkaxafzX3FxeanwfsOQ62yYDN6RaRLu5osJaX cLDsdgxBOYnFcmMFRsM+PzVau8iwk54TelK8vzERY5lu5vAy3+n7blKGfTNUxf+D Cgz2kPtcq6Edia7MhxXx =ujCZ -END PGP SIGNATURE-
Re: [Standards] resurrecting Hop Check (XEP-0219)
On Jun 12, 2013, at 8:41 PM, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 6/6/13 6:40 AM, Matthew Wild wrote: >> 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. > > What I'd like is to know whether the connection from my personal IM > server (stpeter.im) or my company's IM server (say, cisco.com) to a > random server like prosody.im or jabber.ietf.org is encrypted. Sure, > malicious entities can lie, but I try not to create accounts or > authenticate with malicious servers. :-) Look, I need to have *some* > level of trust in the server I authenticate with. I just want to know > if the path from there to the next server is encrypted, too. If I'm a > server admin presumably I have some kind of server-side tool I can > use, but that's not the case if I'm not an admin. I don't disagree that the user is trusting their server by logging in. And if this check were to stop at "my.domain --> other.domain", then I can see some confidence in the results because of the trust. Changes in the state *could* be dealt with by making this information available in a pubsub-like manner (I sensed the collective shudder from some of our server developers and operators before I even typed that sentence (-: ). However, that trust doesn't carry over to the answer for "other.domain --> contact@other.domain" which users will want so very, very desperately. I don't necessarily have a problem with this as a protocol-level diagnostic tool; it can help users (or rather, the developers of the client the user interacts with) and admins to troubleshoot. But the potential of abuse and over-interpretation is extremely high. - m&m Matthew A. Miller < http://goo.gl/LK55L > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] resurrecting Hop Check (XEP-0219)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/6/13 6:40 AM, Matthew Wild wrote: > 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. What I'd like is to know whether the connection from my personal IM server (stpeter.im) or my company's IM server (say, cisco.com) to a random server like prosody.im or jabber.ietf.org is encrypted. Sure, malicious entities can lie, but I try not to create accounts or authenticate with malicious servers. :-) Look, I need to have *some* level of trust in the server I authenticate with. I just want to know if the path from there to the next server is encrypted, too. If I'm a server admin presumably I have some kind of server-side tool I can use, but that's not the case if I'm not an admin. 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/ iQIcBAEBAgAGBQJRuTFNAAoJEOoGpJErxa2pPXAP/1/q/PUY3k+xBxAgXRSlsbEt OHIcyX1NpFwePrRdKWrG50688MEO6+k5gYO4LCDmyxRmzkYES67gqQNxShpnDa2c +9T5ZUPSC95qTyN6PjfUlvGP8NXlqA8AGhx3oRBu0pnZYW33AnVh7WBoUuwOuG95 JqBLqPPP0D+7jsWbbiyVGQIye7vnQP4i+LRG/RpX/E3AXZbV2UIqAl/SuIaUWV6j i8wRBoXqga3ZmbOP17rmVDdTAqcWNGf8nhaTatfMqQI1oFkdAHWpvVJUam3p2NTk nhh4hy/raPSZQKOuaThoXCwdPc3M8R+/HtFHJwm60DUpeloJwW/vbxP0csx8Pyhl qESKMwy0x8jX2WAtSSa6vJO/GPm/kyrdaOzq+P31A0gzhn6wS2/mulUhk+fVtITD LIgAf02NM/6XQ8Bvclih2q/lO7TKqeHlbnhu6OZ0oGoht9cY3SNPswxig3gGQXVH PuViAPId2HvXTWQbqbBwx9HgSiEyJvmbJbbQ86CZUSOye2eJUvuXRVJciNDuyHZP utgEAKy7G+KXhi9RCz4s+so6yGnlOrRkVJtNky/gwaC5RKfZiHYlG7joLW7CMLMY FViPevdF8Aspz1kdz3N1dBKWD3BVDShNO64i2zwSXkqz9MvZjfMRB78c0FrAA3wa Gxgcl4tM5ECqIAeByI9Z =YoPO -END PGP SIGNATURE-
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-
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.
Re: [Standards] resurrecting Hop Check (XEP-0219)
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 [...] 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 ;-)
