[cryptography] preventing protocol failings

Zooko O'Whielacronx zooko at zooko.com
Sat Jul 9 01:57:39 EDT 2011

Thanks for the stimulating discussion, folks.

On Tue, Jul 5, 2011 at 12:11 AM, Jon Callas <jon at callas.org> wrote:
> But how is this actionable? How can I use this principle as a touchstone to let me know the right thing to do. I suppose we could consider it a rule of thumb instead, but that flies in the face of making it "Gospel."

Your examples are about interoperation with existing systems that
include an insecure mode, but Grigg's H3 is about designing new
protocols. In that context, I find it to be eminently practical

When Phil Zimmermann and I were designing ZRTP, we had a complete
protocol design for the secure stream and a working prototype, and
then we decided, against my better judgment, to add the feature of
users being able to switch back and forth between secure mode and
insecure ("clear") mode. (This was before you, Jon, got involved in
the protocol-level details of the ZRTP that eventually became RFC
6189. I think it was in 2006.)

This caused the state transition diagram (which lived on a piece of
8.5x11 paper pinned to the wall above my screen) to balloon from, if I
recall correctly, approximately five states with around ten
transitions to approximately ten states with closer to twenty
transitions. We then added and removed several successive bugs in the
protocol or in the prototype implementation over the next few months,
all of which were in this newly added feature of the protocol.

Phil was concerned about our schedule and frustrated by the delay. He
remarked that if he had known adding "clear mode" was going to cost so
much development time he wouldn't have done it.

Later, the existence of the insecure mode again added complexity when
we wanted to add support for PBXes and call transfer, and instead of
working out how to handle call transfer from one state (secure mode),
we had to work out how to do it from several states—secure mode, clear
mode, the state where you've indicated that you wish to switch from
secure mode to clear mode but the other party hasn't yet ACKed, and
the state where you've indicated that you wish to switch from clear
mode to secure mode but the two parties haven't finished negotiating
the new session. (By this time I had left the ZRTP project to begin
work on what eventually became Tahoe-LAFS, and my contribution to the
PBX/call-transfer issue was merely a little bit of consulting.)

I think that in retrospect ZRTP would have been better if we had
followed Grigg's H3.

Hm, digging around in my keepsakes cabinet, I unfortunately do not
find the original state transition diagram that I mentioned above, but
I do find an artifact that I wrote a few months later—a sketch of a
protocol that I called "ZRTP lite" which was ZRTP as it existed at
that time minus insecure mode, algorithm negotiation, the "confirm"
packet, and the max-retries timeout. The resulting state transition
diagram has only three states (five if you count the beginning
state—before the phone call has begun—and the ending state—after the
call has ended), and only five transitions (counting start and stop).

I never showed this to anyone until now. See attachment.

My next major project after ZRTP was Tahoe-LAFS, and in that project
my co-designers and I have adhered to Grigg's H3. We occasionally get
requests to add an insecure mode to Tahoe-LAFS and so far we have
declined to do so. I could be provoked into posting further musings on
that issue. (The fact that we are refusing to accommodate repeated
requests from users is certainly a warning flag in my view and
deserves careful justification.)



[rfc6189] http://zfone.com/docs/ietf/rfc6189.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMAG0207-compressed-more.jpg
Type: image/jpeg
Size: 386433 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20110708/f2ecba32/attachment.jpg>

More information about the cryptography mailing list