Subject: [TLS] RC4 cipher with NNTP (RFC 4642)

From: Julien ÉLIE <[email-masked]>
Date: Wed, 2 Sep 2015 16:39:59 +0200

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.

Shouldn't something be done about that?
Maybe a new RFC obsoleting RFC 4642 (which could at the same time become 
a standard instead of a proposed standard)?  or do you have other ideas?

What would be the best wording to replace the above paragraph?  Should 
one or several ciphers still be explicitly mentioned, or the paragraph 
totally removed?  (RFC 5246 that standardizes TLS 1.2 already has a 
Section 9 about the mandatory TLS_RSA_WITH_AES_128_CBC_SHA cipher suite.)

Of course, if you see other things that should be amended in RFC 4242, 
do not hesitate to tell.

Thanks beforehand,

-- 
Julien ÉLIE

« Vous savez, les idées, elles sont dans l'air. Il suffit que
   quelqu'un vous en parle de trop près, pour que vous les
   attrapiez ! » (Raymond Devos)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Sep 2015 14:53:35 +0000

> Maybe a new RFC obsoleting RFC 4642 (which could at the same time
> become a standard instead of a proposed standard)? 

Is there any reason why NNTP cannot just use the UTA specifications?  (It's been awhile since I "dabbled" in NNTP :)

	/r$

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Sep 2015 15:00:49 +0000

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)":
> 

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.

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 2 Sep 2015 17:13:08 +0200

Hi Viktor,

> require each side to support the MTI ciphers for each supported

OK thanks, that seems wise.

> mandatory TLS confusion, possibly by describing two separate modes

Noted, thanks.

> be appropriate and one might even consider DANE to harden that.

You're right that NNTP peering is fairly static.  However, TLS is rarely 
used for NNTP peering between two servers.  TLS is more wide-spread for 
the connection of a news client to a news server so as to read or post 
articles.

-- 
Julien ÉLIE

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Sep 2015 08:14:16 -0700

Note: RFC 4642 does not seem to have been a work product of the TLS WG,
so you probably want to raise this in UTA.

-Ekr

On Wed, Sep 2, 2015 at 7:53 AM, Salz, Rich <[email-masked]> wrote:

> Is there any reason why NNTP cannot just use the UTA specifications?
> (It's been awhile since I "dabbled" in NNTP :)
>
>         /r$
>
>
> --
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 2 Sep 2015 17:20:18 +0200

Hi Rich,

> Is there any reason why NNTP cannot just use the UTA specifications?

When you speak about the UTA specifications, is it RFC 7525 
"Recommendations for Secure Use of Transport Layer Security and Datagram 
Transport Layer Security"?
I do not see other document published by the UTA WG that could otherwise 
apply.

Yet, NNTP still needs an RFC to specify the use of TLS because two 
specific NNTP response codes are defined for the STARTTLS command:

       382 Continue with TLS negotiation
       580 Can not initiate TLS negotiation

and the STARTTLS capability has to be standardized in response to the 
CAPABILITIES command -- which is a new command that did not exist when 
you wrote INN :-)

Maybe I misunderstood your remark about the UTA specification, though.

-- 
Julien ÉLIE

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Sep 2015 15:23:08 +0000

On Wed, Sep 02, 2015 at 05:13:08PM +0200, Julien ?LIE wrote:

> used for NNTP peering between two servers.  TLS is more wide-spread for the
> connection of a news client to a news server so as to read or post articles.

I would also expect that a given user's choice of NNTP server is
also fairly static, and in any case user-agents likely want valid
certificates and mandatory TLS (as with IMAP and SUBMIT).

If so, I don't see much of a role for opportunistic TLS in NNTP,
in which case, the updated spec can be simplified to say that
clients SHOULD know whether TLS is expected of their peer, and if
so refuse to proceed unless they obtain an authenticated encrypted
channel (per all reasonable UTA TLS BCP guidelines, and with support
for the MTI ciphers appropriate for all supported TLS versions).

In the server-to-server case, once DANE succeeds or fails to get
traction for SMTP and XMPP, one might explore using DANE rather
than the public CA "Web PKI".  But this is premature at this time.
With peering largely static, "Web PKI" works well enough, and
clients can if they desire more security restrict which CAs they
are willing to accept as issuers of the fixed peer's certificate.

-- 
	Viktor.

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Sep 2015 21:32:01 -0400

On Sep 02, 2015, at 11:20, Julien ÉLIE <[email-masked]> wrote:

> When you speak about the UTA specifications, is it RFC 7525 "Recommendations for Secure Use of Transport Layer Security and Datagram Transport Layer Security"?
> I do not see other document published by the UTA WG that could otherwise apply.
> 
> Yet, NNTP still needs an RFC to specify the use of TLS because two specific NNTP response codes are defined for the STARTTLS command:
> 
> and the STARTTLS capability has to be standardized in response to the CAPABILITIES command -- which is a new command that did not exist when you wrote INN :-)
> 
> 

Julien,

I guess I’m not following why we need a new NNTP draft either.  If you’re looking or something that specifically updates the NNTP MTI cipher suites, then there isn’t such an RFC.  But, RFC 7525 (aka BCP 195) points to RFC 7465 that prohibits RFC4 (for all versions of TLS), so if an NNTP implementer is faithfully implementing TLS and related RFCs then they’ll end up supporting TLS 1.2 with one of the cipher suites in s4.2 of RFC 7525.

If you really, really want to have something that updates RFC 4642 (likely referring to BCP 195), then there’s nothing stopping you from writing that draft.  If you get no nibbles on said draft from the ietf-nntp list I’d try UTA (http://datatracker.ietf.org/wg/uta/charter/).  Note that said draft is out-of-scope for the TLS WG.  

spt

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 3 Sep 2015 10:47:56 +0200

Hi Viktor,

> certificates and mandatory TLS (as with IMAP and SUBMIT).

Yep, you're right.

> are willing to accept as issuers of the fixed peer's certificate.

Thanks again for having shared your thoughts.  We'll take them into 
account (if of course we update RFC 4642).

-- 
Julien ÉLIE

« Audaces fortuna iuvat. » (inspiré de Virgile, pour les chauves)

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 3 Sep 2015 11:31:41 +0200

Hi Sean,

> I guess I’m not following why we need a new NNTP draft either.

RFC 4642 (TLS with NNTP) states:

    In general, the security considerations of the TLS protocol [TLS] and
    any implemented extensions [TLS-EXT] are applicable here; only the
    most important are highlighted specifically below.
    [...]
    NNTP client and server implementations MUST implement the
    TLS_RSA_WITH_RC4_128_MD5 cipher suite [...] This is
    important, as it assures that any two compliant implementations can
    be configured to interoperate.

Along with latest RFCs about TLS, it becomes inconsistent.  No NNTP 
implementation can now be RFC-compliant to both NNTP specifications and 
TLS specifications as there are two incompatible MUST.

That's why I thought we need a new NNTP draft about the use of TLS.  (An 
erratum to RFC 4642 is normally not enough because it is a real change 
to the protocol.)

Isn't it a valid reason?
RFC 7465 that prohibits RC4 updates the 3 RFCs related to TLS 1.0, 1.1 
and 1.2.  It does not update RFC 4642 for NNTP.

> If
> you’re looking or something that specifically updates the NNTP MTI
> cipher suites, then there isn’t such an RFC.  But, RFC 7525 (aka BCP
> 195) points to RFC 7465 that prohibits RC4 (for all versions of
> TLS), so if an NNTP implementer is faithfully implementing TLS and
> related RFCs then they’ll end up supporting TLS 1.2 with one of the
> cipher suites in s4.2 of RFC 7525.

Yes, I understand.  A compliant NNTP implementation will support one of 
the mandatory cipher suites specified in TLS.  So interoperability will 
be guaranteed.

My concern is for the also mandatory RC4 cipher suite for a compliant 
NNTP implementation using TLS (per RFC 4642).  I do not see how to 
conciliate the wording of RFC 4642 with latest RFCs related to TLS.

Maybe I am misunderstanding something in how RFCs work.  Have latest 
RFCs related to TLS automatically taken precedence on the wording of RFC 
4642 without any update relationship between them?

> If you really, really want to have something that updates RFC 4642
> (likely referring to BCP 195), then there’s nothing stopping you from
> writing that draft.  If you get no nibbles on said draft from the
> ietf-nntp list I’d try UTA
> (http://datatracker.ietf.org/wg/uta/charter/).  Note that said draft
> is out-of-scope for the TLS WG.

OK, thanks for your advice.
I understand that an NNTP draft is out-of-scope of the TLS WG.  I asked 
in that WG because I thought an update relationship between RFC 4642 and 
the latest documents produced by the TLS WG would have been enough and 
more straight-forward to solve the wording incompatibility that RFC 7465 
introduced earlier this year.
I pretty well understand that the unfortunate reference to cipher suites 
in RFC 4642 was not known by the TLS WG; so nobody knew that it was time 
to do special care for it.  Neither do I myself followed the drafts and 
the last call of the prohibition of RC4.

That's why I wrote here to in fact ask what could now be done.  I 
thought it could be up to a Section of RFCs produced by the TLS WG that 
could update RFC 4642.  It finally appears that another way should be 
found:  either the NNTP or the UTA WG.

Do not hesitate to correct me if I am wrong in certain points.
And thanks again to all who answered,

-- 
Julien ÉLIE

---

From: Sean Turner <[email-masked]>
Date: Thu, 3 Sep 2015 20:58:42 -0400

On Sep 03, 2015, at 05:31, Julien ÉLIE <[email-masked]> wrote:

> Along with latest RFCs about TLS, it becomes inconsistent.  No NNTP implementation can now be RFC-compliant to both NNTP specifications and TLS specifications as there are two incompatible MUST.
> 
> That's why I thought we need a new NNTP draft about the use of TLS.  (An erratum to RFC 4642 is normally not enough because it is a real change to the protocol.)
> 
> 
> Isn't it a valid reason?
> RFC 7465 that prohibits RC4 updates the 3 RFCs related to TLS 1.0, 1.1 and 1.2.  It does not update RFC 4642 for NNTP.
> 
> 
> 
>> If
> Yes, I understand.  A compliant NNTP implementation will support one of the mandatory cipher suites specified in TLS.  So interoperability will be guaranteed.
> 
> My concern is for the also mandatory RC4 cipher suite for a compliant NNTP implementation using TLS (per RFC 4642).  I do not see how to conciliate the wording of RFC 4642 with latest RFCs related to TLS.
> 
> Maybe I am misunderstanding something in how RFCs work.  Have latest RFCs related to TLS automatically taken precedence on the wording of RFC 4642 without any update relationship between them?
> 
> 
> 
> I understand that an NNTP draft is out-of-scope of the TLS WG.  I asked in that WG because I thought an update relationship between RFC 4642 and the latest documents produced by the TLS WG would have been enough and more straight-forward to solve the wording incompatibility that RFC 7465 introduced earlier this year.
> I pretty well understand that the unfortunate reference to cipher suites in RFC 4642 was not known by the TLS WG; so nobody knew that it was time to do special care for it.  Neither do I myself followed the drafts and the last call of the prohibition of RC4.
> 
> That's why I wrote here to in fact ask what could now be done.  I thought it could be up to a Section of RFCs produced by the TLS WG that could update RFC 4642.  It finally appears that another way should be found:  either the NNTP or the UTA WG.
> 
> 

The easiest way to think about this is that the UTA WG was started to avoid having to write 10-50 drafts updating each RFC that specified an application’s use of TLS. They wrote one draft that ended up being a BCP that basically says that any implementer that is faithfully implementing TLS implement the algorithms specified in that BCP.  What might have tied this all up is an updates header in the BCP that listed every single RFC that is updated.  But, that header would be really long and kind of not necessary because I think that’s what a BCP is all about.

Also, I wouldn’t get too wrapped around the updates header because the meaning has changed over time.  At some points it has been used to point implementers at other related RFCs, but what I think the IESG has settled onto now (Stephen correct me if I’m wrong) is that the update header indicates that implementations of the updated RFC are expected to implement the update (note that expected is too strong of a word because implementing RFCs is purely voluntary - there’s no protocol police).

spt

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Sep 2015 12:57:09 +0100

Hiya,

On 04/09/15 01:58, Sean Turner wrote:
> Also, I wouldn’t get too wrapped around the updates header because
> the meaning has changed over time.  At some points it has been used
> to point implementers at other related RFCs, but what I think the
> IESG has settled onto now (Stephen correct me if I’m wrong) is that
> the update header indicates that implementations of the updated RFC
> are expected to implement the update (note that expected is too
> strong of a word because implementing RFCs is purely voluntary -
> there’s no protocol police).

Right. Though even that may change as IESG personnel change;-)

Anyway, yes the UTA BCP (BCP195. [1]) is almost certainly what
you'd reference when you next write an NTP RFC that mentions TLS.

I would guess that folks in the NTP wg would be the ones who'd
know whether writing a short RFC to make just that change is
worthwhile or not. So probably the next step is to ask that
question on the NTP wg list.

Cheers,
S.

[1] https://tools.ietf.org/html/bcp195

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Sep 2015 13:05:16 +0100

Oops - s/NTP/NNTP/g below:-)

And since there's no active NNTP wg, I guess asking on some
relevant list(s) is the thing to do. If folks there think that
a short RFC to just fix this is useful then feel free to
get back to me and we can figure how best to progress that.

Cheers,
S.

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 18 Sep 2015 20:33:19 +0200

Hi Stephen,

> get back to me and we can figure how best to progress that.

Many thanks for your kind proposal!
I will ask in the UTA list to have their opinion about what should be done.
Have a nice week-end,

-- 
Julien ÉLIE

« Petite annonce : Sourd rencontrerait sourde pour terrain
   d'entente. »

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 18 Sep 2015 20:34:39 +0200

Hi Sean,

> The easiest way to think about this is that the UTA WG was started to
> avoid having to write 10-50 drafts updating each RFC that specified
> an application’s use of TLS. They wrote one draft that ended up being
> a BCP that basically says that any implementer that is faithfully
> implementing TLS implement the algorithms specified in that BCP.
> What might have tied this all up is an updates header in the BCP that
> listed every single RFC that is updated.  But, that header would be
> really long and kind of not necessary because I think that’s what a
> BCP is all about.

OK, I understand.  Many thanks for your explanation.

-- 
Julien ÉLIE

« Quand on aime on ne compte pas… Ça tombe bien, je suis mauvaise
   en calcul ! »