Re: [cryptography] PKI - and the threat model is ...?
On 12/09/11 19:12, Marsh Ray wrote: On 09/12/2011 01:45 PM, M.R. wrote: The system is not expected to protect individual liberty, life or limb, nor is it expected to protect high-value monetary transactions, intellectual property assets, state secrets or critical civic infrastructure operations. It never was, and yet, it is asked to do that routinely today. let's take just one of the above as an example: high-value monetary transactions - the only item in the list that I am somewhat familiar with. I can not think of a single scenario where the two parties that do that, prefer a trust chain that includes a third party for introduction and identity vouching instead of the out-of-channel shared secret or key fingerprint exchange. However, secure mass retail system is pretty well impossible without such trusted third party. This is why the threat model *must* define the profile of communicating parties and the value of transactions. If it does not, it will be so general that it will, with the current state of technology and environment, leave the designer/builder with no option but to create an inadequate system. If the threat model defines it, there must be something that ensures the system use does not spill outside of the model definition. There are, for most systems, two primary methods for this: rules enforcement and user education. When there is no owner around or the owner has no ability to effectively enforce the rules, the education must pick up the slack. Mark R. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI - and the threat model is ...?
| | let's take just one of the above as an example: high-value monetary | transactions - the only item in the list that I am somewhat familiar | with. | | I can not think of a single scenario where the two parties that do | that, prefer a trust chain that includes a third party for introduction | and identity vouching instead of the out-of-channel shared secret | or key fingerprint exchange. However, secure mass retail system is | pretty well impossible without such trusted third party. | Premise: The higher the value of the transaction, the less likely it is done between parties that do not already know each other. Consequent: The market opportunity is in protecting 1,000,000 x $10 transactions, not protecting 10 x $1,000,000 transactions. Complicating Factor: The fully automated opponent sees those two multiplications as equal. --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI - and the threat model is ...?
On Tue, Sep 13, 2011 at 12:36 PM, d...@geer.org wrote: | | let's take just one of the above as an example: high-value monetary | transactions - the only item in the list that I am somewhat familiar | with. | | I can not think of a single scenario where the two parties that do | that, prefer a trust chain that includes a third party for introduction | and identity vouching instead of the out-of-channel shared secret | or key fingerprint exchange. However, secure mass retail system is | pretty well impossible without such trusted third party. | Premise: The higher the value of the transaction, the less likely it is done between parties that do not already know each other. Consequent: The market opportunity is in protecting 1,000,000 x $10 transactions, not protecting 10 x $1,000,000 transactions. Complicating Factor: The fully automated opponent sees those two multiplications as equal. ? Presumably the point of this observation is that the two kinds of transaction should use different protection (or at least, key distribution) mechanisms and so the opponent should not see them as equal. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
-- On 2011-09-11 4:09 PM, Jon Callas wrote: The bottom line is that there are places that continuity works well -- phone calls are actually a good one. There are places it doesn't. The SSL problem that Lucky has talked about so well is a place where it doesn't. Amazon can't use continuity. It is both inconvenient and insecure. Most people who login to Amazon have a long existing relationship: Hence key continuity and SRP would work well. Those few people who login for the first time generally get there by typing a search string into their browser. This is reliable because DNS and routing are not the low hanging fruit. When and if we fix other problems, and they become the low hanging fruit, then yurls will solve that problem. You say that authorities are inevitable and emergent. What is a yurl, but everyone his own authority? On the other hand, a couple browsers (I'm looking at you, Firefox and especially you, Chrome) have gotten utterly stupid about self-signed certificates. I have a NAS box in my house that has a web management console, and spins its own self-signed certificates for SSL. When I attach to it, Chrome puts up a special page with danger icons and a blood-red background and it says, ZOMG! This is self-signed and if you proceed, BABIES WILL DIE! After proceeding, there's a blood-red X through the lock and blood-red strike-through on the https part of the URL. Give. Me. An. Effing. Break. Undue CA influence. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On Mon, Sep 12, 2011 at 5:48 PM, James A. Donald jam...@echeque.com wrote: -- On 2011-09-11 4:09 PM, Jon Callas wrote: The bottom line is that there are places that continuity works well -- phone calls are actually a good one. There are places it doesn't. The SSL problem that Lucky has talked about so well is a place where it doesn't. Amazon can't use continuity. It is both inconvenient and insecure. Most people who login to Amazon have a long existing relationship: Hence key continuity and SRP would work well. I can't help but feel that Thomas Wu's SRP (or other PAKEs) would have helped the folks in Iran. A process which only requires two parties (Google and the individual) had three parties, one of whom failed spectacularly. Not only do the additional parties add undue exposure (as used by hackers on this occasion), its also an additional party which can be strong armed by the US government with gestapo legislation such as the PATRIOT Act (for those who take offense, insert your favorite unkind government). Considering how frequently corporate america complies with law enforcement requests (*not* court orders), removing unneeded parties would certainly reduce or restrict privacy threats since the US government and corporate america have a chronic, progressive history of violations. Those few people who login for the first time generally get there by typing a search string into their browser. This is reliable because DNS and routing are not the low hanging fruit. When and if we fix other problems, and they become the low hanging fruit, then yurls will solve that problem. I look at it as a necessary evil - the relationship must be established somehow. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On 13/09/2011, at 23:57, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Sep 12, 2011 at 5:48 PM, James A. Donald jam...@echeque.com wrote: -- On 2011-09-11 4:09 PM, Jon Callas wrote: The bottom line is that there are places that continuity works well -- phone calls are actually a good one. There are places it doesn't. The SSL problem that Lucky has talked about so well is a place where it doesn't. Amazon can't use continuity. It is both inconvenient and insecure. Most people who login to Amazon have a long existing relationship: Hence key continuity and SRP would work well. I can't help but feel that Thomas Wu's SRP (or other PAKEs) would have helped the folks in Iran. A process which only requires two parties (Google and the individual) had three parties, one of whom failed spectacularly. It's possibly worth remembering that in 1994, PKI assumptions looked better. There were no natural authorities or TTPs on the net. The closest we got was Netscape, yahoo, network solutions and Postel. For various reason, nobody saw these players in the way that we now see the players. Now we have search engines, amazon, eBay, Microsoft, apple, competitive registries, wikipedia, cacert, eff, Mozilla, ... And that's before we get to Facebook and hundreds of social networks. The map has changed, it's chock full of natural parties of trust. Iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On Sep 12, 2011, at 5:48 00PM, James A. Donald wrote: -- On 2011-09-11 4:09 PM, Jon Callas wrote: The bottom line is that there are places that continuity works well -- phone calls are actually a good one. There are places it doesn't. The SSL problem that Lucky has talked about so well is a place where it doesn't. Amazon can't use continuity. It is both inconvenient and insecure. Most people who login to Amazon have a long existing relationship: Hence key continuity and SRP would work well. The problem with key continuity (and I alluded to this the other day) is the tendency of people to just click OK to error boxes. From the perspective of many people, the choice is the inability to visit, say, Amazon, and clicking OK to an error message they find to be quite incomprehensible. Furthermore, they're probably right; most of the certificate errors I've seen over the years were from ordinary carelessness or errors, rather than an attack; clicking OK is *precisely* the right thing to do. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On Tue, Sep 13, 2011 at 10:48 AM, Steven Bellovin s...@cs.columbia.edu wrote: Furthermore, they're probably right; most of the certificate errors I've seen over the years were from ordinary carelessness or errors, rather than an attack; clicking OK is *precisely* the right thing to do. Is anyone aware of any up-to-date data on this btw? I've had discussions with the browser makers and they have some data, but I wonder whether anyone else has any data at scale of how often users really do run into cert warnings these days. They used to be quite common, but other than 1 or 2 sites I visit regularly that I know ave self-signed certs, I *never* run into cert warnings anymore. BTW, I'm excluding mixed content warnings from this for the moment because they are a different but related issue. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
Andy Steingruebl writes: They used to be quite common, but other than 1 or 2 sites I visit regularly that I know ave self-signed certs, I *never* run into cert warnings anymore. BTW, I'm excluding mixed content warnings from this for the moment because they are a different but related issue. I see it about once per week, but not in the course of my own browsing -- in the course of following up on HTTPS Everywhere bug reports where sites used to have a valid cert (perhaps on an HTTPS site that they didn't actively promote) and then stopped. An example from yesterday was https://www.senate.gov/ which had a valid cert a while ago and then recently stopped. (Their HTTPS support was reported to us as working on June 29; according to Perspectives, the most recent change apparently happened on September 9.) HTTPS Everywhere makes users encounter this situation more than they otherwise might. -- Seth Schoen sch...@eff.org Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On Sep 13, 2011, at 2:22 28PM, Andy Steingruebl wrote: On Tue, Sep 13, 2011 at 10:48 AM, Steven Bellovin s...@cs.columbia.edu wrote: Furthermore, they're probably right; most of the certificate errors I've seen over the years were from ordinary carelessness or errors, rather than an attack; clicking OK is *precisely* the right thing to do. Is anyone aware of any up-to-date data on this btw? I've had discussions with the browser makers and they have some data, but I wonder whether anyone else has any data at scale of how often users really do run into cert warnings these days. They used to be quite common, but other than 1 or 2 sites I visit regularly that I know ave self-signed certs, I *never* run into cert warnings anymore. BTW, I'm excluding mixed content warnings from this for the moment because they are a different but related issue. From personal experience -- I use https to read news.google.com; Firefox 6 on a Mac complains about wildcard certificates. And ietf.org's certificate expired recently; it took a day or so to get a new one installed. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On Sep 13, 2011, at 11:57 AM, Steven Bellovin wrote: From personal experience -- I use https to read news.google.com; Firefox 6 on a Mac complains about wildcard certificates. And ietf.org's certificate expired recently; it took a day or so to get a new one installed. This last bit might be relevant to the mailing list. - The IETF's cert was for *.ietf.org - It took a week, not a day or so to get the new one installed Steve: I wonder if your browser, after you dismissed the dialog once, silently remembered that dismissal for a week, or if it stopped asking you after a day. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On 09/13/2011 01:31 PM, Seth David Schoen wrote: An example from yesterday was https://www.senate.gov/ which had a valid cert a while ago and then recently stopped. (Their HTTPS support was reported to us as working on June 29; according to Perspectives, the most recent change apparently happened on September 9.) They got hacked by LulzSec back in June, their web software was ancient like a time capsule. IIRC, there were a lot of subject-alt names on that shared-IP certificate. No doubt the private key was compromised. It probably took this long to reissue and re-deploy all the sites. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On Sep 13, 2011, at 3:00 32PM, Paul Hoffman wrote: On Sep 13, 2011, at 11:57 AM, Steven Bellovin wrote: From personal experience -- I use https to read news.google.com; Firefox 6 on a Mac complains about wildcard certificates. And ietf.org's certificate expired recently; it took a day or so to get a new one installed. This last bit might be relevant to the mailing list. - The IETF's cert was for *.ietf.org - It took a week, not a day or so to get the new one installed Steve: I wonder if your browser, after you dismissed the dialog once, silently remembered that dismissal for a week, or if it stopped asking you after a day. Neither -- I relied on my mailing list archives for the interval, and didn't scroll back far enough... --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
Hi, Is anyone aware of any up-to-date data on this btw? I've had discussions with the browser makers and they have some data, but I wonder whether anyone else has any data at scale of how often users really do run into cert warnings these days. They used to be quite common, but other than 1 or 2 sites I visit regularly that I know ave self-signed certs, I *never* run into cert warnings anymore. BTW, I'm excluding mixed content warnings from this for the moment because they are a different but related issue. I run into it quite regularly, often on sites of non-commercial organisations. Like universities. My favourite page so far said Please ignore the warning that will appear when you click next (that was FU Hagen, I believe). That said, I can see in our monitoring data that about 20-60% of certification chains are broken, and these are sites that people do access (it is passive monitoring data from a large regional ISP). In our scanning data, we find that only about 18% of certificates have both a valid chain plus the correct hostname (wildcarded or not) in their CNs or SANs. Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
From: Seth David Schoen sch...@eff.org To: Crypto discussion list cryptography@randombit.net Sent: Tuesday, September 13, 2011 2:31:59 PM Subject: Re: [cryptography] Let's go back to the beginning on this HTTPS Everywhere makes users encounter this situation more than they otherwise might. A week or three ago, I got cert warnings - from gmail's page. (Yes, I'm using HTTPS Everywhere). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
Randall Webmail writes: From: Seth David Schoen sch...@eff.org To: Crypto discussion list cryptography@randombit.net Sent: Tuesday, September 13, 2011 2:31:59 PM Subject: Re: [cryptography] Let's go back to the beginning on this HTTPS Everywhere makes users encounter this situation more than they otherwise might. A week or three ago, I got cert warnings - from gmail's page. (Yes, I'm using HTTPS Everywhere). When _that_ happens, please tell Google and EFF. I'm sure both organizations would be fascinated. -- Seth Schoen sch...@eff.org Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
Hi, Interesting. Are you pulling the server-certs out of the SSL handshake and then checking if they validate against any browser store? Yes, with the second operation offline and validating against the NSS root store. I don't have a MS one at the moment, it would be interesting (how do you extract that from Win? The EFF guys should know) (Here's a privacy disclaimer, though: only statistics leave our monitor, no certs, no connection data, etc.) In our scanning data, we find that only about 18% of certificates have both a valid chain plus the correct hostname (wildcarded or not) in their CNs or SANs. This data, while interesting, doesn't tell us much about how often users encounter those sites. I much prefer data instrumented from actual web browsers, or network traffic. Well, yes, but it is the Alexa Top 1 million list that is scanned. I can give you a few numbers for the Top 1K or so, too, but it does remain a relative popularity. Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
Hi, HTTPS Everywhere makes users encounter this situation more than they otherwise might. A week or three ago, I got cert warnings - from gmail's page. (Yes, I'm using HTTPS Everywhere). When _that_ happens, please tell Google and EFF. I'm sure both organizations would be fascinated. I would also be very interested to hear from where that happened, and if you can give us a traceroute... Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] MD5 in MACs in SSL
Hi, I'm wondering about the use of MD5 in SSL MACs. We see that quite often here. What is your take on it? Given that SSL includes replay protection for its session keys, it does not seem to give an attacker any useful time window, but am I missing something maybe? Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On Tue, Sep 13, 2011 at 4:09 PM, Ralph Holz h...@net.in.tum.de wrote: Well, yes, but it is the Alexa Top 1 million list that is scanned. I can give you a few numbers for the Top 1K or so, too, but it does remain a relative popularity. How many of those sites ever advertise an HTTPS end-point though? Maybe users are extremely unlikely to ever see a link, etc. that points to their HTTPS endpoint. - Andy ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
From: Ralph Holz h...@net.in.tum.de To: Crypto discussion list cryptography@randombit.net Sent: Tuesday, September 13, 2011 7:14:39 PM Subject: Re: [cryptography] Let's go back to the beginning on this Hi, HTTPS Everywhere makes users encounter this situation more than they otherwise might. A week or three ago, I got cert warnings - from gmail's page. (Yes, I'm using HTTPS Everywhere). When _that_ happens, please tell Google and EFF. I'm sure both organizations would be fascinated. I would also be very interested to hear from where that happened, and if you can give us a traceroute... You mean it wasn't a good idea to just click cancel to make the warning go away? (Of course it wasn't - but ...) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
Ralph Holz writes: Yes, with the second operation offline and validating against the NSS root store. I don't have a MS one at the moment, it would be interesting (how do you extract that from Win? The EFF guys should know) You might look at https://www.eff.org/files/ssl-observatory-code-r1.tar_.bz2 in the microsoft_CAs directory. You can also look at https://social.technet.microsoft.com/wiki/contents/articles/microsoft-root-certificate-program.aspx which used to provide a PDF, but apparently now links to https://social.technet.microsoft.com/wiki/contents/articles/2592.aspx instead (not updated to reflect DigiNotar's removal). One issue is that Microsoft has a protocol for MSIE to ask Microsoft interactively whether to trust a new CA. That means that the list of trusted CAs is not actually stored on an MSIE end-user's machine and can't be displayed in full inside of MSIE. Instead, when a new CA is encountered, MSIE will query Microsoft and ask whether that CA should be trusted. Personally, I find this indeterminism and delegation concerning (since there's no way for users to review CAs ahead of time, or see whether a particular CA will or won't be trusted ahead of time). On the other hand, a similar phenomenon occurs in other browsers with regard to intermediate CAs, because there's no way to get a list of intermediate CAs before they are encountered in the wild, and definitely no way to get an exhaustive list of all of the intermediate CAs that would be trusted. In fact, in some sense no one in the entire world is in possession of that list. :-( Peter Eckersley has produced a list of intermediates which you can see visualized in https://www.eff.org/files/colour_map_of_CAs.pdf but of course that list derives from a scan from a particular point in time (and not using SNI); there is no guarantee that there aren't other intermediate CAs which simply weren't encountered that way (or even intermediate CAs whose existence is kept a secret and that are only used in a limited way by particular attackers under particular circumstances). -- Seth Schoen sch...@eff.org Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On 9/13/2011 4:44 PM, Seth David Schoen wrote: On the other hand, a similar phenomenon occurs in other browsers with regard to intermediate CAs, because there's no way to get a list of intermediate CAs before they are encountered in the wild, and definitely no way to get an exhaustive list of all of the intermediate CAs that would be trusted. I'm not sure I understand why it would be helpful to know all (or any) intermediate CA ahead of time. If you trust the self-signed Root CA, then, by definition, you've decided to trust everything that CA (and subordinate CA) issues, with the exception of revoked certificates. Can you please elaborate? Thanks. Arshad Noor StrongAuth, Inc. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MD5 in MACs in SSL
On 13-09-2011 16:16, Ralph Holz wrote: Hi, I'm wondering about the use of MD5 in SSL MACs. We see that quite often here. What is your take on it? Given that SSL includes replay protection for its session keys, it does not seem to give an attacker any useful time window, but am I missing something maybe? Ralph MACs (read: HMAC) tend to rely on the hash function's second preimage resistance; collision resistance is not a very big deal. MD5 should be fine, although not recommended. Samuel Neves ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On 2011-09-14 4:31 AM, Seth David Schoen wrote: https://www.senate.gov/ which had a valid cert a while ago and then recently stopped. A system that gives false negatives is worthless. It has to be sufficiently reliable that it makes sense to deny access. Of course, a system where one has to interact with a third party to be certified will always give frequent false negatives, requiring the option to click through, and thus training users to click OK on sight. Skype also gives you the option when a stranger you have never interacted with before wants to talk to you, but in the skype case, the criterion is sufficiently reliable that users get trained to click deny on sight. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
