Some draft notes on migrating Tor's ciphersuites

[Watson Ladd]

On Sat, Dec 18, 2010 at 10:34 PM, Nick Mathewson <nickm at freehaven.net> wrote:
> On Sat, Dec 18, 2010 at 9:01 AM, Watson Ladd <watsonbladd at gmail.com> wrote:
>  [...]
>> When a client receives indication that its EXT_CREAT was not
>> recognized it falls back on CREATE. ORs send back a packet that
>> indicates if they do not recognize the SUITE and the client falls back
>> to an earlier revision.
>
> Actually, the fallback mechanism probably isn't even needed: remember,
> the client has a descriptor for the servers that it wants to extend
> from and to, so it knows which keys and ciphersuites the target server
> supports, and which extend protocols the origin server supports.

Looking at the documentation I see the directory is extensible whereas
what is on the wire is less likely to be.

>
> You're right that it's important to limit partitioning opportunities
> in any protocol revision; I tried to go over that in section 2, but we
> shouldn't assume that I've said the last word on this.  We should
> continue to look for ways to revise and improve whatever we come up
> with to get the partitioning and other undesirable things down to a
> minimum.
One way is to be very conservative in suite choices so we don't have
to change them that often. I'm going to also go out on a limb and say
that we also want a crypto API like NaCL that lets us just say
enciphered=encrypt(key, unenciphered) and doesn't force us to worry
about padding or modes because this is a much simpler abstraction
layer and so offers less opportunity for mistakes that could threaten
security. I'll put together a demo program sometime to demonstrate
this.
>
> --
> Nick
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin