Re: [9front] [patch] devtls updates

["Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>]

> For tls, I'd be ok with keeping specific
> obsolete ciphers around if there are
> devices that need it

You could overload the encalgs and hashalgs files to allow writes
of '-hashalg' to remove an entry from the supported list.  In fact,
I think it might be useful to have a general write interface on
those files where +alg adds to the list, -alg removes from the list,
and any other write specifies an absolute list of algs to turn on.
This would give the host owner fine grained control over what TLS
would be willing to do (and, of course, allow them to break things
in spectacular fashion).  Removing write perms on either of the
files would permanently make the underlying alg list immutable.

In conjunction with that, add a '#aX' aname (that's a literal 'X'
character, not a place holder) that references a TLS stack instance
with all the obsolete algs available, but not necessarily enabled.
Running 'bind -a '#aX' /net' would present, e.g., a /net/tls.insecure
directory tree.  Then things like cpu and oexportfs would have to
bind /net/tls.insecure over /net/tls to get access to the old cruft.

It would be good to have a switch that disabled binding the '#aX'
device completely.  That would allow the host owner to easily
prevent the old stuff from ever being used.  Once disabled, it
can't be turned on again.

Anyway, that's just something that sprang to mind when I read the
question.  Take it with the full five minutes thought I've given it.

--lyndon