On Tue, Aug 25, 2009 at 12:44:57PM +0100, Ben Laurie wrote:
> In order to roll out a new crypto algorithm, you have to roll out new
> software. So, why is anything needed for "pluggability" beyond versioning?
> It seems to me protocol designers get all excited about this because
> they want to design the protocol once and be done with it. But software
> authors are generally content to worry about the new algorithm when they
> need to switch to it - and since they're going to have to update their
> software anyway and get everyone to install the new version, why should
> they worry any sooner?

Many good replies have been given already.  Here's a few more reasons to
want "pluggability" in the protocol:

 - Yes, we "want to design the protocol once and be done with" the hard
   parts of the design problem that we can reasonably expect to have to
   do only once.  Having to do things only once is not just "cool".

 - Pluggability at the protocol layer enable pluggability in the
   implementations.  A pluggable design does not imply open plug-in
   interfaces, but a pluggable design does imply highly localized
   development of new plug-ins.

 - It's a good idea to promote careful thought about the future,
   precisely what designing a pluggable protocol does and requires.

   We may get it wrong (e.g., the SSHv2 alg nego protocol has quirks,
   some of which were discovered when we worked on RFC4462), but the
   result is likely to be much better than not putting much or any such
   thought into it.

If the protocol designers and the implementors get their respective
designs right, the best case scenario is that switching from one
cryptographic algorithm to another requires less effort in the pluggable
case than in the non-pluggable case.  Specifically, specification and
implementation of new crypto algs can be localized -- no existing
specification nor code need change!  Yes, new SW must still get
deployed, and that's pretty hard, but it helps to make it easier to
develop that SW.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to