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 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." > > [...]
> 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. Two protocols... still has a downgrade attack: either the user or user agent will have to choose one of the protocols. If the user -> we've failed to make the protocols user-friendly (unless only they could make the decision). If the user agent -> we still have a downgrade. You might intend for the user to choose, but what if the user-agent developers decide to help the user choose? -> downgrade. This is an excellent demonstration of Jon Callas' point regarding complexity: we can only move it about. Moving it to the user is not really friendly to them, and it will result in someone later innovating by moving that complexity back into the user-agent. For the developer the simplest protection against downgrade attacks is to default to a secure setting and fob off any fallback-on-nsecure decision on the user. This works whether there's one protocol with two options or two with none. > 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. Here the user is in a position to decide, and there's few of them anyways and they can be expected to understand or educate themselves about these issues. If we were talking about all the users of the Internet (who do have to grok the difference between "http" and "https", and understand what to do about invalid/expired/self-signed certs, what trust anchors are, and so on)... The main difference between "two protocols, no options" and "one protocol, two options" may well be that the former is packet filter friendly, while the latter would require deep packet inspection for effective filtering. I wish this reason didn't have to matter much. There is no difference as to UIs though: in both cases the two choices can be forced on the user or hidden from them (like when you select whether to use TLS in IM applications, or choose between or act upon the service's choice of http or https in the browser). Neither approach fundamentally prevents downgrade attacks. Nico -- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
