All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [RFC] MPI module
Date: Fri, 30 Jan 2009 09:12:10 +0100	[thread overview]
Message-ID: <20090130081210.GA8157@artemis> (raw)
In-Reply-To: <20090130032506.GA2822@gondor.apana.org.au>

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

On Fri, Jan 30, 2009 at 03:25:06AM +0000, Herbert Xu wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> >
> > My endgame is simple, I'd like to see an in-kernel SSL/TLS
> > implementation in Linux happen. There are many reasons to want that,
> > ranging from performance reasons (waking the userland each time you
> > perform a handshake isn't particularly nice, and it's easy to make
> > system-wide session caches) to really cool features being enabled:
> >  - you can send "secure" file descriptors around through Unix Sockets,
> >    or prepare a "secure" socket, let it be your stdin/stdout pair and
> >    exec a service knowing nothing about SSL (think inetd-like stuff) ;
> >  - you can deploy secure services where the actual server knows nothing
> >    about the certificate that is used ;
> >  - you can have a system-wide service dealing with peer certificate
> >    validations and have a real system-wide policy in this regard ;
> >  - you could even think of some netfilter stuff to enforce security on
> >    a given socket, even if the service behind the socket knows nothing
> >    about it (bye bye stunnel)...
> > 
> > Nowadays, the kernel has most of what we need cipher-wise for TLS/SSL.
> > Only the key-exchange protocols and the very TLS protocol are lacking.
> > I'm currently addressing the former issue, namely, bringing RSA and
> > Diffie-Hellman to the kernel.
> 
> Stop right there.  There is absolutely no reason why you need
> to do the TLS stuff in kernel to achieve the goals you listed
> above.
> 
> What you should do is have user-space create the session, and
> then give the keys to the kernel to do the data-path.  Please
> take a look at IPsec for an example of how the work is divided
> between user-space and the kernel.

So let me rephrase that to be sure we've understood each other. What you
suggest is to have an IKE-like daemon dealing with the keys and all the
handshakes, and that the kernel would only deal with the symmetric
ciphers used on the data path. Is that right ?

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2009-01-30  8:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-30  0:15 [RFC] MPI module Pierre Habouzit
2009-01-30  3:25 ` Herbert Xu
2009-01-30  8:12   ` Pierre Habouzit [this message]
2009-01-30 12:41     ` Herbert Xu
2009-01-30 18:54       ` Loc Ho
2009-01-31 22:34         ` Pierre Habouzit
2009-02-07  0:59           ` Loc Ho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090130081210.GA8157@artemis \
    --to=madcoder@debian.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.