Re: [hybi] Extensibility mechanisms?

[Greg Wilkins <[e-mail]>]

On 22 July 2010 17:08, Adam Barth <[e-mail]> wrote:
>
> You're describing a defense which we've been calling rigidity.  By
> making the handshake rigid, it's harder to squeeze though some other
> protocol's state machine.  However, you can imagine protocols that are
> vulnerable to a perfectly rigid handshake.  As an example, imagine a
> protocol like gopher where the attacker might be able to control all
> the bytes returned by the server (e.g., because the server accepts
> uploads).
>
> There's value to having other defenses against cross-protocol attacks
> in addition to rigidity.  Just as Greg's nonce isn't magic security
> pixie dust, neither is rigidity.
>
>
Adam,

well the nonce idea was not mine (and I once was very unconvinced of it's
need), but as it's current advocate I OK if you want to label it that way.

However, I do very much like your analysis of rigidity as a protection
against security attacks.  In essence, the rigid approach is trying to focus
on the syntax off the message on the basis that it "would be impossible" for
an attacker to generate those bytes.  The nonce/token alternative is based
on the assumption that it would be impossible for an attacker to know what
bytes they need to generate (regardless of syntax).

Of the two, I believe that rigidity is the weaker approach as it is
extremely difficult to "prove" that nothing on the internet can be tricked,
subverted or exploited to produce any arbitrary bytes that an attacker
wishes to generates.

The nonce/token approach is intended to deny attackers working within the
browser having the ability to know what bytes they should generate, so that
even if they could inject them, they don't know what to object.  Thus I
think it is a stronger approach, but for more limited circumstances - as it
does not address non browser clients.

In the spirit of defence in depth, I think we probably need elements of both
approaches.   However, I would suggest that currently the specification has
placed too much emphasis on rigidity, to the extent that it will effect
interoperability and extensibility without any significant gain in security.

regards