ECDH, early capabilities, etc.

[Ian Jackson]

(sending again with Mark's address fixed)

Last night we discussed your X448 [RFC7748] (and perhaps, in the
future, Ed448, RFC8032] implementation, and in particular its
relationship to secnet's protocol negotiation facilities.

Support for X448 would have to be an "early capability" within the
meaning of NOTES.  NOTES says

  advertising an early capability flag will produce MSG1s which are
  not understood by versions of secnet which predate the capability
  mechanism

The commit needed to cope with and ignore an unknown early capability
is "site: fix site name checking leaving room for expansion"
1737eeef9bc4 from July 2013.  That was released in secnet 0.3.0 in
September 2013.

Current advice from secnet release announcements is:

  (Everyone should be running at least version 0.3.4, as all previous
  versions have significant security bugs.)

So I think deploying this with an early capability flag is fine.

Each new group should have a capability flag.  I don't see the need
for a negotiation system for arbitrary user-defined groups.  Instead,
let's just hardcode a capability flag for each new group.

(We don't need a capability flag for the existing Zp group (or
manually-configured different Zp group), since that should always be
the least-preferred option.  We presume that everyone supports it if
we do.)


As for configuration, we want each site administrator to be able to
individually turn on and off each of:
   dh (normally with the conventional default secnet group,
       but theoretically in a specified group);
   x25519
   x448
and presumably to specify a preference order.

I think we can do this by making the `dh' argument to site closures be
a list.


Something like this:

 * Change the dh closure interface to move any Zp-specific parts from
   site.c into dh.c (and perhaps rename the dh closure to
   `key_agreement' or something in the code and the README).

 * Change the site closure to look for `key-agreement', rather
   than `dh'; and provide a default definition of key-agreement
   which is simply a list containing only `dh'.

 * Add a field to the key_agreement closure declaring its
   capability index (-1 for the existing closure), and the
   negotiation/selection algorithm.

 * Add the new algorithms.


Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.