[cryptography] preventing protocol failings

Nico Williams nico at cryptonector.com
Tue Jul 12 18:02:10 EDT 2011


On Tue, Jul 12, 2011 at 12:10 PM, Hill, Brad <bhill at 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
--



More information about the cryptography mailing list