On Wed, Sep 02, 2015 at 04:39:59PM +0200, Julien ?LIE wrote:
> Since the publication of RFC 7465 "Prohibiting RC4 Cipher Suites", there has
> been a discrepancy with the requirements of Section 5 of RFC 4642 "Using
> Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)":
>
> NNTP client and server implementations MUST implement the
> TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
> important, as it assures that any two compliant implementations can
> be configured to interoperate. All other cipher suites are OPTIONAL.
It would be best if NNTP did not specify MTI TLS ciphersuites and
left that to the relevant TLS specifications. Instead, it would
be more useful to specify a minimum TLS protocol version, and
require each side to support the MTI ciphers for each supported
protocol version.
It seems that 4642 is rather muddy on whether TLS in NNTP is
opportunistic or not. On the one hand it requires server
authentication, which seems to be mitigation of active attacks via
mandatory TLS, and on the other it talks about clients possibly
continuing despite absence of STARTTLS capability or STARTTLS
failure.
If an update is published, it should resolve the opportunistic vs.
mandatory TLS confusion, possibly by describing two separate modes
of operation.
AFAIK, NNTP peering relationships are fairly static, and mandatory
TLS seems like the way to go in that case. But if NNTP servers
contact other servers "on the fly", then opportunistic TLS may
be appropriate and one might even consider DANE to harden that.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
