Early capabilities, and ECDH
ijackson at chiark.greenend.org.uk
Tue Apr 25 13:43:34 BST 2017
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
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
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
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);
and presumably to specify a preference order.
I think we can do this by making the `dh' argument to site closures be
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
* Add the new algorithms.
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.
More information about the sgo-software-discuss