[patch] more TLS configuration options for nnrpd

Russ Allbery eagle at eyrie.org
Mon Nov 10 17:21:49 UTC 2014

Julien ÉLIE <julien at trigofacile.com> writes:

> I was concerned with the SASL security layer it can add (depending on
> the SASL mechanism used).  It seems that GSSAPI described in RFC 4752
> can offer a security layer.  Other mechanisms can use TLS, as I see in
> RFCs listed here:
>     http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

GSSAPI security layers are much simpler, since they use symmetric key
encryption and don't have all the interesting public key negotiation
problems of TLS.  The security of a GSSAPI layer is almost entirely
external to the application and depends on the negotiated underlying
encryption algorithm and key, which is intentionally a black box to the
application using GSSAPI.

So, in short, the security work for GSSAPI belongs on the local site
administrator, who needs to do things like use good Kerberos encryption
types.  I don't think there's a similar application-level need to select
algorithms and TLS models.

> Another thing I see in TODO is:  "when using SSL, track the amount of
> data that's been transferred to the client and periodically renegotiate
> the session key."  Is it a recommended practice in bettercrypto too?

This is definitely a general crypto recommendation.  The more encrypted
data you give an attacker, the better chance they have of exploiting some
crypto flaw that allows statistical analysis.

Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.

More information about the inn-workers mailing list