Re: [Dime] Obsolete TLS wording in Diameter protocol

Julien ÉLIE <julien@trigofacile.com> Mon, 09 January 2017 21:14 UTC

Return-Path: <julien@trigofacile.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484EA12958A for <dime@ietfa.amsl.com>; Mon, 9 Jan 2017 13:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpXkNTcvYUVV for <dime@ietfa.amsl.com>; Mon, 9 Jan 2017 13:14:09 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D58129522 for <dime@ietf.org>; Mon, 9 Jan 2017 13:14:08 -0800 (PST)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d22 with ME id WME61u00117Lgi403ME6yK; Mon, 09 Jan 2017 22:14:06 +0100
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Mon, 09 Jan 2017 22:14:06 +0100
X-ME-IP: 92.170.5.52
To: "dime@ietf.org" <dime@ietf.org>
References: <3f911981-962e-3a60-9fa5-a20ee1bb30fa@trigofacile.com> <4987_1483973970_5873A552_4987_327_1_6B7134B31289DC4FAF731D844122B36E0BFDC80F@OPEXCLILM43.corporate.adroot.infra.ftgroup>
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <0f30c8a6-d039-c2b5-da88-909428ed9f57@trigofacile.com>
Date: Mon, 09 Jan 2017 22:14:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <4987_1483973970_5873A552_4987_327_1_6B7134B31289DC4FAF731D844122B36E0BFDC80F@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/0eV80FEKJEFqUIT62nYSqXlsBFM>
Subject: Re: [Dime] Obsolete TLS wording in Diameter protocol
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jan 2017 21:14:12 -0000

Hi Lionel,

First of all, thanks for your answer.


> The first point on cipher suites has been already raised. The
> prohibition of the use of the RC4-based cipher suites (RFC7465) came
> after the publication of the RFC6733. But the RFC7465 is anyway an
> update of the RFC5246 that is a normative reference in the RFC6733.
> So anyone implementing TLS should be aware of this update. There is
> no need of an errata report but it will be covered in a future
> update of the RFC6733 if any.

I agree that TLS implementations are now required to follow the 
requirement of RFC 7465 "TLS clients MUST NOT include RC4 cipher suites 
in the ClientHello message", so using TLS with Diameter nodes should 
normally be safe.

However, the consequence is that there is no longer any 
Diameter-compliant implementations with regards to nodes using TLS.  As 
a matter of fact, without updating RFC 6733 that requires that "diameter 
nodes MUST be able to negotiate the following TLS/TCP and DTLS/SCTP 
cipher suites: TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_RC4_128_SHA, 
TLS_RSA_WITH_3DES_EDE_CBC_SHA", that requirement can no longer be 
fulfilled.  So, unfortunately, RFC-compliance for Diameter 
implementations using TLS no longer exists!


As a side note, an erratum could be reported for the wording "the 
following TLS/TCP and DTLS/SCTP cipher suites" because RC4 does not 
exist for DTLS.  It is specific to TLS according to RFC 4347, Section 
4.1.2.2:  "The only stream cipher described in TLS 1.1 is RC4, which 
cannot be randomly accessed.  RC4 MUST NOT be used with DTLS."



> For the RFC6125, it should be first worthwhile to mention that the
> RFC6733 indicates that, for the time being, there is no Diameter
> server Certification Authorities. However, the RFC5280 is given as
> normative reference and this one is not superseded by RFC6125 so
> far.

The problem is that RFC 6733 references RFC 5280 only for the Extended 
Key Usage extension.  (And for the time being, there is no CA for 
authorization.)
But there are certificates for authentication and TLS negotiation.  It 
is required by RFC 6733.  See Section 13.1: "the Diameter node acting as 
the TLS/TCP and DTLS/SCTP server MUST request a certificate from the 
Diameter node acting as TLS/TCP and DTLS/SCTP client, and the Diameter 
node acting as the TLS/TCP and DTLS/SCTP client MUST be prepared to 
supply a certificate on request."
That's why I suggested that RFC 6733 could reference RFC 5280 (Section 
6) and RFC 6125 to make clear how to verify certificates.
That's what is for instance done in:
   https://tools.ietf.org/html/rfc7817



> At least, it is my current understanding. I hope that it clarifies
> your concerns.

Well, I am not under the impression that all these points are limpid in 
RFC 6733.  And for the first point about TLS, it means that there aren't 
any RFC-compliant Diameter implementations because a MUST is not 
fulfilled...

-- 
Julien ÉLIE

« Ambo florentes aetatibus, Arcades ambo » (Virgile, _Églogue VII_)