Re: [cryptography] preventing protocol failings

2011-07-12 Thread Hill, Brad
Re: H3, There is one mode and it is secure I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give. We haven't yet found a way to hide enough of the complexity of security to make it free, and this inevitably causes conflicts with goals like

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Nico Williams
On Tue, Jul 12, 2011 at 12:10 PM, Hill, Brad bh...@paypal-inc.com wrote: Re: H3, There is one mode and it is secure I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give.  We haven't yet found a way to hide enough of the complexity of

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Andy Steingruebl
On Tue, Jul 12, 2011 at 2:24 PM, Zooko O'Whielacronx zo...@zooko.com wrote: When systems come with good usability properties in the key management (SSH, and I modestly suggest ZRTP and Tahoe-LAFS) then we don't see this pattern. People are willing to use secure tools that have a good usable

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Nico Williams
On Tue, Jul 12, 2011 at 5:36 PM, Andy Steingruebl a...@steingruebl.com wrote: I reject the SSH key management example though.  Especially if you've ever maintained a large number/variety of unix servers running SSH, where hardware failures, machine upgrades, etc. lead to frequent SSH key

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Ian G
On 13/07/11 8:36 AM, Andy Steingruebl wrote: On Tue, Jul 12, 2011 at 2:24 PM, Zooko O'Whielacronxzo...@zooko.com wrote: When systems come with good usability properties in the key management (SSH, and I modestly suggest ZRTP and Tahoe-LAFS) then we don't see this pattern. People are willing

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Andy Steingruebl
On Tue, Jul 12, 2011 at 3:56 PM, Ian G i...@iang.org wrote: The SSH-vs-telnet example was back in the mid-90s where there were two alternatives:  secure telnet and this new-fangled thing called SSH. The way it for for everyone I knew that went through it was: 1. Sniffing was sort of a

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Marsh Ray
On 07/12/2011 04:24 PM, Zooko O'Whielacronx wrote: On Tue, Jul 12, 2011 at 11:10 AM, Hill, Bradbh...@paypal-inc.com wrote: I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give. We haven't yet found a way to hide enough of the complexity of

Re: [cryptography] preventing protocol failings

2011-07-12 Thread James A. Donald
On 2011-07-13 7:24 AM, Zooko O'Whielacronx wrote: On Tue, Jul 12, 2011 at 11:10 AM, Hill, Bradbh...@paypal-inc.com wrote: I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give. We haven't yet found a way to hide enough of the complexity

Re: [cryptography] preventing protocol failings

2011-07-12 Thread James A. Donald
On 2011-07-13 3:10 AM, Hill, Brad wrote: Recognize in advance that users will demand an insecure mode and give it to them. I don't see any demand for an insecure mode for tor hidden services, and though SSH provides an insecure mode, no one uses it. If users demand an insecure mode,

Re: [cryptography] preventing protocol failings

2011-07-12 Thread James A. Donald
On 2011-07-13 8:36 AM, Andy Steingruebl wrote: I reject the SSH key management example though. Especially if you've ever maintained a large number/variety of unix servers running SSH, where hardware failures, machine upgrades, etc. lead to frequent SSH key churn. In those cases the only

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Hill, Brad
If users demand an insecure mode, it is because your secure mode has bad user interface. I'm actually thinking about things like web services where the user isn't someone sitting in front of a UI, but a programmer, or a team of programmers, testers, and operational personnel.It's easy to