TLS sandboxing

[Poul-Henning Kamp]

--------
In message <CABoVN9D0LGaRNorsPogRCkKKojpXJ9vDLWHi=tAPGa-tzYz1_Q at mail.gmail.com>
, Dridi Boukelmoune writes:

>I have given more thought to this and I'm torn between "this is 2019
>and we still don't support HTTPS" and the very good reasons why we
>don't. However I still think we should support it and I gave a tiny
>bit more thoughts to this.

Absolutely, all such decisions needs to be revisited as circumstances
change.

>First, in-kernel TLS is coming,

Yes, and about f**king I might add...

(See also: https://people.freebsd.org/~gallatin/talks/euro2019.pdf)

Unfortunately, the kernel people only seem to want to do the easy
part :-(

	https://reviews.freebsd.org/D21277

>But once we have that we circle back to handshakes. And I very much
>agree that a keyless approach would be best. However this is still
>2019 so I think we should own it, and not rely on a third party.

I'm not in any hurry to add crypto code to our plate in any way
shape and form.

The primary reason is that as far as I know there are *at best* 1½
persons in the project with skills which *approximate* what would
be required.

The secondary reason is that neither of them are particularly eager
to add another job to their workload.

I can *possibly* be persuaded that we can handle session keys, and
I will be perfectly happy to point at a 3rd party keyserver packages
and say "that's where you get your keys from".

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.