Re: [Uta] Using TLS with NNTP

[Julien ÉLIE <[e-mail]>]

Hi all,

What would you recommend to refresh RFC 4642 so that it can be 
consistent with the latest published RFCs about TLS and its best practices?

A new RFC obsoleting it, or only an update like RFC 7590 is for XMPP?

And is UTA the right WG to work on that refresh?


You'll find more background about that in my mail below.
I've CC: the original authors of RFC 4642.

Thanks beforehand,

-- 
Julien



Le 02/11/2015 11:12, Julien ÉLIE a écrit :
> Hi all,
>
> 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.
>
>
>
> Another point is the fact that TLS 1.3 will remove support for
> compression.  The NNTP protocol is currently relying on that feature of
> TLS, as we can see in the abstract and the description of the STARTTLS
> command in RFC 4642:
>
>     The STARTTLS command is usually used to initiate session security,
>     although it can also be used for client and/or server certificate
>     authentication and/or data compression.
>
>
>
> A huge thread of more than a thousand messages has just been held in the
> TLS IETF working group. The chairs agreed to remove compression from TLS
> 1.3:
>      https://www.ietf.org/mail-archive/web/tls/current/msg17941.html
>
> Basically, it is not the role of a security layer to provide a facility
> (compression) that is known to cause security issues (CRIME attack for
> instance).
> If compression with TLS is wanted for NNTP, then clients and servers
> will have to use TLS 1.2 (or more ancient).
>
>
>
>
> I was advised in the TLS mailing-list to contact the UTA WG.  (The NNTP
> WG is no longer an active IETF WG.)
>
> The questions are:
>
> - what move should be done about RFC 4642?
> The good news is that Stephen Farrell, an IETF/IESG chairman, is willing
> to shepherd us on refreshing RFC 4642.  We have to decide the best move
> to do between a new RFC that obsoletes RFC 4642 or a short RFC that
> updates RFC 4242.
>      http://www.ietf.org/mail-archive/web/tls/current/msg17562.html
>
> - what should we say in that refresh?
> An idea is that we could just refer to RFC 7525 (Recommendations for
> Secure Use of Transport Layer Security (TLS) and Datagram Transport
> Layer Security (DTLS)), that is a Best Current Practice:
>      https://tools.ietf.org/html/bcp195
>
> - do you see other things that should be improved at the same time in
> RFC 4642?
>
> - as for compression, there is a draft for a COMPRESS command:
>      http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html
> Is it the right move to do for Applications that are currently relying
> on the compression provided by TLS?
>
>
>
>
> P.-S. : Maybe in the wiki of UTA, the NNTP protocol could be mentioned :)
>      http://trac.tools.ietf.org/wg/uta/trac/wiki
>