[cryptography] preventing protocol failings

Ian G iang at iang.org
Wed Jul 13 02:02:28 EDT 2011

On 13/07/11 3:10 AM, Hill, Brad 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 security to make it free, and this inevitably causes conflicts with goals like adoption.
> An alternate or possibly just auxiliary hypothesis I've been promoting on how to respond to these pressures is:
> "Build two protocols and incentivize."
> That is:
>     Recognize in advance that users will demand an insecure mode and give it to them.

I've heard of users demanding easy modes, but never demanding insecure 
modes :)

>     Make it a totally different protocol, not an option, mode or negotiation of the secure protocol.
>     Encourage appropriate self-sorting between the secure and insecure protocols.
> Making two completely different protocols means that neither has to pay the complexity cost of the other mode, (avoiding e.g. the state explosion Zooko described with ZRTP) eliminates or greatly reduces introduced attack classes around negotiation and downgrade, and makes the story around managing and eventually deprecating legacy clients simpler.
> The self-sorting is the tricky bit.  Google Checkout and SXIP are good examples of this.   Google Checkout allowed both signed and unsigned shopping carts.  Unsigned shopping carts were dead-easy to implement, but had a higher fee structure than the signed carts.  This meant that it was easy to join the ecosystem as a prototyper, hobbyist or small and unsophisticated business.  But it also meant that as soon as your transaction volume got large enough, it was worthwhile to move to the secure version.   SXIP built the incentive between protocols by having additional features / attributes that were only available to users of the secure protocol.

I would never have done that.  I would have had signed shopping carts, 
period.  I would have just set the fee structure on whether I recognise 
the signer of the shopping cart, or not.

(I'm not saying it is wrong, just that there is an easy way to get the 
same benefit without having two modes...)

> The other advantage of building two protocols is that if/when the insecure protocol actually becomes a target of attack, the secure version is ready to go, deployed, proven, ready for load, with libraries, sample code, the works needed for a smooth transition.
> This is a bit like Ian's "Build one to throw away," except that I'd say, build them both at the same time, and maybe you won't need to throw away the insecure one.

I know it sounds good, but has it ever worked?  Has any vendor ever been 
successfully attacked through a weak demo system, and then rolled out a 
new one *which happened to be prepared in time for this eventuality* ?


More information about the cryptography mailing list