Re: [therightkey] Barely-capable CAs
Stephen Farrell wrote: On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: Having worked in Web security over 20 years now, I have still to see a case where a system was breached because of a really subtle design flaw. Bleichenbacher? Debian OpenSSL CPRNG goof? -Martin ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
This is about barely capable sysadmins. Different problem. On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Nov 1, 2012, at 2:10 AM, Ben Laurie b...@google.com wrote: Its only software. The process of participating in CT for a server operator is: 1. Run command line tool once, giving it your certificate as input and an SCT file as output. 2. Add one line of configuration to your server config. Not exactly rocket science. If people _really_ find it hard, we could build it into the servers so there was no manual step at all. As someone who has to trust every CA in the root pile in my browsers and OSs, I find it frightening that a CA who can say this is your bank's certificate cannot handle new requirements for how to say that. If adopting a simple protocol like this causes an ossified CA too many problems, maybe I don't trust that CA to be able to issue certificates for my bank, much less to be able to know which certificates that they are actually issuing. --Paul Hoffman ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker hal...@gmail.com wrote: This is about barely capable sysadmins. Different problem. From the perspective of the relying party (me, caring about making a secure connection to my bank), the problems are indistinguishable. A CA who retains a sysadmin who is barely capable deserves less trust than one who retains sysadmins who are capable. My bank, when trying to decide which CAs might get removed from the root piles in the future, should also see the problems as indistinguishable. That is, I would hope that my bank would pick a CA who is capable and non-ossified so that, when the incapable and ossified CAs are removed from the root piles, my bank doesn't need to get a new cert. I would not mind if adoption of certificate transparency hastens the shedding of barely-capable CAs; the one-time hassle for some users would be far outweighed by the longer-term benefit to the security of the Internet. --Paul Hoffman ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
From my perspective it is much cheaper for me to build a tool that does the job right and give it to you than to follow the usual approach of yet more poorly designed and documented stuff that might work or might not. Having worked in Web security over 20 years now, I have still to see a case where a system was breached because of a really subtle design flaw. Every security issue I have seen has been really simple once it has been identified and isolated. Computer systems are hard to run and harder to secure because of the volume of complexity rather than the degree of complexity. Each individual step is trivial in itself but the cumulative effect is very large. I am sitting next to the print edition of the Oxford English Dictionary which is 20 volumes of dense print. It is something like 200Mb in total. That was the pinacle of achievement of Victorian research taking several decades and thousands of authors. Modern operating systems and applications are much larger. And because we design and build them in the wrong way it only takes one mistake for them to fail. One way that real world sysops defend themselves against complexity is to refuse to learn anything that is new. Judging the deployability of a protocol change based on whether IETF participants are able to do so and willing to invest the necessary effort skews the sample badly. If it were left to us we would have been using IPv6 for over a decade already. On Thu, Nov 1, 2012 at 12:38 PM, Lucy Lynch lly...@civil-tongue.net wrote: On Thu, 1 Nov 2012, Phillip Hallam-Baker wrote: This is about barely capable sysadmins. I'm a barely capable sysadmin and the steps Ben outlined seem both reasonable and do-able to me. I also like the option to build it into the server where smart hands can build it into the default options for configuration - - Lucy Different problem. On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Nov 1, 2012, at 2:10 AM, Ben Laurie b...@google.com wrote: Its only software. The process of participating in CT for a server operator is: 1. Run command line tool once, giving it your certificate as input and an SCT file as output. 2. Add one line of configuration to your server config. Not exactly rocket science. If people _really_ find it hard, we could build it into the servers so there was no manual step at all. As someone who has to trust every CA in the root pile in my browsers and OSs, I find it frightening that a CA who can say this is your bank's certificate cannot handle new requirements for how to say that. If adopting a simple protocol like this causes an ossified CA too many problems, maybe I don't trust that CA to be able to issue certificates for my bank, much less to be able to know which certificates that they are actually issuing. --Paul Hoffman __**_ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/**listinfo/therightkeyhttps://www.ietf.org/mailman/listinfo/therightkey ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: Having worked in Web security over 20 years now, I have still to see a case where a system was breached because of a really subtle design flaw. Bleichenbacher? S. ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
On 1 November 2012 18:00, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: Having worked in Web security over 20 years now, I have still to see a case where a system was breached because of a really subtle design flaw. Bleichenbacher? TLS renegotiation? S. ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
Again, does it appear so subtle after it has been discovered? Would the flaw have been discovered sooner if there was not so much dead code? On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie b...@google.com wrote: On 1 November 2012 18:00, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: Having worked in Web security over 20 years now, I have still to see a case where a system was breached because of a really subtle design flaw. Bleichenbacher? TLS renegotiation? S. ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
On 01/11/12 16:46, Paul Hoffman wrote: On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker hal...@gmail.com wrote: This is about barely capable sysadmins. Different problem. From the perspective of the relying party (me, caring about making a secure connection to my bank), the problems are indistinguishable. A CA who retains a sysadmin who is barely capable Paul, this is about barely capable sysadmins _at your bank_, not at the CA. (Ben wrote The process of participating in CT for a _server operator_ is...) deserves less trust than one who retains sysadmins who are capable. Obviously I agree that CAs should retain capable sysadmins. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
On Nov 1, 2012, at 1:00 PM, Rob Stradling rob.stradl...@comodo.com wrote: If by actively participating you mean that the CA has embedded the CT proof in the cert, then yes, there is no requirement on the bank. That's one definition of actively participating, but there are others, such as publishing a list that the auditors pick up. If the CA instead embeds the CT proof in OCSP Responses relating to the cert, then there is no requirement on the bank apart from to use OCSP Stapling. This confuses me. If the CA is putting the CT proof in its OCSP responses, why does the bank have to do anything? If the CA is not participating in either of these 2 ways, then there is a requirement on the bank (aka the server operator), which may or may not be rocket science, depending on your opinion. If the CA is not participating, why should that CA be in the trust pile of software that relies on CT? --Paul Hoffman ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
On 01/11/12 20:33, Paul Hoffman wrote: On Nov 1, 2012, at 1:00 PM, Rob Stradling rob.stradl...@comodo.com wrote: If by actively participating you mean that the CA has embedded the CT proof in the cert, then yes, there is no requirement on the bank. That's one definition of actively participating, but there are others, such as publishing a list that the auditors pick up. What sort of list did you have in mind? Would this list be transparent? (i.e. if the CA were to publish an inaccurate or incomplete list, would the auditor definitely notice?) If the CA instead embeds the CT proof in OCSP Responses relating to the cert, then there is no requirement on the bank apart from to use OCSP Stapling. This confuses me. If the CA is putting the CT proof in its OCSP responses, why does the bank have to do anything? Because not all clients do online OCSP checks. Because far too many online OCSP checks fail due to the Responder being unreachable. Because OCSP Stapling is not currently enabled by default in (at least) Apache and nginx. If the CA is not participating in either of these 2 ways, then there is a requirement on the bank (aka the server operator), which may or may not be rocket science, depending on your opinion. If the CA is not participating, why should that CA be in the trust pile of software that relies on CT? AFAIK, this is the first time it's been suggested that CT should require CA participation. I think it's an idea we should consider seriously. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] Barely-capable CAs
On 01/11/12 21:55, Rob Stradling wrote: On 01/11/12 20:33, Paul Hoffman wrote: On Nov 1, 2012, at 1:00 PM, Rob Stradling rob.stradl...@comodo.com wrote: If by actively participating you mean that the CA has embedded the CT proof in the cert, then yes, there is no requirement on the bank. That's one definition of actively participating, but there are others, such as publishing a list that the auditors pick up. What sort of list did you have in mind? Would this list be transparent? (i.e. if the CA were to publish an inaccurate or incomplete list, would the auditor definitely notice?) Ah, perhaps you've got this agenda item in mind: JSON format for CAs to report recent certificate issuance, Phill Hallam-Baker – 10 mins I think Phill coined the term weak transparency for this sort of thing. I'd only been thinking about Ben's strong transparency sunlight-02 proposal in this thread so far. snip -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
