[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography-randombit
Subject:    [cryptography] Commiittee disease
From:       jamesd () echeque ! com (James A !  Donald)
Date:       2010-09-11 10:20:05
Message-ID: 4C8B57D5.3040206 () echeque ! com
[Download RAW message or body]

On 2010-09-10 12:39 PM, Ian G wrote:
> Also, algorithm agility can in theory replace the algorithms when
> broken. However this is a double-edged sword. It involves a lot of
> complexity (hence work and insecurity), and often doesn't work nearly as
> well as you'd hope. An example of this is the re-negotiation break in
> SSL. We are now in the presence of a roll-over of a broken protocol, and
> we're at 1 year and counting. SSL renegotiation is instructive because
> people really care. We can see the same game going on with "get rid of
> SSL v2" which is around 5 years and counting .. but there most people
> don't care.
>
> In contrast, non-committee-based systems like Skype can probably roll
> over in weeks or months.

A committee is required to establish consensus. You need consensus so 
that clients and servers agree on what the bits mean - but with 
sufficiently flexible protocol negotiation, you should need less agreement.

If a standard is successful, more and more people want to be in the 
committee, many of whom represent business profit centers and government 
special interests, and who really do not understand much about the 
technology, except that any change might be adverse to the very 
important people who sent them there.

As the committee gets larger, it gets more unworkable, and as it 
represents more and more special interests, it gets more unworkable.

When an old protocol is broken, clients and servers that have not 
upgraded to a new improved protocol will remain forever, so the old 
defective protocol has to be supported forever - without, however, 
allowing an attacker a downgrade attack.

Often, it is impossible to support the old clients, because protocol 
negotiation was never adequately designed in, or because it was designed 
in but was designed vulnerable to a downgrade attack.

But let us suppose the protocol negotiation was well designed:  The 
committee has to assign a code.  And of course, they will only assign 
this code to a protocol that they agree is right - and nothing gets done.

One solution is to have quite large protocol identifiers, or arbitrarily 
large variable length protocol identifiers, so that anyone can whip up a 
protocol and assign it an identifier, and hack a client and server to 
use it, without having to walk it past three dozen members of the committee.

But then, of course, we would probably wind up with a lot of protocols. 
  This could potentially lead to a lot of protocol negotiation round trips

	Do you speak protocol A

	No

	Do you speak protocol B

	No

	Do you speak protocol C

	No.

One solution to this problem is to have complete lists of protocols, 
call it a protocol dictionary, which dictionary maps the long 
probabilistically globally unique protocol names to short local protocol 
names, and gives an order of preference.  If the client names a 
dictionary that it supports, and/or the server names a dictionary that 
it supports, then the can usually come to immediate agreement.




[prev in list] [next in list] [prev in thread] [next in thread]