[9fans] replace p9sk1 with something better(9front)

[9fans] replace p9sk1 with something better(9front)

[gracc]

as per http://wiki.9front.org/bounties
>>replace p9sk1 with something better

I'm looking to start on this, does anyone have thoughts on improvements?
At the moment I am intending to just replace the DES keys with AES but
is there any call for more structural changes?

I was thinking that an overhaul using public keys might be appropriate
so that the auth server would still be a trusted key holder but without
secret keys having to leave the user's machine.

(9front mailing list was down so im sending to 9fans instead, sorry if
that's a bother)

Re: [9fans] replace p9sk1 with something better(9front)

[steve]

I think just replacing des keys with AES is not worth it. there is so little data that des is quite secure (imho).

replacing p9sk1 with pki is much more useful. rus posted to 9fans about wanting to do this so a terminal could cache tickets to speed auth when the auth server is remote - I cannot remember the details, sorry.

also pki would allow the old 9grid ideas to resurface, if there are enough plan9 machines left :-)

-Steve


ps. inferno already uses pki, it would be best to be compatible unless there is a very good reason not to be.



> On 2 Jul 2015, at 12:37, gracc <oniichan@tfwno.gf> wrote:
> 
> as per http://wiki.9front.org/bounties
>>> replace p9sk1 with something better
> 
> I'm looking to start on this, does anyone have thoughts on improvements?
> At the moment I am intending to just replace the DES keys with AES but
> is there any call for more structural changes?
> 
> I was thinking that an overhaul using public keys might be appropriate
> so that the auth server would still be a trusted key holder but without
> secret keys having to leave the user's machine.
> 
> (9front mailing list was down so im sending to 9fans instead, sorry if
> that's a bother)

Re: [9fans] replace p9sk1 with something better(9front)

[Anthony Sorace]

Personally, I think two separate things are called for.

1) A straight-forward update to use AES
2) Some public key system.

The p9sk1 *model* is great, and it'd be a real shame to drop it. Doing the upgrade and teaching should be easy, although there's tedious work in telling all the things to start using it,
The fun/interesting parts live in that second one, though. Lots of questions, starting with deciding if something existing might make sense to import (Inferno's public key system is the obvious first thing to look at there, but its details are dusty in my head). Public key systems have different enough properties that it'd be good to have both, in cases where one or the other fits the use case better.

Re: [9fans] replace p9sk1 with something better(9front)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

On 2 July 2015 at 13:30, Anthony Sorace <a@9srv.net> wrote:

> The p9sk1 *model* is great, and it'd be a real shame to drop it.


There always seems to be trouble setting it up, which suggests that the
documentation people typically first see might need revising
(or better pointers if it exists but people don't find it).

[-- Attachment #2: Type: text/html, Size: 642 bytes --]

Re: [9fans] replace p9sk1 with something better(9front)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

I hadn't looked at the "bounties" page recently. It includes

"improve the tls(3) device $10 - The TLS device implements the record layer
protocols of Transport Layer Security version 1.0 and Secure Sockets Layer
version 3.0. It does not implement the handshake protocols, which are
responsible for mutual authentication and key exchange. Wanted: more
ciphers, support for user certificates, support for certificate
verification. ECDSA! ECDHE!"

I think that I'd avoid putting the negotiation and certificate stuff (as
such) in the kernel device.


On 2 July 2015 at 13:57, Charles Forsyth <charles.forsyth@gmail.com> wrote:

>
> On 2 July 2015 at 13:30, Anthony Sorace <a@9srv.net> wrote:
>
>> The p9sk1 *model* is great, and it'd be a real shame to drop it.
>
>
> There always seems to be trouble setting it up, which suggests that the
> documentation people typically first see might need revising
> (or better pointers if it exists but people don't find it).
>

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re: [9fans] replace p9sk1 with something better(9front)

[lucio]

> I think that I'd avoid putting the negotiation and certificate stuff (as
> such) in the kernel device.

Speaking as an amateur, I'd be tempted to investigate pushing the Plan
9 paradigm further and see how hard it would be to fragment the kernel
into asymmetric portions.  To be more specific, something of the
magnitude of TLS, or USB, ought to be constructed as a subkernel or a
super-driver, able to run on GPUs in parallel with the CPU-based
kernel.  Thinking on my feet, I'd say the important factor would be
the establishment of boundaries between modules that can only be
crossed with the right type of credentials.

How much of this is old hat to those of us who are close to academia I
can't guess, but not having seen much mention of similar concepts, I'm
curious if anything in this vein is being explored at all (I'm sure
something that would appeal to me is, there are close to an infinite
number of monkeys out there typing on pretty close to an infinite
number of keyboards and an even more infinite number of CPUs).

Lucio.

Re: [9fans] replace p9sk1 with something better(9front)

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

isn't it settled that keeping of secrets and exchange thereof are the
domain of factotum?


On Thu, Jul 2, 2015 at 6:14 AM, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> I hadn't looked at the "bounties" page recently. It includes
>
> "improve the tls(3) device $10 - The TLS device implements the record
> layer protocols of Transport Layer Security version 1.0 and Secure Sockets
> Layer version 3.0. It does not implement the handshake protocols, which are
> responsible for mutual authentication and key exchange. Wanted: more
> ciphers, support for user certificates, support for certificate
> verification. ECDSA! ECDHE!"
>
> I think that I'd avoid putting the negotiation and certificate stuff (as
> such) in the kernel device.
>
>
> On 2 July 2015 at 13:57, Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>>
>> On 2 July 2015 at 13:30, Anthony Sorace <a@9srv.net> wrote:
>>
>>> The p9sk1 *model* is great, and it'd be a real shame to drop it.
>>
>>
>> There always seems to be trouble setting it up, which suggests that the
>> documentation people typically first see might need revising
>> (or better pointers if it exists but people don't find it).
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2202 bytes --]

Re: [9fans] replace p9sk1 with something better(9front)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

On 2 July 2015 at 17:44, Skip Tavakkolian <skip.tavakkolian@gmail.com>
wrote:

> isn't it settled that keeping of secrets and exchange thereof are the
> domain of factotum?


I hope so.

[-- Attachment #2: Type: text/html, Size: 485 bytes --]

Re: [9fans] replace p9sk1 with something better(9front)

[cinap_lenrek]

> Wanted: more
> ciphers, support for user certificates, support for certificate
> verification. ECDSA! ECDHE!"

client certs, client side DHE and ECDHE already done in 9front, just
take it :)

--
cinap