Subj : Secure binkp
To   : NuSkooler
From : Oli
Date : Fri Nov 29 2019 01:48 pm

On Wed, 27 Nov 2019 09:25:49 -0700
"NuSkooler -> Oli" <0@121.1.21> wrote:

 N> On Wednesday, November 27th Oli said...
 Ol>> What is still missing is some authentication of incoming
 Ol>> connections if no session password is configured. On the TLS
 Ol>> level we could use client certificates, but it would make
 Ol>> everything more complicated and less flexible.

 N> I've used client authentication many times over the years, what are
 N> you concerns over compliexity/less flexible here? As for passwords,
 N> they are now OK to send as they don't go over the wire unless the TLS
 N> handshake completes (or maybe I'm misunderstanding what you're saying
 N> here)

To make sure that we are talking about the same thing: If we are receiving a
binkp call, we don't know if the presented FTN address is really the address of
 the caller (until both nodes uses a shared password). Now it would be possible
 to use client certificates to authenticate the calling node. I just don't
think we should depend too much on TLS certificate stuff.

Complexity: managing certificates: signing, distributing, renewing, revoking.
Based on FTN's own CA or on real Internet domains and CAs?

(In)Flexibility 1: only works with mailers that supports TLS directly. Doesn't
work with proxies and wrappers.

(In)Flexibility 2: we would need to fully commit to TLS. I don't think it would
 happen nor that it is a good idea.

I would use TLS as a simple encryption layer that is used for secure encryption
 only.

I also wonder if we should use QUIC instead of TCP+TLS?

---
 * Origin:  (21:1/151)

.