Re: [jdev] manifesto DANE does not cut it
Hi Tony, DNSSEC is a step into the right direction. I do not dispute that and salute the jabber community for recognizing this. DNSSEC reduces the risk of an active attack. DNSSEC does not eliminate that risk. On the client/user side this is not sufficient. DNSSEC wont give the user the security that he believes he is getting. (During the 2011-revolutions wrongly understood Internet security got people arrested, tortured or worse). Let me elaborate a bit further here why this is so important. Let me quote from The Universal Declaration of Human Rights: DNSSEC does not change this. Only DNSSEC and pinning does. And in fact pinning alone I've drawn up example scenarios over and over. On Mon, Nov 18, 2013 at 3:39 PM, Tony Finch d...@dotat.at wrote: Ralf Skyper Kaiser sky...@thc.org wrote: The user has to trust ALL keys and not just the single ROOT KEY. That's true, but the amount of trust you have to put in high-level DNSSEC keys is relatively limited. DNSSEC is aware of zone cuts, and high-level keys cannot authenticate domain names below a zone cut. The DNS also caches a lot, so if an attacker tries to redirect part of the namespace without obtaining the corresponding private keys, they will cause suspicious validation failures at sites where the proper public keys were cached. It would be nice to have something better than DNSSEC, but at least it has a safer structure than X.509. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___ ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
Hi Tony, DNSSEC is a step into the right direction. I do not dispute that and salute the jabber community for recognizing this. DNSSEC reduces the risk of an active attack. DNSSEC does not eliminate that risk. DNSSEC in fact only marginally reduces this risk considering the real-world attacks that happened since 2011. On the client/user side this is not sufficient. DNSSEC wont give the user the security that he believes he is getting. (During the 2011-revolutions wrongly understood Internet security got people arrested, tortured or worse). Let me elaborate a bit further here why this is so important. Let me quote from The Universal Declaration of Human Rights: Whereas disregard and contempt for human rights have resulted in barbarous acts which have outraged the conscience of mankind, and the advent of a world in which human beings shall enjoy freedom of speech and belief and freedom from fear and want has been proclaimed as the highest aspiration of the common people, It is so important that it is not mentioned somewhere random but in the Preamble itself. It is the second sentence. Jabber with DNSSEC requires the user to trust the ROOT (domain name .). This ROOT KEY is ultimately controlled by an entity which is geopolitically aligned with US policy (and therefor US government). Let's assume that everybody in the US trusts the US government (quite an assumption in a Post-PRISM world). Even then would this be less than 5% of the world population. And with DNSSEC it gets worse. A user in country .XX connecting to a jabber-server.XX has to trust . _and_ .XX. Trusting your own government (which ultimately controls the .XX zone in many countries) is the problem, not the solution. Peter, I hope you understand how important this is and I kindly ask you to include cert-pinning in your manifesto. regards, Ralf On Mon, Nov 18, 2013 at 3:39 PM, Tony Finch d...@dotat.at wrote: Ralf Skyper Kaiser sky...@thc.org wrote: The user has to trust ALL keys and not just the single ROOT KEY. That's true, but the amount of trust you have to put in high-level DNSSEC keys is relatively limited. DNSSEC is aware of zone cuts, and high-level keys cannot authenticate domain names below a zone cut. The DNS also caches a lot, so if an attacker tries to redirect part of the namespace without obtaining the corresponding private keys, they will cause suspicious validation failures at sites where the proper public keys were cached. It would be nice to have something better than DNSSEC, but at least it has a safer structure than X.509. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___ ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
I don't think anyone here is advocating for downgrading security or not respecing human rights. I do think that we're being pretty sanguine about not letting the perfect become the enemy of the good and incrementally upgrading XMPP's security. Good security is based on layering trust and trust points being open to inspection. DNS is about as open as you can get and comes with a pretty good api. I'd expect that services like the SSL Observatory start offering a service that inspects DNSSEC records. And publish any oddities. Regarding having to trust the owner of . changing keys, presumably pinning the root key would mean that you would notice it changing? DNSSEC would let you could pin any other keys in your app and notice them changing. Nevertheless, Tony makes a good point: a cut in the namespace would be pretty obvious to all. S. On 19 November 2013 12:16, Ralf Skyper Kaiser sky...@thc.org wrote: Hi Tony, DNSSEC is a step into the right direction. I do not dispute that and salute the jabber community for recognizing this. DNSSEC reduces the risk of an active attack. DNSSEC does not eliminate that risk. DNSSEC in fact only marginally reduces this risk considering the real-world attacks that happened since 2011. On the client/user side this is not sufficient. DNSSEC wont give the user the security that he believes he is getting. (During the 2011-revolutions wrongly understood Internet security got people arrested, tortured or worse). Let me elaborate a bit further here why this is so important. Let me quote from The Universal Declaration of Human Rights: Whereas disregard and contempt for human rights have resulted in barbarous acts which have outraged the conscience of mankind, and the advent of a world in which human beings shall enjoy freedom of speech and belief and freedom from fear and want has been proclaimed as the highest aspiration of the common people, It is so important that it is not mentioned somewhere random but in the Preamble itself. It is the second sentence. Jabber with DNSSEC requires the user to trust the ROOT (domain name .). This ROOT KEY is ultimately controlled by an entity which is geopolitically aligned with US policy (and therefor US government). Let's assume that everybody in the US trusts the US government (quite an assumption in a Post-PRISM world). Even then would this be less than 5% of the world population. And with DNSSEC it gets worse. A user in country .XX connecting to a jabber-server.XX has to trust . _and_ .XX. Trusting your own government (which ultimately controls the .XX zone in many countries) is the problem, not the solution. Peter, I hope you understand how important this is and I kindly ask you to include cert-pinning in your manifesto. regards, Ralf On Mon, Nov 18, 2013 at 3:39 PM, Tony Finch d...@dotat.at wrote: Ralf Skyper Kaiser sky...@thc.org wrote: The user has to trust ALL keys and not just the single ROOT KEY. That's true, but the amount of trust you have to put in high-level DNSSEC keys is relatively limited. DNSSEC is aware of zone cuts, and high-level keys cannot authenticate domain names below a zone cut. The DNS also caches a lot, so if an attacker tries to redirect part of the namespace without obtaining the corresponding private keys, they will cause suspicious validation failures at sites where the proper public keys were cached. It would be nice to have something better than DNSSEC, but at least it has a safer structure than X.509. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___ ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___ -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
On 19 Nov 2013, at 11:58, Ralf Skyper Kaiser sky...@thc.org wrote: This attack and vulnerability in the TLS authentication has been recognized by all major browser manufactures. Pinning (on top of DNSSEC) is being implemented as we speak. Why jabber tries so hard of being less secure than the web browser is a mystery to me. I guess one of the issues is that XMPP, being federated, is far more complicated than the straightforward client-server of the web. I’m far from an expert on these things but some kind of certificate pinning would require some extra xmpp protocol would it not? Plain DNSSEC and DANE could be implemented today though so my view would be let’s make sure we’re using the best we can do today in imlement the silver standard, and then have a really good discussion about how to implement the gold standard (potentially certificate pinning, but even this has drawbacks). For users that absolutely require secrecy then they can still use e2e encryption today. Let’s implement what we already have standards for today as a good start, and then, once that’s implemented, we can look at the gold standard. Otherwise we risk delaying for no really good reason. — Ash smime.p7s Description: S/MIME cryptographic signature ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
Hi On Tue, Nov 19, 2013 at 12:26 PM, Ashley Ward ashley.w...@surevine.comwrote: On 19 Nov 2013, at 11:58, Ralf Skyper Kaiser sky...@thc.org wrote: This attack and vulnerability in the TLS authentication has been recognized by all major browser manufactures. Pinning (on top of DNSSEC) is being implemented as we speak. Why jabber tries so hard of being less secure than the web browser is a mystery to me. I guess one of the issues is that XMPP, being federated, is far more complicated than the straightforward client-server of the web. I’m far from an expert on these things but some kind of certificate pinning would require some extra xmpp protocol would it not? Plain DNSSEC and DANE could be implemented today though so my view would be let’s make sure we’re using the best we can do today in imlement the silver standard, and then have a really good discussion about how to implement the gold standard (potentially certificate pinning, but even this has drawbacks). Pinning does not require any protocol change in its simplest form. It can be done with just minor changes on the client side. For users that absolutely require secrecy then they can still use e2e encryption today. Does not help as your entire buddy list and meta data is not protected by OTR or other jabber plugins. Let’s implement what we already have standards for today as a good start, and then, once that’s implemented, we can look at the gold standard. Otherwise we risk delaying for no really good reason. I agree. No single security feature should delay the deployment of other security features. But let's add it to the manifesto so that we have a road-map to work towards. regards, ralf — Ash ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___ ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
On 19 nov. 2013, at 12:58, Ralf Skyper Kaiser sky...@thc.org wrote: Hi On Tue, Nov 19, 2013 at 11:37 AM, Simon Tennant si...@buddycloud.com wrote: I don't think anyone here is advocating for downgrading security or not respecing human rights. I do think that we're being pretty sanguine about not letting the perfect become the enemy of the good and incrementally upgrading XMPP's security. Good security is based on layering trust and trust points being open to inspection. DNS is about as open as you can get and comes with a pretty good api. I'd expect that services like the SSL Observatory start offering a service that inspects DNSSEC records. And publish any oddities. Regarding having to trust the owner of . changing keys, presumably pinning the root key would mean that you would notice it changing? DNSSEC would let you could pin any other keys in your app and notice them changing. Nevertheless, Tony makes a good point: a cut in the namespace would be pretty obvious to all. No it would not. This is the wrong assumption. The ROOT or the TLD KEY can be (ab)used to perform a active attack. Nobody but the targeted user would see the changed public key and then it would vanish. This attack and vulnerability in the TLS authentication has been recognized by all major browser manufactures. Pinning (on top of DNSSEC) is being implemented as we speak. Why jabber tries so hard of being less secure than the web browser is a mystery to me. regards, ralf Hello, I think it is important to make a distinction between suggested key pinning and automatic key pinning. Suggested key pinning is what is proposed in [1] and [2], automatic key pinning is what SSH uses. Automatic key pinning works for SSH, because private keys are rarely changed and people are more tech-savy than average XMPP users. If you start doing this for XMPP, you'll see a lot of false positives. I doubt you can convince a large part of the network to start using self-signed certificates valid for a long time. Every time a user who doesn't understand the security implications removes a pin, the security of the system is weakened because it makes MitM attacks easier. The manifesto requires software to be able to inform users when a certificate changes and I think this is the right approach to automatic pinning. Suggested key pinning would be the server telling the client please verify one of these keys is used on your next connection: xxx, yyy. I'm greatly in favor of this, and for those who might have missed it, I wrote a proposal on how to apply it to XMPP on [3]. But right now this is just a proposal, with no working code to go with it. With the manifesto going in affect on May 19 2014, I think making this a required part of it would be too soon. [1] = https://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 [2] = https://tools.ietf.org/html/draft-perrin-tls-tack-02 [3] = http://mail.jabber.org/pipermail/standards/2013-November/028229.html Regards, Thijs signature.asc Description: Message signed with OpenPGP using GPGMail ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
Hi, On Tue, Nov 19, 2013 at 12:29 PM, Thijs Alkemade th...@xnyhps.nl wrote: On 19 nov. 2013, at 12:58, Ralf Skyper Kaiser sky...@thc.org wrote: Hi On Tue, Nov 19, 2013 at 11:37 AM, Simon Tennant si...@buddycloud.com wrote: Automatic key pinning works for SSH, because private keys are rarely changed and people are more tech-savy than average XMPP users. If you start doing this for XMPP, you'll see a lot of false positives. I doubt you can convince a large part of the network to start using self-signed certificates valid for a long time. Every time a user who doesn't understand the security implications removes a pin, the security of the system is weakened because it makes MitM attacks easier. The manifesto requires software to be able to inform users when a certificate changes and I think this is the right approach to automatic pinning. By 'average XMPP user' you mean 'average XMPP Server admin' I think. The user only sees a new certificate if the admin chooses to create a new key on the same domain name. The average XMPP server admin is tech-savy. I think I would go as far as saying that the average XMPP server admin is more tech-savy than the average apache admin - and apache/web-browsers are going to support pinning soon. There are enough fallbacks to help the tech-unsavy admin if he looses the key and has to create a new key: - Can use a new domain (jabber-1.mydomain.org becomes jabber-2.mydomain.org - Can ask all users to reinstall the jabber client - Can ask all users to manually remove the pinned key from the client - Can use 'reverse fingerprinting' where the user can remove an old pinned key by entering the fingerprint of the new certificate. - Backup Key (requires protocol change?) But right now this is just a proposal, with no working code to go with it. With the manifesto going in affect on May 19 2014, I think making this a required part of it would be too soon. Can we add it as an optional goal for May 19 2014? [1] = https://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 [2] = https://tools.ietf.org/html/draft-perrin-tls-tack-02 [3] = http://mail.jabber.org/pipermail/standards/2013-November/028229.html Thanks for [3]! Regards, Thijs ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___ ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
On 19 nov. 2013, at 14:07, Ralf Skyper Kaiser sky...@thc.org wrote: Hi, On Tue, Nov 19, 2013 at 12:29 PM, Thijs Alkemade th...@xnyhps.nl wrote: On 19 nov. 2013, at 12:58, Ralf Skyper Kaiser sky...@thc.org wrote: Hi On Tue, Nov 19, 2013 at 11:37 AM, Simon Tennant si...@buddycloud.com wrote: Automatic key pinning works for SSH, because private keys are rarely changed and people are more tech-savy than average XMPP users. If you start doing this for XMPP, you'll see a lot of false positives. I doubt you can convince a large part of the network to start using self-signed certificates valid for a long time. Every time a user who doesn't understand the security implications removes a pin, the security of the system is weakened because it makes MitM attacks easier. The manifesto requires software to be able to inform users when a certificate changes and I think this is the right approach to automatic pinning. By 'average XMPP user' you mean 'average XMPP Server admin' I think. The user only sees a new certificate if the admin chooses to create a new key on the same domain name. The average XMPP server admin is tech-savy. I think I would go as far as saying that the average XMPP server admin is more tech-savy than the average apache admin - and apache/web-browsers are going to support pinning soon. No, I mean average XMPP user. I claim that the percentage of SSH users that know what it means to remove a line from ~/.ssh/known_hosts is higher than the percentage of XMPP users that will know what it means to do the equivalent thing in their client. There are enough fallbacks to help the tech-unsavy admin if he looses the key and has to create a new key: - Can use a new domain (jabber-1.mydomain.org becomes jabber-2.mydomain.org This breaks all your presence subscriptions. - Can ask all users to reinstall the jabber client If a server admin would ask me to do this, I’d be looking for a different server. This would make users lose so much other data too, they'd be pissed. - Can ask all users to manually remove the pinned key from the client We should make sure this is needed _very_ rarely. - Can use 'reverse fingerprinting' where the user can remove an old pinned key by entering the fingerprint of the new certificate. How are they going to securely obtain the new fingerprint? - Backup Key (requires protocol change?) Yes, this comes back to the point of the proposed XEP: only pin if the server admin tells you you should pin and when the admin proves they have backup measures set up. :) Regards, Thijs signature.asc Description: Message signed with OpenPGP using GPGMail ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
On 19 Nov 2013, at 12:30, Ralf Skyper Kaiser sky...@thc.org wrote: Pinning does not require any protocol change in its simplest form. It can be done with just minor changes on the client side. Agreed - in its simplest form you could use it on the c2s connection to ensure the server’s certificate hasn’t unexpectedly changed and there’s nothing to stop xmpp clients implementing it. But this is only a small part of it. XMPP is federated, so how does a user ensure that the ongoing s2s connection isn’t compromised? Do you have to rely on your server admin to pin the certificate of every remote server their users might want to talk to? What if a user sends a message to a new server? Do we deny access until the server admin has accepted the certificate? Otherwise should we connect anyway and inform the user somehow that the remote connection can’t be trusted, or do we let them think everything’s fine? And then what about the c2s connection at the other end. How do we know that hasn’t been compromised? There are so many edge cases here that I can’t see how it could be implemented in a cohesive and user friendly manner without some serious thought and protocol involved. I haven’t been following this thread very closely so some of these points may have been discussed already. The fact is that it really isn’t as simple as the web browser case. I’m just wondering whether pinning in its simplest form actually buys very much. The only use case I can currently think of for this simple implementation is for a user in an oppressive regime who wants to use a service located in a safer country and wants to be able to trust their connection to the outside of that regime (i.e. the trusted hop is the one from client to server) but it still requires that the initial connection wasn’t compromised or that they can get the key via other means. I think we also need to be careful not to downplay DNSSEC and DANE too. They are infinitely better than most of what’s happening today, so saying things like DANE does not cut it” could be disingenuous and may deter people from implementing anything because it’s not “perfect”. As Peter said in the manifesto: it’s This commitment to encrypted connections only the first step toward more secure communication using XMPP”. Let’s not try to run before we can walk. — Ash smime.p7s Description: S/MIME cryptographic signature ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
On Tue, Nov 19, 2013 at 2:12 PM, Ashley Ward ashley.w...@surevine.comwrote: On 19 Nov 2013, at 12:30, Ralf Skyper Kaiser sky...@thc.org wrote: Pinning does not require any protocol change in its simplest form. It can be done with just minor changes on the client side. Agreed - in its simplest form you could use it on the c2s connection to ensure the server’s certificate hasn’t unexpectedly changed and there’s nothing to stop xmpp clients implementing it. It would be nice to have this as an optional item in the manifesto (either Pinning-light or full pinning) so that it is on the roadmap. But this is only a small part of it. XMPP is federated, so how does a user ensure that the ongoing s2s connection isn’t compromised? I agree. But just because we do not have a solution for every security problems shall we not stop developing a solution for any security problem. [...] I think we also need to be careful not to downplay DNSSEC and DANE too. They are infinitely better than most of what’s happening today, so saying things like DANE does not cut it” could be disingenuous and may deter people from implementing anything because it’s not “perfect”. I agree. DANE is an important step into the right direction. regards. ralf ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/13 9:21 AM, Ralf Skyper Kaiser wrote: On Tue, Nov 19, 2013 at 2:12 PM, Ashley Ward ashley.w...@surevine.com mailto:ashley.w...@surevine.com wrote: On 19 Nov 2013, at 12:30, Ralf Skyper Kaiser sky...@thc.org mailto:sky...@thc.org wrote: Pinning does not require any protocol change in its simplest form. It can be done with just minor changes on the client side. Agreed - in its simplest form you could use it on the c2s connection to ensure the server?s certificate hasn?t unexpectedly changed and there?s nothing to stop xmpp clients implementing it. It would be nice to have this as an optional item in the manifesto (either Pinning-light or full pinning) so that it is on the roadmap. But this is only a small part of it. XMPP is federated, so how does a user ensure that the ongoing s2s connection isn?t compromised? I agree. But just because we do not have a solution for every security problems shall we not stop developing a solution for any security problem. [...] I think we also need to be careful not to downplay DNSSEC and DANE too. They are infinitely better than most of what?s happening today, so saying things like DANE does not cut it? could be disingenuous and may deter people from implementing anything because it?s not ?perfect?. I agree. DANE is an important step into the right direction. And progress is being made (with many thanks to Thijs for the code running at the IM Observatory!): http://xmpp.net/reports.php#dnssecsrv BTW, I have not read this thread because I am ultra-busy with work at my day job. I hope to catch up later this week. 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/ iQIcBAEBAgAGBQJSi5DdAAoJEOoGpJErxa2pC8MP/1m6i/xojNVy0YEagVtiLLX2 HF23BwoPiN2cqbC4pDPaTAla6wvAR7YHNWyqbIjhjlwu0iOJ1fNNzMRNqM0p8ydM jnKog+X1PcnlZL9/E2mnVibtgHg2s2NqVy75eVzzAlWNShsv5UnUccwiXyi4SilS Gy3F7CtNzg0zljxFKsamaQFSRpdvnGLEPKk1JxkI8ZeB0u4+DnB4ANS5gSWrzNCJ a8r0dRr5AMYIKMGi3dwpwazkbOw7eUxIHTYnQMgNO3m7UOAgBpAh218ffqPAZXti hN6oBR1UikaWTyeAxTtomEDpSgSNiJ9dtfPJLzzCnd1LIrjiNG8ouTRP2kkfmhY7 k6Ol5BtAWJ6fQYGR7RmFdNMfYTp9n7Kfh5kqldNosmAu7Dx7LpbCCQrHNAkV/HPI xI3M2KaaWjeZ6xNX+zLU4VdU/L6afjf7JIgfZT8r+RX8IKNBO04+nU9Xga4ox12b PRPcXuymFn8DZwZz5tqgkfN2PsqM7J2+uKy+GlL3Ft+TGAMGjYSM1p6ZH5TH3QSf wjqbiKlTtGYMHvYUL/kTMwVsyLAPMNawRKL/9a7qsvhqmF5sXR16OPSYS2jFi6Iu bhs0iD7ThGQ4QMoI+wHoao5bymU64R+ajeU6NboobyvM0XktswFnez9z91bxadUp XhD+bq3ZXqjeaftVYKpI =jDK/ -END PGP SIGNATURE- ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
Ralf Skyper Kaiser sky...@thc.org wrote: The user has to trust ALL keys and not just the single ROOT KEY. That's true, but the amount of trust you have to put in high-level DNSSEC keys is relatively limited. DNSSEC is aware of zone cuts, and high-level keys cannot authenticate domain names below a zone cut. The DNS also caches a lot, so if an attacker tries to redirect part of the namespace without obtaining the corresponding private keys, they will cause suspicious validation failures at sites where the proper public keys were cached. It would be nice to have something better than DNSSEC, but at least it has a safer structure than X.509. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
On Thu, Nov 14, 2013 at 6:11 PM, Matt Miller linuxw...@outer-planes.netwrote: On Nov 14, 2013, at 10:43 AM, Ralf Skyper Kaiser sky...@thc.org wrote: On Thu, Nov 14, 2013 at 4:49 PM, Matt Miller linuxw...@outer-planes.net wrote: On Nov 14, 2013, at 9:34 AM, Ralf Skyper Kaiser sky...@thc.org wrote: On Thu, Nov 14, 2013 at 4:24 PM, Dave Cridland d...@cridland.net wrote: On Thu, Nov 14, 2013 at 4:09 PM, Matt Miller linuxw...@outer-planes.net wrote: On Nov 14, 2013, at 8:33 AM, Ralf Skyper Kaiser sky...@thc.org wrote: (In fact it's not just the root key that the user/admin has to trust but all keys up to his subdomain). No, it's really just the root key everyone places trust in; each other key is signed by the next key up in the chain. No. The user has to trust ALL keys and not just the single ROOT KEY. The user has to trust: 1. The key was generated securely (enough bits, good primes, ...) 2. A good RNG was used (hi debian! Thanks for a bad RNG). 3. The key is not leaked (on purpose) by _any_ of the admins in the domain chain 4. The key is stored securely and not stolen 5 . ...This list is incomplete...and goes on and on. Maybe this example gives a better idea: User in Iran. Jabber admin sets up a jabber server at myjabberserver.my-university.ir. The user has to trust ROOT (domain .). ROOT is ultimately geopolitically aligned with the US. The user has to trust .IR. That's ultimately the Iranian government. The user has to trust MY-UNIVERSITY.IR (which is ultimately aligned with Mr. Khomeini) The user has to trust MYJABBERSERVER.my-university.ir which is the actual jabber server admin. SARCASM That really sounds like a great idea! Unless of course 1. You are a gay person in Iran 2. An Atheist in Saudi Arabia (or a women) 3. Leonardo da Vinci and dare to suggest that the earth is round 4. A black person wishing to sit in the front row of a bus 5 ... /SARCASM DANE does not protect any of the above people. DANE just does not cut it. Not in a Post-Prism world. Certificate Pinning does. regards, ralf ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
On 15-11-13 10:30, Ralf Skyper Kaiser wrote: Hi, 1. You are a gay person in Iran 2. An Atheist in Saudi Arabia (or a women) 3. Leonardo da Vinci and dare to suggest that the earth is round 4. A black person wishing to sit in the front row of a bus 5 ... One of the lessons from Snowden is that evil empires in whatever form, tend to route around strong encryption. To achieve their goals, they will compromise around the strong security measures and use easier attack vectors. And if any digital measures fail, then a good beating up will be next. And exactly that beating up is already commonplace in any of the situations you mention anyway, except of course for the third: we have no records on Leonardo da Vinci being beaten up for having suggested the earth is round, not in the most because he was not openly participating in that discussion. Neither do we have any records on Galileo Galilei being beaten up for his suggestions, though he did get into trouble for it. But even certificate pinning would not have helped him there. The political problems you mention can only be solved on a political level, not by technology. Still, as developers on this list, we should do our best to protect our users against eavesdropping technology (regardless of the politics behind it). We do that best by accepting the fact that any technology has flaws, by recognizing those flaws and work from there on improvement. Shouting everything but one solution is unsafe and deny the flaws of that one solution won't help us to protect our users. Winfried ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto DANE does not cut it
Hi, Definition: - POST-Prism means the time after PRISM. What we know now. It does not imply that PRISM ever carried out a DNSSEC or DNS attack. Sorry if this was not clear. - Khomeini: Sorry, you are right. He is dead. Use Khamenei. Sorry for the typo. Makes zero difference. Let's stay technical. On Fri, Nov 15, 2013 at 10:30 AM, Dave Cridland d...@cridland.net wrote: On Fri, Nov 15, 2013 at 9:30 AM, Ralf Skyper Kaiser sky...@thc.orgwrote: No. The user has to trust ALL keys and not just the single ROOT KEY. The user has to trust: 1. The key was generated securely (enough bits, good primes, ...) 2. A good RNG was used (hi debian! Thanks for a bad RNG). 3. The key is not leaked (on purpose) by _any_ of the admins in the domain chain 4. The key is stored securely and not stolen 5 . ...This list is incomplete...and goes on and on. Excellent... So we'll run through a first-time connect without DANE, and with just pinning. [...] OK. Small note there, actually. You also have to trust any authority over your IP connectivity at this point, plus spoofing DNS is relatively easy without DNSSEC, so you're basically trusting *everyone*. Which just makes you a nice guy, right? Can I borrow €1,000? Assuming the DNS was used then the user could be tricked in connecting to the wrong IP address of the jabber server. Yet the security is not compromised because the TLS connection will fail (assuming the certificate is pinned). The attacker can prevent the user from connecting to the jabber server but the attacker can not read the data/chat/messages of the user. What we should focus on is that the data/chat/messages stay confidential. Pinning does this. The pinning (without DNSSEC) is open to attack on the first connect. SSH is vulnerable the same way. SSH works on the same model (pinning). See my other email why the 'first connect' scenario is not practical for an attacker. (and if you want to fix this then you can use DNSSEC with PINNING). On the other hand just using DNSSEC requires the user to trust at least 3 different keys from 3 different entities that have 3 totally different geopolitical interests. What can possible go wrong... SARCASM That really sounds like a great idea! Unless of course 1. You are a gay person in Iran 2. An Atheist in Saudi Arabia (or a women) 3. Leonardo da Vinci and dare to suggest that the earth is round 4. A black person wishing to sit in the front row of a bus 5 ... /SARCASM Typically, sarcasm is used to posit something that is clearly the opposite of what you intend, by the way. Aside from That really sounds like a great idea, I'll assume that the remainder of the argument you state above is, you believe, valid. Sorry if this was not obvious. DANE does not protect any of the above people. regards, ralf ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
