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* ?
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
