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

[Sean Turner <[e-mail]>]

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

> 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,

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