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.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
